Computing stuff tied to the physical world

Wireless, the CAN bus, and enzymes

In Musings on May 27, 2013 at 00:01

How’s that for a title to get your attention, eh?

There’s an interesting mechanism in communication, which has kept me intrigued for quite some time now:

  • with JeeNode and RF12-based sensors, wireless packets are often broadcast with only a sender node ID (most network protocols use both a source and a destination)
  • CAN bus is a wired bus protocol from the car industry, its messages do not contain a destination address, there is just a 11- or 29-bit “message ID”

What both these systems do (most of the time, but not exclusively), is to tag transmitted packets with where they came from (or what their “meaning” is) and then just send this out to whoever happens to be interested. No acknowledgements: in the case of wireless, some messages might get lost – with CAN bus, the reliability is considerably higher.

It’s a bit like hormones and other chemicals in our blood stream, added for a specific purpose, but not really addressed to an area in the body. That’s up to various enzymes and other receptors to pick up (I know next to nothing about biology, pardon my ignorance).

Couple of points to note about this:

  • Communicating 1-to-N (i.e. broadcasting) is just as easy as communicating 1-to-1, in fact there is no such thing as privacy in this context – anyone / anything can listen-in on any conversation. The senders won’t know.
  • There is no guaranteed delivery, since the intended targets may not even be around or listening. The best you can do, is look for the effects of the communication, which could be an echo from the receiving end, or some observable side-effect.
  • You can still set up focused interactions, by agreeing on a code / channel to use for a specific purpose: A can say “let’s discuss X”, and B can say “I’ll be listening to topic X on channel C”. Then both A and B could agree to tag all their messages with “C”, and they’ll be off on their own (public) discussion.
  • This mode of communicating via “channels” or “topics” is quite common, once you start looking for it. The MQTT messaging system uses “channels” to support generic data exchange. Or take the human-centric IRC, for example. Or UDP’s multicast.
  • Note that everything which has to do with discovery on a network also must rely on such a “sender-id-centric” approach, since by definition it will be about finding a path to some sender which doesn’t know about us.

Having no one-to-one communication might seem limiting, but it’s not. First of all, the nature of both wireless and busses is such that everything reaches everyone anyway. It’s more about filtering out what we’re not interested in. The transmissions are the same, it’s just the receivers which apply different filtering rules.

But perhaps far more importantly, is that this intrinsic broadcasting behaviour leads to a different way of designing systems. I can add a new wireless sensor node to my setup without having to decide what to do with the measurements yet. Also, I will often set up a second listen-only node for testing, and it just picks up all the packets without affecting my “production” setup. For tests which might interfere, I pick a different net group, since the RF12 driver (and the RFM12B hardware itself) has implicit “origin-id-filtering” built in. When initialised for a certain net group, all other packets automatically get ignored.

Even N-to-1 communication is possible by having multiple nodes send out messages with the same ID (and their distinguishing details elsewhere in the payload). This is not allowed on the CAN bus, btw – there, each sender has to stick to unique IDs.

The approach changes from “hey YOU, let me tell you THIS”, to “I am saying THIS”. If no one is listening, then so be it. If we need to make sure it was received, we could extend the conventions so that B nods by saying “got THIS” and then we just wait for that message (with timeouts and retries, it’s very similar to a traditional ACK mechanism).

It’s a flexible and natural model – normal speech works the same, if you think about it…

PS. The reason this is coming up, is that I’m looking for a robust way way to implement JeeBoot auto-discovery.

  1. I’m curious what you’re going to come up with. I’ve been thinking that messages need to describe what they contain, rather than who they come from. Often these things are related, but they’re not the same.

    That said, where a message came from is relevant as well, but for people not machines. In your user interface you want to be able to distinguish the different temperature sensors to be able to attach meaning to the resulting data.

    In my eyes though the most complicated part is the receiver. The transmitters (the sensors) can be very dumb. Given you want to also support proxies to handle nodes out of range this means that you might need to do quite some processing to determine what to do with the received information.

    Not an easy problem.

  2. Hello, I am really enjoying your website.

    I have a couple of comments on CAN. Messages transmitted onto a CAN bus do actually need to be acknowledged. If a device tries to transmit onto a network on which there are no other listening nodes, the message will actually fail to send. The acknowledgement only indicates that the message was received with no errors. It is not an indication that the payload has been actually read.

    Multiple nodes are allowed to transmit messages with the same ID. The node that wins arbitration of the bus will get to send the message. Arbitration is decided based on the priority of the message ID. An ID with a high number has a lower priority than an ID with a low number.

    All the best.


    • Thanks for the clarification, stay tuned for a follow-up on this topic. But one thing I think is inaccurate: the message ID on the CAN bus needs to be unique, because bus arbitration only takes place during the sending of that ID. It can be re-used by different nodes, but there should never be two nodes trying to send a message with the same ID at the same time, or bus arbitration will fail to spot this case. I’m no expert, but that’s my current understanding of it all, anyway.

  3. I agree that it is bad design practice to re-use IDs between nodes. Although it is certainly possible to do it without breaking any of the CAN rules.

    In the very specific case where two nodes transmitting on the same ID at exactly the same time will simultaneously win arbitration. However, if the data payload in them varies, this will be detected by one of the transmitting nodes (they monitor the bus as they transmit) and the transmission will be aborted (the bus held dominant). This means that even in that unique scenario, robustness is preserved.

    Looking forward to more articles on this.

    PS. I love CAN :-P


  4. CAN messages are usually defined in a message catalogue, the catalogue defines all the message parameters including the data lengths, transmission timings and scaling etc.(No repeated ids on our networks though)

    In a vehicle network, this CAN catalogue is very important because the control units on the network are usually built by different suppliers and it’s important that all the messages meet the specific requirements otherwise the functions, distributed across several controllers, may not work.

    There are other flavours of CAN like flexray that have a predefined message schedule that all controllers must comply with.

Comments are closed.