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.