RFBee firmware updating

Glad you had a great vacation. While you were out I spent some time playing with XBees to understand how they deal with these issues. This post will summarize what I have learned.
To configure ports that have a set of AT commands D0-D9 and P0-P3 as well as M0 and M1.
For the D? and P? the values 0-5 that configure the available pins. The values are 0 disable, 1 some form of enable if the pin has a standard use on their boards like an LED or button. 2 analog in if appropriate, 3 digital in, 4 digital out low, and 5 digital out hi.

For sending values they have several other params. IR which is the report interval, ST which is the time until it goes to sleep(WT makes more sense, but I am reporting what I learned.), SP for sleep period, IC which is a BITMAP of which pins are being monitored for change.
SO is for sleep options, 0-6 I can report more on that if you like.

So to monitor a pin you set the pin mode with ATD0n (n=0-5) set the reporting interval ATIRn(n=16bit value in ms units), ATSPn(n=16bit units are 10s of ms) the sleep mode ATSOn(n0-6) and/or ATIR(16bit mask of pins). Then everytime it notices a state change, or IR ms has past while awake, it sends a 2byte hex code of the digital pins with those selected as inputs reported( I believe it skips this if no digital inputs are selected), the rest 0 then a \r and if any analog values are being monitored they are sent one per \ras ascii numbers. If the unit is asleep it sleeps until the sleep pin is manipulated or the time period expires, then it wakes up for ST ms reporting changes vi IC or every IR ms. M0 and M1 let you set the pwm output value of the two pwm ports that they have.

To query values you can use ATIS and it generates the same output. Unfortunately there is no AT command to query a remote node, that can be done via their api, but not via AT that I could find, although I know I once found the command to connect to the AT processor of a remote node, I can not make that work currently.

They have a few more modes dealing with counting syncs of coordinators and missed syncs, but I think this captures most of it. Almost all the pins can be remapped this way. They also have a WH which is a send a character to the localhost to wake it interval. The IR and IC triggered packets are just sent to the output data stream across the radio. To poll with the API you send the remote node an ATIS, and get the output back in response. API mode is a different set of firmware that is designed for uprocs to speak to each other with. Each command in the AT set is sent to and address with variable input data, and a binary packet is sent in response which is sent back to the requesting processor as a packet. Basicly all AT commands are designed for humans, and a packetized version exist for programs. When you configure a node you pick API or AT firmware and load the one you want. There are a few things like polling an IS command that are only in the API, but the rest is in both.