Which boards to use for multy drop sensor network?

Projects General Guidance
1

I am new to Arduino, although not programming, and would appreciate some advice.

I have a Mega2560 and display for my HMI and want to add several 'functional nodes' for want of a better description.
I need to make a sensible decision about which board to use for the nodes.

Nodes will have different functions but for example I will want one with several PWM outputs, to regulate charge current for different solar panels.
It would be handy if it also measured battery voltage and temperature
That would be 4 digital outputs and 2 analogue inputs.

Another one will need to handle my generator, temp fuel, speed .....
The actual functionality isn't all that important in the greater scheme of things, if space or scan time are tight I will simply split the functionality over a few units.

However communication's are less simple.
I need a multi-drop, multi-master serial network.
Devices will need to broadcast information, for any other device to listen to and then utilise, as well as being able to respond to specifically addressed commands.
Obviously the serial protocol will need to handle multiple devices competing for a single bus, RS485 esque, and I would rather not have to muck about with handshaking lines if possible.

The network will need to have a star/spur structure and legs as long as 100m
I don't know much about protocol specifics, other than RS232 which will not work anyway, and even less about implementing them within the Arduino IDE.

I would be very interested in your thoughts RE specific devices and how I might go about creating the required network,

Al

2

First find out the cost of cabling required and compare that against the cost of some RF modules like Xbees - that might help decide which route to go down.

For wired comms the physical layer would need to be something like RS485 to get reliable 100m - differential signalling is reassuringly robust - that would suggest using CAT5 cable for cheapness (though its not rated for outdoors I believe).

3

Sorry I'v been out all day ...
Yes 485 or at least 485 esque is what I thought.
I don't want to go wireless the cost of TX units will far exceed the cabling cost using cat5 as all runs are in existing conduits.

What I don't know is how 485 works either the protocol or the physical layer.
My data rates will be very small, a byte from a node every few seconds would probably be overkill.
There are things that need to happen quickly, modifying throttle position to compensate fro a reduction in generator frequency for example but that can be handled locally in the node, all the coms will have to do is tell the local logic if it should be generating or not, and report status to the HMI.

I suppose what I am asking is do I start from scratch, design a protocol and then build a library to bit bang it, which I think is entirely plausible I might add, or is there some quick win, already implemented on 'standard' hardware that will do what I need.

Should I buy 'Nano' Mini or MinoPro?
If I am bit banging I guess it doesn't matter but I would be interested to know if any of those might simplify my coms implementation.

OK I get that if the project was the coms I should perhaps spend several months researching and testing but the project is the distributed logic network.
In the same way that I am buying Arduino boards and displays, so I can concentrate on the functionality not the electronics, I would like to find a quick win for my coms requirements.

If there isn't a fit then I will build a protocol, design a library to implement it and then publish but I cant help thinking that clever folk than me will have done all that already and I simply haven't found, or perhaps recognised, it yet.

Feel free to point out my failings ... it how I learn
Thanks
Al

4

485 is just a physical layer - protocol is up to you - also lots of driver chips available, dual and quad packages too. Its fairly power hungry though using full-swing differential signals into 100 ohm loads, a LVDS chipset would improve on that markedly.

For low signalling speeds serial is still attractive, but long runs could introduce problems with mismatched grounds. If you low-pass filter and then schmitt-trigger you can clean up a lot of noise pick up if only needing low baud rates.

5

low-pass filter and then schmitt-trigger ...
Yes that was the thought process but although I have a protocol in mind, of my own design, I cant help thinking that far cleverer folk than me must have solved this problem before.

multi-master networks seem thin on the ground.

What I am getting at is that my nodes will only need to send data when it is pertinent, changed, and perhaps a copy every minute or so to declare that they are alive.
I am thinking half duplex, differential line.

I didn't realise that 485 is just a physical, that sort of explains why I cant find much info that looks definitive or useful.
My protocol idea is relatively simple .... would you be up for discussing it?
I cant decide if going bespoke is a good plan or not.

Al

6

Sounds like you are wanting a lightweight networking protocol, using the physical layer as an ether (in the original sense of ethernet!). So some sort of collision-detection or retry mechanism is needed. Just make sure the physical layer can handle collisions without damage.

You might want to look at some of the simple packet schemes used in RF transceiver modules such as the nRF24L01+ - you then have a framework that could be easily switched from wired to wireless. There are no doubt a handful of relevant open-source networking protocols to look at that could be suitable. Have a look through the forum archives esp. the networking/protocol/devices forum I guess.

7

Multi-master and multi-drop == collision detection which can be a problem, but if you have low speeds and infrequent transmissions it won't be that hard.

