2
\$\begingroup\$

We are trying to develop a wired sensing network that will have up to 200 sensors attached to it, spread over what could be 100 m. There will be one main controller that uploads each sensor's information to the cloud software. This is because there is no Internet connection. Thus, we are forced into using a 4G mobile data system.

I currently have a 24 sensor network setup with a Raspberry Pi, but it uses I²C as the communication method (GASP, I know) and so is definitely not scalable in any way shape or form.

My question is around what would be the industry recommended protocol for communicating between the sensors and the main controller. Ideally, the main controller will not be required to poll all of the sensors to check if they have more data, but rather each node would push this data to the main controller. My current thoughts are leaning towards CAN. However, would this decision be future-proof?

I am going to give a brief overview of why I was thinking CAN. If you could please correct any of my misconceptions, or add more information it would be much appreciated. I also will add my thoughts on using other wired/wireless networks and why I don't think they will work:.

CAN

  • Built-in collision detection
  • Multi-master built in
  • ISO protocol
  • Fast (1 Mbit/s)
  • Future-proof due to its prevalent usage in industry.
  • Expandable (no extra hardware required to add a node)

Ethernet (LAN)

All sensors to have power of Ethernet capability.

  • Lightning quick
  • All sensor modules would require more expensive hardware for the Ethernet stack
  • Would require a large switch infrastructure for many bays
  • Every new module would require running of more cable
  • Distance may be a problem for Ethernet

Bluetooth

Each sensor has its own Bluetooth connection.

  • Range is too limited. We could create a mesh network, but the close sensors would have a large throughput of data.
  • Limited number of connections to the main controller (20 max)

Wi-Fi

Each sensor has its own Wi-Fi chip.

  • Increases cost of the sensor hardware
  • Require a power router to have that many connections
  • Setup becomes an issue as there are no inputs on the sensors
  • Range of the Wi-Fi is usually not up to 100 m.

RS-485

A multidrop; however, this is just a simpler version of CAN in reality.

1-Wire

I think this would be a joke trying to use this, but I am open to suggestions.

\$\endgroup\$
2
\$\begingroup\$

I think CAN is a good choice IF:

  1. You can live with less than 1 Mbit/s. 100 m is too far for that speed. The worst case delay just due to distance is the out and back time between the two most distant nodes. That's 200 m propagation distance in your case. Let's say that the propagation speed on the twisted pair is half light speed, so that comes to 1.3 µs due to propagation delay alone. That out and back response needs to happen usually within about 2/3 bit time for the collision detection to work properly, so that means you're exactly at 500 kHz from the above numbers. I'd say 250-350 kHz would be a reasonable speed for such a CAN network.

  2. You can have nodes manage multiple sensors. 200 nodes on a single CAN bus won't work with some bus transceivers, like the common MCP2551. I vaguely remember it is specified for up to around 110-120 nodes. Check the datasheet. If each module handles just 2 sensors, you're within spec. If the 200 sensors are evenly spaced over the 100 m, then a quad-sensor node only has to have a reach of 2 m, or up to 1 m cable to the actual sensors.

    It's probably smart to design quad sensor boards anyway. You can still use them to handle individual sensors when they are far apart, then 4 at a time for a clump.

\$\endgroup\$
  • \$\begingroup\$ Thanks for the detailed answer. I am little confused about what you mean by have a quad sensor board? I was under the assumption that MCP2551 had to be used in conjunction with a controller like MCP2515 ie they had be used as a package. Also, how does a quad sensor only need to have a reach of 2M, I am slightly confused about that? \$\endgroup\$ – Lhh92 Jan 18 '15 at 20:48
  • \$\begingroup\$ @Lance: By quad sensor, I meant a whole board with a single CAN connection but that handles 4 sensors. A MCP2551 can only be used with a single controller, but that controller can generate lots of different messages and can take input from multiple sensors. 200 sensors over 100 m means one sensor every 500 mm if they are evenly spaced. \$\endgroup\$ – Olin Lathrop Jan 18 '15 at 21:21
  • \$\begingroup\$ I see what you mean now. I have considered doing what you suggest. Due to our system architecture where each module is self contained I do not believe I could do that, but it is worth investigating I think! Thanks for your help. \$\endgroup\$ – Lhh92 Jan 19 '15 at 19:36
0
\$\begingroup\$

Zigbee/Xbee is widely used for distributed sensor networks. Of course the cost per sensor (wireless module+battery/power supply) is higher than wired but the deployment is easier.

\$\endgroup\$
  • \$\begingroup\$ Agreed, but in a large distributed system where there could be 100 nodes wouldn't the closest nodes in the mesh network become logged with the large throughput due to the mesh network? \$\endgroup\$ – Lhh92 Jan 18 '15 at 20:46
0
\$\begingroup\$

I think CAN would do OK. You won't get 100m at 1Mbit/s though - do you need 1Mbits/s? There are some charts around to estimate max bus length vs bit rate.

Ethernet will do 100m, but you will need a big switch (or use something funkier like EtherCAT maybe?)

\$\endgroup\$
  • \$\begingroup\$ We definitely do not need the 1Mbit/s, we currently use I2C at 20kHz and it is plenty fast enough. So the distance vs speed would not be an issue. \$\endgroup\$ – Lhh92 Jan 18 '15 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.