Hi Hans,
Thank you so much for the updating. We will have a test on your new code apha2. 
And we are so glad to hear you can help out with the datasheet. 
It will be in the time when the firmware is ready.
We will consider your valualbe suggestion about the code updating.
Thanks again!
-Icing
Is this code something I should try at this point?
Well, if you want to be sure please wait till Icing has posted a âfinalâ version.
If you are willing to try something and donât feel bothered by reinstalling 1.01 if this doesnât work, then yes you have a reasonable chance that this will work.
Mind my remarks on the receiveData function though.
Having a look at the source code might already give you some insight on how you can extend/improve it (should you want to 
) as the main structure will most likely be ok.
Cheers,
Hans
Sure is not fun. So I loaded it. A couple of comments. I am first just poking at the UI. Please understand my comments are only intended to be helpful, not critical. I like what you are doing.
One data values reporte from AT commands are all broken. They need a â, DEC)â added to the println so that the values are converted to strings, not treated as ascii characters 0x01 and the like. This seemed to fix it for me. I could send the changes, but it is trival to do.
For some reason, it does not stay in command mode. I could not quickly see what the issue was, but you canât issue two AT commands one after another, as one might expect. Normally most devices stay in command mode for several minutes, or until you issue a command to connect on go into data mode.
Why do you echo the length of the transmit/receive string? This was very confusing to me, I issued a command and got 5 back? Then I tested and realized it was saying it got/transmitted 5 chars the length of the command. At first I thought it was telling me the current value was 4, or 5 Now I realize it was the string length and I was out of command mode.
I see now it always goes out of command mode after a single command, I was in the wrong routine. This is unfortunate, but as long as it is predictable I can workaround it.
Also I am confused on baud rates, the tables list 9600 to 115200 as available baud rates, but I find the default baud rate is now 4800? Some where there is an /2 going on. I just reinstalled arduino - 18, and have not done any patches. The board is set to Arduino Deci* 168
That is the setting you said to use isnât it?
I forced a Config reset and it is clear that somehow my clock speed is half of what the Arduino core things it should be. Is this a fuse issue, or is this a slow 168? I have not yet changed any of the configs on this install. I know I have not moved any hand edits over to this install. However it is clear my clock speed is off by a factor of two.
I like the new code style, much easier to work with. I âfixedâ the status print outs in my version and made the command case independent. I also implemented the old ATO0 command to drop out of command mode. I am not happy with the current BD command because the input and output are inconsistent. Not sure which way I want to fix it. Hopefully I will get on to the rf side soon. I agree with Hansâs comment on another thread that we will need a little link level protocol to do all I want to do.
I am still not understanding where the echo back of the character count is from, and I commented out the go back to command mode after every command. I am not sure I like the whole command must be typed in 100 msecs to be seen as a command. That was part of the problem I had with the original interface. I was typing from a tty interface that sent the chars as I typed them. That should work, but neither of these modules seem to be able to handle that. (On the other hand when I try to write embedded code it never fits so I will admit that I am to used to real memory spaces and no limits. This is much easier to understand and modify.)
Found the output of the length in transmit, I added #ifdef debug on that.
Rich,
thanks for commenting ! As soon as the Bees arrive Iâll give it a go myself
With regards to jumping out of command mode, I do prefer the ATO (or ATO0) as well, however since the original firmware only allows for single commands I didnât want to break backward compatibility
@Icing: what do you think ? Should we change the command behaviour from single commands only to allowing multiple commands ? (and switching back to datamode using ATO (or ATO0)).
The DEC is indeed required to get readable output. Case independence is indeed convenient
Your remark on the 4800 baud is a bit confusing to me. Do you mean the IDE is standard on 4800 baud ? On my wintel box the serial monitor starts at 9600.
The IDE totally runs on the PC/Mac side, only the code produced with the IDE runs on the Rfbee, so the version of the IDE does not impact the clockrate of the device.
I just reread the datasheet of the RFbee and it says:
âSelect Tools->Board->Ardunio Pro or Pro Mini (3.3v, 8MHz) w/ATmega168.â
My previous suggestion of usening âArduino Diecimila , Duemilanove or Nano w/ATmega 168â was based on my compilation efforts of the original firmware (not having a device), compilation works fine on this setting, but apparently some other settings are required as well Apologies for the incorrect advice 
With regards to the âlink level protocolâ I would like to suggest to align with the xbee format as it avoids reinventing the wheel
The challenge with devices like this is indeed resources. My last version uses about about 7.5Kb flash out of 14 (16 - 2 for the bootloader) so we still have âplentyâ of flash space. RAM is 2K and unfortunately a bit hard to measure on these critters. Thatâs why I try to retain as little globals as possible, use bytes instead of ints and moved the config tables to PROGMEM (which is flash ).
With regards to the timeout on commands, it is possible to fix that behaviour by changing readSerialCmd().
Attached a new version which solves your issue (and contains the strncasecmp and DEC fixes as well )
Anyways: many thanks for sharing your experiences and your suggestions for fixes.
Hans
rfBeeSerial.zip (2.76 KB)
Ok, I was a bit too quick with the fix, not that I think that I broke anything, but the solution is not complete yet.
The problem remaining is that if you have 4 command chars then its unclear to the firmware whether it should wait for another parameter (SET) or return the current value (GET). Just looked up the âhayes command setâ on Wikipedia http://en.wikipedia.org/wiki/Hayes_command_set and this specifies that any command should be terminated with a (ascii 13).
It also specifies a one second pause after the +++ to ensure not accidentally going to cmd mode. Now 1 second might be very long by todays standards, but I can imagine us implementing a 200ms check or something like that to get the same behaviour.
Implementing both (or one of them ) is easy, but will break backwards compatibility.
@Icing: do you want to go this route ?
Cheers,
Hans
Great if I get a vote it would be for doing those changes, but I want to hear Icing input as well.
Making the UI work I suspected would require \r detection. Your changes more or less match mine. What to you think of the fact ATBD returns different values from the input? That is bugging me a bit.
I tried a simple RF loop back test, and that failed. I need to look some more.
Thanks for the pointer on the correct device setting. That is certainly my problem cause the clock is acting like at 16mhz set would.
I hope you get your bees soon. No disagreement on not reinventing the wheel, but I found little information on the link lvl proto for xbeeâs that did not leave me worried it was too much for what we have here. I understand that can wait, but if we want to make a link lvl change the sooner the better for Seeed I suspect. I do not want to cause them problems, I like what they are trying to do here.
I tried to implement a rf loop back mode, added a config setting and did a send of the receive if set. Figured that would be the simplest way to test out xtrans mode and two rfbees. That way a serial port to a powered rfbee would be sufficient, and I have this conveint ada kit adapter for xbees that take 5v and supplies the rfbee with 3.3. Unfortunately other than a couple rf failure errors it was a bust. I need to think a bit and maybe add a slight delay. I still think it is a easy debug setting that maybe worth considering. I suppose I could jumper the input to the output and that might work? A remote loopback has always been a good test mode for me in the past.
Skip this post if you havenât read it, I figured out what was going on in the next.
No there is another problem I just got the problem to happen both ways. Always get an error, than send a second +++ and get an unending set of errors.
the strncasecmp is not working reliably for me? It works on one sometimes and not on the other. It should work. I changed it to
if (Serial.available() >= 4){
// read the AT
data[0]=toupper(Serial.read());
data[1]=toupper(Serial.read());
if (strncmp(âATâ,data,2)==0){
// read the command
data[0]=toupper(Serial.read());
data[1]=toupper(Serial.read());
for(int i=0;i<=sizeof(atCommands);i++){
// do we have a known command
if (strncmp(atCommands[i].name,data,2)==0){
// call the command function
result=atCommands[i].function();
break;
}
}
}
Which is how I wrote it the first time and that works everytime. I canât tell you why, as either should work.
Okay it is a ram problem. I added two small strings RFBEE and Firmware and ran out of ram at linking, which means we are way over the limit. I guess all the strings go to PROGMEM, and we need to find more data to shove there. This would explain the bizarre runtime things I am seeing.
My first past failed trying to move AT_COMMAND to progmem and a strings_p.h for the const strings, but those seem like the first to go. Followed by the datarate and baud rate tables. Those compare functions can be either rewritten to always look at progmem or have _P variant as needed. I figure if I hit a link error on mem with 2 new commands and 2 strings we are way over on memory usage. That means we have 1k of constants and the like. Icing why didnât you guys use a 328 
Hans are you familiar with the avr gcc progmem stuff? I am still trying figure it all out.
While were at it wouldnât making CONFIG static remove a pointer or two, same for SPI and CCx? There is no way we can have two on this platform. This seems silly to me, but I am clear not of the embedded mind set, and I am trying to figure out the ways of this constrained space.
1K ram is not very much and it seems it is needed for a couple of state variables and stack space, nothing else will fit.
Hi there,
Thank you so much! Hans and rich, your updating is really stimulative to the perfection of RFBee firmware.
Sorry for my late updating, as Iâv been working on the new product Music Shield.
I had looked into the bugs of v1.1a2 submitted by Hans, and figured out most of them, including the baudrate problem, echo data, command mode life cycle, and so on. I had submitted it on the first page.(Still some bugs unsolved)
As for the command mode life cycle, I take the same way as v1.01, which stay in command mode excepting receiving ATMD* command. Maybe it is the most convenient way. Whatâs your opinion?
As for the RAM memory, I think code of Hans version is much better, there should be much free ram space for user application and has much potential to dig out. 
The original purpose of RFBee is just an RF bridge without much function. However, if you guys want it much stronger, we will consider to release ATmega328 based RFBee.
Thank you again!
-Icing
Team ,
bit short on time today. However I got one RFbee working and reprogrammed
(need to fix some cabling for the second one )
@Rich: I added a number of serial.printlnâs without running out of RAM so I presume something else is wrong, you might want to post your full code so we can see what is happening.
@Icing: great to see your 1.1a3, I already had a quick look and as usual I have some suggestions which I hope to post in the coming days.
I checked the Xbee doc and that uses to mark the end of an AT command so I think its a good move to do the same.
(Iâll try to fix it in an 1.1a4 )
Kind regards,
Hans
Good to hear, I will puzzle a bit, and if I come up empty I will post my mods. I was just adding the ato0 command, and a failed attempt at a new config option for RFEcho mode that added a transmit call in the recieve method that switch the input to the output and called the transmit method. The idea was to make one echo everything it hears to the other. ATO0 was simply leave command mode, I would be happy with icing idea as I understood it of atmd# being an implied mode switch. (If I understood him correctly.) My baud rate issue was the board setting of course. I am still a bit bugs by atbd printing a value that is not what one sets. Maybe it should print both or have a variant which is device status that prints everything is human readable format. Personally I would prefer the later as the start up. The current ok implies that we are in command mode even though we are not.
Hmm need to learn this tool chain better. Thanks for the input. I still worry a bit that something is funny, because once I added a couple commands, and a few strings first I started getting intermittent failures. (Things like all commands giving an error response, or an infinite loop if I did +++ twice.) Then I tried a few more and I got a tool error that is simular to the one I get when the code space is too big, but I thought it said data space was the issue. What is the current data size in the image? I need to find the tools for all of these things. I know the commands are all there, but I has been a while since i used them, and learning the avr versions is slightly different for me. I also thought about how small the data space is and realized that I have to be very careful.
Team,
I have been rewriting the AT command parser and Iâm almost done now. Its getting late in my timezone and I donât have the time to test now.
However I do have a question
Since we are breaking backwards compatibility anyways (using as terminator etc) I was wondering if we still need the DR command ?
Its a rather ugly beast now that we have the option to switch across multiple modes using ATCF (once we get that to work ).
Therefore I would like to suggest that we take it out.
Cheers,
Hans
ps. I added the ATO0 as its a natural fit to the standard hayes set
We really ought to setup a code repository somewhere, so it is easier to exchange modules. Sounds like great progress.
Hi rich,
We have submitted our open source project here:http://code.google.com/p/rfbee/, and hope more electronic fans to join in.
If youâd like, you can create google account, and then send your email address to me([email protected]). I will add you as a committer.
Please feel free to ask any question!
All the best,
-Icing
BTW remembering a lot about things, and reading I now see that my current image is using 473 bytes of memory for globals, statics and the like. I have no idea on stack usage, but we are near the 50% point. The largest contributors seem to be the command table, and strings that we could move to progmem if necessary. (I have almost figure that part out, in terms of syntax and non-trival declaration. I still have a few issues there, but I am making head way.)
Rich,
can you teach me the trick of getting stats out of the image ? Can be very useful
Looking at the size of the code, most bytes seem to be spend on arduino core calls. The arduino core tends to inline a lot (wonder why). E.g. when using an extra Serial.print the code size immediately grows.
Looking at the command table we now have 13 (after removal of ATDR ), per record we use two bytes and a function pointer, if we assume the function pointer to be a long thats 6 bytes times 13= 78 bytes. For the buffer we reserve 65 bytes and then thereâs the occasional global or static variable (I estimate less then 20) So all in all our own code occupies less then 200 bytes of the 473 you found, so the rest must be arduino core.
Stack usage is pretty low in my view as we pass little variables and seem to max at around 10 calls deep. Would be cool though if we could actually measure this.
If you have questions on the progmem trick, just shout, I donât claim to be an expert in C++, but I have plenty of experience on Google
As soon as my google code access works Iâll upload my a4 which works with and in which you can type your commands in human speed
ATO0 is added and like I mentioned I cleaned out the ATDR. I also rewrote all AT commands to be less complex and rewrote getParam to enable it to work with the trick.
@Icing: in receiveData() you had a very clever trick to remove the RSSI byte from the data received. Since it took me some time to figure out what you did, I rewrote it into a more readable variant to help other readers as well.
Kind regards,
Hans