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:.
- 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
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)
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.
A multidrop; however, this is just a simpler version of CAN in reality.
I think this would be a joke trying to use this, but I am open to suggestions.
Answer
I think CAN is a good choice IF:
- 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.
- 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.
No comments:
Post a Comment