Communication protocols ideas - Page 1
Forum section: electronics / projects

author: Red_Micro
author_rank: Regular Contributor
timestamp: March 16, 2021, 06:06:32 pm
content: I’m building a bus with 6 sensors. Each sensor has its microcontroller. We call it a node. There will be a master micro which will communicate with all the nodes. Later, this master micro will communicate to another system micro. The flow will be as below:Sensor -> Sensor microcontroller <-> Master micro <-> System microThe idea is to add more sensors in the future and to avoid the need to do a firmware upgrade in the field either in the master or the system micro to configure new sensors added.What communication scheme, firmware/hardware techniques would help here? I’m thinking of RS-485/Modbus or CANbus/CANopen. Somehow there should some addressing/IDs technique to address the different sensors and be flexible in case of adding more. Modbus is master-slave and CAN is multi-master. I would go for one which allows me to easily configure nodes. CAN actually has good features on collision and error management. Cable length and speed are not critical aspects. It’s a small system. I’m just trying to not overdesign or overkill. Any suggestions?

author: nctnico
author_rank: Super Contributor
timestamp: March 16, 2021, 06:48:08 pm
content: CAN solves a lot of issues with addressing and there are tools to decode messages for you as means to aid debugging.If you go the RS485 / UART route then do yourself a favour and use a text based (human readable) protocol. Very easy to debug and extend. Take the GPIB/SCPI protocol used by test equipment as an example.BTW: If the master micro and system micro are on the same board then do yourself a favour and combine these in one microcontroller. This will be much easier to debug / upgrade / maintain.

author: ajb
author_rank: Super Contributor
timestamp: March 16, 2021, 07:03:05 pm
content: Collision management is really only useful if multiple devices are expected to try to talk at the same time, so in a single-master system where nodes only respond when polled and do not send spontaneous messages it's not necessarily of great value to you. A checksum, which you probably want anyway for message integrity reasons, will inform you of errors resulting from collisions as well as any other cause, and is sufficient for a lot of applications. If you do need to have nodes send spontaneous messages, there are time-division methods that can be used to allow this with minimal chance of collision, for example each node can be allocated a specific time slot based on its unique address in which to send a message. This may lead to fairly long intervals if you have a lot of nodes, but it may be acceptable in a lot of cases.Station addressing in Modbus, and probably many other protocols that have such addresses, is a manual affair; it is up to the user to configure all nodes on a bus to have unique addresses. A mechanism where all nodes have fixed and universally unique IDs that the master system can discover may be preferable, since it doesn't require any pre-configuration of the nodes--you simply plug them into the network and then any necessary configuration can be done through the bus. The unique ID can be the same as, or derived from, a device serial number--if your devices don't have serial numbers, a lot of MCUs now have unique IDs built in that could be used.An example of this mechanism is RDM, which is a protocol used in the entertainment lighting industry for discovery and management of lighting fixtures on DMX networks (DMX uses RS485 signaling, and it and RDM are strictly polled, single-master systems). The protocol is described in ANSI E1.20, which you can download for free here:https://tsp.esta.org/tsp/documents/published_docs.php.In a nutshell, each device has a permanent 48-bit unique ID, and the discovery process starts with the controller sending a broadcast "Discovery Unmute" message that tells all devices to respond to subsequent discovery messages--since this is a broadcast message, the nodes do not send any response. The controller then sends a "Discover Unique Branch" message giving a range of UIDs. Any device with a UID in that range will then send a response message. The response message is formatted in a specific way to minimize the chances of collisions resulting in messages that devices that do not support RDM will interpret as DMX data, but in a new system this precaution is not necessary. The first Discover Unique Branch message covers the entire range of UIDs, so every device on the network should respond, resulting in expected collisions, which will cause a checksum failure. So the controller knows that if it receives any response with an invalid checksum that multiple nodes in that UID range are connected. The controller then bisects the UID range and sends a new Discover Unique Branch message. It continues this binary search process until it either receives no response, at which point it knows that there are no devices in that range, or it receives a valid response, at which point it knows that exactly one device is in that range (a unique branch). When the controller identifies one device in this way, it adds it to its device list, and then sends that specific device a "Discovery Mute" message telling that device to not respond to any more discovery messages. The controller then moves to the other half of the current range, and continues in this way until the whole binary search pattern is complete, at which point it has a complete list of devices by their UIDs. Since all of the existing devices will be muted at the end of the discovery process, the controller can periodically send a Discover Unique Branch covering the full UID range which will detect if any new devices have been connected since the last discovery.Once the discovery process is complete, the controller can then send unicast messages to unique devices via their UIDs, or broadcast messages to all devices, or 'vendorcast' messages that are multicast to all devices of a specific manufacturer, but in a similar protocol you could use the UID initially to assign an arbitrary bus address to a node, or define groups that could be used to direct messages as well or instead. Some of the defined messages allow the controller to interrogate a device to discover its manufacturer, model, software version, etc, and can even discover an arbitrary list of parameters that the device can expose for the controller to read and/or modify. These parameters include the DMX address, which controls how the device responds to DMX data, and could be analogous to something like a Modbus station address. That whole mechanism is probably overkill if you control all of the devices that will be on the bus, but it can be useful to allow new devices with new sets of parameters to be supported by the controller without the controller needing to be updated. Simply plug the new sensor or whatever in, and the controller can interrogate the device to figure out how to interact with it. In a situation like with RDM where tons of different manufacturers are creating devices with wildly different parameters it's extremely valuable.

author: L1L1
author_rank: Regular Contributor
timestamp: March 17, 2021, 08:19:32 am
content: I'm the designer on the NoCAN platform:https://www.omzlo.com/articles/the-nocan-platformThe NoCan IoT platform enables the creation of a very reliable wired network composed of Arduino-compatible nodes connected through CAN bus, targetting application domains where wireless approaches are not satisfactory. Each node features a 32-bit ARM cortex microcontroller (SAMD21G18) and the network is managed by a Raspberry-Pi.I may be biased here, but I think it seems that it would fit exactly your needs

author: wizard69
author_rank: Super Contributor
timestamp: March 17, 2021, 12:46:53 pm
content: I think the bigger question is how much effort do you intend to put into unique code. Both CAN and Modbus are widely supported with both commercial and open source software. Modbus is probably the simpler solution for your needs if you can accept some limitations.Quote from: Red_Micro on March 16, 2021, 06:06:32 pmDo you really need that Master Micro. I'm not sure what you mean by "System Micro" but these days you can get single board computers running several cores making it almost completely transparent to other software running on the board.I guess it just looks redundant to me.QuoteI'm not sure how or what you are calling firmware here. If you add a device you will need to adapt you app to access any resources on that node.QuoteModbus is pretty easy in this respect. CAN is likely somewhat better as you don't set addresses manually. However CAN might be easy fo the guy plugging in something but it does come with a more demanding environment programming wise.QuoteI wouldn't jump on one or the other without knowing more. I'm more familiar with Modbus in industrial work but that is directly related to an entire manufacturing system built around Modbus. You don't go into what each node is doing and that would be a factor. Modbus is great for numerical data is small chunksI'm wondering if you have ever considered POE instead?

author: Red_Micro
author_rank: Regular Contributor
timestamp: March 17, 2021, 11:40:06 pm
content: Quote from: wizard69 on March 17, 2021, 12:46:53 pmThe idea is to write the firmware such that when a new node is added, the master itself is able to identify it, give it an address and configure it. Like hot plugging or plug and play.I believe POE is overkill for my application.

author: mattselectronics
author_rank: Contributor
timestamp: March 19, 2021, 12:39:06 am
content: Dynamic addressing is always a challenge with this kind of bus systems.Building a daisy chain like structure can solve this, but be aware, there might be some patents still lurking (especially if you use LIN).

author: Marco
author_rank: Super Contributor
timestamp: March 19, 2021, 04:49:24 pm
content: Quote from: mattselectronics on March 19, 2021, 12:39:06 amJust don't use LIN ... theideaof just enumerating a daisy chain to assign addresses is too obvious to not be patented a hundred times over before 2000. Here'sone.

author: mattselectronics
author_rank: Contributor
timestamp: March 21, 2021, 01:00:26 am
content: I think the LIN related one is this:https://patents.google.com/patent/EP1566022B1Unfortunately, not yet expired.I was surprised, that this is even worth to be patented, because there is not much of an invention to use LIN instead of RS485.

author: wizard69
author_rank: Super Contributor
timestamp: March 21, 2021, 02:18:20 am
content: Quote from: Red_Micro on March 17, 2021, 11:40:06 pmYes but why another board when you need that system controller (or whatever you called it). My point being that with all the multicore credit card sized computers we have today, you could easily handle that duty as a task or dedicate a core to it.QuoteI understand what you are trying to achieve with what amounts to a plug and play solution, but my question is this, is it worth it? I'm not convinced it is. I've worked on automation systems since the Texas Instruments TI5 was new and lots of variety since and have never seen setting an address as a big obstruction to installation. Usually far more effort is required to get the rest of the device configured.If you go the auto configure route you need to realize that there are two different problems, one is adding to the bus (easy) the other is replacement mid bus in an established system (a little harder). The replacement issue often requires that the new adopts the olds address, which is a bit more difficult than assigning an address to a new device added to the net.I don't really know what your volume expectations are but if they are relatively low I'd just put some addressing switches on the device or make the address a programed config value. I'd especially would go with a programmed address if there is any other configuration needed on the device.

author: Renate
author_rank: Super Contributor
timestamp: March 21, 2021, 04:38:26 pm
content: I don't think that it makes sense to re-invent the wheel.If you need/want multi-master or asynchronous alarms, go with CAN.If not Modbus is fine.I run a RPi3 with a USB RS-485 (home-brewed) adapter and 9 nodes for home automation.Since each node runs different sensors, different software, I just program them offline with firmware and address.