FWIW myself and another bloke are working on a sensor network that will I think do exactly what you want. It's not multi-drop (redundant ring) but is multi-master. It won't be ready next week :slight_smile: but if you're interested email me. The scheme we are working on should allow a combination or wired/wireless as well, the idea being that it is essentially a wired network but you can have sub-networks connected wirelessly if there's a difficult place to get wires to.

It may be good to have 1-2 more people on the "team", anyone interested please email me as well.

Rob

8

Mmmmm, interesting.

I'v been digging and I think I want something like CAN-BUS.

The collision problem is addressed with message priority, which in my case would increment with resends, and devices are not addressed but listen for pertinent data as defined in the packet header.
Essentially everything is clear to send when the bus has been idle for some time.
Any device with data to send will do so simultaneously, whilst monitoring its own progress.
1n's always superseded 0'z and the first byte of the message is always the message priority.
If a talking device sees a 1 on the bus when it intended to send a 0 then it will assume that it has been talked over bay a higher priority message and stops sending, increment its message priority and weight for the next slot.
This bit checking continues for the entire packet which will prevent massages with the same priority but differing data form conflicting.

If anyone is aware of a software implementation of this kind of protocol for Arduino I would be most grateful for a pointer.
Failing that I think I will probably start with SoiftSerial, for the interrupt structure and work from there.

I suspect this will be harder than I am currently giving it credit for.
Al

9

If a talking device sees a 1 on the bus when it intended to send a 0 then it will assume that it has been talked over bay a higher priority message

Normally it's the other way around with the 0 being dominant, but that's up to your hardware.

Any device with data to send will do so simultaneously,

There will be race conditions where two or more nodes test and send at the same time, the more nodes you have the more this is likely to occur. This should be trapped by testing for bit clashes though.

Your code will have to be very tightly written (depending on the bit rate you plan) as you can get phase errors that will not be detected by the transmitting nodes but still corrupt the waveform, possibly enough to cause a problem with the receiving node's reading of the data.

I'm probably being paranoid and I haven't tested this but to me it's always seemed to be a week link with such schemes. Someone else may know more about this.

everything is clear to send when the bus has been idle for some time.

Sounds reasonable and the only way I know to sync with a true binary waveform.

I suspect this will be harder than I am currently giving it credit for.

Probably :slight_smile:

Rob

10

Hey Rob,

Glad to see you are progressing.

I'd be interested in testing the RS485 dongle approach.. Let me know how I can help...

Regards, Terry

11

I have never heard of "race conditions", Google me thinks, however I know enough to be concerned about stray reactence, l and c, and propagation times.

To be honest I don't need fast and will be actively seeking solutions that are simple to implement, hardware and software, by virtue of the fact that they are slow, relatively speaking I mean.

I am essentially talking squirt and prey with everything being a global broadcast, if I need ACC functionality of some specific chunk of important data then I will make that a logical function of the control system as opposed to a function of the protocol.

This is all new to me and I appreciate the insight, thanks. I am rather pleased that you didn't say I was just talking rubbish, it was and is a distinct possibility given my lack of basic knowledge at this point.

I had envisaged a network power source that pulled both differential lines high which means that the devices will only ever pull low, avoiding the scenario that multiple devices are pulling a line high with a single device attempting to pull it, and therefore all of them, low.
That way the maximum current a device will have to sink will not increase with node count.

I would be interested in your thoughts RE implementing CAN-BUS as is or designing a simplified version from scratch.

Thanks
Al

12

Hi Terry, yep things are progressing slowly. I keep being distracted by other stuff but I now have a partner in crime (a bloke in NY state) who is backing the hardware manufacturing so that's keeping me focussed.

The first "product" is a Leonardo-compatible board with the RS-485 networking built in (LPC co-processor) and provision for IO modules to be plugged in. After that we have ideas for about 20 IO modules to get the ball rolling.

The Arduino dongle interface is still current but on the back burner for the moment, it will have to be done before long as well I suppose to allow standard Arduinos to connect to the network.

What I could use right now is someone else to look at the schematics and find the bugs or suggest better ways to do things, there is also a rudimentary document describing the system that you may be interested in. I would certainly like to have 1-2 more people involved if possible.

If you want to look at the docs let me know (PM/email/here) and I'll send them.

@Al

I am rather pleased that you didn't say I was just talking rubbish

No, I think you are on the right track and in fact what you propose is very similar to one of my earlier (never implemented) designs.

I am essentially talking squirt and prey with everything being a global broadcast, if I need ACC functionality of some specific chunk of important data then I will make that a logical function of the control system as opposed to a function of the protocol.

I think that's reasonable.

I had envisaged a network power source that pulled both differential lines high which means that the devices will only ever pull low,

Yep, if you apply normal "fail safe" biasing to an RS-485 line you will get it to idle high with no enabled drivers. What you then have to do is wire the transmitters in a slightly unconventional manner. An inverted version of your data goes to TE and the transmitter input is hardwired to GND. That way when you are transmitting a 1 the transmitter is disabled and the biasing pulls the line high, when you transmit a 0 the transmitter is enabled and it transmits the hardwired low.

You cannot get full speed like this but it doesn't sound like you need that.

I would be interested in your thoughts RE implementing CAN-BUS as is or designing a simplified version from scratch.

To be honest it's probably better to just use CAN chips, but CAN has a limited range (40m/130' IIRC) and anyway I'm a DIY kind of guy :slight_smile: As you can probably tell I prefer to design stuff myself, not the most efficient way I suppose but you learn a lot more. So as long as this isn't for a commercial product with a tight deadline I'd go for it.

Rob

13

Interesting ...
But wouldn't I have an issue with a null state, given that I want to implement dominant bits.
If both lines are high when null then the following would be true, wouldn't it?

State D1 D2
NULL - H H
1 - H L
0 - L H
Error - L L

If two devices are in contention over a bit it is easily detected but the data is destroyed in the process, all be it with the devices able to determine which should have had priority.

Please correct me if I am wrong but the options are:-

Bias the network to HI/LO which gives a default of 1 0r 0 depending on how you interpret it, I will assume its a 1.
Not ideal because you don't know a bit has been sent unless its a 0.
Allows dominant bits, 0's to talk over 1's so collisions can be detected, and a device quieted, without loosing data. Messages do not need to be resent.

Bias the network to HI/HI which gives a default of null
All data is positively identified, including errors - Error bit sent
When a collision is detected the data must be resent from scratch.

The only other options I can think of involve timing ...

  1. Split the bit into phases, 'error check' and 'valid data'.
    This would allow a device attempting to send a recessive bit to identify the error and release the lines before other devices on the bus read the data.

  2. Bias the bus LO/HI and have only two valid states [LO/HI > NO Data | HI/LO > Data]
    The time between a No-Data>Data transition and a Data>No-Data transition would indicate 1 or 0
    Since any device could hold the bus in a 'Data' state the longer of the two pulses would naturally be dominant

Detecting errors with LO/LO and resending if necessary seems the simplest option to me and unless the network was crazy busy the overhead doesn't seem that bad, I was only planning to use one byte for message priority which means a conflicted message would almost always be ditched within the first 8 bit

I would like to try and do this, first experiments anyway, directly with the 5v digital pins.
I think initial experiments should concentrate on sending and receiving bits, which I suppose I need to think of a tri-state 1,0,Err

I would be most interested in your thoughts before I dig in ...

Al

14

If both lines are high when null then the following would be true, wouldn't it?

Assuming you're talking about the A and B line, they should never both be high as I'm sure that will be an undefined state on the line.

TBH I can't follow all the HI/LO/LO/HI stuff (well I'm sure I could but life's to short :)), all the talk about the actual RS-485 signal lines is really confusing the issue, until you have electrical problems the two signal levels are immaterial, it's the Txd and Rxd data signals on your UART that count.

Failsafe biasing ensures that when the line is not being driven the logic level presented on the RO pin and therefore to the Rxd pin is HIGH. The biasing is usually a ~560R resistor from A to VCC and another from B to GND. This is such a standard that in fact it's often built into the transceiver chips and I suspect applying resistors in any other combination (except adding the normal 120R terminator if required) may cause problems.

Have a look at Nick's tutorial here

So FS biasing ensures that an idle line is high but has no affect when the line is being driven high, that requires different wiring of the transceiver.

Now the bog-standard-used-by-every-man-and-his-dog method of doing this sort of thing has the line being driven low (assertive level) and let go to hi-z for a high (recessive level). This can be done many ways, open-collector, open-drain, tri-state buffers etc but if you want to use RS-485 you have to get a bit clever and wire the transmitter as I mentioned above.

If done properly such a system is non-destructive so you don't lose any data if there's a clash.

Which brings us to the "done properly" part.

  1. Split the bit into phases, 'error check' and 'valid data'.
    This would allow a device attempting to send a recessive bit to identify the error and release the lines before other devices on the bus read the data.

That's essentially correct, receivers typically read the bit at the 50% point but as long as you use a non-destructive scheme I don't think that matters as long as the overridden transmitter releases the line before the next bit starts.

So the code has to be very tight relative to the bit rate. In other words if it takes you 150uS to detect the clash and the bit time is 100uS then you will corrupt the data. Depending on your bit rate this normally means no long-winded function calls, probably putting all the transmit code in a single function.

What bit rate do you have in mind?

I would like to try and do this, first experiments anyway, directly with the 5v digital pins.

So you transmit an active low but for highs you make the Tx pin an input to tri-state it.

Rob