Minimalist communications between microcontrollers both solves and creates some specific problems.
For example, how do you decode a message and know what context it was written in, what meaning it conveys and having got the decoded arguments, what do you do with them?
Some protocols put the arguments in specific places in the packet, for example, start of packet header, source address, destination address, number of bytes, payload and checksum etc would be placed in the packet in a given sequence. The microcontroller just needs to find the start of the packet header and work its way through the various fields.
An example of this is the simple format is the free and open SNAP (scalable network application protocol) devised some years ago by Swedish home automation company High Tech Horizons.
Another example is to use a mark-up language, such as XML, to convey the context of the various data fields. The CurrentCost CC128 Energy Monitor uses this approach, but the packets tend to be fairly verbose, which is fine if you have a PC, lots of RAM as a packet buffer and high level language with which to parse the packet. This is not often the case with a $3 microcontroller.
How could you convey context to a small packet of data, without having a massive overhead of extra data? In effect strike a balance between SNAP which is context free and relies solely on the order of the data fields in the packet and XML whre everything is spelt out for you with lots of additional text strings.
The answer lay nicely in the cipher machines and code breaking techniques of WW2.
In the 1940's the Enigma machine was used to encryt and decrypt messages so that they could be sent between German Command and various outposts. The Enigma machine had been sold throughout the 1930's as a secure messaging machine for businesses.
The key to the Enigma machine were three (and later four) alphabetical code wheels. The user was instructed what particular codewheels to fit, and in what order. The code wheels were then turned so that a particular letter was visible to the operator.
Once this was done correctly, all characters in and out of the Enigma machine would be correctly encrypted/decrypted.
Remembering this gave me a flash of inspiration. How do you come up with very short messages, which are character efficient but allow a wide variety of different tasks to be actioned?
The answer is to use a method analogous to fitting different code wheels. And these "codewheels" convey the context. You would only need to send the "codewheel" byte once, and from that point everyone who's listening, knows what you are on about.
For example sending Context 55, would tell all your subscribers that they should look up from ROM that Context 55 is for a 6 channel temperature sensor, and so that all subsequent messages contain temperature data in centigrade to one decimal place.
For simplicity, lets assume that single alpha characters A,B,C initiate certain action routines. In order that the Nanode performs the correct action for the application, it first has to be instructed which code wheel or rather book of actions it should be using.
By instructing a subscribing Nanode to use a different set of action routines, would be a very quick way of changing its application or context.
There would be a default set of routines to which all respond in the same manner, and a series of command primitives or directives based on punctuation characters like @ and #.
The first character of any nano-tweet message would either be an alpha character to signify an action routine, or a punctuation character to define a primitive command or the context of the remainder of the message.
4 comments:
Ken,
I don't understand your passion for short messages resulting in an over complicated messaging system. Does it really matter whether a nano-tweet is 5, 10, 50 or a 100 bytes long?
Even serially connected they'll still take a relatively short time to communicate unless you are planning a massive system with very frequent communication. Surely it's the latency that is likely to have a much bigger impact on the system performance and having a complicated messaging system to decode on a relatively slow controller will impact the latency.
If you make one character an escape then you can always extend the number of available codes
e.g. abcdefghijklmnopqrstuvwxy
then
za,zb,zc etc
then
zza,zzb,zzc etc.
Mark,
The short messaging protocol arose from a simple serial command interpreter used to send short commands to an instrument I was developing. Commands typed over a serial link were used to control different functions of the instrument. It was essentially a human readable set of commands - restricted, by way of convenience to only having to type in the shortest text strings to control the instrument.
Some point afterwards, I realised that my simple typed commands were a good match, to what could be passed through a Pachube Feed - i.e. short sequences of comma separated arguments. It became clear that Pachube could be used to convey these commands between two simple network connected nodes.
My background was in energy monitoring, remote sensing and home automation, where the quantity of data to be sent is not great. Small packets of data are sent at regular intervals - say every 10 seconds. The Pachube CSV Feed is a good means of transferring this data from the publishing device to the subscriber.
The 8 bit microcontrollers used in these low cost energy monitors and sensing devices are often very lacking in resources, with only a couple of K of RAM. Many of the original devices had little support for connectivity - at best a serial port. Outputing short strings of serial data is better than nothing.
One notable exception is the CurrentCost energy monitor which outputs a sream of XML data every 6 seconds. For the amount of information sent, the actual efficiency of real data content is very low.
All that is needed to handle these CSV strings is a simple command interpreter and a switch statement which decodes the various commands.
I agree that there are better ways to send longer packets of data, but given the history of this device, the resource limitations at eache end, and the nature of the Pachube Feed.
If all you want to do is send a few sensor or meter readings, or turn a few relays on and off, the nano-tweet meets those requirements.
Details of the Currentcost XML protocol can be found here:
http://www.currentcost.com/cc128/xml.htm
It was on reading this that I decided that XML was not the way to proceed if all you had was a microcontroller with limited RAM.
Just parsing the XML stream to extract the data would tax my programming capabilities.
Post a Comment