RAK3172 Overlooked but Useful LoRaWAN® AT Commands

The RAK3172 WisDuo module with the default RAK firmware is usually used as a LoRaWAN modem together with the host MCU in most IoT applications. You can have a successful end-device when the host MCU sends even just the basic EUIs/keys commands and joining/sending commands. In this article, I will share five overlooked commands that is not usually used by RAK users who are only familiar with the previous WisDuo Modules based on RUI V2 firmware.

1. Checking if the last confirmed uplinks is successful or not.

RAK3172 has a command to check if the last confirmed message is successful without needing to check the asynchronous `+EVT:SEND CONFIRMED OK` reply after sending the uplink payload. Using this feature is a lot easier to do in the host firmware than creating an additional parser for the successful confirmation of the confirmed uplink. You just need to send `AT+CFS=?`. This command will return 0 if the last confirmed uplink failed and 1 if it was successful.

2. Configuring uplink payload to be confirmed or unconfirmed directly on a single send command.

The standard way of sending uplink payload on RAK3172 is via `AT+SEND`. The other option that is introduced in RAK3172 is the `AT+USEND` command. On the standard `AT+SEND`, you can only set the port of the uplink payload. On the more configurable command `AT+USEND`, you can directly set not only the port of the uplink payload but also if it is a confirmed or unconfirmed payload.

You can also configure the number of retransmission attempts if the payload is set to be confirmed. In this example, the uplink is confirmed and uses port 2 and configured to have 5 retransmission attempts.

3. Checking the connectivity status of the device to the LoRaWAN® network.

In the LoRaWAN specification standard, there is a dedicated MAC command for validating and checking the connectivity status of the end-device to the network. This MAC command is `LinkCheckReq` and has a CID (Command Identifier) 0x02 in the LoRaWAN specifications. In RAK3172, this MAC command is made accessible via `AT+LINKCHECK`. By using this AT command, you will have the status reply from the network server for the `LinkCheckReq` request. You can have the information about DemodMargin, number of Gateways, RSSI and SNR by utilizing this feature. Take note that network server reply to `LinkCheckReq` is a downlink packet to the end-device so it must be used strategically and only when necessary.

4. Sending long uplink payload.

There are some applications that long payload size is needed to be transmitted. RAK3172 accommodates this requirement by introducing `AT+LPSEND` command. This command is a custom command developed by RAKwireless and only compatible to WisGate Edge gateways. With this feature, you can transmit up to 1024 bytes of payload in one go and will be sliced and reconstructed automatically for you. Another good thing about this command is that it handles proper slicing of the payload depending on the DR(DataRate) you use.

5. Getting the UTC time from the LoRaWAN network server

RAK3172 also has the ability to get the UTC time from the LoRaWAN network server. You need to use `AT+TIMEREQ=1` and `AT+LTIME=?`commands to utilize this functionality. In LoRaWAN specification standard, this is a special MAC command called DeviceTimeReq. This is very helpful in applications that needs to know the exact time. By using this feature, you can save cost on RTC chip as well as CMOS battery used by the RTC. Your RAK3172 device should be successfully joined first and must have a successful uplink to get the UTC time.

6. Removal of sleep mode command.

The new RAK3172 has no more sleep mode command unlike the previous WisDuo Modules. There are many inquiries from the RAK user community about how to make the RAK3172 go to sleep mode. Good news is that it is not a mistake in the documentation that it is missing, because it was totally removed by design. The RAK3172 module will automatically go to sleep mode after processing each commands. This is a definitely an improvement in WisDuo line.

There are situations that RAK3172 will not go to sleep mode because the RF section must still be on. Example on this is when the device is operating in LoRaWAN class C mode and when the device is in continuous receiver mode in LoRa P2P mode. Nonetheless, a LoRaWAN module that automatically sleeps by default and without necessary configuration is helpful for LoRaWAN application and device developers specially if they are working on battery powered LoRaWAN devices.

7. Configuration of RX Window Parameters

The RAK3172 has the flexibility in the RX windows configurations. The previous WisDuo modules has no capabilities in modifying the RX window parameters of the LoRaWAN payload uplinks. This is critical on LoRaWAN applications where the users needs to change LoRaWAN network server settings.

The classic example to this is when The Things Network changed their RX1 and RX2 delays when they migrated to TTN V3. The table shows the AT Commands and parameter that it can modify.

8. Setting up RF test mode.

All LoRaWAN end-device and nodes transmits and receive Radio Frequency (RF) signals. It is critical for RAK customers who develop LoRaWAN devices to certify their products in their respective markets. Like for US, there is FCC which is the agency that ensures that each products follows the RF regulations mandated by law. In the previous WisDuo modules, RF test mode is not implemented. In RAK3172, there is a set of AT commands dedicated on RF test mode and compliance. These commands is designed to aid LoRaWAN device developers in getting certifications on their IoT products. The table shows the AT commands that configure the RF test mode of RAK3172.