Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Receiving a multi-line payload response from MQTT-related BG95 AT commands #123

Closed
mikalai-kavalchuk opened this issue Dec 20, 2022 · 8 comments
Assignees

Comments

@mikalai-kavalchuk
Copy link

Hello!

I'm trying to implement MQTT-related AT commands for BG95 and have encountered one issue related to receiving multi-line response with AT+QMTRECV command.

I registered URC handler for "QMTRECV" and can handle incoming MQTT publications.
But if I send MQTT publication with payload that include <LF> symbols inside (formatted JSON with line feed):
image
thereafter the first <LF> symbol in payload interpreted as the end of line so in the URC handler for "QMTRECV" I can only see part of the payload up to the <LF> symbol. Next parts are come as AT_UNDEFINED messages.

Looks like an issue while processing responses in _handleAllReceived because the responses must include <CR><LF><response><CR><LF> according to AT Commands Manual

I can register _Cellular_RegisterUndefinedRespCallback to proceed all the rest of "QMTRECV" but it looks like workaround. What can you suggest to do in this situation?
Thank you!

@chinglee-iot chinglee-iot self-assigned this Dec 21, 2022
@chinglee-iot
Copy link
Member

Hi mikalai,

Thank you for your interest in cellular interface.
I will take a look at the AT command "AT+QMTRECV" and reply to you later.

@chinglee-iot
Copy link
Member

Hi mikalai,
Cellular interface support reading byte stream from AT command.
We can give the following method a try:

  • Use the buffer mode for received message : Message not contained in URC. Receive the message from the buffer.

  • Receive the message from buffer with recvID : Cellular interface can handle one byte stream in the response.

  • Reference the Cellular_SocketSend implementation for receiving byte stream from AT command response.

@mikalai-kavalchuk
Copy link
Author

Hi chinglee,
Thank you for the information! I will try this mode and report the results later

@tpecar-ltek
Copy link

I would also like to add here that I've encountered the same issue on SIM800C.

There are however other issues with the current MQTT client on SIM800C before I would consider it viable for production use, and I would encourage others to use the FreeRTOS-Cellular socket interface + coreMQTT (or similar) on the SIM800C platform.


For the sake of documenting the issue, on SIM800C the incoming messages are provided via +SMPUBLISH URC and there is no configurable option in AT+SMCONF for a "notification + read at request" mode of operation (as is for example for modem TCP/IP stack).

@chinglee-iot
Copy link
Member

Hi tpecar,

Thank you for your feedback to cellular interface.
It looks like SIM800C doesn't support buffer access mode for MQTT AT command.
Receiving byte stream in URC is a new feature to cellular interface. We would discuss to add this function.

@mikalai-kavalchuk
Copy link
Author

Hi mikalai, Cellular interface support reading byte stream from AT command. We can give the following method a try:

  • Use the buffer mode for received message : Message not contained in URC. Receive the message from the buffer.
  • Receive the message from buffer with recvID : Cellular interface can handle one byte stream in the response.
  • Reference the Cellular_SocketSend implementation for receiving byte stream from AT command response.

Hi chinglee! I did everything in the same way as for sockets, as you advised, and now I can receive incoming MQTT publications without any issues.

Thank you so much for your help!

@chinglee-iot
Copy link
Member

We have a PR to support the feature to receive data from URC #137. This PR is still under development.
One of the similar use case is the socket direct push mode. This PR for BG96 can be referenced.
Suggestion to the PR is welcomed.

@chinglee-iot
Copy link
Member

PR #137 is merged. I will close this issue first. Feel free to feedback further question here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants