RFBee firmware updating

Can't find a proper forum to drop the topic, drop here.

Moderators: lily.li, violet

Post Reply
Icing
Elementary-1
Elementary-1
Posts: 140
Joined: Wed Oct 21, 2009 10:39 pm

RFBee firmware updating

Post by Icing » Fri Mar 19, 2010 8:34 pm

v1.01
1.Change method of receiving RF data from interupt to polling, making RFBee more stable and when in transv mode.

2.Add state check, avoiding RFBee into dead state.

3.Modify ATDR command response info.
******************************************************************

RFBee firmware v1.03
Main changes:
1. Txoff-> IDLE
2. Only transmit the threshold length every time.
3. Delay 10ms in every transmitting.
*****************************************************************

RFBee firmware v1.1a3 (by Hans and Icing)
Main feature(compared to v1.03):
1. More clear and extenable code structure.(Do not need to modify arduino library)
2. More free RAM space for user applications.
3. More stable

Main changes(compared to v1.1a2):
1. Keep RFBee staying in command mode excepting the ATMD* command.
2. Make the ATBD* command work ok.
3. Add ATSI* command to control if adding RSSI byte or not. ATSI0 disable RSSI, ATSI1 enable RSSI.
4. Modify the readSerialData(),so that the RFBee can properly transmit the last buffer data before entering command mode.
5. Default dest and source address are both set as 'A'(0x65).

Still existing problems:
Command ATDR1 for RF datarate 1200bps and ATCF1(2,3) do not work properly.
****************************************************************************

BTW, from here you can get the latest firmware and join to the RFBee open source project developing. http://code.google.com/p/rfbee/
Attachments
RFBee_v1_1.zip
Latest firmware for RFBee v1.1
(39.48 KiB) Downloaded 514 times
rfBee_v1_1_a3.zip
RFBee firmware v1.1 apha3 modified based on v1.1 apha2
(38.38 KiB) Downloaded 472 times
RFBee.zip
RFBee v1.03
(27.06 KiB) Downloaded 447 times
RFBee v1.01.zip
(14.81 KiB) Downloaded 484 times

jklu
Kindergarten
Kindergarten
Posts: 65
Joined: Fri Sep 04, 2009 2:05 am

Re: RFBee firmware v1.01

Post by jklu » Sat Apr 24, 2010 2:51 am

Hi,

I have been looking at the firmware and have a question out of curiosity:

