RFBee firmware updating

Hi Team,

Thank you so much for the updating.

Hans, you are right, CRC OK does not mean packet is fly passed to the FIFO, which causes the problem we met. The setting of GO0 to 0x01 can solve this problem.
However, I still found several problems:

1. When in ATCF1~3, RFBee doesn’t work well, as the receiver can receive only one byte what ever the transmitter sends.

2. In ATCF0(default configuration), the RFBee will receive some nonsense bytes when keep it silent there. I think it is the interruption of the RF signal around it. And when we set GDO0 with 0x01, which also means it has no CRC, the interruptive RF data may be received by the RFBee.

How about your testing result?

Regards,

-Icing

Hi Andy,

If you don’t like the 2mm pitch sockets, we can change them to the pads which can be soldered on your mother board, which will make the assembly much thiner.

Or if you have any special demand, please free to ask.

All the best,

-Icing

Icing,

I haven’t tested CF1-3 yet. However if we can get this to work for CF0 then I don’t see why we could not make this work for CF1-3.
(but hey, I’m optimistic )

I’m sure we can filter out noise by checking the CRC bit [7] of the LQI byte. (I’ll fix that)

In the meantime I have Wake On More or less working (RFbee claims it goes to sleep and wakes from both serial and radio), however the savings don’t seem to be very significant. Using my multimeter I measure 18mA with ccx in WOR and atmega in SLEEP_MODE_IDLE which is pretty disappointing as a fully active Rfbee consumes 21.6 mA.
(btw: in my previous post I mentioned mw where I should have typed mA)

Anyways, I’ll continue the search

Cheers,

Hans

Team,

just checked in rev32 (at rfbee.googlecode.com/svn/branches/v1.1/RFBee)
In this version:

• added CRC check in receiveData, so Icing should not see garbage any more
• added decimal output format (ATOF3) , so Rich can read the RSSI and LQI values
• stripped CRC bit from LQI value.
• added low power mode (ATMD4) (which currently does not seem to be really low power )
• moved sleep mode to 5 (ATMD5) to make room for low power mode

I have the same issues as Icing with ATCF2 receiving only 2 garbled bytes or so
ATCF1 and ATCF3 still don’t work in my environment.

So there’s plenty to research

Cheers,

Hans

OK everybody… here’s the terribly hacked RFbee code for the Reflecting The Stars.

There’s a windows test application in there that all it does is send data out the serial port through a UartSB Xbee explorer. The windows software is written BADLY, so be warned, I spent all of one hour on it.

Then there’s the RFbee firmware, based off 1.1.A3. I am not an arduino programmer, or a C programmer, so I did my best. Here’s what I told Icing… I will rudely paste it here.
[size=85]
First… hook up an RFbee to the computer, and start my software
Andrew Baker: open the com port and it will automatically send serial commands to the RFbee to configure it as transmitter. This is OK.
Icing Chang - Seeed Studio: ok, I’ll test it in a minute
Andrew Baker: Now change the unit number combo box to something like unit 2, and click “Burn RD chip to address above” and you’ll see the commands go across to set up that chip.
Andrew Baker: Unplug that RFbee, it’s now set up to be a reciever on address #2. Put LEDs on pins PD5 and PD6
Andrew Baker: Hook a new RFbee to the computer, restart the software, open com ports. The old RFbee we set to “2” will light up both LEDs
Andrew Baker: you can then change the sliders to adjust the brightness of both LEDs
Andrew Baker: When you see the program working and showing commands, you will know how it’s being done.
Icing Chang - Seeed Studio: ok, let me try
Icing Chang - Seeed Studio: However, I have no leds in hand
Andrew Baker: should be no problem, it will put out serial also
Icing Chang - Seeed Studio: only with two RFBees and UartSBs
Icing Chang - Seeed Studio: yes, I’ll look what will happen
Andrew Baker: serial output from the reviever will just print out from 0-240
Andrew Baker: decimal value of one bute.
Andrew Baker: Btyte. If it was in HEX it would be 00-EE
Andrew Baker: first HEX is blue, second HEX is white
Andrew Baker: EE = both on
Andrew Baker: 0E and E0 = one on, one off
Andrew Baker: 88 = both half on
Andrew Baker: 00 = both off
Andrew Baker: and so on[/size]

Just thought I’d throw this out there… I know I’m a bad person for not commenting better or explaining better.

Now here’s a question for the folks smarter than me, and there’s plenty of you…

