nRF91 - thingy91_at_client_2020-04-29_bc7ade8b - is it possible to send and receive data with that client?

[Achim Kraus]

Is it possible to send and receive data with the thingy91_at_client_2020-04-29_bc7ade8b?

I found, that this is not supported by AT commands, instead socket libraries for zephyr are used. 

Is there a function in that client, which maps UDP traffic to the USB interface?

[Didrik Rokhaug]

Hi.

No, the at_client cannot be used to send data.

However, we also have the serial_lte_modem sample, which extends the functionality of the AT client to also include commands for socket operations.

You can find the documentation for that sample here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.2.0/nrf/samples/nrf9160/serial_lte_modem/README.html

I have also attached a compiled version of the sample. Note that it must be flashed with an external programmer.

Best regards,

Didrik

slm.hex

[Achim Kraus]

> This sample is an enhancement to the nRF9160: AT Client sample.

Now I get a "OK" for a "AT", and for "AT+CMEE=1", I get "\0x00OK" (binary 0x00 at the head).

After that, it stops to answer. I had to restart the thingy91.

If I don't send that "AT+CMEE=1" and send instead "AT+CFUN=0", I still get "\0x00OK" and it seems not to stop. But the other answers I checked are all starting with a binary 0x00.

Sometimes I read "at_host: Could not send AT command to modem: -8" from the serial.

Is that binary zero intended? For me that doesn't make too much sense.

[Didrik Rokhaug]

I also get the extra 0x00 byte, though it does not seem to cause any problems for me.

What program are you using to communicate with the Thingy?

[Achim Kraus]

A custom java application. I simply drop the 0 at the head, so it works for me as well.

I was just wondering, that a example which claims to be an extension, introduces also such changes. In the meantime I got aware, that the prebuild is 1.1. The sources are currently 1.2. So maybe, if I manage to spend some time into building it, the behavior changes back.

[Didrik Rokhaug]

The hex file I sent was from NCS v1.2.0.

The AT#XSLMVER command (I assume that is what you used), gives the version of the sample, not the SDK version.

Do you still have the problem with +CMEE=1?