We’re using the AT command mode (not API) and we will be sending/receiving bits of xml ( messages would be things like status, current configuration, user message to display, etc.) and we need to parse them on the other end. We’re fighting internally about whether we should even use xml, given the small payload size, and, if we go the xml route, how to make it smaller. For instance, we would have a message something like this:
15_08_471.2Good morning to you. Is anyone else using xml with their payloads?
Digimesh supports a payload size close to 250 (depends on some Xbee options/modes), so from that stand-point you shouldn’t suffer too much pain if your xml is 200 bytes or less.
What you MIGHT see is that certain network event might cause the XBee to send data prematurely (so before the RO setting times out). So you’d get the first half of your XML, then perhaps 500 msec later the second half arrives. I can’t explain any exact experience with this, but I think some network maintenance has a higher priority so the Xbee ‘flushes’ pendign data to free up buffer space for ‘important event X’.
You might want to look at something like JSON, which actually looks much like a Python dictionary as text! Or even comma-seperated-value (CSV).
You may want to also consider a non-XML wrapper, so perhaps “:XXYY\r”, so ‘:’ could be the start-of-line, XX the length as 2 ascii-hex chars, YY a simple CRC and the ‘\r’ as a clean way to detect end of message. This will alow a very simple parser to absolutely reassemble your XML without needing to understand anything about XML!