For any kind of communication to happens it’s necessary to define some protocol, a well defined set of rules known by all parts involved in the conversation. Talk² is not here to propose a specification for a new protocol, instead we are presenting some guide lines and to assist you developing your ideas.
On this post we’ll be talking a little bit about the Protocol used on Talk², which technologies we chose and why we’ve decided it.
One thing to keep in mind is that Talk² does not restrict you to any physical media or lower level protocol, instead it provides you a simple frame format. This means the only rule you need to follow is to respect the message format below:
|Field||Length (bits)||Short Description|
|ext||1||Message Id format|
|rtr||1||Remote transmission request|
|dlc||4||Data length, or payload size|
|data||64||Transmitted data, up to 8 bytes|
If you’re familiar, you may noticed that the frame format above is very similar to the CAN bus. The reason for that is because Talk² uses CAN Bus as primary protocol, and by using a similar message format we can simplify the development and load the whole frame, exact as it is, from the CAN Bus into the Application.
Also, using a small frame format means that it’ll fit on the top of almost any protocol.
The message id should be used to identify the message. The use can decide to split this field according to its needs, for example to include source, destination, type of message, etc.
Message id format indicates if the message id filed above is 11 bits or 29 bits long, standard or extended format, according to CAN Bus specification. If set to 0, this can be used to reduce the total frame size.
Remote transmission request works as a “ping” command. If set to true (1), the message will have no payload. This can be used to request some data from another node using a very small frame.
Data length, or payload size. It can be from 0 to 8 and represents the number of bytes transmitted in the message payload.
The data itself, which can be from 0 to 8 bytes and is dictated by the dataLen field above.
Now, looking to the payload size of 8 bytes you might think that’s not enough for your application, but if you do a bit of maths you’ll see that’s more than anyone needs to transmit any kind of sensor data or to control any type of actuator. See https://en.wikipedia.org/wiki/9223372036854775807.
Another advantage to have smaller frames is to reduce power usage, especially if your application will use RF link and be powered by battery. Less data to transmit equals to less power and better reliability. At the end, if you do require a bigger payload to be transmitted, like to perform firmware update over the air you still can break the data into multiple frames – Keep you eyes open for more to come about updates over-the-air subject.
As described before, the standard for wired media is CAN Bus, which supports up to 1Mbp/s on a 40m cable or, if you prefer, incredible 1,000m cable length at reduced speeds. Longer cables are also possible using repeaters. The CAN standard is written for 120ohm cable which can be replaced by the popular Cat5e without major dramas.
If you heard about OSI Model and still remember the layers, you’ll be happy to know that CAN Bus implements not only the Physical layer but also the Data Link layer on hardware, including error detection, acknowledgement, message framing, validation and others. Different from other communication methods like RS-485, where you have only the physical layer and need to implement everything else on the top. In any case, if you decide to transmit a Talk² message over any other media
or protocol, you need to make sure you can pack and un-pack the five fields listed above, as well perform any kind of message routing required for your application to work.
Other features associated to the CAN Bus is the great reliability and good immunity to external interference. That’s why is the standard protocol for automotive industry as well industrial automation, it’s even present on the aeronautical and naval industries.
The cost for CAN Bus controllers and transceivers is very low, is also very easy to find MCUs with built-in CAN controllers. Probably the most popular silicons are the Microchip MCP2515 and MCP2551, available in many packages, including the prototype friendly DIP.
Details about the Wireless like will be presented on our next post.
- Introduction to the Controller Area Network (CAN) by TI
- CAN Bus Wikipage
- Controller Area Network (CAN) Overview
- Controller Area Network Physical Layer Requirements by TI