Anyone have a solution that works well for them to determine the end of the MQTT message received URC? There is no length information in the URC, so it seems to me that the only way to determine the “end” of the URC payload is to look for "\r\n character sequence.
What if " and Ctrl characters are in the payload?
I see that to publish a MQTT message on the BG96, you signal message end with Ctrl-Z, so maybe the MQTT implementation on the BG96 does not support binary data. Anyone no for sure?
Thanks,
Greg Terrell
1 Like
Dear customer
you can send “1a” ，instead of crtl-z
anymore issue ， you can send email to support@quectel.com for more support
@GregTerrell i got the same issue any update on it
" Anyone have a solution that works well for them to determine the end of the MQTT message received URC? There is no length information in the URC, so it seems to me that the only way to determine the “end” of the URC payload is to look for "\r\n character sequence.
What if " and Ctrl characters are in the payload?"
No. My testing shows that embedded double-quotes " are simply forwarded out in the URC output. In my code test for a trailing " followed by \r\n\r\n\r\n (there are 3 line endings after the closing ").
So, really stuck if there is a " with 3 line ends embedded in the MQTT message, but this seems unlikely. I would like a more deterministic approach but that seems not to be available.
Quectel hasn’t thought about this. With MQTT it’s always a problem (if your data may contain newlines or quotes). With HTTP downloads, it can be a problem if the connection is interrupted during download.
Another sign of lack of planning: some commands, when they need payload data, respond with a CONNECT, others respond with > . it’s inconsistent and I see no reason to have both.
Quectel really should spend some engineering on this.