[apparatus-templi] Milestone 1

From: Jonathan Nelson <ciasaboark@xxxxxxxxx>
To: apparatus-templi@xxxxxxxxxxxxx
Date: Tue, 28 Jan 2014 00:17:33 -0500
Good news.  I’ve completed enough of the coordinator core that the drivers are 
now able to send commands to the remote modules through the coordinator, 
completing the requirements for Milestone 1.  If you have the hardware 
available, you can begin writing drivers to control the remote modules.  If you 
need a sketch to use as a base for the remote arduino I’d recommend using 
led_flash in skeleton/arduino-sketches/remote-modules/.  The LedFlash.java 
driver could be used as a base for the java code.

I’ve added the ability for the application protocol to change as we add 
features.  This version uses protocol version 0.  This is the basic protocol 
that we went over in the last team meeting.  It sends commands using the xbee 
at mode serial interface.  The message is composed as a destination and command 
separated with a colon.  The message is terminated with a single newline:
[destination | ‘:’ | command | ‘\n’]

If you want to start sending messages, just make sure that the destination and 
command contain no line-feed characters.  Also note that it will likely not 
work with more than two xbees.  I would also recommend adding a delay of at 
least 2 seconds between transmissions in the driver to avoid out of order 
characters (not sure what the reason for this is).

Since this protocol has a number of design limitations I’ve started work on 
version 1.  This will add support for binary transmissions and multiple end 
points sending and receiving at the same time.  The format for the transmission 
is nearly identical, but a single byte is added to the beginning of the header:
[start_byte | destination | ‘:’ | command |’\n’]

This additional byte carries information about the type of transmission:
bit 7 indicates whether this is an ascii text transmission (0) or a binary 
transmission (1)
bit 6 is reserved for later use
bit 5 is reserved and always 1.  This makes sure that the start byte can never 
equal the line-feed char (0x0A)
bits 0 - 4 are the protocol version (00000 for protocol 0, 00001 for version 1…)

In the future coordinator should be able to keep track of what protocol each 
remote module speaks so that their code will not have to be updated 
immediately.  The switch from version 0 to version 1 will require new code on 
the arduinos however, so I’ll delay the switch to v1 until later.  The 
interface for the drivers will remain the same.

I have some ideas for version 2, but would like to see what types of remote 
modules we are making (and how well version 1 supports those designs) before 
deciding what features it should support.  

--  
Jonathan Nelson
[apparatus-templi] Milestone 1

Other related posts:
