Go Down

Topic: Looking for a simple daisy-chained communication (Read 1 time) previous topic - next topic

oneAU

Hi,

I'm currently using a KNX bus (EIB/Instabus) system for parts of my home automation.
Now I would like to create my own sensors. Preferably on that KNX bus but the interface modules are far too expensive and seem to have an ungenerous limit of 50mA 5V power supply per node.
So I'm trying to find a daisy-chained DIY bus system with parallel power or power line communication.
I Have been trying to find out if PoE can be daisy-chained but it doesn't seem to support that?
And 230VAC PLC is too risky. Bulky components that will get hot and could cause fire in the walls.

What I need is a wire communication that can be at least 25 meters long, support at least 100mA per node and support at least 3-4 nodes per wire.
The speed can be quite low since it's only sensor data, no streaming, that will be transferred.
Any suggestions?

mikb55

KNX runs over twisted pair.
Use Cat5 cable and use the unused conductors for power.

Are you asking for a freeware implementation of the KNX protocol that runs on Arduino without requiring the proprietary interface chip?

Without delving deeply into the documentation I'm guessing (I could be wrong)  that that this is derived from, or is similar to CANbus or USB.  Implementing a complex protocol may consume too much memory for a small memory micro, hence the need for a dedicated chip.

If you want an Arduino (plus RS485 driver) only solution then use MODBUS or something similar.

oneAU

I realize that my question was a bit too broad. To keep it short I'm looking for three characteristics:
1. A minimum 25 meter topology that is as free as KNX i.e. not only daisy chained but also allows for long stubs or "branches".
2. Keep the number of wires as low as possible.
3. Power wires that will be routed in parallel with the communication wire(s). I don't like batteries :D

I've been reading about the RS485 and is tempted to use that protocol with the MAX485 chip. But as far as I know, you can't have branches on a RS485 daisy chained wire. That is a huge drawback for me. But I can live with it if there are no other simple and cheap alternatives.

mikb55

RS485 drivers cannot tolerate the 24v used by KNX so you'll need a separate cable.

RS485 needs 3 wires for a reliable connection (A + B + ground). You'll need a fourth for power distribution. Cat5 is cheap and you can use the spare conductors for power or troubleshooting purposes.

Most documentation on the web assumes that you're running at high speed hence the dire warnings about branches.
The allowable length of branches is inversely proportional to the data rate. At 300 baud you could probably run the whole house as a series of branches, in other words a star configuration. You'll need to do the experiment yourself to verify that it works well enough for your purposes.


oneAU

Super thanks for telling me about the branch<->speed relation.
I have read a couple of pages hinting about this but it was very vague.
300 baud is indeed very slow, too slow for this application. (simple sensor data)
But tests will be needed both for speed and to find out whether or not I need a resistor at the end of each branch.
Already ordered a couple of MAX485.

Running an RS-protocol on the same wires as KNX was never my intention. I could use the two spare wires in the KNX four wire cable but that would be really stupid and probably illegal.
My intention was to be able route the RS-485 cable + a 12 VDC through the same tubes that was originally installed for KNX topology.

Cheers!

mikb55

Super thanks for telling me about the branch<->speed relation.
I have read a couple of pages hinting about this but it was very vague.
The companies that make RS485 drivers have application guides that typically talk about speeds down to 50 kbits/s.  Anything below that isn't worth mentioning because the correctness of the wiring becomes increasingly less important.

KNX, whilst not RS485, runs at a pedestrian 9.6 kbit/s and that speed is considered fast enough to support an entire office building.

At the super slow 300 bit/s you can still send a 16 byte packet in a fraction of a second which is probably good enough if you only need a motion sensor to switch on a light.

Right now I'm running 19.2 kbits/s RS485 point to point (no branches) over "alarm cable", that's the non-twisted pair, non-shielded cable designed for hooking up motion sensors to an alarm panel. It works great. According to the RS485 standard I should be using shielded twisted pair.


musskopf

Give a go with Can Bus... Very simple and cheap to implement. Also very resilient for interference.

One good advantage over RS 485 is that it implements not only the physical layer but also the data link layer, offering retry, crc and frame format out-of-the-box.
http://talk2.wisen.com.au

mikb55

Give a go with Can Bus... Very simple and cheap to implement. Also very resilient for interference.

One good advantage over RS 485 is that it implements not only the physical layer but also the data link layer, offering retry, crc and frame format out-of-the-box.
In terms of hardware cost, RS485 only need a single line driver chip whereas CAN bus needs a line driver and interface chip.

I see CAN bus boards on Ebay for $3 including shipping. Assuming the chips are genuine, this is a tiny fraction of the price that Sparkfun and Seedstudio are charging. Not sure what's going on there.

I suppose it depends on how much time you are prepared to spend looking at things on an oscilloscope, or whether you just need a relatively simple way of connecting devices. If you do your own data link layer, you can literally spend weeks (I did) looking at packet structures, byte stuffing algorithms, checksums and handshaking.