We have a light sensor on Analogin(7) and we’re trying to figure out the best way to keep this unit asleep in the day time. I’m not an expert in the code, so I don’t know if things are interrupt driven or in a loop, so I ask this…

Somewhere in that main loop, I’d like to do this:

If AnalogIn(7) > 50 THEN DEEP SLEEP for 5 minutes, else REMAIN IN RX MODE

Anybody have any suggestions on how we might implement this?

Regards,

Andy B
RFbee Reflecting The Stars.zip (40.6 KB)

HI Hans,

Thanks for your updating!

The CRC is ok now, and there’s no garbage any more.

I have one question to ask:
In the latest verison, When the Arduino on RFBee is in sleep mode, what’s the condition that will wake it up?

Thank you,

-Icing

Icing,

currently when the RFbee wakes up CONFIG_RFBEE_MODE is set to SLEEP_MODE and the CCx is in IDLE mode.
This is not extremely usefull, as you then need to set antother ATMD followed by an ATO0, I decided to create ATSL (see rev 33)

The commit comment says it all:

If you think we should alter this behaviour, just let me know

Cheers,

Hans

Andy,

the challenge is to create the “void deepsleep( 5 mins)”
As you can see from the code we know how to sleep, but now the question is how to wake up after 5 mins.

That can be done using a timer, however if you really want deeeeepsleep the timer will also need to be asleep.

And thats where the watchdog comes into play, this is a mechanism outside the core CPU that can be programmed to generate an interrupt every x milli up to at 2 seconds. Since you want 5 mins you just need the something like the following:

void deepsleep(volatile int secs){
enableWatchdogInterrupt(); // config the watchdog to wake you up after the 2 secs
while (secs > 0){
lowPower(SLEEP_MODE_PWR_DOWN);
// this is where the code resumes after wakeup
secs -=2;
}
disableWatchdogInterrupt();
}

See news.jeelabs.org/2010/06/20/batt … sure-plug/ for details .

If you need more help, just let me know.

Cheers,

Hans

So I missed something here, so I am asking a few questions to clear up my understanding.
Currently there is no ATSL, or I can’t find it in the sources. So the only sleep is a ATMD5 which sleeps until?
(I am guessing that it sleeps until a command to change mode is received. This appears to do a deep power down of everything. From what I read into your comment this can be woken on serial input and that is about all. Is this correct?)

You are proposing adding an ATSL sends the system to sleep until? (From the quote I believe it does so until a character is received on the serial port, but that seems very close to ATMD5 other than the radio mode is preserved. This seems a bit funny to me as you were in command mode, so this is a sleep and wake not in command mode. Is that correct?)

It seems highly likely that what one would want to do is sleep for a set of expressible different conditions. One as Andy is trying to do is sleep for time interval, then wake and resume radio mode. Many receivers I have can be set to sleep for n ms and listen for a period p ms. This is done so that battery life is extended when nothing is there to be heard. Is this a space under consideration? I am not as sure about this, because for me this is mostly useful for the concentrator end which is not the end I worry about power at as much as the sensor end.

For a sensor I think of environmental sensors like temp, light, Rel. Humidity, flow, distance, or level.
I can easily a remote rain gauge around here not needing to say anything for 6 months or more, other than a periodic, I am still alive message. To me I would like to be able to send the values associated with a set of pins, like the current voltage, and sensor pins. Here I want to define the pins, intervals, and have it transmit values until some intervention occurs. Basically I am thinking of setting states/thresholds, and intervals to use when above or below these values.

From a ack perspective I am actually thinking of a remote go to sleep for a long period. So a sensor wakes up and transmits until the receiving unit sends a go to sleep message. So I am thinking about a remote go to sleep command. Go to sleep be sleep for time, or external event like interrupt or serial command is received.

This way the device wakes up and periodically transmits the sensor value, until told okay go back to sleep.
With remote sensors it is very reasonable to sleep for minutes to hours, wake up, report status a few times and go back to sleep if nothing of note is occurring. This is kinda of Andy’s request for sleep until the ambient light is below a threshold, and a several minutes of error probably a non-issue.

I am debatting if I want to implement a manual relay mode or not. In my current thinking I am not until I find a case that requires it, but not a XBee retrans type situation. XBees already do that so if I can’t do something better, why not use one of them?

Sorry I missed the update. Now I have ATSL. Why does sleeping imply leaving command mode? (I feel I am missing something here?)

It appears that ATSL is minimal sleep the AVR, and pwr down the radio, and recover.
ATMD5 is gone.

Is this the current state?

Rich,

the most recent version is the one with ATSL.

