Using Xbee as a buffer

dellarb

New Member
Hi all. I hope this hasn't been posted before. Its a surprisingly obvious and simple soloution but it may help somone.

When looking at using Xbee modules for wireless telemetry between a PICAXE (28X2 in this case) and a PC I faced the common problem of not knowing when the PICAXE would start listening for serial data from the XBEE. To ensure commands were received properly using the good old fashioned method of sending a 'Start' sequence and using qualifiers in the serin works but means the signal must be sent multiple times to guarantee that the PICAXE gets the full string. Also it introduces delays while the PICAXE is ignoring all the junk data halfway through strings waiting for the qualifier.

To fix this when using the XBee modules I experimented and came up with a solution using the RTS pin. The Xbee has a buffer for incoming data that holds at least 146 bytes (verified by me). If you enable RTS Flow Control on D6 under Serial Interfacing in X-CTU, the XBee will not send serial data until its RTS pin is pulled low.

By having the PICAXE manually pull the RTS pin low immediately before performing a serin and send it high again immediately after the XBee will happily buffer your commands until the PICAXE is ready to get them.

In the below code pin a.2 is directly connected to the RTS pin of the XBee and pin a.1 is directly connected to the (oddly named) TX pin (AKA DOUT i believe). The pause of 1ms after driving low is required as without it all of the incoming data gets garbled for some reason unknown to me.

Code:
low a.2
pause 1
serin [10,continue],a.1,T4800_8,("$$"),b0,b1,b2

continue:

high a.2
Now 2 very important things. At T4800 Baud using Setfreq M8 on a 28X2 the first 2 bytes waiting in the buffer will be lost before the PICAXE is fully ready to listen for serial. Additionally after finishing receiving the serial an additional 6 bytes will be sent by the XBee that are not received by the PICAXE before the RTS is high and Xbee stops sending. I have found that a timeout of 10ms while waiting for the qualifier is plenty and means that program flow is very rapid even when there is no new command to retrieve.

So... make sure you pad your instructions with at least 2 bytes at the front and 6 bytes at the end of junk info. For the demo code I send it ASCII ##$$ABC###### and with 100% accuracy it will result in B0= "A" B1= "B" and B2 = "C", even when i introduce silly delays like pause 4000 between checking serial to simulate program workload. You can send as many payload bytes as you like (I've tested it as high as 26 bytes of payload but it should handle more). Just be aware that the Xbee can only buffer ~146 bytes so you should not be sending it code too fast to fill up the buffer or it may overflow.

If anyone has any comments questions or suggestions about my idea feel free to go for it. It’s my first i guess 'independent' discovery of something very useful so just thought i would share.
 
Last edited:

hippy

Technical Support
Staff member
You may be able to delay the XBee seeing RTS so you are in SERIN before it starts to send with a simple RC ...
Code:
                      3V3 -.-
                         __|__
                         --.--     ___
.------.        ___        |      |   \
|      |---.---|___|---.---^------|    |
`------'   |           |          |___/
 PICAXE    `----|>|----'          XBee
 
Top