The original Hayes spec (http://en.wikipedia.org/wiki/Hayes_Micr ... r_Products ) used "+++" and then a one second pause to avoid an accidental switch to command mode. This also avoids problems caused by "+++" in the datastream.
Is the current behaviour intentional ?

Cheers,

Hans

Icing
Elementary-1
Elementary-1
Posts: 140
Joined: Wed Oct 21, 2009 10:39 pm

Re: RFBee firmware v1.01

Post by Icing » Sat Apr 24, 2010 9:33 am

Hi Hans,

RFBee will change to command mode immediately as "+++" is checked in the data stream. And we do not do other protection method.

-Icing

rich
Elementary-1
Elementary-1
Posts: 171
Joined: Wed Oct 21, 2009 12:24 pm

Re: RFBee firmware v1.01

Post by rich » Tue Apr 27, 2010 2:49 pm

I am having issues communicating with the RFBEE from a terminal emulator, as far as I can tell the input routines only support if the whole line is sent as a unit. looking at the code I am confused as to why you changed the HardwareSerial to play with the Ring buffers, which makes it much more complicated. Is there a reason for this complexity that I am missing?

Icing
Elementary-1
Elementary-1
Posts: 140
Joined: Wed Oct 21, 2009 10:39 pm

Re: RFBee firmware v1.01

Post by Icing » Tue Apr 27, 2010 7:47 pm

Hi rich,

Do you mean the terminal emulator can not receive data from RFBee unless the data are sent as a unit?
There is a threshold in the RFBee controlling the data unit size, the default is 4, and you could change it using command "ATTH".

As for the ring buffer of Hardwareserial, the reason is it is more convenient to use it directly from the arduino library, and the buffer designed like this is space saving than two different bufffers operated in "pingpang" mode.

However, it may not be the best design, and it can be optimized more clear and efficient. So you can do it :P

Regards,

-Icing

rich
Elementary-1
Elementary-1
Posts: 171
Joined: Wed Oct 21, 2009 12:24 pm

Re: RFBee firmware v1.01

Post by rich » Wed Apr 28, 2010 4:27 am

Actually it is the opposite problem I am seeing if I a write a program that sends +++\nAT?? it seems to work, but if I type it from a terminal emulator I always get an error. As this is the first way many people test things I think it needs fixing. I am thinking of reworking some of it, but I wanted to understand why before I start changing things. (I prefer not to look like a fool so I ask questions first.)

What I am thinking of is adding a couple commands to tell it to transmit or poll the value of a pin at a fixed interval. Probably a bit map for digital and a separate one for analog. There would be some software channelization so that a UART stream could be sent at the same time.(Not a priority at the moment.)

First I was going to add a read/set local pin digital
Then read local analog
Then read remote pin command. (Either poll or broadcast value.)
Then a read analog pin.
Then set a period value and repeat the steps. This way you could track pins, and get started quickly.

I am undecided whether it should be a broadcast or poll model used here. Polled might have better behaved radio traffic, but broadcast would be simpler to write.

So you could
ATD1 set destination

ATRA # analog pin to read on remote. RA ReadAnalog
ATRD # digital pin to read remotely RD ReadDigital
ATSD # digitial pin to set. SetDigital
ATPM # pin mode for named pin mapping to arduino pin model. PinMode
Then maybe a track mode where I can set
ATTP 0xff TrackPinstate
ATTI # frequency at which to poll/transmit. TrackInterval

So in command mode it would be simple to read, set, or track a remote pin. Anyway this is what I was considering. Comments?

Icing
Elementary-1
Elementary-1
Posts: 140
Joined: Wed Oct 21, 2009 10:39 pm

Re: RFBee firmware v1.01

Post by Icing » Wed Apr 28, 2010 1:01 pm

Hi rich,

When you reset the RFBee, does the terminal receive "ok"?
Then you should type "+++" and send it, the terminal will receive "ok". The RFBee is now in command mode.
Then you can send "AT***" to configure the RFBee.

If your RFBee couldn't work like that, you may scratch and submit some pictures to let me check it out.

As for adding the command, take care the resource of ATMega168, it is no much left. So if you find some of your code are not working, may be the problem of lacking of flash or ram space.

PS:Try to reduce the frequrency of using "Serial.print("") ".

All the best,

-Icing

jklu
Kindergarten
Kindergarten
Posts: 65
Joined: Fri Sep 04, 2009 2:05 am

Re: RFBee firmware v1.01

Post by jklu » Thu Apr 29, 2010 3:07 am

Hi,

I don't have an RFbee myself so I can't check what I'm preaching but looking at the firmware and looking at the CC1100 datasheet I think it can be optimized a bit :)

a) you don't need to latch CS on every operation, but only during the init phase of the SPI
b) there seems to be no need to wait for the SPI Data In to complete on every operation, only after a init/reset of the CCx
c) using an SPI class like http://www.arduino.cc/playground/Code/Spi makes the code more readable
d) the status byte returned by the CCx is currently ignored, although it contains info which could be usefull to handle errors like underflow and overflow
e) I think CCx reception using interrupts can be made to work using cli() and sei()
f) CCxSetup code of the CCx can be simplified by using an array instead of a struct, as all values are bytes one could have a loop to setup the CCx, this also makes CCxreadSetup much lighter ;)
g) the TestIo stuff (factory test ?) can be #defined so its not always linked in.
h) serial data is already copied into the dstBuffer so we already have the ping and the pang, no need to have the complex ringbuffer imho
i) CheckCMDMode has a quirck, if gplus is 2 (we already saw ++) then with the next round we will ignore the first 2 chars ;)
j) the serial-in can be made to sleep as well and wake on interrupt, which would increase the battery life of an RFbee
k) encryption can be added (if resources permit, need about 2K ;)
l) there is some debug code in it which can be optimized.

So.. thats my view (could be very wrong of course ;-))
If anyone is interested I'm happy to give it a go to put the above into code, however I don't have a rfbee to verify and I'm not to keen on becoming lifelong maintainer of the code ;)

Cheers,

Hans

jklu
Kindergarten
Kindergarten
Posts: 65
Joined: Fri Sep 04, 2009 2:05 am

Re: RFBee firmware v1.01

Post by jklu » Wed May 12, 2010 9:25 pm

Hi,

here is my take on a new firmware version for the rfBee, learned a lot while writing it ;-)

Remember: I don't have a pair of RFbee's to test it out, so its an alpha version at best :-)

Main differences with the official 1.01 version:
- no need for ring buffer modifications, only a single global buffer used for transmission
- use of PROGMEM for CCx config stuff to save on RAM
- the ability to switch between the 5 CCx configs using the new ATCF command
- more robust AT parameter checking (e.g. 999 is not allowed as Destination Address ;-))
- Serial AT handling separated from main RFbee stuff
- Clean isolation of the CCx code in a CCx class
- optional Interrupt Driven Receiver (see #define INTERRUPT_RECEIVE) using a state machine
- no latch CS on every operation, but only during the init phase of the SPI
- use of a (simple) SPI class
- factory selftest rewritten to reduce memory footprint (see #define FACTORY_SELFTEST)
- code compiles both on 168 and 328 without modification

Enjoy,

Hans
Attachments
rfBee-v1.1-alpha.zip
(34.34 KiB) Downloaded 444 times

Icing
Elementary-1
Elementary-1
Posts: 140
Joined: Wed Oct 21, 2009 10:39 pm

Re: RFBee firmware v1.01

Post by Icing » Thu May 13, 2010 10:30 am

Hi Hans,

Thank you so much, it looks great. We will test it on our RFBees.

Please send your address to me(icing.chang@seeedstudio.com). We will send you a couple of RFBee as a small reward. :)

Regards,

-Icing

Post Reply