RFBee firmware updating

Thanks Rich,

Yes… the power budget is a problem. Currently, we have the LEDS dropped down quite a ways so they’re only drawing about 6mA each… We can obviously cut the LEDs down during the day…and yes, it draws down to about 18mA

The problem is the “client” and I take liberty with that word because this is a charity project… but the client is killing the power budget by putting the solar cell BEHIND A PIECE OF MILKY WHITE ACRYLIC… As it is, I’m lucky if the cell even puts out 50mA, so really at this point, the solar cell is just there to make the batteries drain more slowly - One step forward, two steps back sort of thing, so I want to be able to cut daytime power as much as possible. I’m having a hard time convincing them that the aesthetics of a NON working project are worse than a little black square as viewed from a hundred feet at night. Protesting only got me so far. OK enough complaining - Maybe some kind of watchdog timer that will wake it every 10 minutes or so, and check the solar level. If it’s still sunny, it can go back to sleep. Biggest problem is that I don’t know the language that well -I’m a fast learner…but still… a watchdog timer sounds the best. My question is are there any timers still available on the chip? Maybe I should stop sleeping myself!

Thanks guys!
Andy

Team,

the watchdog is part of the atmega168 CPU, so you can use it without additional electronics.

@Andy:
As you don’t need to wake on serial input, you can really put the whole bee to sleep, let it wait for the watchdog every 2 secs and if the 5 or 10 mins haven’t passed, immediately jump to sleep again.
Then after 5-10 mins you start darkness detection, if that fails (i.e. its still light enough) start the whole round again.

Depending on required response time you can play with the wake-on-radio timers of the CCx. However if you stretch this, it could mean you loose packets.
So if you have a central command radio (on grid power), it could output a continous stream of commands.

e.g:

00
00
00
88
88
etc
which means that when a packet is missed the next reception might pick it up.
However, as Rich mentioned the Leds will most likely be killing your power budget way more than the rfbee.
(rfbee with CCx in powerdown and atmega in Idle consumed about 1.1 mA and with atmega in deep sleep it will consume even less )

So you might want to focus on that:
a) If you can get away with different light intensities during the night (e.g. more brightness during twilight) that be a power saver.
b) If say most visitors view the installation before 2AM then you could put the installation to sleep (e.g. by radio command) so the leds don’t need to light until daylight.

With regards to the milky white. Try to get the piece above the solar cell as thin as possible (maybe even foil ?) Or try to get it in such a way that its an optical illusion. Eg. if you have milky white dots , it already looks more whitey, but still lets in much more sun than behind 3mm white acrylic.
Last but not least you could try to put the cell on the harbour facing side, so visitors can’t see it

Looking at the code you posted it looks like the modifications you have made are still minor. If that is the case I advise you to upgrade to the most recent version and apply your code there, as its more robust against timing issues. If you don’t have subversion you can pick it up here:
http://code.google.com/p/rfbee/source/browse/#svn/branches/v1.1/RFBee

@Rich, I have been thinking about having sleep as ATMD5, however as the CCx is not able to send nor receive immediately after sleep, I decided to make it ATSL. As soon as the rfbee wakes it will continue in the mode it was before being put to sleep (e.g. Transmit, Receive etc). That’s also why I made it return to serial data mode.
If you all think that’s a mistake we can always make it ATMD5 again.

Using ATOF to switch between decimal and binary for reporting sensor readings like a sensible move to me. If you use the same semantics then 0-2 will still be binary and 3 will be decimal output.

I was thinking about a WOR mode as ATMD5, which is basically a variant of RECEIVE_MODE, but now with the atmega in deep sleep and the CCX in wor.

What do you think ?

Cheers,

Hans

Okay the watch dog time is the timer you should be using. It is the only one that is still active in the deepest sleep, and is designed for things just like this. The other on board timer(s), I forget how many the 168 has, do not function in a deep sleep. The JeeNodes link has the code you need and I thought a good explanation of the use. You can always ask specific questions, and I will try to answer. Sigh on client understanding. I hate it when they want to violate the rules of physics to conform with their lack on understanding. Been there done that many times. The watch dog timer is at its slowest faster than you want, so a tight loop counting and sleeping is the answer. Then every n seconds/minutes you can sample the light a few times and decide if it is getting dark. Keep the last 3 to 10 samples, and a running average of them if they are minutes apart that should give you a good indicator of when it is getting dark.

