Xbee 868 revived?





Update Aug 2011:


After a great deal of tests, this option for telemetry did not work for our us, I now have a working telemerty kit option which can be seen here, and you can buy the Telemetry kit from www.buildyourowndrone.co.uk




The Xbee 868 how ever an older module it still has a great deal to offer and as some of you might remember this post as the original fix there has been a lot of other fixes that came to light hardware (Quick_and_Dirty) and software thanks to James and Noth666 but in A recent post of mine, we discussed the options for the UK and I came upon a new fix that seems simple yet effective enough to get the advantage of the offered 40km range as stated Here.


What you must do is reset your Xbee through the UART, modify the telemetry output to stop for a (guard time) amount of time, send the "escape sequence (+++), wait for another "guard time" and then send the reset command (ATFR). In this case the escape sequence is changed from the default (+++) to @@@ because the telemetry for Ardustation for example contains the +++ sequence and because of this there is great risk of putting the XBee in command mode when you don't want to.


I made contact with Marcus Fahlen and he was kind enough to supply a great deal of information on his work, and work around, the following information & code is the work of Marcus Fahlen, and with his permission I have added it below, I'm at this point where I need help on where and how to implement the code and from which pins, just to make sure


// XBee control functions by Marcus Fahlén

// sends a reset command (ATFR) through the

// UDB telemetry UART.

void xbee_reset( void) ; // This routine runs from the "servoPrepare.c" module in MatrixPilot

// main code directory. There is a flag i "options.h" for enabling or

// disabling the use of this code.


// This setup is for the 868 XBee PRO module which has a duty cycle

// of 10% (6minutes continuous transmission). Because of this I have written

// this piece of code that is meant to reset the XBee module at a choosen

// interval. I have done a lot of experimenting with different settings but

// I still have to find one that works 100% (count up to the guard time,

// send the escape characters, count up another guard time and then send

// the reset command. I don't bother to listen for any "OK" to check if

// the procedure was successful. That would demand bi-directional

// control code which I'm not capable of producing at the moment.



#define XBEE_PRE_GUARDTIME 25000

// XBEE_GUARDTIME : use approx 50000 for the "guard time counter"

// if your XBee is set up fo 50ms guard time.

// I have had greatest success with 50ms guardtime. I'm not sure why,

// but the shorter guardtime the more critical the timing becomes.

// Then again, longer guard times often results in a state where the

// XBee is in command mode but never recieved the reset command?

// This highly unwanted state ends when the XBee command mode "times-out"


// before it returns to "normal" operation. This time-out period is settable in

// the XBee and should of course be as short as possible.

// XBee control functions by Marcus Fahlén
// As for noe it only sends a reset command (ATFR) through the UDB telemetry UART.
// Hopefully it will be able to perform more sophisticated control functions later
// like output power management based on distance to base station and other circumstances
// that calls for a variation in output power.

void xbee_reset (void) ;

unsigned int xbee_skip = 0 ;
long guard_time = XBEE_PRE_GUARDTIME ; // XBEE_GUARDTIME : approx nnn for 10ms guard time 

void xbee_reset( void)
 ////// Skip every other run through this function.
 if (++xbee_skip < XBEE_RESETPERIOD) return ;
     unsigned int delay;
     for(delay=0;delay<guard_time;delay++);     // pre escape sequence guard_time 
         serial_output( "@@@" ) ;     // send escape sequence
       for(delay=0;delay<guard_time;delay++);     // post escape sequence guard_time
     serial_output("ATFR\r\n") ;
     xbee_skip = 0 ;
     return ;


// Maybe the reason for the reset routine missing is that it becomes

// "disturbed" by the interrupts running on the UDB? If an interrupt occurs between the

// the time where the "ATTENTION" command is being sent, but before the "reset" command is

// sent, I think causes the "hang state" that I have a lot of trouble with.

// The only thing to do is to calculate the timing need carefully, and maybe disable the

// interrupts all together while the "reset" command is being sent. That would assure that the

// reset is carried out as fast as possible. (50ms guard time times two + the time it takes to

// send the command characters)


// Use a command mode timeout of 200ms (ATCT2) which is the shortest possible.

// As described above, there is a chance that the routine "misses" and leaves

// the XBee in a non-transmitting state (comand mode), but it will only last for 0.2sec

// if setup as described. Then the XBee exits the command mode and resume normal operation.


// Also change the default escape character to "@" since the the telemtry

// output uses lots of "+++" in its data.

