Release 0.4 (Beta) problem in AP=1 mode (ATAP=1) with SERIES_2

[GoogleCodeExporter]

In API mode, Some frame are dropped when sent from arduino to coordinator on PC 
(python).

This problem was present in previous version (modified by myself for use with 
newsoftserial and Arduino022). Still present with Xbee 0.4 (beta) in 
arduino_1.0.1 when used with SoftwareSerial.

I did the following modification in XBee.cpp for a quick solution.

replace:
void XBee::sendByte(uint8_t b, bool escape) {

    if (escape && (b == START_BYTE || b == ESCAPE || b == XON || b == XOFF)) {
//      std::cout << "escaping byte [" << toHexString(b) << "] " << std::endl;
        write(ESCAPE);
        write(b ^ 0x20);
    } else {
        write(b);
    }
}
by:
void XBee::sendByte(uint8_t b, bool escape) {
#if ATAP == 2
    if (escape && (b == START_BYTE || b == ESCAPE || b == XON || b == XOFF)) {
//      std::cout << "escaping byte [" << toHexString(b) << "] " << std::endl;
        write(ESCAPE);
        write(b ^ 0x20);
    } else {
        write(b);
    }
#elif ATAP == 1
        write(b);
#else
#error incorrect ATAP value
#endif

}

otherwise, working great !

Original issue reported on code.google.com by philippe...@gmail.com on 18 Dec 2012 at 4:28

[GoogleCodeExporter]

You need to modify XBee::readPacket() as well to account for removing escapes - 
 I've done this but am not sure I like the final result - I have to calculate 
the #s but I think the glitching I get on comms errors may outweigh the 
benefits - that is, I waste more bytes retransmitting cause the framing seems 
to get messed up when there is noise 'in the air' than I save by not using 
escapes - but that is a suspicion right now, not a fact 

Original comment by MarkMMul...@gmail.com on 26 Feb 2013 at 1:01

[GoogleCodeExporter]

You're right, there is still some processing done in readPacket. The arduino 
may be loosing some packet containing ESCAPE characters. This did not bother me 
too much, so I did not notice it, I am transmitting ascii characters and by 
chance my 64 bit addresses did not contain 7E byte ! (what about 16 bit 
addresses ? I am a little bit afraid!)
I have digged a little bit more on the AP setting and found and interesting 
thread: 
"Arduino Forum :: Using Arduino :: Networking, Protocols, and Devices :: 
Finally taking a look at the XBee library"
It seems that AP setting affects only the serial link between arduino and xbee. 
Xbee will send out data to the serial port only when the packet is fine (and 
will acknowledge to the sender who do the retries). So I don't understand why 
your arduino pgm should take care of errors, unless problems are arising from 
the serial link itself (but it would be the same problems with AP=2 which 
requires some extra processing power)
So, concerning the RF com, AP seems to have no effects.
The only benefit I see using AP=2 is:
1-if an incomplete packet is sent out to the serial, the parser can recover 
more easily the frame start. But I don't know when this can occur: an Xbee 
reset ?
2-a serial read mistake which gives a checksum  error:
if the error is on packet length (Byte 1),then any 7E after the pseudo end of 
the packet will be taken as a frame start in mode AP=1, while in AP=2, all but 
frame start will be escaped. A clever parser could handle it, I don't think it 
is done on arduino xbee library, much easier on big machine like a PC.
if the error is on an other byte, I don't see differences between the two modes.

I will try to modify the readPacket and reconsider the AP setting.
Other consideration: I am using 19200 bauds between softSerial and Xbee, higher 
speeds gave problems on my boards

Original comment by philippe...@gmail.com on 26 Feb 2013 at 3:58

[GoogleCodeExporter]

AP=1 is not supported

Original comment by andrew.rapp@gmail.com on 2 Feb 2014 at 7:06

• Changed state: Invalid