Thursday, March 10, 2011

Swapping wireless data

After highlighting our need for a wireless protocol in the precedent post, I've been carefully thinking about the way to proceed. Finally, I've taken the decision to create a custom protocol, something really simple and usable for generic M2M needs. We specially need a very lightweight protocol, simple to implement, flexible, robust and capable to fit into the list of features provided by the CC1101 chip.

Figure 1: First panStamp boards

After working with dozens of M2M protocols, mainly for wired systems, I've learned some useful things that may be applied to our wireless protocol. Flexibility is a concept rarely wanted in protocols nowadays. Instead, “plug and play” is showed as the ultimate goal for any communication technology. I personally think that a correct balance between both requirements can give the optimum result, mainly for general-purpose systems where application variables are not known at the time of designing the communication schema. The following list shows our requirements in terms of communications:
  1. Our communication frames must fit into the CC11XX packet structure. This requirement may seem obvious but the CC11XX chips provide some useful filters and smart functions based on the contents of each data packet, and these features may result useless if the final protocol frames do not respect some basic rules.
  2. We just need a peer-to-peer protocol, not a wireless mesh technology. Mesh systems entail maintaining routing tables and this usually requires more RAM. Instead, we want a flexible agnostic P2P protocol capable to do relatively complex things without having to invest resources for maintaining wireless infrastructures.
  3. Our protocol must allow some basic encryption algorithm and a defensive mechanism against replay attacks. Then, the user may decide to use these features or not, depending on his requirements in terms of security and confidentiality.
  4. Networks should be identified by custom ID's in order to minimize collisions and interferences from other neighbour networks. This feature would also allow creating multiple networks into a common building or area.
  5. Our protocol must be very simple and allow an extremely compact implementation. Although our prototypes are initially using Atmega328p's (32KB of flash), we should be able to reuse the communication stack on Atmega168p's (16 KB) and Atmega88p's (8 KB).
  6. Our protocol will be free and open source. We'd really like to see ports of this protocol stack for other microntroller platforms, like Microchip PIC's, TI MSP430's, generic 8051's, etc. In fact one of the first non-Arduino ports could be done for my Texas Instruments ez430-Chronos.
  7. Our protocol must allow accessing off-line data through some external data recorders. Mobile devices like the ez-Chronos, may want to read some battery-operated device that could be sleeping at the moment of sending the query. Instead, the Chronos could send the query to a central node (data recorder) that would be permanently listening the channel for news from those battery-based sensors. In a typical mesh network, the coordinator would be this central node.
  8. Our protocol must be contents-agnostic. From my experience when I worked with Modbus - an old boy from the 70's - I learned that abstract protocols provide an extra degree of flexibility and compactness. Any M2M information, including the most exotic one, can fit in a row of bytes. No need to create function profiles or heavy data dictionaries. At the end, the ultimate application, the one that really needs to decode the received data, has just to know the way to do it, maybe through the use of XML-based product definitions. This ultimate application will be running on a computer most of the times. Computers have the power, memory and disk space to do this kind of things whilst the wireless nodes can concentrate on transmitting and receiving data following their own formats.
  9. Our protocol should be endpoint-based. We don't want to work with fixed-length registers as Modbus does. Instead, we''ll create variable-length endpoints at start-up time, addressable by a unique ID within the network.
  10. Every device developed will contain a unique identifier (common for all devices of this type). This identifier will be used by the “ultimate” applications to decoded the endpoint values.
Well, we have a good list of requirements. I've already started working on the protocol schema, called SWAP (Simple Wireless Abstract Protocol) from now on. I expect to come back to this blog with a presentation of the protocol in a few days, so please hold the line :-) Thanks for your time!

3 comments:

  1. How can i make connection (wireless) betwean arduino and panstamp?

    ReplyDelete
  2. You need a CC1101 RF front-end for your arduino. Once you get this you can use the panStamp library like you would do for with panStamps. Have you taken a look at the official webpage?
    http://www.panstamp.com

    ReplyDelete
  3. got any simple sample for SWAP that on arduino?

    ReplyDelete