Timing on a half duplex RS485 link is critical. As Nick Gammon talks about in his RS485 notes, when transmitting you have to add hard coded delays so that all the bits have had a chance to leave the Tx UART before you put the RS485 driver into receive mode and the receiving device must delay sending a reply for a few microseconds to give the first device time to release the bus and switch into receive mode. None of the manufacturers application notes I've seen talk about this stuff. It's very easy to create something that works OK on the bench works but is on the edge timing wise so has problems when you deploy in the field.

After many weeks I ended up with something that is very reliable, reasonably efficient, but not very flexible. I've learnt a lot along the way, but knowing what I know now I would've spent the time to investigate an off the shelf solution like Modbus even though it is very primitive in a 1970s kind of way.

As for future projects, after I found the cheap CAN bus adaptors on ebay I saw this video about CAN bus sniffing on Linux  https://www.youtube.com/watch?v=oHqDLWN3a_w
so I'm now waiting for a USB2CAN adaptor and bunch of MCP2515 adaptors to arrive.

musskopf

$3 to $4 is correct, the controller costs a bit over $1.2 and the transceiver around $0.5... many MCUs also have CAN peripheral built in, so only a transceiver is needed.
http://talk2.wisen.com.au

oneAU

Sorry for the late reply. I have not been able to fiddle with any Arduino project during the last week.
I'm trying to compare CAN with RS485
One disadvantage with CAN seems to be a very short stub tolerance. 0.3 meters to be exact.
http://digital.ni.com/public.nsf/allkb/D5DD09186EBBFA128625795A000FC025
That is far from the "several meters" stubs that I would like to have.
I could use two CAN modules on each Arduino node that is connected to the bus and make sure that each node could act as a router. But the drawback here is that a single CAN module is at least five times more expensive than a MAX485 module. So that would make the bus communication part of each Arduino node 10-15 times more expensive.
What is the cable requirements for a CAN bus?

musskopf

Hello oneAU, the CAN is designed to be a daisy-chain, not a star topology. If you have a node far away you need to make your daisy-chain go there, connect to the node and get back to the next node, no need for a long stub. Saying that I had successfully used stubs just over one meter from the daisy-chain on a small (few nodes) network. RS-485 is also best implemented in a proper daisy-chain and not star or long stubs AFIK.

I did not understand why you would need 2 CAN Bus on each Arduino node. You only would need data in case you have two CAN networks and wish to router traffic from one to another. Could add a diagram of your project/plan?

For the pricing, it costs less than AUD $3, which is close to USD $2 (http://www.ebay.com.au/itm/High-Quality-MCP2515-CAN-Bus-Module-TJA1050-Receiver-SPI-Module-for-Arduino-/191735507499). You might find a RS-485 for USD $1, so it might become a difference only if you plan to deploy more than 50 nodes... and still remember that RS-485 only implements the physical layer, you going to need to "frame" your messages (http://www.gammon.com.au/forum/?id=11428), where CAN bus does that for you.

For the cable, you can run CAN Bus on CAT-5e.
http://talk2.wisen.com.au

mikb55

#11
Dec 14, 2016, 03:27 am Last Edit: Dec 14, 2016, 03:31 am by mikb55
One disadvantage with CAN seems to be a very short stub tolerance. 0.3 meters to be exact.
http://digital.ni.com/public.nsf/allkb/D5DD09186EBBFA128625795A000FC025
0.3 meters at 1 Mbps is correct, however in the absence of data for the other data rates the author has lazily copied the same number to the other rows in the table. Either poor journalism or the author didn't understand what they were writing about.

Generally speaking the length numbers are inversely proportional to the data rate.

See http://www.ti.com/lit/an/slla270/slla270.pdf

"When critical length is taken into consideration, driver slew-rate control becomes a valuable design asset.
The Standard recommends a maximum un-terminated stub length of 0.3 m with a 1 Mbps signaling rate,
but with slew rate control, reduced signaling rate, and careful design, longer stub lengths are easily
obtained.
For example, if a 10 kΩ resistor is applied for slope-control at the Rs pin (pin 8 ) of the HVD230 CAN
transceiver, a 160 ns driver transition time increases the maximum stub length to 16/3 m or 5 1/3 meters"

Electrically the CAN bus drivers are similar to RS485 drivers so you would expect to see similar numbers.

oneAU

I did not understand why you would need 2 CAN Bus on each Arduino node. You only would need data in case you have two CAN networks and wish to router traffic from one to another.
Yes. I was thinking of each branch (long stub) as a separate sub-bus that would be routed from/to the main bus by the Arduino node. Of course, I wouldn't need such router functionality on each Arduino node. Only on those that are placed at the begin of a branch.

and still remember that RS-485 only implements the physical layer, you going to need to "frame" your messages (http://www.gammon.com.au/forum/?id=11428), where CAN bus does that for you.
That's exactly why I will look into the CAN bus alternative as well. Already ordered a couple of modules so that I can compare pros and cons of the two buses.

Go Up