Go Down

Topic: Bus network, multiplexing signals to (theoretically) infinite arduinos (Read 4817 times) previous topic - next topic

CrossRoads

#15
Oct 24, 2011, 07:58 am Last Edit: Oct 24, 2011, 08:04 am by CrossRoads Reason: 1
@manutenfruits,
Do  you have access to elektor magazine?
www.elektor.com
In the 2011 Jan-Feb-Mer-Apr-May-Aug-Sep-issues, and I guess the rest of the year, they have had an on going article about doing just what you are asking.
What transceivers, designing a protocol, some standalone devices to put at the various ends, etc., and it is based on ATMega88, which is in the ATMega328 family.  The October issue is supposed to go into the C coding to  implement the protocol. Before that they used BASCOM, which looks to me like Basic with some C, or not too difficult to turn into Arduino C.

The magazine articles are available online as well, and published in Spanish  as well.
www.elektor.com, look for "Here comes the Bus!"

Oh - looks like Nov is out already!  I'm still on the September article.
http://www.elektor.com/magazines/2011/november/here-comes-the-bus!-(9).1971982.lynkx?tab=4
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

nickgammon

What you are proposing sounds reasonable. I haven't tried RS485 myself, but if I were you I would get a couple of those chips and see if they work for the longest run OK. Otherwise the suggestion of having some sort of relay per floor might be required.

As for protocol, some sort of address/command structure (eg, node 5, turn on the light) sounds pretty good. To allow for line glitches you might append a sumcheck  (CRC) and have the receivers discard any command that doesn't have the correct sumcheck.

You could probably poll all devices pretty fast (eg. node 42, is the doorbell pressed?) to be reasonably responsive.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

graynomad

Quote
is the doorbell pressed?

Yes, you have to be pretty fast for anything a human wants to do, maybe < 100mS from event to action. It's very disconcerting to flick a switch and have a delay before a light comes on.

OTOH who cares about knowing the hot water system's temperature in fast time? Every minute or so is good for that.

In a polled system one way around this issue is to have 2 or even 3 polling schedules with urgent stuff polled frequently, medium stuff every minute or so and maybe other stuff every 10 minutes or even an hour.

This is actually one argument for multi-master as data is event-driven and sent straight away when something happens while non-critical stuff doesn't clog up the bandwidth with unnecessary polls.

Another issue with polling is event stretching, a person can easily press and release a button before the node is polled so the node has to remember the press until it is polled.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

nickgammon


Another issue with polling is event stretching, a person can easily press and release a button before the node is polled so the node has to remember the press until it is polled.


The node could debounce, and indeed could remember a sequence of keypresses.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

manutenfruits

Well, I am thinking about another scenario where I like to have event triggers on the master node. This will allow me to know what lights are turned on or off instantly, if someone just presses the switch.

But that supposes a whole lot of extra trouble, right? Although packets are sent in no time, there is a slight chance that if you press two switches at the same time the whole thing goes boom. Can I build any kind of carrier-sense network, so that the nodes only use the network if it's free? Any guidelines on this?

nickgammon

I wouldn't say packets are sent in no time, I think that would violate various laws of physics, and you would be hearing from Einstein.

Assuming you use serial comms, and you choose 115200 as the baud rate, then each byte will be sent at 1/11520 of a second, which is around 87 microseconds (uS).

Let's assume you have some sort of protocol of packet start/command/length/data/sumcheck/packet end, so a packet might be (say) 10 bytes. Now it would take 870 uS or just under a millisecond to send a packet. Now if you have one device per room, and say 20 rooms, then you could poll the lot in around 18 mS, plus say another 18 mS to get the replies. So add in a fudge factor to allow for the devices to "think" and you might poll and get a response from all in 50 mS.

Now compare this to human reaction time. I have read, I think, that you can't react much faster than 1/7 of a second to stimuli (that is, 143 mS). And movies are screened at around 25 frames per second because your persistence of vision kicks in at about that rate. That is 40 mS.

So my point basically is that at this rate, you would get reasonable responsiveness. In fact the time you allow to debounce switches would probably exceed the time it takes to poll every device.

I must admit you are giving me ideas here. I have my rooms wired up with Cat5 cable, some of which is not in use, so it would be interesting to test this scenario, and see what sort of cable run lengths work reliably.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

manutenfruits

#21
Oct 24, 2011, 10:37 pm Last Edit: Oct 24, 2011, 10:47 pm by manutenfruits Reason: 1

I wouldn't say packets are sent in no time, I think that would violate various laws of physics, and you would be hearing from Einstein.


Well, English is not my first language, I meant that they are sent as you say in 18ms, and then to have a collision you will need to trigger another message in that 18ms time (not likely to happen very often, but still possible).

My idea was to make the slaves update the master (plus a periodical recheck from the master to keep coherence. Let's say that I've left the house but then someone breaks in, or a fire starts in the basement. Obviously I could be polling all slaves whenever I'm surfing through the interface, or poll them every minute or 10 seconds. It's just that I don't want to have the master running checks every X time.

graynomad

#22
Oct 25, 2011, 01:32 am Last Edit: Oct 25, 2011, 04:23 pm by Graynomad Reason: 1
Quote
Can I build any kind of carrier-sense network, so that the nodes only use the network if it's free? Any guidelines on this?

The best way I can think of to do carrier sense is to time the edges on the data stream. If a certain period goes by without an edge (say 16 bit times) then the line is idle and you can go for it.

The trouble is that X nodes may all do the same thing at roughly the same time which means you then have to detect bush clashes and synchronize the data steams.

Two ways to do this, bitwise or bytewise clash detecting.

With bitwise you have to monitor every bit and detect the state where you are putting out a 1 and the network shows a 0. When you see this you kill the transmission. This allows non-destructive detection, meaning that all nodes that detect a clash back off and there will be one node left that doesn't know what happened. This node's frames is transmitted unaffected so the bandwidth is not wasted. All the other nodes have to retry, usually after a random period.

This method requires very precise timing and some method of synchronizing the bits to to remove race conditions. Not easy. I designed a protocol that did just this (never built it mind you) and I dedicated a processor with tight assembly language code just for the clash detecting.

Personally I don't think this is practical on an Arduino with code written in C and with other things to do.

So then there's bytewise clash detection. In this case you transmit at will and read back the characters from the bus. If that doesn't == what you sent you back off and try again after a random period. This is fairly simple to implement but all transmitting nodes will lose their frame so bandwidth is lost. That's probably not an issue with your network. You do still have the potential for data corruption if two transmitters out of phase as this shortens all the 1 bits which may cause a bad read on another node. Your protocol has to handle that with a CRC or other error detection method(s).

Using either method you have to have line drivers that tri-state for a high bit and drive a low bit. This can be done with RS485 if you wire the transceiver in a slightly different manner to the norm.

It has to be said though that this adds a layer of complexity to the project, you have to decide if it's worth the effort. I think a polling system with high and low priority polling schedules would have the same overall affect and be simpler to implement. It will however create a lot of network traffic.

Another method that combines both polling and "interrupting" nodes.
The master polls all nodes as we've been talking about but with no priority, just a round-robin scheduler. The frame format of course includes a node address. A node that has something urgent to say overrides this address byte with 0. This is detected by the master who immediately terminates the transmission of the polling frame. The next byte to appear on the bus is the interrupting node's address provided by said interrupting node.

The master reads this then polls the interrupting node.

This method also requires bus clash detecting and some fancy timing.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Go Up