QMTRECV receiving binary data

Hello,

I’m trying to receive binary data using AT commands with BC96 module. Everything works well, and in an ideal case, it’s possible to receive binary data in +QMTRECV reading until \r\n characters.

However, binary data itself may contain \r\n characters.

Is it possible to switch +QMTRECV to output in HEX code or Base64?

Thank you!

1 Like

our mqtt observe mqtt 3.1.1 ,bin file can be tranmitted . by default , we think it is UTF-8 string ,but in your PC
You can choose to convert to which format, or how to display.

with our qcom tools ,you can show it as hex format

image

Hi Stephen!

We connect to the module from ESP32 MCU via UART, so the data is read raw as bytes.

In the AT firmware, you typically read until the end of the line, which is represented by \x0D\x0A. The problem is that binary data as output by +QMTRECV may also contain \x0D\x0A somewhere in the middle.

Oh , No idea .

Maybe you can add some characters as your end flag in your rawdata

Well, I was hoping that there’s a way to add to AT+QMTCFG, for example, “format” parameter, where 0 would be raw data as bytes, and 1 would be HEX encoded data (i.e. a string “68656c6c6f0d0a” instead of raw encoded bytes “hello\r\n”).

Would you consider that for the public firmware? We’re also open to 二次开发, though this feature sounds rather small.

The \r\n stripping is performed in the ril layer. The default ril_mqtt.c (as of sdk 1.6) handles only 10% of the MQTT functionality, eg. no RECV callback, no & splitter, no uridecoder, no normal MQTT configs (esp. LWT), and a few broken system functions, which are easily fixed.

I added my own OnURCHandler_MQTT_RECV() and ensured that only the very first \r\n and very last \r\n are stripped. Beware: The QSDK_Get_Str() function is limited (no in-dquote detection) and prettty broken also (for the last sequence).

Thank you @Reini_Urban! Sounds interesting. I googled (and “githubbed”) and cannot find any reference to OnURCHandler_MQTT_RECV, and very limited references to ril_mqtt.c. Are you referring to OpenCPU SDK?

yes. this callback is missing there