Progress Report 24/02

• Did some intensive investigation into why match data wasn't being given out properly over the serial port. I had a dig around with the FlashViewer application and it turned out that the match data wasn't even being stored in flash properly! Spent a long time trying to figure out why before giving in and posting to the TinyOS support mailing list. A guy called David Moss from Rincon replied and told me that the modules I was using for flash access - BlockRead and BlockWrite, were riddled with problems and suggested I use his replacement for flash access - FlashBridge. Seemed like a good idea.

• Spent a long time getting FlashBridge working. Since the distribution of TinyOS that is supplied with my motes (Boomerang) was based on an old version of TinyOS and FlashBridge was written for a later version, FlashBridge was not happy at all. After a day of fiddling around creating some horrible hybrid version of TinyOS that didn't really work at all, I discovered that there's a compiler flag for FlashBridge for Boomerang users. Doh. Once I started using that everything seemed to work fine...
• ... Except the match details were still being stored incorrectly! Luckily I quickly realised that during all my playing around I had moved the code to store matches into the event handler for receiving the radio message. This is bad because on TMote Sky modules the radio and external flash share a bus. The problem was fixed by moving the code to write a match back out into a task and posting the task, so that the system scheduler could run it when the bus was free.
• The hardware side of things is nearly complete now, and it's certainly functional enough for me to get on with writing the rest of the system. There are a few more things I'd like to do to it though:
• Stop the flash being erased each time a unit is powered up. At the moment this is because I have no easy way of storing the number of matches held in flash. Shouldn't be too hard to simply read in the records from flash one by one on startup and count them all up.
• Add a message so that the current battery level can be queried over USB.
• Make the device go into an error state if it is not bound to a user account. At the moment it still sends out notification messages on the radio with user ID and device ID of 0.
• Now that I have working hardware and a library to interface with it via the USB port, I started work on the device dock application. Hopefully this should prove to be a fairly simple part of the project. Indeed, I was able to make a decent start with around an hour's work. The application searches through all available COM ports and queries to see if there's a finder device attached to any of them. It then displays the device ID and user ID of any devices it finds in a table. It also looks really pretty: screenshot.
  

Progress Report 13/02

• Added a "Set Time" COM port command so that the PC can set the local time on the mote. The mote will update the current time every time it sends an announce packet over the radio. Because there is no power source except the standard batteries, there is no way to store the time when the batteries are taken out. As such, I've had to drop the requirement that the system can continue functioning normally after the batteries are removed. Match data will still be kept on the flash though.
• Motes now receive announcement packets from other motes over the radio and store the user id and device id in flash, along with a timestamp. At the moment each announcement results in a new entry being made in the flash, which is a bit rubbish because the sector I have allocated for match data can only hold 8192 such matches. A better approach would be to store update a running total in each record for the number announce packets in a row (within a specified time frame) have been receieved from a particular device. This is hard, however, as each bit in a sector can only be written to once without erasing the entire sector and starting again. Hence keeping a running count would be difficult.
• Had some difficulty in figuring out how to store the current number of matches held in flash. There were a few approaches I considered:
• Storing the current number of matches in the device config sector of the flash and erasing and re-writing this sector each time a new match is made. Such frequent erasing and re-writing is not good for the flash memory, however.
• Storing the current number of matches in a sector of its own and erasing that every time a new match is added. Has the same problem as the previous approach, and because the minimum size of a sector is 16k this would be extremely wasteful.
• Storing the current number of matches in volatile RAM and counting the number of matches currently held in flash only when the device is first started up.
• I decided to go for the third approach, however I have not yet written the code to count matches in flash. Therefore, at present the match data volume is simply erased every time the device is started and the match count set to zero.
• The FlashViewer module was interfering with my LED control by setting LED values when various operations I was performing completed, which made debugging even harder than normal. I have disabled it for now. If I need it back then I will wire its LED interface to a dummy LED component.
• Added a "Get number of matches" COM port message to the system. Seems to work perfectly.
• Added a "Get match x" COM port message for retreiving match data. Doesn't seem to work properly, need to look at a dump of the flash memory to see if this is because the values are stored incorrectly in the memory or whether they are being transmitted wrong.
  

Progress Report 10/02

• Devices now recognise when they're been connected/disconnected from the USB port and update their state accordingly.
• Devices now send out radio messages advertising their user and device IDs every 5 seconds when they are not docked with the PC.
• There is still a bug where a device will lock into the error state if it is booted up while connected to the PC. This is because the state when it is first starting up is the configuration reading state and while it is in this state the "Connected to USB" event fires. This event signals an error if it occurs whilst the device is in any state other than idle.
  

Progress Report 04/02

• Motes now read their configuration information (user ID and device ID) from flash memory when they are booted up.
• Added a "GetConfig" message and response that can be sent over the serial port, so that a PC can get the current configuration of the device attached to it.
• Maybe the motes do receive packets in little endian format - when I started using the GetConfig message the device/user IDs were coming out backwards. I guess data is stored in the flash little endian (and displayed like this in FlashViewer), but is actually retrieved big-endian.
  

Progress Report 01/02

• Seems the motes transmit the payload part of data packets over the serial line in little-endian format, but receive them in big-endian. Changed my serial interface layer to not send messages to the mote in little-endian format.
• "Bind device" message to the mote appears to be working correctly, it's writing the user ID and device ID to the first 8 bytes in the system information volume on the external flash. At some point I should improve this so that it checks the CRC of the data written to the flash.
• Added the FlashViewer module into my configuration so that I don't have to keep switching between my app and FlashViewer to see what's going on in the flash.
• Added a Bind Device Response message so that the device gives some feedback about how the binding went.