vacation was great, thanks for all the good wishes !
ideally the Wait state (atmega in IDLE, RFbee in WOR) would be the default state, however WOR is less stable than Receive (else TI would certainly have done the same thing ) I’d rather leave the decision to the user.
Hibernate is a tricky thing, because it will only work with external interrupts and basically requires additional custom coding (e.g. like Andy’s project)
thats why I’m a bit reluctant to put such functionality in the default firmware. The hints are there so if some one wants to customize (like Andy did) the pointers are there. Same goes basically with the whole watchdog thing. If one really wants to go this route then it’s imho much more easy to write custom code than trying to create a command structure to capture this behaviour.
There seems to be a bit more life in Firmata again, so I’m waiting for them to come with an updated version which we can run via serial and radio. That would be nice for a 2.0 firmware and might make hibernate and sleep via firmata commands instead of AT commands.
IDLE is indeed a bit of strange beast as TX does basically the same, so yes we could ditch IDLE. @Icing: what do you think about removing IDLE mode ?
I also notice that it is nonsense of IDLE mode, and it’s more compact to keep TRANSMIT_MODE, RECEIVE_MODE, TRANSCEIVE_MODE, LOWPOWER_MODE. And SLEEP_MODE can also be removed as there’s no ATMD5, with ATSL instead.
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.
Icing wants to launch a new batch of RFBees with the new V1.1 firmware. Therefore I rounded up the last changes and commited R41 (code.google.com/p/rfbee/source/detail?r=41)
The log message says it all:
I’ll be working now on updating the documentation.
Just tested in my ipod touch (the only Apple at hand ) and the toc does not show a box.
So it must be something special to your version of Apples preview.
I just dowloaded v1.1 and try to compile in Arduino_021
In file included from RFBee_v1_1.cpp:207:
TestIO.h:5:20: error: config.h: File or folder does not exists
RFBee_v1_1.cpp:305:23: error: rfbeeCore.h: File or folder does not exists
I just unpacked all files to my sketchbook folder.
Also tried to comment out all related to TestIO
Doing some additional demos I have found that the device does not recover well from a receive buffer overflow error. I have been poking at it a bit, and I thought I mention it. I also don’t fully understand why I am getting them in that the totalled transmitted is less than the full buffer size.
I believe the problem is in the handling and that when an overflow occurs some reset needs to occur, but does not until a latter time. Power cycling clears it right away, but sending data seems to eventually clear it as well. If I have one node that is only sending, and the receiving node gets one of these I have to send from the one that got it, before it will receive again. Let me try to get a better characterization of the issue.
I am trying to implement a read RSSI function in the firmware. Currently it will only return max value (255). Has anyone implemented this functionality before and if so, can you point me in the right direction?
) I’d rather leave the decision to the user.