If I configure XBee Pro (hardware 1842, firmware 1084) to use API Mode 1, then can I transmit a message that contains a 7E character (or 7D or 11 or 13), that otherwise are interpreted as Start, Escape, Xon, Xoff characters?
In other words, can my tranmit message payload contain any binary data, in API Mode 1?
Yes, to both questions.
The packet length bytes tell you how long the payload is, and the checksum confirms that you’ve received it correctly. Within the payload there can be any values, including 7e and the others.
HTH
So is the only advantage of Mode 2 that it helps cover for noisy serial transmission?
If my PIC is tied directly to the XBee, can I use API Mode 1 for any old binary data? [For some reason, back in Dec '06, you guys convinced me otherwise]
It does give some protection against noisy transmission, because if 7e codes are always escaped within the packet, you can resynchronize after an error. But that’s not the only reason: if (say) you wanted to use XON/XOFF flow control, you’d have to make sure those characters could never appear in the data stream, and hence another need for an escape mechanism.
I believe that, yes, you can use mode 1 for any old binary data - as long as you’re not also trying to use XON/XOFF.
After all, the payload for many packets includes the module’s serial number. No reason why there shouldn’t be a 7e or any other code in there. And of course, one time in 256 the checksum will happen to be 7e.
In case you’re still not convinced, consider the API packet for any command that sets a timer. If the timer has a range 0 to 0xff, then any setting in that range is legal. In the API command packet that value will be transmitted as a single byte. So if you want to set the timer value to 126 decimal, that means there’ll be a 7e byte within the packet.
I concur. I am now successfully using API Mode 1 now instead of mode 2, and it’s a lot less headache (and RAM buffers) not having to do the escape sequences.