Icing,
small question: did you ever get the RFbee (e.g. 1.03 or older) working on 868Mhz ?
ATCF 2 and ATCF 3 do not give me a working connection, now it could be that I need to play with SmartRF Studio, but it would be nice to know if it ever worked before 
Cheers,
Hans
Hi Hans,
Thank you so much for your committing! 
Well, it’s ok,and I ever thought of that. However if threshold is set to 1, it will decrease the transmit efficiency. We need to give advice to users to set the threshold as long as possible.
Yes, it will be very well and is much easier to implement in your new version than seeed v1.0.
The rfbee(hardware v1.0) works ok in 868MHz, and we’v tested that. However, rfbee(hardware v1.1)is not tested in 868MHz, so at which frequency we not sure if it works ok with software v1.0 or v1.1a2. As it is in weekend, I do not have rfbees in hand to test that. You may use sofware v1.0 to test the new rfbees working in 868MHz.
BTW, I also met the similar problem as I was debugging the code you committed(using hardware v1.1). As I use v1.03 send data in 915MHz with datarate 1200, the rfbees can not transceive data with each other.
However, when I use one rfbee with software v1.03 send data in 1200 datarate to the rfbee with sofware v1.1a2, the later received. So it is the problem of the transmitting with v1.1a2.
I checked the difference of the settings between v1.03 and v1.1a2, they are the same.
This also made me confused.
So I guess the biggest difference between two version is the state of rfbee after transmitting.
In v1.1a2, the rfbee retrun to idle state, while in v1.03 the rfbee stay in transmit state. I also met this problem even when I debugg the software v1.1a2 working in 915MHz, so I add delay(5) after transmitting in function transmitData().
May it useful to your debugging. And I’ll look into it next week.
Regards,
-Icing
Icing,
just commited R25 with the small suggestions applied. ATMD is now persisted and ATTH now has 1 as default.
I loaded my bees (hardware 1.1) with firmware 1.01, 915Mhz works fine, but 868Mhz fails.
I would expect that it does not matter for the CCx whether it sends on 868 or 915 apart from some clock pulse. My first guess would be that we need to fix another clock parameter, or need to give the bee more time to rescale the clock. When I have some time I’ll check the datasheet to look for clues
Cheers,
Hans
Great work I will be testing here seeing if I can figure any of it out. This is becoming much easier to work with. I like your firmata suggestion. I am off to look into that more, but it seems like what I was wanting. I am still seeing very random communication where it works well for a short while then stops for quite a while, then starts up again. I am seeing more errors than before which i few as a good sign, but there is still clearly some confusion. Also I noticed the size is down!
Rich,
random errors could be due to interference with other devices in the neighbourhood. (e.g. weather stations etc)
The ISM band (see http://en.wikipedia.org/wiki/ISM_band ) is pretty wild west. The only way succesfull transmission is possible is because it is assumed (dangerous word here ) that all transmitters only send a small percentage of the time (e.g. less than 1%). Most devices I have seen will send the same message 3 times, hoping that at least one instance will survive collisions with other transmissions. As 915Mhz is uncommon in Europe, I get perfect transfers , as soon as I get 868 working I expect to see more collisions.
Alternatively one could use a ack protocol to get a more robust stack. Or if you want to be creative (:-)): something like automated channel hopping, or a micro tcp/ip stack
Cheers,
Hans
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:
@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:
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”