Bad ReadPacket()

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Receive remote analog data.

in
void XBee::readPacket() {
...
 if (_pos > 0 && b == START_BYTE && ATAP == 2) {
            // new packet start before previous packeted completed -- discard previous packet and start over
            Serial.println("New Packet?");
            _response.setErrorCode(UNEXPECTED_START_BYTE);
            return;
        }
...
}

the condition b == START_BYTE will be true any time an analog sample value of 
254, 510, 766, or 1022 is received. Since a single packet can hold up to ~45 
analog samples, your code rejects a large portion of valid remote analog sample 
data.

There are other places you do this too. if (_pos > 0 && b == ESCAPE) {...} 
regularly triggers incorrectly also.

Original issue reported on code.google.com by michael....@gmail.com on 15 Feb 2011 at 10:10

[GoogleCodeExporter]

Just started using this library, but past experience with xbee -> if you set 
api mode = 2 then all control characters will be escaped and xord with 0x20. 
Are you running in api mode = 1?

Original comment by theh...@gmail.com on 18 Feb 2011 at 2:57

[GoogleCodeExporter]

It is set to API = 2... I've read over the documentation for the radio, and the 
library is in fact correct. This issue is a non-issue.

It would seem that my radio somehow misses adding about half of its escape 
characters, though that seems oddly in line with all the other troubles it has 
given me. ... Well, at least it seems to work reliably doing remote sampling.

Original comment by michael....@gmail.com on 23 Feb 2011 at 6:11

[GoogleCodeExporter]

The remote radio also needs to be in API 2, you could potentially see this if 
the master is in 2 but the remote is in 1. Are you using a recent-ish firmware? 
I used 10CD with success, although I haven't extensively tested the range of 
values. I just made it send enough packets that the dropped ones are a 
non-issue.

Original comment by theh...@gmail.com on 23 Feb 2011 at 5:39

[GoogleCodeExporter]

The remotes are in API = 0. The remote devices are sampling their analog pins 
and sending the data to the master. Everything works perfectly as long as this 
particular radio isn't the master. 

The same radio is also a pain to read/write with X-CTU, and just seems to be a 
pain in the ass overall to work with, while the others just work. My final vote 
goes to bad radio.

Original comment by michael....@gmail.com on 25 Feb 2011 at 3:56

[GoogleCodeExporter]

I believe that if the remotes are in API 0 the packets will not be escaped by 
the sending radio. Pretty sure the master just passes whatever it receives out 
through the UART. From the knowledge base (where Radio 2 is the receiver) 
*Radio 2's AP option can be set to either 0 (API off), 1(API without escaped 
characters) or 2 (with escaped characters). The receiving message will still be 
the same.

Original comment by theh...@gmail.com on 25 Feb 2011 at 4:29

[GoogleCodeExporter]

Sorry for late response but looks like you all figured it out.  Yes, API mode 2 
is required.

Original comment by andrew.rapp@gmail.com on 3 Apr 2011 at 2:23

• Changed state: Invalid

[GoogleCodeExporter]

API mode 2 is required both for master and for end devices (receiving radios)???

Original comment by mattia.f...@gmail.com on 8 Oct 2011 at 8:14

[GoogleCodeExporter]

I think only the local radio should need to have AP=2 but please test and let 
us know

Original comment by andrew.rapp@gmail.com on 8 Oct 2011 at 6:57

[GoogleCodeExporter]

I tested remote radio both API 2 and 1 and won't work... :(

Original comment by mattia.f...@gmail.com on 11 Oct 2011 at 6:53