it is sending ERROR and SQNSMQTTONPUBLISH back to back so is there something else that we need to do to get the SQNSMQTTONPUBLISH async response without having to send any other commands?
also if i wait for less time ~2-3 seconds instead of the 2 minutes it does the same
The AT command doesn’t match our AT reference manual, the 3rd parmater is QoS, and its range is 0,1,2. May be you executed: AT+SQNSMQTTPUBLISH=0,“test”,,28
From the later print, AT returns ERROR, I suspect the data you sent is not encoded as ASCII characters lead to its length is longer than 28 bytes. There is some characters left in the input buffer, and it is sent to modem together with AT together lead to ERROR. You can confirm this by sending \r\n just after you type “{“data”:{“test”:“test 1”}}”
If there are characters left in the input buffer, you will get ERRER
If the input buffer is empty you will not get any output.
What software did you use for the AT operation? May be you can try Tera term on Windows to see if it works?
you are aright im sending with like AT+SQNSMQTTPUBLISH=0,“test”,,28
i have an extra space at the end making it one extra character long and that is why i get an ERROR after the AT\r\n command
so i fixed that and send \r\n after 60 seconds and get no ERROR message. but that is still not solving my problem with the URCs not being sent during that 60 seconds waiting period, as soon as i send the \r\n it send the URC i am expecting with a response URC of +SQNSMQTTONPUBLISH: 0,2,0
so is there something else i should look into why the URC would be held until a new message is sent?
ive also attached a logic analyzer(using saleae logic capture) so you can see byte by byte with a timeline what is happening
Thanks for confirming the length issue and for the Saleae capture.
A URC that only comes out after the host sends another character usually means the modem’s UART is not free to transmit during the idle period. The two usual causes are hardware flow control (the host deasserting RTS) and UART low-power / sleep handling on the modem side.
Could you please share:
Module and firmware version (ATI1)
Which UART you are using and its configuration (AT+BIND?, and AT+SQNHWCFG="uart0" or the UART in use)
Whether RTS/CTS flow control is wired and enabled on the host, and the RTS level during the 60 s wait (if your can add RTX/CTS line to your capture will be helpful)
Whether any power saving (PSM/eDRX or UART sleep) is configured, AT+SQNEDRX?,AT+CPSMS?,AT+SQNIPSCFG?
If possible, a DM Light trace with MQTT logs and IPv4/IPv6 PDU checked, covering the publish and the wait period would also help us see when the PUBACK is received versus when the URC is output.
im using UART0, the bind command responds with(AT+SQNHWCFG="uart0" responded with error)
+BIND: UART0,“AT”
+BIND: UART1,“AT”
+BIND: UART2,“CONSOLE”
RTS is grounded directly so that shouldn’t change it
power save mode is should not be configured
+SQNIPSCFG: 2,5000
+CPSMS: 0,“10100011”,“00100001”
+SQNEDRX: 0,4,“1101”,“0000”,1,1
other URCs are working correctly mainly the one for AT+SQNSMQTTCONNECT. it responds with a URC without any commands being sent between them. and since RTS is grounded it seems strange am i suppose to send /r/n after my full message has been sent via SQNSMQTTPUBLISH
AT+SQNHWCFG="uart0" only works on AT+CFUN=5 mode. which is why it returned ERROR.
Are you using EVK or something else? How and where are RTS0, and RTS1 grounded to?
Are CTS0 and CTS1connected to host side?
Does host enable HW flow control on UART0?
+SQNIPSCFG: 2,5000 means the modem’s idle power saving is enabled, so the UART can go to sleep 5 s after the last activity. Could you retry the publish test with AT+SQNIPSCFG=0 and check whether +SQNSMQTTONPUBLISH is then output without any host activity?
If the issue remains with power saving disabled, a DM Light trace with MQTT logs and IPv4/IPv6 PDU covering the publish and the wait would help.