How to send " (0x22) over UDP through AT#XUDPSEND in SLM > v1.7

[Ivan Herrera]

Hi!

In previous versions of the SLM it was possible to provide a hex datatype to the XUDPSEND command to send blobs of data over UDP, without having to worry about a stray " value in your data. In the newer versions of the SLM this seems to be removed, and you either have to opt for regular data or data-mode. We tried both, and are failing to make it work. We've tried the following:

1. Escaping the double quotes in the regular AT command as below. This did not work. The SLM-application does not send any data and does not respond back with an error or acknowledgement.
   

   AT#XUDPSEND="Can \"we\" escape this?"\r\n

2. Using SLM-datamode. We've tried both with and without an equals sign, both error when any data is send after the first CR LF. The modem responds with "\r\nERROR\r\n". Whenever we send eg. AT#XUDPSEND="test"\r\n, the modem responds fine with the amount of bytes transferred, so we think the error is related to our use of the data-mode?
   

   AT#XUDPSEND\r\nThis is a test+++\r\n 
   AT#XUDPSEND=\r\nThis is a test+++\r\n

Would be great if you guys could give us any insight on this issue, as we'd like to upgrade our application to a recent SLM to enjoy some of the new features.

[Didrik Rokhaug]

Hi,

Please take a look at this ticket: https://devzone.nordicsemi.com/f/nordic-q-a/86231/send-hex-data-over-udp-connection

I believe your questions will be answered there.

Best regards,

Didrik

[Ivan Herrera]

Hi Didrik!

Thank you for that ticket. We've already had a look at that ticket but we're having trouble implementing the data-mode that is mentioned by you over there. We seem to be able to enter data mode, but whenever we send anything over, it exits data-mode with an ERROR response. Do you have any clue as to why? Does flow-control need to be enabled when using data-mode?

[Didrik Rokhaug]

Do you have any logs?

Preferably also the debug log which is sent over RTT. Logging is enabled by default, but it would be nice if you also set CONFIG_SLM_LOG_LEVEL_DBG=y to increase the level of logging.

[Ivan Herrera]

Hi Didrik! We haven't yet come to setting the log-level to debug but we have looked at the RTT output of the nRF91 module and these are our findings:

If we just send "AT#XUDPSEND\r\n" the RTT output is the following: 

00> *** Booting Zephyr OS build v2.7.0-ncs1-4-gf295fb7c67ca  ***
00> 
00> [00:00:00.202,026] <inf> slm: Serial LTE Modem
00> [00:00:00.231,811] <inf> slm_at_host: at_host init done
00> [00:00:25.491,973] <inf> slm_at_host: Enter datamode

Though... if we immediately send some data with that e.g. "AT#XUDPSEND\r\nThis is a test+++\r\n" we get the following output:

00> *** Booting Zephyr OS build v2.7.0-ncs1-4-gf295fb7c67ca  ***
00> 
00> [00:00:00.202,056] <inf> slm: Serial LTE Modem
00> [00:00:00.231,842] <inf> slm_at_host: at_host init done
00> [00:00:26.281,402] <err> slm_at_host: AT command invalid

It seems that data-mode isn't even entered? Now, when we add a delay of about 5ms (we chose this arbitrarily) between the "AT#XUDPSEND\r\n" command and the actual data, we get the following output.

00> *** Booting Zephyr OS build v2.7.0-ncs1-4-gf295fb7c67ca  ***
00> 
00> [00:00:00.202,026] <inf> slm: Serial LTE Modem
00> [00:00:00.231,811] <inf> slm_at_host: at_host init done
00> [00:00:28.102,691] <inf> slm_at_host: Enter datamode
00> [00:00:28.596,252] <inf> slm_at_host: Raw send 22
00> [00:00:28.596,649] <inf> slm_udp: datamode send: 22

We also note that the exit sequence (+++) is being transmitted, and the device does not exit data-mode. After reviewing the documentation we suspect this is due to the CONFIG_SLM_DATAMODE_SILENCE parameter? Still, this doesn't explain the 5ms delay which seems to be required after the data-mode command. Do you have clue as to why it is behaving this way?

[Ivan Herrera]

Additional question: in NCS 1.6, the CONFIG_SLM_DATAMODE_SILENCE parameter is defined in the SLM app documentation, but it has disappeared on the documentation in NCS 1.9. Is this configuration option still valid?