I had the same question about the life in firmata, but it seemed like the right idea. I am still prowling around trying to find an alternative.
The size I always get on the invalid rf frames is zero.
Rich,
do you get the zero’s only when your other rfbee is transmitting or also when its quiet ?
Cheers,
Hans
Hi! Me again…
So I thought I’d share the news…
Using the 1.1.a3 firmware, I was able to get my project going by inserting a few lines of code in the main program, just as the serial data goes out… one byte at a time, first four bits scale and control PWM on the first LED, second four bits to the next LED, and it pretty much went off without a hitch. I’ve since handed it off to the interns to figure out the power saving and other battery management stuff. The solar cell is monitored on pin 7 (reffed’ against the battery voltage) so we can figure out day and night, and the interns are going to figure out some wake-on-radio stuff. That will be useful, because as it sits, I think the whole board draws around 30 mA when powered up. I’ll be sure to post the code if we come up with anything good.
Also… this is what we’re making - PUBLIC ART!
thewindmillfactory.com/refle … stars.html
I have gotten 0 with only one powered on, or with both up and occasional data transfers working. The scanners and wide band receiver are not detecting much energy in band so I am really doubting that noise is the issue.
Hi Andy,
Have looked your great project, it’s really amazing and fascinating.
Here is my several questions and you may need to consider:
- How many nodes you may need?
(As the max number of hardware address of RFBee is no more than 255, if need more, it can be implemented by software.) - What about the longest distance?
(The longest communication distance of RFBee is about 150m with datarate 1200bps in best situation.)
Sorry I do not really understand “and it pretty much went off without a hitch” for my poor English.
Current firmware does not do the wake-on-radio part, however I have tested this function in our earlier version. And you may find there’s some code commented in InitCCx() in version v1.0. Maybe that’s useful to you.
Again, thanks for your updating!
-Icing
Andy,
looks like a nice project 
If you need more than 255 devices per channel you can just add an address to the packet data. In the old days the OSI protocol used 40 bytes address space and one of my collegues once calculated thats enough to address all objects in the universe 
Wake on radio (WOR) will reduce power usage on the CCx. By using interrupt receive on the atmega you can put the atmega to sleep as well, saving more power.
More details on sleeping can be found here: rubenlaguna.com/wp/2008/10/15/ar … the-usart/
And if you really want to read a lot on powersaving: news.jeelabs.org/tag/lowpower/
@Icing: should we extend rfbee sleep mode to letting the atmega sleep as well ?
We could define a ATSL to define sleepmode. E.g.
0- WOR for CCX, IDLE for at168 (radio reception will work, serial will still work)
1- WOR for CCx, STANDBY for at168 (radio reception will work,serial will take some time to wakeup)
2- SLEEP for CCx, SLEEP_MODE_PWR_DOWN for at168 (lowest power consumption, but longest wakeup time, WOR will not work)
etc
Cheers,
Hans
ps. “without a hitch” means “without a problem”
Did a bunch of testing, and a couple of local fixes. I will check them in if you want.
First the Serial.print(s) for the address rssi and lqi are missing DEC args.
Second I added some formatting if those are turned on
So I did some keyboard to keyboard testing, and this is what I get on one of them now.
The last line is messing 3 characters as well as the address info? I am going to poke into to this, as it came after I typed the 4th char, but something is going wrong that the addresses did not come out. I am suspecting this is not a ccx bug, but somewhere else. On the return path things slightly different, in that I get “, 3:” for the address??? and I see the same occasional failure with one char, followed by the rssi-lqi. I added the formatting to the address and rssi stuff so I can see the boundries while debugging.
I got a couple invalid rf data, but all without size. so I think it was this one i hit
stat=CCx.Read(CCx_RXFIFO,len);
// payloadLen should be total size - 3
if (*len != (size - 3)){
Rich,
I left the RSSI and LQI intentionally as a byte and not the decimal version because else its hard for software to determine where the RSSI ends and the LQI begins
This could of course be solved by proper formatting, but that would make the serial protocol more complex.
The problem you get with the:
if (*len != (size - 3)){
is probably because size = 0 where size should be (payload length + 3).
The 3 bytes are the first byte (length) + the last 2 bytes being RSSI and LQI.
Payload = source address, destination address + data.
Now the question is why CCx.Read(CCx_RXBYTES,&size); returns zero for size in your setup ?
According to section 20 (page 54) of the CCX datasheet we should only be using the CCx.Read(CCx_RXBYTES,&size); for packets longer than 64 bytes,
but as we limited the size to 61 the received packet will always fit in the fifo, so if we are fast enough to read it out before the next packet arrives we should have no problems.
So we should be fine to ignore the CCX_RXBYTES and just read the packet from the queue. Simplifies the code (less bytes ), and avoids false positives for errors which don’t seem to be errors. What do you think ?
Cheers,
Hans
Hi there,
Thanks for your updating!
Hans,
That will be very good, which I was always wanting to do. And thanks for your valuable link
This is much easier to understand to me 
Rich,
I did not do the test, but I guess I may encounter the same question as you. I think Hans is right, especially the size of CCx_PACKT_LEN may have some influence which I ignored on the datasheet.
Maybe we could have a try, though it seems not much reassuring.
Again, Thank you so much!
-Icing
Team,
I can get the atmega into sleep, recovering from idle sleep also works, but I need to spend a little more time to recover from power down
Also having sleep as the 4th mode is not that convenient as its unclear whether the bee should bee in transmit/receive/transceive mode after wakeup…
I’ll give it a try to sort it out and to also include the WOR stuff, might take some time though
Cheers,
Hans
Team,
thought I’d share some measurements
(measured with a hobby multimeter)
in Transceive/Receive mode (atmega + cxx fully active) the Rfbee consumes about 21.4 mw
in Idle and Transmit mode (ccx idle) 6.1 mw
in sleep mode (ccx powerdown, atmega SLEEP_MODE_IDLE) 1.1mw
so thats about 20x more battery life by just going to sleep. Mind you: in SLEEP_MODE_IDLE the rfbee still responds to serial commands !
The deeper the sleep the bigger the savings
Next up: wake on radio !
Cheers,
Hans
okay I will not check in my formating. I kinda view the outputing of those fields as mostly for humans, as a program could call the interface directly. I don’t think fifo size is the issue as I have been operating keyboard to keyboard, and watching the packets come every n chars where n is the threshold size. As such the total bytes in both fifos is not more than 9-10, when i was testing 8 bytes sending I could get a char or two ahead. No way did I ever get a whole packet behind.
More testing, more data.
If I type slowly I can get several transmissions to go back to back. If I paste a longer stream, I get the first packet, then errors. The errors do not always come out the same. Some times I get an empty packet, with a good rssi/lqi other times I get error: received invalid RF data. If I send another packet it frequently goes into the infinite loop 0 bytes received error case.
If I paste the string “abcdefghijklmnopqrstuvwxyz0123456789” known to be 36 characters in length it sends the first 8, my current threshold, and give an error: received invalid RF data. If I send again I get the infinite output. Note that I did not get the 0 on the first error.
error: received invalid RF data size
0
error: received invalid RF data size
0
…
Can someone tell me if they see the same thing. I have two windows open one to each RFBee, and I paste the above string into one with the two devices configured in transceive mode to talk to each other.
More testing data. Threshold set to 8. I can send 8, or 16 bytes at a time successfully. If I send 26, only the first 8 come through. Once I get the error, any input or output on the receiving unit will go into that error loop. Sending 18 bytes works as well, as long as the total at anyone time does not reach 3x the buffer size. That seems to reliably fail
Occasionally I see errors in smaller groups, but this always causes the problem for me. So I can past upto threshold3 -1 without a consistent error, but threshold3 and above only receive the first packet, and get an error. Hope this helps.
Rich,
I see your problem too !
Using the newest code (rev 30 at rfbee.googlecode.com/svn/branches/v1.1/RFBee), putty as serial terminal and after ATRS, the following happens:
- I copy/paste abcdefghijklmnopqrstuvwxyz0123456789 on the sender:
however the receiver shows:
abcdefghijklmnopqrstuvwxyz0123 - when pasting again the receiver shows:
abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuv - when posting again the receiver shows:
abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789
so the third paste does not show and after that reception seems blocked. Both bees still respond to +++ and chars typed at the receiver still show up at the sender.
When I switch on debugging on the sender it shows that the paste is send as two transmissions. First 16 bytes and then 20, where the 36 would easily fit in a packet. (txfifofree says 64)
Funny part is that with debug on the sender side active, the receiver seems to get better reception, so I presume its a timing issue.
I’ll try to find the cause of this.
Cheers,
Hans
Team,
seem to have found the cause:
reading the fifo when GDO0 goes high results in a half frame packet, waiting a microsecond in receiveData for the fifo to stabilize solves that issue.
Packets are then coming in stable, however it is a bit of a kludge as we don’t want to waste time
A more stable solution is to change IOCFG0D (GDO0 output pin configuration)
its currently set to:
7 (0x07) Asserts when a packet has been received with CRC OK. De-asserts when the first byte is read from the RX FIFO.
However when CRC is OK the packet is not yet fully passed to the FIFO.
Changing this to:
1 (0x01) Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is
reached. De-asserts when the RX FIFO is empty.
Solves the issue on my side !
Just committed the patch
Cheers,
Hans
Okay version 31 is working much better here. Now I will write some test to work out how strong the connection is. At this point I appear to be able to send lots of data without the errors I was seeing before.
Bootloaders (Because it’s firmware too)
Redundant post, but I’d been messing around with the in-circuit programming. I got tired of it, so I switched back to “Bootloader”, I burned the ‘Arduino PRO’ bootloader. DUMB. Lilly-pad would have been a much smarter choice. I beat my head against the wall for a full day before I figured this one out.
At this point, it’s occurred to me that I may have gotten off easy, since I’ve read that it’s possible to so thoroughly screw up the fuses that you’d need to tear the chip out and put it in a parallel programmer (not going to happen with a SMT) or drive the reset pin up to 12V. At least adding the external crystal pulled me out of this one. It was a 12 mhz one that I had laying around, and it was enough to get me back on track. Does anybody know the actual bootloader to use? For my project, I’m actually going to use in-circuit programming, since 2mm pitch sockets are driving up the cost and the thickness of the assembly, making it hard to get the covers on (for Reflecting The Stars)http://thewindmillfactory.com/reflecting_the_stars.html
Live and learn. Our first prototypes are going out for environmental testing on Tuesday. We need a $3 million insurance policy to nail five stupid soup cans (full of RFbees) to pier pilings. Love that NYC bureaucracy.
I don’t know which bootloader they are usings, I thought it was the arduino 168 stock one. The right settings are for an Arduino Pro 168 at 8mhz in the Arduino ide version 18. The bootloader checks the chip, but not the clock settings, as I found out the hard way earlier. baud rate was off by 1/2 since originally I had it set to 16mhz 168. I mess up fuses all the time if I am not carefull, glad you where able to recover.
I hear you about the insurance, I have dealt with public agencies before, and they are all the same.
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:
-
When in ATCF1~3, RFBee doesn’t work well, as the receiver can receive only one byte what ever the transmitter sends.
-
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