How to put heaps of devices on a cheap simple serial network

Hi, this is a description of a serial network I designed for my own home automation use back in 2009. I debated for some time whether to put it up on the net as it is nothing too original and it's quite low tech in this age of LAN and ethernet etc.

But it does have some advantages in that you can use many very cheap devices on a single data wire, and it uses standard serial and can work with cheap PICs with or without USART. Since this type of system doesn't seem to be discussed much I thought it was worth putting up on my web page just in case someone wants a low-tech reliable way to put a lot of cheap devices all communicating on a very simple serial wire.

**broken link removed**

https://www.romanblack.com/blacknet/blacknet.htm

The "round robin" system with incrementing wait periods was discussed many years ago on the PIClist (back in 2000?) but I might be the only person to actually build a working network with this system.

It combines a number of simple concepts working together like; multiple devices on one pull-up data line, devices taking turns, devices can be powered from the line, devices don't need to transmit (which allows large numbers of devices) and can be made with the lowest tech hardware like PIC 10F 12F 16F etc.

[FONT=Arial,Helvetica,Verdana,Geneva,sans-serif][SIZE=-1]It looks like it works, but the limitations are vast especially in practical applications and multi drop bus protocols aren't always that bad, even for the more advanced multitdrop buses it only takes a few support components to allow even a basic PIC to work with it, no more external components that are required by your bus.
[/SIZE][/FONT]

Thanks for the input Sceadwian.

I just made an update to that page as someone had asked me about a "minimum hardware" network;

**broken link removed**

This only requires one diode per PIC (or zero parts per PIC if using bit banged serial). Remember as devices are never required to transmit or receive, there is no time usage for devices that just listen on the bus so it still allows hundreds of listening devices, or even hundreds of transmitting devices provided they don't all need to transmit at once.

If you're bitbanging the serial, you only need a single IO pin - it's a low output to transmit '0' & a pulled-up input otherwise.

how do the devices identify themselves? i suppose the communication protocol is flexible, and half dux.

Dougy- good point, I drew it showing 2 pins for clarity of separation as some devices may be receive only or transmit only.

Unclejed613- The devices are not required to identify themselves. Receivers have no need to identify themselves and transmit devices wait an appropriate time before transmitting (so they don't talk over each other). Their device number could be decoded from that wait time, or if it is important for transmitting devices to identify themselves then it's trivial to get them to send their device number as part of their transmitted data packet.

Half duplex is probably an accurate description as only one device can transmit at one time and all others can be receiving at that time.

There was a project on the net, I 'think' it was called PICNet - but unfortunately the site disappeared a few years ago. It covered a PIC based network around a house, originally using serial, and I think later on it did USB as well?.

I wished I'd saved it

RB,
Can u give a text sequence as to how 3 devices would work on this bus?

I am looking at designing an irrigation & motion sensing system for farmers and each sensor pack could be made intelligent and reduce the wiring!.

Using a single pin for bit-banged serial I/O on a 1 pin bus is easy. I've been doing it awhile using the Icom CI-V open-collector or open-drain 1 pin bus protocol. The diagram below is from a 2007 post using 2 I/O pins but I have used a single pin in a a couple antenna controller projects.

Cheerful regards, Mike

Nigel- There's still some google links to Open PIC net but the page seems to be gone...

Mosaic- I thought my web page already described it pretty well.

Here is the simple version (if you need to have all 3 devices talking in every cycle);
1. device1 transmits it's data packet (only device 1 is allowed to initiate the cycle)
2. then, after a "bus free" period of 2T, device 2 transmits its data packet
3. after a "bus free" period of 3T, device 3 transmits its data packet
4. eventually device 1 transmits again and initiates the cycle again (say every second?)

MikeK8LH- Agreed, that's the same hardware which is pretty much as simple as it gets. I'm more interested in the protocols, especially collision avoidance. How did you stop the multiple devices talking over each other?

Mr RB said:

Nigel- There's still some google links to Open PIC net but the page seems to be gone...

Click to expand...

Yes I know, the page went a number of years ago

If I had an email address for the author, I'd ask him if he wanted me to host it for him.

Nigel Goodwin said:

Yes I know, the page went a number of years ago

If I had an email address for the author, I'd ask him if he wanted me to host it for him.

Click to expand...

There's always the Wayback Machine:
Internet Archive Wayback Machine

Don't know how long ago Open PIC net disappeared, but if there is a URL in a broken link, there's a chance you can view the site.
Some time ago, I was looking for a circuit which was from http://www.cpemma.co.uk but the site has since disappeared.

I found what I wanted using the above.

EDIT:
Yay! It works.....but some content is missing - images etc. but some of the source is still there if you click to download.
http://replay.web.archive.org/20040514090109/http://www.viewing.ltd.uk/OpenPicNet/index.htm


EDIT2: EEEK - Post #666 :-(

Thanks for that - I always forget about the Wayback Machine

However, it has showed me that it's not the site I was thinking of, it was different to that one.

RB:

For an auto ID system, how about this:
1) The master regularly xmits a query & new ID for an as yet unassigned device to respond to, and waits a short time.
2) Any new devices wait a short random time to respond, then responds with it's (master supplied) ID & data byte.
3) Other new devices which have not yet responded wait for the next Master query & ID.
4) After each query cycle the MAster updates it's device database and adds the new ID to be queried.
5) Then the Master runs a token ring query system to poll the established devices for data.

Hmm, that's not a bad system and thanks for the input! But there is one issue; If the master (device1) transmits then the other transmitting devices will transmit after it (as usual). So the "short time" would have to be longer than the T period needed for the last device (it would be after all the other devices).

How about this minor change;
1. When device1 initiates a normal cycle it sends (as part of its normal data packet) the next available device number.
2. A new device on the net would accept that number and reply (transmit) back at the normal time for that device number to acknowlege.

However as you know that would rely on only one new device being connected at one time...

Your random (extra) delay is a good idea to allow one new device to grab the slot before another but still has a chance of collision if 2 new devices both happen to be connected at one time and choose the same random number. I wonder if there is a way to remove that chance altogether?