Hi Paul,
Thank you for your good suggestion.
> digi recommends API mode 1 for most uses.
I didn't know that.
MQTT & MQTT-SN should transport a binary payload.
therefore, I thought simply escape mode is only way out to get the real start byte, not 0x7e in a payload, for a stable communication.
so, I have never tested API mode 1 from the beginning.
I'm expecting your XBee testing of API mode 1.
> This should probably be configurable.
It's easy to change the code for TEST.
Just comment out as follows:
=========================================
void XBee::send(uint8_t c)
{
// if(c == START_BYTE || c == ESCAPE || c == XON || c == XOFF){
// _serialPort->send(ESCAPE);
// _serialPort->send(c ^ 0x20);
// }else{
_serialPort->send(c);
//}
}
int XBee::recv(uint8_t* buf)
{
if (_serialPort->recv(buf) )
{
// if ( *buf == ESCAPE)
// {
// _serialPort->recv(buf);
// *buf = 0x20 ^ *buf;
// }
return 0;
}
return -1;
}
==========================================
XBee programs as far as I know are just sending with out Frame ID. It's unstable same as QoS0.
In my experience, A point of stable communication of XBee API mode is
that using a Frame ID in Transmit Request and get Transmit Status.
I will change it configurable after my struggling with client certificate required TLS connections.
Thank you for your cooperation.