Tuesday, March 22, 2011

Piping wireless packets to the computer

The computer gateway will be one of the key pieces of the panStamp ecosystem. In order to communicate with the panStamps from my PC, I've developed an Arduino application that basically converts wireless packets to ASCII strings and vice-versa. Since I need to configure some parameters such as device address, carrier frequency and channel, this gateway has also been programmed to accept a set of AT commands.

Figure 1: panStamp mounted on the USB board working as serial modem

One of the important things about this gateway is that is does not implement the SWAP stack itself. Instead of this, the “modem” simply pipes raw wireless packets to the computer, making it compatible with other wireless protocols. Later, we'll have to develop an implementation of the SWAP protocol for PC, where computation resources and disk space are something unlimited compared to Atmega's.

Another advantage of working with ASCII packets and AT commands is that anyone can access the modem from a serial terminal such as hyperterminal (for Windows) or minicom (for Linux). Apart from this, ASCCI strings also simplify the integration from custom applications, making the use of additional drivers and libraries almost unnecessary.

Figure 2 : minicom in the process of capturing some wireless packets 
The above screenshot shows minicom receiving frames from a mote. Taking one of those frames, we can de-compose it as follows:


0xD7 is the RSSI value whilst receiving the frame, coded as the CC1101 datasheet indicates.
0x30 is the LQI alue (7 bits), as explained in the CC1101 datasheet too.
0x00 is the destination address. This packet has been broadcasted then, as specified by the SWAP protocol.
0x01 is the address of the source device or mote
0x00 is the value of the hop counter (4 bits) and the security option (4 bits). In other words, this packet has never been repeated and includes no security protection.
0x1E is the cyclic nonce. Even if it's not taken into account (security option = 0), every information packet being transmitted makes this counter increment.
0x00 is the function code, indicating that the packet is a SWAP information message, reporting the value of an endpoint
0x01 is the address of the device actually owning the endpoint. This tells us that the device that owns the endpoint is also the one having sent the info packet.
0x0A is the index of the endpoint. Endpoint address (0x01) and endpoint index (0x0A) make a unique endpoint code within the wireless network: 0x010A.
0x0CA4 is the value of the endpoint. This 2-byte digit particularly shows the voltage supply on the remote device (0x0CA4 hex = 3236 dec = 32.36 VDC).

What is the next step? I'm already working on a PC tool for configuring SWAP motes wirelessly without having to handwrite command frames from the serial terminal. This tool may also derive into some kind of diagnosis application for testing remote motes and helping developers in their projects. Meanwhile, I have a good excuse for developing a SWAP Java library.


  1. The MAC and PHY in the HopeRF/SiLabs and TI chips is proprietary to each vendor, unlike, say, 802.15.4. However, '15.4 at 868/900 or 2.4GHz (type-certified modules (not chips or demos) are available from many vendors, including Digi (XBee), Jennic, Atmel/Meshnetics, OKI, Panasonic, et al). One might argue that these modules, at $25-35 each, though already FCC (and its peers) type certified, are an overkill for some applications. I have used XBees and Jennic extensively.

    Recently though, I have a project that is quite cost conscious and needs low speed and longer range for bi-directional data. That leads one to a simple sub-GHz module, at a 1ea cost point of $6 or so, for a 2mW transmitter. With FSK and narrow channel bandwidth, the range with just dangling wire antennas is hundreds of ft. line of sight, sufficient for a star topology, or a simple self-forming mesh. However, not using a standards based module does require that you ensure that the type-certified module vendor (not the chip vendor) is a robust vendor, and the module won't go EOL before you want.

    In home automation, there's Z-wave - proprietary. Used in mesh form by some large companies (licensed).

    In a perfect world, the new 802.15.5 (not 15.4) standard for meshing could be adapted for use on other than 15.4 modules. The 15.5 standard is at layer 2.5 as they say, making it a peer of ZigBee and ISA100.11, but 15.5 is an open IEEE standard

    I'm so far using
    sold in the US by

  2. Thanks Stevech for commenting on this blog.

    I too agree in that IEEE802.15.4 brings some basic interoperability between different vendors. However, I also think that 802.15.4 may not be the solution for everything since other non-15.4 radios still provide some advantages – price among them, as you say -

    Jeelabs is indeed a very good example about how open-source hardware and software can co-exist for the benefits of a project and its users. Very good project and great blog!