For home use IoT systems, getting sensor data from tons of physical locations centralized to a single Raspberry Pi can be a difficult job, especially when considering the power consumption that’s necessary for doing it all over WiFi. When you’re using an ESP8266, for instance, swapping out batteries and accounting for connectivity issues can be a major hassle for a long-term solution. The NoCAN platform, created by [Alain Pannetrat], solves this problem using a wired approach that improves the use of the CAN bus.
Since SPI and I2C only work for short distances, approaches like RS-485 and CAN bus are a better bet for this type of setup. For systems with one centralized point, RS-485 works best – thus, the CAN bus is the better approach when you’re considering using multiple masters in a single environment.
CAN devices typically need a static address, so messaging involves sending data to the known address of the destination device. With NoCAN, a dynamic address assignment scheme allows nodes to request an address from a node manager on boot-up (similar to DHCP). A command line application also allows users to send and receive message from nodes using a pub/sub implementation – a device sends messages to a channel, and every device subscribed to the channel receives the message.
The hardware for the NoCAN platform consists of a Raspberry Pi with a “PiMaster” HAT and an Arduino-compatible CANZERO board. The PiMaster HAT uses an STM32F042 ARM Cortex M0 MCU, acting as an interface between the Pi and the CAN bus as well as preventing over-current events with a software-controlled smart switch. The CANZERO is based on the the SAMD21G18 ARM Cortex M0+ running at 48MHz, similar to the Arduino MKR Zero, with CAN bus networking using the STM32F042 ARM Cortex M0. The double MCU design allows the secondary MCU to reset the primary if it gets stuck due to a programming error, with the messages sent over the CAN bus.
To join the network together, a four-wire cable daisy-chains the nodes in the bus network, providing connectivity for up to 1000 feet. Either 12V or 24V DC power runs through the network, stepping down to 5V or 3.3V at each node. The approach is similar to PoE (power over Ethernet), although it is slower and lower in cost. Overall, it seems like a good solution for environments where wireless connectivity simply doesn’t cut it.
who misses AXLink?
“CAN devices typically need a static address, so messaging involves sending data to the known address of the destination device”
Typically that’s entirely up to the application protocol that’s used upon CAN. The CANOpen protocol for instance also allows dynamic node-id adjustments. In practice however many devices have dip-switches to set the id, and it is only in situations where the device is completely sealed the dynamic addressing is often used.
I don’t see the advantage of running a network cable to all the endpoints – given that effort, why not just power the ESP devices from the wall rather than running them on battery?
Hey, I’m the designer behind this project! :-) awesome to be on hackaday!
So if you have any questions, please shoot!
No questions yet, just a comment – nice job! This could be interesting for some vehicle/boat/house projects I have in mind.
Is it just me or you are mixing apples and oranges. People are using wi-fi for a reason. It is hard to put new wires all around the place to connect “tons of physical locations”.
First myth: “SPI and I2C only work for short distances”… NO NO NO. The ignorance here is egregious. Synchronous protocols can work at any distance if the frequency is reduced. There are many other reasons to not use SPI here (CS lines being the most relevant). I2C with 2 pairs of differential lines can be run at full speed. Then you can use whatever I2C peripheral you want and not something requiring CANZERO.
Second myth: CANZERO is low power. A relative thing, but when compared to MSP430, a Cortex M0+ is an energy hog with a long wakeup time between sleeps. It will consume more power when an Arduino lemming puts all their logic in the loop() command.
SPI more than I2C.
Sure I2C is synchronous, but the highly stateful nature of I2C means it becomes a royal pain in the ass over long distances. Devices miss packets or hang the line.
Heck, I2C can even be a pain in the ass over short distances.
Timeouts reset state. This is true at all levels of programming
Most online resources will suggest that SPI is limited to less than 10 meters because propagation delays will cause a de-synchronisation in the return direction between the Slave and the Master. Jan Axelson in the book “Serial port complete” puts that limit at 18 feet (~5.5meters).
“the maximum bus length of an I2C link is about 1 meter at 100 Kbaud, or 10 meters at 10 Kbaud”
Source: http://www.mosaic-industries.com/embedded-systems/sbc-single-board-computers/freescale-hcs12-9s12-c-language/instrument-control/i2c-bus-specifications
NoCAN networks running at 125Kbps can span 300 meters.
SPI is not a good choice for what you are doing, and I don’t think you quite understand all the online resources out there.
I love you throw out the 300 meter length without even specifying ANYWHERE on the website what kind of cable you used.
And you wouldn’t run 300 meter spans without a form of isolation on your comm lines.
Otherwise you would have put more than TVS diodes on your comm lines.
I can forgive the HaD content mill for pushing more blogspam, but you sir have more responsibility.
I strongly recommend redesigning your approach before you unleash your kickstarter on unsuspecting people.
Or you’re just another software guy designing from datasheets.
We actually tested our solution over 300 meters, with cat5 cabling. For real :-)
My roof if strung with cat-5 cabling talking OneWire. If I need a nonstandard device, it’s beens fairly easy to cook it up using an ATTiny and OneWireHub.
People are using WiFi for a reason. It’s wireless. No one wants to bother with using cables for each node.
Wouldnt a 2.4Ghz radio without all the WiFi stack be better for battery operated IoT devices?
You can make some fine IoT projects with some WiFi chips and batteries, and if that works for your application that’s great.
But the reality is that, a straightforward ESP8266 WiFi application will only last a few days on a few AAA batteries. You may extend that substantially by using some software tricks (sleep modes) but it does not suit all applications, especially those that require instant response. If your nodes are enclosed in boxes on rooftops or in the back of a garden, changing batteries will become a royal pain. If, for example, your nodes power the valves of your garden watering system, each requiring 300mA to open, your battery budget will look even worse, even if you have fine-tuned your microcontroller power budget. (As a side note, Zigbee or Lora are probably much better for power sensitive applications.)
Next, you might discover that your WiFi network does not always extend where your nodes need to be, buried in a box in the garden, or behind a drywall near your central heating system, for example. You might discover that your network comes to a standstill for a few seconds every morning when your neighbour switches on his cheap microwave oven. And that may or may not be an issue depending on your application.
By no means, does NoCAN claim to be better than WiFi. NoCAN aims to address all these cases, where wireless/battery solutions just don’t cut it. It does that, while offering extreme ease of use, and plenty of interfacing options (REST, MQTT, blynk, etc.).
I think you’ve put together a fine solution. People will argue the technical points, and that’s fine, but you’ve packaged something together and done a nice job of documenting it. Kudos for that! I don’t suppose it will make you wealthy, but you’ve got my respect.