As part of my thesis research on 802.15.4 wireless sensor networks, I have recently become a developer on the GoodFET project. This project was started by Travis Goodspeed and “is an open-source JTAG adapter, loosely based upon the TI MSP430 FET UIF and EZ430U boards.” However, as you will see, it has grown into so much more. I started working on the GoodFET CCSPI (ChipCon SPI Flash) client and firmware which Travis had started to support the Tmote Sky and TelosB branded sensor boards. These are termed “motes” and originally developed at UC Berkley and sold under several names, primarily for wireless sensor network routing/topology research. They consist of a USB FTDI chip, MSP430 processor, CC2420 802.15.4-compliant radio chip, along with other hardware like sensors, EEPROM memory, etc.
Travis has introduced some of the GoodFET port to this platform on his post, and basic installation is covered on the appropriate GoodFET hardware page. I encourage you to read those – I won’t repeat everything here. Instead, I’ll focus on one of the parts of code I wrote, specifically the port of the TinyOS demonstration code RadioCountToLeds. In order to test and validate the GoodFET firmware’s compatibility with other OS (motes typically run OSs like TinyOS or Contiki, which have more feature bloat than GoodFET), Travis suggested that I port the RadioCountToLeds application – specifically the transmit end – to the GoodFET. All code for the GoodFET project consists of “hacky” code in files like goodfet.ccspi, and the more refined library code in files like GoodFETCCSPI.py. As features mature and are tested, they are moved into libraries.
The RadioCountToLeds code basically requires two devices to be flashed with it, and they maintain a 4Hz counter broadcasting the value of the counter in an AM packet (a TinyOS abstraction that I find quite frustrating when trying to work with real 802.15.4) over the radio to the other device. The receiving device displays the lower 3 bits of the counter received on it’s three LED lights (built into mote design boards). This basically validate AM communication and timers for the TinyOS system.
So, how do we pretend to be a TinyOS RadioCountToLeds transmitter? There are two ways, each of which I implemented in goodfet.ccspi (run with verb txtoscount -i or -r). First, we could just send messages at a set interval with different counter values (-i option). The key is that we wanted to make sure that GoodFET was forming valid packets that would be accepted by the receiving TinyOS node. From capturing a TinyOS packet (using KillerBee which is my main research focus or using the goodfet.ccspi sniff command), we see that the application is sending packets like:
[0x0f, 0x41, 0x88, 0xFF, 0x22, 0x00, 0xff, 0xff, 0x01, 0x00, 0x3f, 0x06, 0x00, 0xFF]
The two 0xFF bytes are changed to have the correct counter values, and before transmission, a two-byte 802.15.4 FCS sequence must be appended. The 0xFF at index 3 holds the counter value, and the 0xFF at index 13 holds a value one greater than the counter value at index 3. Hmm – let’s go with it. With a few tweaks to the GoodFETCCSPI transmission function (RF_txpacket) to make sure checksumming was being handled correctly, this worked.
The second way to play the RadioCountToLeds game is closer to what the actual TinyOS application does, and this is accessible with “goodfet.ccspi txtoscount -r”. It waits for an incoming packet from a real TinyOS node and then replays this over the air. Simple enough. The key with receiving is making sure that the CC2420’s registers are set (ex disable/enable auto-CRC and address validation) correctly to receive the packets. Also note that the CC2420, if auto-CRC is on, changes the FCS bytes in the incoming packet to communicate other information (link quality, RSSI, and one bit to say if the FCS was correct). So, we truncate the incoming packet to only have the MAC header and data payload (aka chop off the FCS data) before re-playing it as auto-CRC is enabled on CC2420 (using the GoodFET function RF_autocrc(1) to set it) and it will recalculate and append the FCS for us.
That is just a brief intro of how the GoodFET firmware and client scripts can easily enable transmit and receive over 802.15.4. I’ll get around to writing more about my work with parsing/generating 802.15.4 frames (see my commits to scapy-com) and some other work with the GoodFET and KillerBee projects to bring 802.15.4 capture and injection to this platform (via killerbee/dev_telsob.py driver support).
Contact me with questions, comments, etc.
Project link: NA