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?

[Didrik Rokhaug]

Ivan Herrera said:

It seems that data-mode isn't even entered?

Without having checked the code to see if my assumption is correct, it sounds like the SLM isn't splitting on the \r\n, and takes the whole string as a command.

Ivan Herrera said:

We also note that the exit sequence (+++) is being transmitted, and the device does not exit data-mode

The exit sequence must be sent without any line endings. I.e. there is a difference between "+++" and "+++\r\n". The first should get you out of data mode, the second one will not.

Ivan Herrera said:

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?

No, that option no longer exist.

[Ivan Herrera]

Hi Didrik!

When upgrading from SLM 1.8.99 to SLM v1.9.1 the first issue disappeared. The second issue with it not exiting data-mode also was resolved when exclusively sending +++ without any CR LF. 

Regarding the silence period, there still seems to be a small pause required around the "+++" send but sleeping for 1ms does the trick for us so this is more than acceptable in our use case.

Thank you for your support!