How to remotely prompt the LoRaWAN "end device" to send "uplink" data to LoRaWAN "gateway"

I have a RAK7431 “LoRaWAN end device” connected to the RAK7243C “LoRaWAN gateway”. RAK7431 supports “GSM modem/phone” AT commands listed here.

When I connect to the RAK7431 using the “RAK serial port tool” (here) and execute the simplest AT command i.e. at+version, RAK7431 responds by answering


Here is how it looks:

I want to execute the same AT command remotely using the Chirpstack and get the same answer. Therefore navigate to the Applications, select the application from the applications list and select the device from the devices list.

Then I navigate to the section “Enqueue downlink payload” where I set:

Note that:

  • “fPort” field is set to 130.

    Value 130 according to official documentation (source) defines “RS485/232 downlink data sent remotely in transparent RS485 transmission mode”.

    My RAK7431 operates in “transparent” RS485 mode which I can check using “RAK serial port tool” where command at+transparent returns true.

  • “Confirmed downlink” check mark is set to true.

  • “Base64 encoded string” field is set to YXQrdmVyc2lvbg0K.

    I encoded YXQrdmVyc2lvbg0K string using a web tool (here). There I entered at+version <CR><LF> string and set field “Destination newline sepparator” to CRLF Windows before encoding.

    Note that RAK7431’s AT commands have to by definition end with a Windows new line i.e <CR> <LF> and not Linux new line <LF> (source).

When I press ENQUEUE PAYLOAD, payload is enqueued (“FCnt” is 332):

Immediately after this I get txack (event)

  "applicationID": "9",
  "applicationName": "lorawan-test",
  "deviceName": "RAK7431--001",
  "devEUI": "rB8J//4DtNU=",
  "fCnt": 332,
  "tags": {}

and then soon ack (event):

  "applicationID": "9",
  "applicationName": "lorawan-test",
  "deviceName": "RAK7431--001",
  "devEUI": "rB8J//4DtNU=",
  "acknowledged": true,
  "fCnt": 332,
  "tags": {}

which has a key-value pair "acknowledged": true, so the base64 encoded string was received by RAK7431 device, but is it possible that it couldn’t decode it because I can’t see any data comming back…

What am I doing wrong? Am I missing anything in order to get back the data? How is data even returned? Is it by an up (event)?

Hi @71GA,

AT commands are not supported by themselves through LoRa transmissions

Depending on the end device they can support equivalent commands but with payload LoRa formats, this is, for instance sending Payload 0106 through port 23 could return some information if the end device is programmed to do that.

In your case everything is working ok, you are sending a command, the end device received it, it sent you an ack telling just that it received it.
But the device is doing nothing, as it doesn’t recognize the command that you sent.
And it is not programmed to send any answer if it fails when processing the received command.

That’s all

1 Like

I am having the exact same problem with exact same device right now.

Here is a link to the documentation.

All i have tried to do on chirpstack with it is send a reboot command, always get a txack back but device never reboots.

send to port 200 payload of 1F to reboot.
printf “1F” | base64

sending downlink to port 200 of MUY= does not work, i receive a txack but never a reboot.

RAK’s repose was " Downstream device reboot - For this, the DTu command word is 1F so you just need to send this and the device will be rebooted."

(NB. Previously we have rebooted this device and added registers and changed values to registers using downlink on TTN)

Screen Shot 2021-02-27 at 9.58.58 pm

@pulidoj pointed out at commands are not supported remotely. So there is 100% another way.

@ccall48 in the RAK7431’s “AT commands manual” I found Data interface commands chapter. Interesting options in this chapter are:

  1. at+dtumode (make sure you have it set to MODBUS i.e. at+dtumode=modbus),
  2. at+modbustimeout (I set it to default value i.e. at+modbustimeout=1000),
  3. at+transparent (I gave up on “transparent” mode, so I set it back to default “non-transparent” mode i.e. at+transparent=0),

Description of the at+transparent command mentions that in “non-transparent” mode, we should read the Appendix II: Modbus data encapsulation protocols where instead of at commands there is a description of the data encapsulation to be used - this is what @pulidoj was talking about.

In the appendix I can immediately see the point “2. Transparent Instruction / Data Message” and I am sure this is the one to be used.

Well anyway I have “polling” (RAK7431 “end device” periodically sends “uplink” messages to my gateway) already established and if I check up (event) in Chirpstack, I can find the data field that looks like this:

"data": "gQ3IAAgCAQMCAZF4eA==",

When I “decode” this data using base64 algorithm (online decoder) I get these bytes:

81 0d c8 00 08 02 01 03 02 01 91 78 78

This is how to get the bytes:

I can immediately see that first byte is 0x81 and if I check In the appendix I can immediately see the point “1. Data for Scheduled Polling Task” defines a “Execution success message format” as:

Check the first byte! It is 0x81! So I already have an example of “uplink” messages and I know how they are encoded. Now I just have to create a working example for “downlink”. But probably I will do it on monday.

@ccall48 If you will make this work before me, post an answer here. :+1:

I have not read the documentation that you linked, but it seems very likely that it wants a single byte, 0x1f, to make a reboot happen.