I will answer language question on a time available bases.

Great work. I gave it a little thought and this is what I came up with as feedback. Again have a great vacation.

Frankly I think WOR should be a sleep argument to the SL command not a mode, as the previous mode should be unchanged. This is the issue I have with the current low power, it really isn’t a mode like the others. Is Low Power really a mode, or simply better controlling of the radio subsystem. In WOR Low Power I do not see that the users should notice any change in behavior.
(Is this correct? If it is I will argue for it being the normal state.)

I view it as there are several general states here.
Reduce Power until event occurs, where event is anyone of
WOR
Interrupt received.
Serial received.
To me this is not a mode, but a efficiently wait state.

    Hibernate, ignoring Local events, other than watch dog if independently enabled.
            WOR
            WatchDogTimer  if independently enabled.
            External circuit trigger.
                    This is sleep on radio, node is a remotely controlled slave.

     Sleep.
            Radio traffic ignored.
            WatchDogTimer  if independently enabled, or other external wakeup
            Serial data ignored.
                     Shutdown for until locally kicked or watchdog.

There is one more option to complete things, but its value is not as clear to my fuzzy thinking.
Turn off radio, but leave the 168 going. That is this is
SleepRadio, but save state.
168 is uneffected. Radio is pwr’ed down until wake. This is the best candidate for a MD to me. This is really Mode radio power downed, and until an ATMD is issued to wake it up and set the resumed state it is powered down.

Is there a need for IDLE radio, not sleep, not WOR, but just stay in the IDLE state? This condition is implied by transmit mode, where the radio goes to this state when there is no data to send, but does this state as a mode need to exist? This is leave the radio up and calibrated, but not doing anything. It is clear that this state is used, and may speed the transition to other states. I am just not clear if the speed up it offers is enough to expose it in the model.

@icing
I was reading the datasheet, and I noticed it claimed 2 analog inputs. This is confusing me because, 1 10 input, adc7 is mapped, but adc6 the other does not appear to be brought out. Now from reading the 168 datasheet 6 of the PortC pins can be made analog inputs, 8 bits, but that doesn’t add up to 2. Can you clarify what is meant here? I am simply curious as Hans has things working well enough I am getting read to try so configurations with sensors and the like.

Also since somebody asked I was thinking of connecting the i2c interface in a slave config. the pins are mapped so it should fly, but I thought I would double check.

Hi rich,

Thanks for your updating.

The PC0~PC5 and ADC7 should be all analog inputs, except the PC6 which is not lay out.

The I2C is also available as they are multi-used with PC4 and PC5.

Regards,

-Icing

Okay that means I read the wiring diagram correctly please add this to things to fix on the documentation. It claims 2 analog inputs. Although If you do a new ref, I would recommend bringing out the other port.

Rich,

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 ?

Cheers,

Hans

Hi Hans,

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.

Regards,

-Icing

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.

Team,

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.

Cheers,

Hans

Sounds good, I will try some test on the current pool. If you want me to review any documentation send me a note.

Thanks, as soon as I have something tangible I’ll post it for comments

Team,

I just committed an updated version of the RFBee manual:

code.google.com/p/rfbee/source/b … 20v1.1.pdf

Cheers,

Hans

The current source still has some wakeup messages in it. It appears a set of ()'s are missing.

Also factory test is left on so I get an io error message on startup.

The toc in the docs is boxed which seems funny. Outside of that things are pretty good.

Fixed the sleep and wakeup prints (thx Rich ) in rev 43.

I don’t get a boxed ToC in the docs, what PDF reader do you use ?

Cheers,

Hans

Apples preview.

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.

Cheers,

Hans

Hans are you still working on this code base? I have encountered a few problems?

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