#define XBEE_POSTCOMMAND 10000



E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Where should I write exactly the code in the arduplane files? (I'm working with arduino IDE to compile .hex)

    And What values should ​​I put in variables to be reset every 5 minutes?

    Thank you.


  • Distributor

    Please see this blog post for a working Telemetry Kit.





  • Hi all


    Just wondering what if any progress has been on this problem? I have bought the kit and have everything fixed in place, I just need to get this code working in the right place asap! Any updates would be greatly appreciated and willing to help to sort this out. I just have no idea where to start looking in the code!





  • Hi all.

           First post here! If you hav'nt already ordered the kits, can you count me in for one?

  • Distributor
    Hello Marcus,

    I hope you are well?
    Thank-you for your original code and the additional post you have made above.
    I was going to drop you an email a little later to update you on where we were with the code and to ask when you a question on the 10 way point flight, the kmz posted on your forum page, did you have communication with the Xbee's throughout the flight?


  • I will just make this one comment in this thread:

    As stated above, the "easiest" way to reset a XBee is the "quick-and-dirty" method of pulling the reset pin every now and then, but there is a serious drawback to this approach, believe me, I have tried this myself as the first remedy to the "10% DC problem":

    Sometimes the XBee doesn't reset properly. It's hanging in an "un-known" state where it doesn't listen to commands or send anything. You can verify this by repeatedly pressing the reset button while watching a terminal window with some kind of readable ASCII scrolling over the screen. Sometimes it requires several resets before the data starts to flow again. The only way to know if the reset is carried out is to listen for the "OK" ASCII string sent out on the UART. If you choose to solve the reset problem by pulling the reset-pin to GND, you still need to listen on the UART to verify that the reset was successful. If you are going to write / modify firmware that listens to the UART, you can as well control the reset via an AT command through the same channel. It's so darn simple. Just wait until the TX buffer is empty, otherwise there is a big risk for a "hang-up" and you end up in the "un-known" state described above.

    I have at the moment had the "Happy GCS" connected to my drone over 24h without a single glitch. That's because I wait until the transmit buffer is empty, send the reset command, listens for "OK" and then continue. The whole operation takes less than 200ms. The higher baudrate you use, the more often you need to reset the 868 XBee. The duty cycle has NOTHING to do with temperature as has been stated elsewhere. It's required by law to limit the use of the 868MHz band. I read somewhere that the output power was decreased the higher baudrate used. This is also wrong. I have used 230400 baud @ 300mW just to test. It worked fine. Problem was my computer didn't support this comport speed...

    To summarize this post:

    To reset the Xbee do the following:

    Configure your XBee to use a "PACKETIZATION TIMEOUT" of 0.
    In your telemetry output, include a counter that counts a few minutes (RESET FREQUENCY).
    The you need another counter for the (GAURD_TIME).

    In pseudo code it would look something like this:

    #define RESET_FREQUENCY = 120s
    #define GUARD_TIME = 10ms
    #define ESCAPE_CHAR = "+++"
    #define REBOOT_TIME =200ms
    #define CONFIRMATION = "OK"


    If you choose to listen for the "OK" string you will have to listen for it twice. One time for when the XBee is going into "command mode", and one when the RESET code is accepted.
    After the second "OK" string you will have to wait approx 200ms before starting to pump data again.
    I personally don't see the idea with buffering the telemetry data. It's only introducing lag. I throw all my data coming in during the reset procedure straight in the "bit bucket".

    Kind regards

  • Distributor

    I agree that the “static stations” are more in keeping with the design / use of these unit, and I know that that some people are looking to use these units for more than the basic telemetry, it has already been proven to work at “close” range as a RC controller, so in theory the range question will only come at the time of doing some open space moving field tests.

    In the local area to where I live I can find places where LOS will be at least 4 miles + so I would be happy to test and confirm what can or cannot be achieved.

    However I would like to see if there is a way to get this code working so we can answer these questions with testing! :)

  • Moderator

    The long range links are between beams and static situations with the lowest baud rate. These modems are not designed for bullet proof control links.

  • Moderator

    The search radius for your UAS at 10km would be enormous, you won't be flying outside of VLOS of course so no issues there. With tracking antennas and high gain ones on the airframe you should make 10km, you won't with non directional stuff.

  • Distributor

    Hi Abey,


    That is it in one! There have been a few different work arounds to achieve the reset, after a few days of research I found the information / code posted above, I hope that someone will help with the implementation of the code, as this is beyond my abilities.

This reply was deleted.