Currently ATSL puts the CCx in powerdown and the Atmega in Idle mode and sleeps until a byte is received via the serial port.
ATMD4 (low power mode) currently puts the atmega in idle and the CCx in Wake on Radio.
This means that a oscillator on the CCx will wake the radio every few ms and if no signal is detected, puts it back to sleep.
By changing CCx registers this can be extended to let the radio sleep for hours.

The problem however is not sleeping but waking up.

The reason for using atmega IDLE sleep is that one can wake up using the serial port without any extra electronics.

The reason for using a short Wake On Radio cycle is the problem that if you sleep for longer periods (e.g. hours) it will be hard to know when the rfbee is awake. In a Controller -> Sensor scenario that might not be an issue as the controller can ping the sensor for hours and as soon as the rfbee wakes up it will pickup a signal. But for other scenarios it will be less convenient. As there will be many variations possible in this area I find it hard to code a command line interface for that. If one wants to do such things I think its easier to pick up the current source code and modify it to ones exact needs.

If we put the atmega in a deeper sleep, there is no other way to wake it up than via an external interrupt or via the watchdog. That’s all possible but the exact requirements depend on the application. If you look at Andy’s problem, he basically wants to sleep till its dark. That can be done quite easily, but its rather specific and depends on electronics outside the rfbee (light sensor on analog 7). As we don’t know what applications the rfbee will be in, the generic firmware should IMHO provide enough tricks to do basic stuff out of the box, but should also provide enough hooks for people like Andy to modify the code to fit their specific application.

It is very much appreciated if people share their customizations like Andy did, so others can use their tricks and ideas to build their own custom logic.
Now the question is of course: what functionality should be in the generic firmware ?
Any specific suggestions in that area are much appreciated ! I hope you like the ATOF3, as its implemented as a result of your suggestion

Cheers,

Hans

Andy,

on more suggestion
Apart from using the watchdog timer you could also use the light sensor itself to create an interrupt.
I’m no electronics guru, but using an opamp you can measure whether your light intensity goes below a certain threshold, if thats the case you pull a pin of the RFbee high or low and use that to trigger an interrupt. That interrupt will wake the RFbee which means that the RFbee will be fully asleep till dark.

Things to watch out for are of course clouds, raindrops, bird shadows etc which temporarily reduce the amount of light coming in

Cheers,

Hans
ps. as of Monday I’ll be offline for a few weeks due to annual leave…

Yes I did appreciate the OF3 implementation. It allowed be to dump my local customizations. Things are getting to the point that I hope to start experimenting with remote control commands and pin sending commands. (Set pin mask, set period. A value per pin is sent to the configured address at the specified frequency. In thinking through the design I have been playing with the idea that the OF flag should control whether it is sent as binary, or ascii data. What do you think?

Also in reading Andy’s stuff I am wondering about the watchdog timer. Is that a fuse setting or an external circuit? If it is all built in, I will definitely look into a local/remote sleep until watchdog timer, or interval has past.

So ATSL is sleep radio off and the 168 idled. Low power is nap the radio, but wake up if something is heard, and wake up if anything happens to the 168. The current code is clean enough that you are correct one can implement any variants. The thing that is confusing me is that ATSL which is a command(Sleep and exit command mode), and ATMD4 which is a mode seems a little off. Shouldn’t the mode be what it was, and the different sleep options an arg to atsl? One could want to be in lower power mode, and tranceive, or receive mode at the same time.

Anyway have a great vacation.

No you are not a bad person, just average.

Okay first question I have is how low power do you really need. You have a solar cell, so you have power during the day, is IDLE a deep enough sleep to allow the battery to be charged? It seems it ought to be enough to me, but I do not have your energy budget in hand to be certain. Why push the edge when you probably have more energy than you need while the sun is out. Backporting Hans low power mode seems like a quick easy way to go to minimal power, but before you try to do more than that I would be certain you need to do more.

At night I can see wanting to idle more, to prolong battery, but you need the timers on so you can’t go much below idle and still have them. Unless the watchdog can be configured to the period you need for timers. (This sounds like alot of work, so I am not sure it makes sense.) The rfbee in low power will save you some power as well, but you may need to send command a few times to be sure that they take. On the other hand with the LED on you are almost noise in the power calculations, or so it seems to me. Hans said he had low power down to ~18 mAs, that is not great, but it is very little compared to a bright LED. 3.3 * .018 = .06 Watts so If you have a 1/2W to a 1W solar cell, it is hard to see why you need a lower sleep level during the day.

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