Hi there,

What I pointed out is not that AT are not supported.

AT commands are supported via RS232 with some kind of PC software.

Apart from that the developer of the end device software could build some pararell way via Downlink commands to do the same things as AT commands.

It is even possible that these pararell commands have the same name (AT+REBOOT for instance) that the similar AT command, but it is really difficult to find this method in an end device.

Usually AT commands are implemented as “translated” Downlink LoRawan commands

I also track your line of thought.

I have tried sending the single byte, complete list of empty bytes except for this byte. Doing so in lsb and msb order lol :joy:

I’m running out of ideas right now for this device. It is still running on a test device but thats where i got up to a few weeks back with it. Kind of in the not wasting any more time basket right now for a fresh look at a later date!

going back through some of my kept history i have tried the following (all to port 200).

printf “0x1F” | base64

printf “1F” | base64

printf “\x1F” | base64

printf “\x1F\x00\x00\x00\x00\x00\x00\x00” | base64

printf “\x00\x00\x00\x1f” | base64

printf “\x00\x00\x00\x1f\x00\x00\x00\x00” | base64

@ccall48 You are forgetting one bit! 1F00000000 is wrong.

If you use “non-transparent” mode (at+transparent=0) and you want to restart the device you must use port 129 (not 200) and you send 1F00010000 (note the one bit in the middle) where :

  • 1F tells to restart,
  • 0001 tells the message number (this is our first message),
  • 0000 is the data, but there is none.

Well actually you don’t send 1F00010000 but you first base64 encode it and then send HwABAAA=:

Good luck! This works for me.

1 Like

Hey thanks, i’ll check it out again - we have our device in transparent mode though.

I played with sending a change register value yesterday that worked on ttn in sending bytes, but not on chirp converted to base64. But i think that might be my fault as i need to add the last mser to the value to downlink payload and recalculate before sending for a valid downlink.

OK, thanks for time and sharing your information.

I collected the device and checked it over serial while playing around, at some point we must of changed some settings on this… transparent was set to off and it was set for class c :joy:

Anyway, can confirm with device set to non-transparent your packet does reboot the device if sent to port 129. here is the serial log of the event.

17:24:51.445 -> SYSLOG:4:DTU Tx : 01030100000185F6
17:24:51.479 -> SYSLOG:4:DTU Rx : 0103020130B9C0
17:24:51.512 -> SYSLOG:4:LoRa Tx : 8100550008010103020130B9C0
17:24:52.581 -> SYSLOG:4:LoRa Rx : 1F00010000
17:24:53.776 -> EVENT:0:STARTUP
17:24:53.811 -> SYSLOG:4:OTAA Join Request
17:24:59.278 -> SYSLOG:4:OTAA Join Success
17:24:59.278 -> EVENT:1:JOIN_NETWORK
17:24:59.278 -> SYSLOG:4:LoRa Tx : 
17:24:59.384 -> SYSLOG:4:DTU Tx : 01030100000185F6
17:24:59.417 -> SYSLOG:4:DTU Rx : 0103020130B9C0
17:25:01.032 -> SYSLOG:4:LoRa Tx : 8100010008010103020130B9C0
17:25:02.139 -> SYSLOG:4:DTU Tx : 010301010001D436
17:25:02.139 -> SYSLOG:4:DTU Rx : 010302012CB809
17:25:02.173 -> SYSLOG:4:LoRa Tx : 810002000802010302012CB809
17:25:03.267 -> SYSLOG:4:DTU Tx : 010303000001844E
17:25:03.267 -> SYSLOG:4:DTU Rx : 0103020064B9AF
17:25:03.301 -> SYSLOG:4:LoRa Tx : 8100030008030103020064B9AF
17:25:04.394 -> SYSLOG:4:DTU Tx : 01030500000184C6
17:25:04.394 -> SYSLOG:4:DTU Rx : 01030200057847
17:25:04.429 -> SYSLOG:4:LoRa Tx : 81000400080401030200057847
17:25:05.519 -> SYSLOG:4:DTU Tx : 010305010001D506
17:25:05.519 -> SYSLOG:4:DTU Rx : 0103020000B844
17:25:05.553 -> SYSLOG:4:LoRa Tx : 8100050008050103020000B844
17:25:06.651 -> SYSLOG:4:DTU Tx : 0103050200012506
17:25:06.651 -> SYSLOG:4:DTU Rx : 0103020000B844
17:25:06.685 -> SYSLOG:4:LoRa Tx : 8100060008060103020000B844
17:25:07.754 -> SYSLOG:4:DTU Tx : 0103060000018482
17:25:07.788 -> SYSLOG:4:DTU Rx : 0103020000B844
17:25:07.788 -> SYSLOG:4:LoRa Tx : 8100070008070103020000B844

@ccall48 Great that it also works for you! Where did you manage to read this log? Is this the /var/log/syslog pn the Raspberry Pi OS?

I have connected the device via usb serial to my mac and watching the data. You can use screen or minicom for this, easiest i’ve found is the arduino ide via the serial console.

1 Like