Hi there,
I’v tested the firmware v1.03 in the trunk fo svn on my rfbee(hardware v1.1), it works also ok on 868MHz with daterate 76800 and 1200bps.
I will look into the software v1.1 and do some debugging later.
Regards,
-Icing
Hi there,
Did some test, and see the updating of google code r27.
Changes:
1.Set rfbee into proper state after tx,rx, as in seeed v1.03.
2. Remove the delay(5) after CCx.Strobe(CCx_STX) in transmitData().
Reason:
ATCF0~3 all works now.
Issues:
The data length you send to the rfbee should be the same as the threshold every
time. Otherwise, the receiving rfbee will receive invalid data endlessly as rich has met.
The problem may exist in:
Transmit process.(As I use v1.03 as transmitter, v1.1_r26 as receiver, it works
ok). And I dont think it is the interuption by the other signal in ISM surrounding us.
Regards,
-Icing
Icing,
did some major rework , see the updating of google code r27.
Simple config only commands (e.g. atth etc) are now handled in a standard way (modifyConfig)
AT commands that actually need to do something (e.g. ATCF to change config and CCx settings) follow the standard way and then, as post processing call a function defined in the command table. (setCCxConfig() for ATCF)
Commands that don’t change config (e.g. ATRS), have 0 digits, and therefore only execute the post processing call.
The 915/868 is still a mystery to me.
Over here ATCF0 and ATCF2 works, but ATCF1 and ATCF3 not.
seems like the 1.2 baud is picking up noise in my environment as I can not think of another explanation because it seems to work in your environment.
If you have some time, can you load r27 on your end and see if CF0~3 all work ?
I use threshold value 1 and overflowing that produces no errors.
Could be though that CCx_PACKT_LEN needs to be shortened to 61 as per section 15.3 of the datasheet (CCx_FIFO_SIZE - 3 bytes)
So that if you try to send say 80 bytes at once, it will first send 61 and then the remaining 19.
Cheers,
Hans
Just updated. I will try to test. The two devices where so close last time, that no other possible radiator would have had a chance. (I am a ham and I am well aware of where all the transmitters around me are located. noise sources are something I am always having to find.) I was concerned of possible over drive issues given the .25 M separation.
Rich
Hey guys,
Looks like you’re all doing a ton of good work. I’ve been lurking around a bit and trying to get the firmware on my RFbees up to the latest and mostly working files. I took all the files from the Google code library, compiled, uploaded, and I was faced with this:
[size=85]rfBeeInit:
setCCxConfig:
setMyAddress:
setAddressCheck:
setPowerAmplifier:
setRFBeeMode:
ok
writeSerialData:
receiveData:
writeSerialError:
error: received invalid RF data size
writeSerialData:
receiveData:[/size]
and on in to infinity.
Issuing an ATRS met with no results. I’m running hardware V1.1. This has happened on all of my units. I know I should be able to revert to an older firmware.
Here’s the thing… I have a simple wireless job I’m trying to run, literally I need two bytes of data to set some LEDs on PD5 and PD6, so I figured the RFbee would have enough residual horsepower to at least pull that off. I know we’re up against a RAM wall here, so this is why I’m looking to the newest code, since it looks like you guys have been doing a bang-up job of getting the RAM size down. What exactly is going on here? Is it that the EEprom is set up with disagreeable values? The firmware compiles OK, but is there a chance that I have different files from different versions? Where do I look (in google code I assume) for the whole package of the latest firmware? trunk? branch?
Thanks! (and forgive me if I’m in violation of the open source code development protocol, I’m just some yahoo trying to make a public art project happen here in Brooklyn!) I’ve done plenty of PIC programming and a whole bunch of electronic work, so I’m not a complete newbie, I’ve just never participated in an open source project.
Regards,
Andy
Hi Andy,
The latest firmware you are using is still not reliable as I met the same error as you. You may try this: The data length you send to the rfbee should be the same as the threshold every
time, otherwise, the receiving rfbee will receive invalid data endlessly. (However, it does not happen on Hans)
If just control PD5 and PD6, I think firmware v1.01 is no problem, and you may need to do some small changes in the ISR receiving function.
Yes, firmware v1.1 has much free RAM than v1.01 or v1.03, and the structure is more clear. However it is not steady now.
Yes, the data perestored to the EEPROM is different.
Use SVN you can get different versions(latest or older) from branch.
seeed is trying to do more open source project, and we are glad to hear any suggestion or advice to make the platform much better.
May this helpful to you, and feel free to ask any question!
Reagards,
-Icing
Team,
@Andy: welcome to the project and the team 
I just committed rev 29 at rfbee.googlecode.com/svn/branches/v1.1/RFBee
In this version:
- Changed CCx_PACKT_LEN to be CCx_FIFO_SIZE - 3 as suggested in section 15.3 of the datasheet.
- Switched #define debug off
- Added a Serial.print(size.DEC) to the error routine of receiveData to chase the “invalid RF data size” bug.
@Andy and Icing: can you try this version and let me know the value of Size ?
Cheers,
Hans
Team,
about the firmata integration:
I have been looking at the firmata source for arduino and posted a message on their mailing list. But it all is pretty silent 
Yes I am sure we can make it to work, but I’m in serious doubt whether firmata is the right format as the project seems rather ehm dead…
Any suggestions appreciated,
Hans
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