-
Notifications
You must be signed in to change notification settings - Fork 3
AT Command Interface
The modem firmware provides an AT command interface (ATCI) via an UART port on the TypeABZ's GPIOs PA2 (pin 23) and PA3 (pin 24). By default and upon a factory reset, the port is configured as 19200 8-N-1 (8 data bits, no parity, one stop bit).
MKR WAN 1310 Builds: Firmware build variants for the Arduino MKR WAN 1310 board can detach (disconnect) from the GPIO pins used by the ATCI UART port. See AT$DETACH for more details.
All commands start with the case-sensitive prefix AT and are terminated with a carriage return (ASCII 0x0D). The following rules in the augmented Backus-Naur form (ABNF) [RFC 5234, RFC 7405] describe the general syntax of all AT commands:
command = %s"AT" name (get / set / async) ; the prefix AT is case-sensitive
name = ("+" / "$") id ; AT command names are case-sensitive
id = 1*(VCHAR) ; VCHAR can expand to any visible character except "?" and "="
get = "?" CR
set = "=" 1*OCTET CR ; OCTET can expand to any character except CR
async = [params] CR [data] ; The length of data must be determined by params
params = SP param *("," param) ; A list of parameters delimited by ","
param = 1*OCTET ; OCTET can expand to any character except "," and CR
data = 1*OCTET ; The number of octets is determined by one of the parametersThe modem acknowledges all AT commands with a response. The following rules describe the general syntax of the response:
response = inline-response / multiline-response
inline-response = "+" (success / failure) CRLF CRLF
multiline-response = 1*(0*OCTET CRLF) %s"+OK" CRLF CRLF
success = %s"OK" ["=" value]
failure = %s"ERR" = code
value = 1*OCTET ; OCTET can expand to anything except CR and LF
code = "-" number
number = 1*DIGITAn +OK response indicates that the command was understood and has been accepted for processing. An +ERR response indicates that the modem could not process the command. The code can be any of the following values:
| Code | Meaning |
|---|---|
| -1 | Unknown command |
| -2 | Invalid number of parameters |
| -3 | Invalid parameter value(s) |
| -4 | Factory reset failed |
| -5 | Device has not joined LoRaWAN yet |
| -6 | Device has already joined LoRaWAN |
| -7 | Resource unavailable: LoRa MAC is transmitting |
| -8 | New firmware version must be different |
| -9 | Missing firmware information |
| -10 | Flash read/write error |
| -11 | Firmware update failed |
| -12 | Payload is too long |
| -13 | Only supported in ABP activation mode |
| -14 | Only supported in OTAA activation mode |
| -15 | RF band is not supported |
| -16 | Power value too high |
| -17 | Not supported in the current band |
| -18 | Cannot transmit due to duty cycling |
| -19 | Channel unavailable due to LBT or error |
| -20 | Too many link check requests |
| -50 | Access to LoRaWAN security keys denied |
| -51 | Request to detach ATCI rejected (PB12 is low) |
The modem generates asynchronous notifications in response to network activity or internal state changes. The following rules describe the general syntax of asynchronous notifications:
notification = "+" (recv / event / ack / answer)
recv = %s"RECV" "=" number "," number CRLF CRLF [data] CRLF ; See above for number and data
event = %s"EVENT" "=" number "," number CRLF CRLF ; See above for number
ack = (%s"ACK" / %s"NOACK") CRLF CRLF
answer = %s"ANS" "=" number [params] CRLF CRLF ; See above for number and paramsNote: The modem can generate asynchronous notifications at any time. For example, the application should be ready to receive asynchronous notifications between an AT command and the response to that command (+OK or +ERR).
The modem generates a +RECV notification for each downlink message it receives from the network. The first number represents the destination port number. The second parameter defines the payload size (data) in bytes. This notification respects the AT+DFORMAT setting. If set to 1, the payload will be encoded in a hexadecimal format. If set to 0, the payload will be sent in binary form. The size parameter is always in bytes, regardless of the AT+DFORMAT setting. The payload is delimited from the notification with a pair of CRLF. The modem transmits another CRLF sequence at the end of the payload. The CRLF sequences are excluded from the payload size value.
The modem generates +EVENT notifications in response to internal or network state changes. Each notification carries a pair of numbers delimited with a comma. The first number represents the subsystem that generated the event. The second number represents the type of event. The following table summarizes those values:
| Event | Meaning |
|---|---|
| +EVENT=0,0 | Modem rebooted |
| +EVENT=0,1 | Factory reset |
| +EVENT=0,2 | Modem switched to bootloader |
| +EVENT=0,3 | Modem halted |
| +EVENT=0,9 | The GPIOs used by ATCI have been reattached |
| +EVENT=1,0 | Join failed |
| +EVENT=1,1 | Join succeeded |
| +EVENT=2,0 | Network server did not respond to a LoRaWAN MAC command |
| +EVENT=2,1 | Received a LoRaWAN MAC command response from the network server |
| +EVENT=2,2 | Uplink retransmitted |
| +EVENT=9,0 | Continuous wave transmission ended |
| +EVENT=9,1 | Continuous modulated FSK transmission ended |
The modem generates +ACK and +NOACK notifications in response to confirmed uplink messages. The former indicates that the network server confirmed the uplink. The latter means that the network server did not confirm the uplink. These notifications carry no parameters or values.
+ANS notifications are generated when then network server responds to a LoRaWAN MAC request from the device. The general syntax is +ANS=<CID>,<params...>, where <CID> is the MAC command's identifier according to the LoRaWAN specification and <params> are command-specific parameters. The format of the parameters is documented in the corresponding AT command section in this wiki.
The modem implements three classes of AT commands: getters, setters, and actions. A single AT command can support all three types simultaneously or just a subset of the types.
Getter AT commands are terminated with ?, for example, AT+UART?. Most getter commands return a value immediately with the +OK response, for example, +OK=19200,8,1,0,0. The syntax of the value is command-specific. A small number of getters and actions can return a longer value spreading over multiple lines between the AT command and an +OK response which terminates the output, for example:
AT$CHANNELS?
0,902300000,0,0,3,0
...
0,909100000,0,0,3,0
+OK
Setter AT commands are of the form AT<name>=<value>, for example, AT+UART=9600. The syntax of the value is command-specific. Setter commands return no value via the +OK response. Setters are generally used to modify modem parameters. Since a setter must report the status of the operation immediately, it cannot be used to perform operations that require network communication.
Action AT commands are of the form AT<name> [params], for example, AT+LNCHECK. An action command can accept a variable number of comma-delimited parameters separated from the command by a single space (ASCII 0x20). Some action commands accept arbitrary data (payload) following the CR character that terminates the command. Action commands are generally used to perform operations that do not complete immediately, e.g., uplink transmission, factory reset, reboot, etc. The modem acknowledges the reception of an action command with +OK. This response only indicates that the modem enqueued the command for processing. The status of the operation will be reported via separate event notifications, for example, +EVENT=2,1.
Two meta-commands can be used to display a list of all AT commands implemented in the modem: AT$HELP and AT+CLAC. The first returns a list of all implemented AT commands followed by a short description of each. The second returns AT command names only. Note: In firmware versions <= 1.1.3, AT$HELP and AT+CLAC did not terminate the output with +OK. In newer firmware versions, the two commands terminate the output with +OK.
The modem implements two sets of AT commands. The commands that start with the prefix AT+ are designed to be compatible with the AT commands implemented by the Murata Modem firmware in the Type ABZ-93 line of modules. The commands that start with the prefix AT$ are custom extension AT commands explicitly designed for this firmware. The extension commands generally provide additional functionality not found in the AT+ set.
The rest of this page documents individual AT commands.
Configure the baud rate of the ATCI UART port. This command can only be used to configure the port's baud rate. Other parameters such as data bits, parity, stop bits, or flow control cannot be configured. Only the following baud rate values are supported: 4800, 9600, 19200, 38400. The configured value is permanently stored in NVM (EEPROM). The modem will switch to the newly configured baud rate after reboot.
When used as a getter, the command returns a tuple of values delimited with commas:
<baudrate>,<data_bits>,<stop_bits>,<parity>,<flow_control>
The default configuration of the UART port after the factory reset is 19200 8N1.
AT+UART?
+OK=19200,8,1,0,0
AT+UART=9600
+OK
See also: AT+REBOOT
Return the version and build date of the emulated Murata Modem firmware.
The AT+ commands implemented by the open firmware emulate a certain version of the Murata Modem firmware shipped with Type ABZ modules. The string returned by this AT command indicates which Murata Modem version is being emulated. Both the version and the build date are intentionally set to match the emulated Murata Modem. The only currently emulated Murata Modem firmware version is 1.1.06.
To obtain the real version of the open firmware, use the command AT$VER instead.
AT+VER?
+OK=1.1.06,Aug 24 2020 16:11:57
See also: AT$VER
Return the model of the Type ABZ module hardware. This command always returns the string "ABZ".
AT+DEV?
+OK=ABZ
Restart the modem.
This command can be used to restart the modem. By default (when invoked without any arguments), the command performs a clean restart, where the modem first waits for all active tasks to complete and then it schedules the restart. In this case, the modem returns +OK to indicate that a restart has been scheduled. Once the restart has been performed, the modem sends an asynchronous notification: +EVENT=0,0.
To perform a hard restart without waiting for anything, the application can invoke the command as AT+REBOOT 1. In this case, the modem will restart immediately. Note that the modem does NOT return a +OK in this case. The modem sends a +EVENT=0,0 upon hard restart. The hard restart option is a custom extension not present in the original Type ABZ firmware.
AT+REBOOT
+OK
+EVENT=0,0
Re-initialize all modem parameters to factory defaults. Upon restoring all parameters, the modem automatically performs a reboot. A successful reset to factory defaults is signaled with +EVENT=0,1. A successful reboot is indicated with +EVENT=0,0.
This AT command takes an optional flags integer argument that can be used to select additional settings to reset to factory defaults. When omitted or set to 0, no additional settings will be reset. When bit 0 is set, the DevNonce setting will be reset to zero. When bit 1 is set, the DevEUI setting will also be reset to a default value. To reset both, invoke the command as AT+FACNEW 3.
Since 1.1.0, AT+FACNEW does NOT reset the DevNonce setting by default. The value from before the factory reset is preserved. This ensures that the device can rejoin the network with an OTAA Join upon factory reset.
Since 1.1.2, AT+FACNEW does NOT reset the device EUI (DevEUI) by default. If you wish to reset this setting, the bit 1 in the flags parameter must be set. The DevEUI is reset to a value derived from the MCU's unique ID, i.e., the factory default DevEUI value is different on each modem.
AT+FACNEW
+OK
+EVENT=0,1
+EVENT=0,0
See also: AT+REBOOT
Configure the region to be used by the modem. When used as a getter, the command returns the id (number) of the currently activated region. The following table summarizes the regions supported by the firmware.
| ID | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|---|---|---|---|---|---|---|---|---|---|---|
| Region | AS923 | AU915 | CN470 | CN779 | EU433 | EU868 | KR920 | IN865 | US915 | RU864 |
When you select the same region as the currently active region, the modem will only respond with +OK. When you select a different region, the modem will perform a partial factory reset indicated by +EVENT=0,1, followed by a reboot indicated by +EVENT=0,0. A partial factory reset configures factory defaults for most LoRaWAN-related parameters, but leaves security keys, the DevNonce value, and system parameters such as the UART port baud rate unmodified.
AT+BAND?
+OK=8
AT+BAND=5
+OK
+EVENT=0,1
+EVENT=0,0
Note 1: Attempts to configure bands 2, 3, or 4 in the original Murata Modem firmware return +ERR=-15. Since version 1.2.0, those bands are also disabled in the official build of the open firmware. However, the open firmware can configure those bands if explicitly enabled at build time. Note that the transceiver frontend in the TypeABZ module has been tuned for the 868 MHz and 915 MHz bands only.
Note 2: Band 9 has a different meaning in the original Murata Modem firmware and in the open firmware. In Murata Modem, band 9 was a modified version of US915 called US915-hybrid. That pseudo-region was designed to help devices cope with older 8-channel US915 gateways unable to configure a channel subset into the device. This trick is no longer needed with recent LoRaWAN gateways and band 9 is thus assigned to RU864 in the open firmware to keep the numbering consistent with the LoRaMac-node library.
Configure the LoRaWAN device class. The device class determines how the LoRa receiver operates. In class A the LoRa receiver is only active during two short time windows that follow the transmission of an uplink. In class C the receiver is active at all times and can receive downlink messages at any time. Keeping the receiver permanently activated will increase the power consumption of the device considerably. Thus, class C mode is only suitable for mains-powered devices.
The following table summarizes the supported classes and their IDs.
| ID | 0 | 1 | 2 |
|---|---|---|---|
| Class | A | B | C |
Please note that this AT command can only be used to switch between classes A and C. Switching to class B is not supported.
The LoRaWAN class of the device can only be switched while the device is idle, i.e., when the device has no uplink or downlink operation in progress.
AT+CLASS?
+OK=0
AT+CLASS=2
+OK
[1] LoRa Developer Portal, "What Are LoRa and LoRaWAN?", Accessed: April 2022
Configure or query the LoRaWAN network activation mode to be used by the device. The value 1 switches the modem into the over the air activation (OTAA) mode. The value 0 switches the modem into the activation by provisioning (ABP) mode. The default mode is ABP.
AT+MODE?
+OK=0
AT+MODE=1
+OK
Get or set the LoRaWAN device address (DevAddr) assigned to the modem. In OTAA mode, the device address is assigned by the network server upon Join. In ABP mode, the device address must be manually configured using this command.
The DevAddr is a 32-bit number that consists of two parts: an address prefix and a network address. The address prefix is unique to each LoRaWAN network and is centrally allocated by the LoRa Alliance. If you need to manually configure the DevAddr, select an address within the range assigned to your network. If your network does not have an address prefix, or if you don't know it, you can select a DevAddr from the two ranges allocated for experimental or private nodes:
- 00000000/7 : 00000000 - 01ffffff
- 02000000/7 : 02000000 - 03ffffff
You can use the following Python snippet to generate a random DevAddr that falls into the second range from above:
import random
print(format(random.randint(0x02000000, 0x03ffffff), '08X'))In the AT command interface, the DevAddr is encoded in a hexadecimal format with the most significant byte (MSB) transmitted first. Thus, the address prefix is encoded first.
Upon factory reset, and whenever the DevAddr consists of all zeroes, the modem generates a random DevAddr in the second range from above during start.
AT+DEVADDR?
+OK=00C86190
AT+DEVADDR=00123456
+OK
Configure the LoRaWAN device EUI (DevEUI). The DevEUI is a 64-bit globally unique extended identifier assigned to the device by the manufacturer. Upon factory reset, the device is assigned a DevEUI derived from the unique identifier of the microcontroller. The AT command interface transmits the DevEUI encoded in a hexadecimal format.
Note: In the original Type ABZ firmware factory reset does not change the DevEUI. Our implementation restores the DevEUI to the value derived from the unique MCU identifier.
AT+DEVEUI?
+OK=3632313961398608
AT+DEVEUI=3632313961398608
+OK
See also: AT$MCUID
Query or set the LoRaWAN AppEUI. In recent LoRaWAN specifications, the parameter was renamed to JoinEUI. The AppEUI is a 64-bit globally unique identifier that identifiers the join server (or the application server). This value is meant to identify the server that shares the device's root application (AppKey) and network (NwkKey) keys. In the AT command interface the AppEUI/JoinEUI is encoded in a hexadecimal format.
The default value is 0101010101010101.
AT+APPEUI?
+OK=0101010101010101
AT+APPEUI=0202020202020202
+OK
See also: AT$JOINEUI, AT+APPKEY, AT$NWKKEY
Get or set the LoRaWAN network session key (NwkSKey). The network session key is a 128-bit symmetric key that secures communication between the device and the network server. In OTAA mode, the key is automatically negotiated between the device and the network server during Join. Thus, there is no need for the application to use this command. In ABP mode, a unique key must be provided by the application during provisioning.
You can generate a new random NwkSKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2This AT command is designed for LoRaWAN 1.0 activation. Since the underlying implementation is LoRaWAN 1.1 compatible, this command configures the following keys with the same value: FNwkSIntKey, SNwkSIntKey, NwkSEncKey. If you wish to configure these keys individually, use AT$FNWKSINTKEY, AT$SNWKSINTKEY, or AT$NWKSENCKEY instead.
When used to obtain the currently configured value, the command returns the value of FNwkSIntKey.
In the AT command interface the key is encoded in a hexadecimal format. The default value after factory reset is 2B7E151628AED2A6ABF7158809CF4F3C.
AT+NWKSKEY?
+OK=0EBE7178CC09F92B6F66C641AC8E89EF
AT+NWKSKEY=0EBE7178CC09F92B6F66C641AC8E89EF
+OK
See also: AT$FNWKSINTKEY, AT$SNWKSINTKEY, AT$NWKSENCKEY
Get or set the LoRaWAN application session key (AppSKey). The application session key is a 128-bit symmetric key that secures communication between the device and the application server. In OTAA mode, the key automatically negotiated between the device and the network during Join. Thus, there is no need for the application to use this command. In ABP mode, a unique key must be provided by the application during provisioning.
You can generate a new random AppSKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2In the AT command interface the key is encoded in a hexadecimal format. The default value after factory reset is 2B7E151628AED2A6ABF7158809CF4F3C.
AT+APPSSKEY?
+OK=0EBE7178CC09F92B6F66C641AC8E89EF
AT+APPSSKEY=0EBE7178CC09F92B6F66C641AC8E89EF
+OK
Get or set the LoRaWAN root application key (AppKey). The AppKey is a 128-bit symmetric key that is used to derive an application session key (AppSKey) during LoRaWAN OTAA Join.
This AT command is designed for LoRaWAN 1.0 activation. LoRaWAN 1.1 introduced an additional root key called NwkKey. Since the underlying implementation is LoRaWAN 1.1 compatible, this command configures both AppKey and NwkKey with the same value. If you wish to configure the two keys individually, use AT$APPKEY or AT$NWKKEY instead.
You can generate a new random AppKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2When used to obtain the currently configured value, the command returns the value of AppKey.
AT+APPKEY?
+OK=2B7E151628AED2A6ABF7158809CF4F3C
AT+APPKEY=2B7E151628AED2A6ABF7158809CF4F3C
+OK
See also: AT$APPKEY, AT$NWKKEY
Join LoRaWAN network in over-the-air-activation (OTAA) mode.
If the modem is in OTAA mode (AT+MODE=1), this command sends a Join LoRaWAN request to the network (Join Server). If the modem is in ABP mode (AT+MODE=0), the command returns +ERR=-14.
This is an asynchronous command. The modem responds with +OK or +ERR immediately. An ok response indicates that the Join request was successfully enqueued and could be sent. An error response indicates that the modem could not send a Join request at this time, e.g., due to duty cycling restrictions or some other operation in progress.
Upon receiving a Join accept from the Join Server, the modem sends +EVENT=1,1. If the Join Server does not respond in time, the modem sends +EVENT=1,0 to the application to indicate that the Join request timed out.
Since firmware version 1.1.0, Join requests are transmitted up to nine times. This also means that it will take longer to receive an +EVENT=1,{0,1}, up to a minute if no Join answer is received from the network. The default number of Join transmissions is set to nine to make sure that the Join is transmitted at least once in each eight-channel sub-band in regions that use all 64 channels, such as US915, plus one extra transmission in the 500 kHz channel sub-band.
The modem applies a small randomly generated delay before each retransmission in accordance with Section 7 of LoRaWAN Specification v1.1. The random number generator is seeded from the LoRa radio which generates a random seed on each device. The random delay is between 100 ms and 500 ms.
Please note that the number of retransmissions configured via AT+REP and AT+RTYNUM do not apply to OTAA Joins.
This AT command takes two optional parameters: AT+JOIN [<data_rate>[,<transmissions>]]. The first parameter controls the data rate used to transmit the Join request. The value must be between 0 and 15 and is region-specific. The default value is 0. The second parameter controls how many times the Join request will be transmitted. This value must be between 1 and 16. The default value is 9. If you only wish to change the number of transmissions, set the first parameter to 0 (the default).
The optional parameters are a custom extension of this firmware. They are not supported by the original Murata Modem firmware.
Note: Join requests are subject to additional duty cycling restrictions even in regions that otherwise do not use duty cycling. See the documentation for AT+JOINDC for more details.
AT+JOIN
+OK
+EVENT=1,1
Enable or disable OTAA Join duty cycling.
Uplink messages sent synchronously by a large number of devices in response to a common external event, e.g., network outage, have the potential to trigger a network-wide synchronization, also known as the thundering herd problem. In LoRaWAN networks, OTAA Join is one of such messages. A large number of devices transmitting (and retransmitting) OTAA Join requests synchronously could overload the available radio channels or the LoRaWAN network server.
The LoRaWAN specification in Section "7 Retransmissions back-off" defines two mechanisms designed to mitigate RF or network overload:
- Additional duty cycling of Join requests;
- Join retransmission randomization.
Join requests transmitted by LoRaWAN devices are subject to additional duty cycling restrictions, in addition to any duty cycling already enforced by the region (band). The additional duty cycling restrictions placed on Join request transmissions can be summarized as follows:
- The aggregate transmission time in the 1st hour since device start must not exceed 36 seconds;
- The aggregate transmission time between the 2nd and 11th hour since device start must not exceed 36 seconds;
- The aggregate transmission time over the most recent 24 hours after the 11th hour must not exceed 8.7 seconds.
When retransmitting a Join request, LoRaWAN-compliant devices are also required to postpone the retransmission by a small randomized delay to prevent network-wide synchronized transmissions.
This AT command can be used to enable or disable the additional Join duty cycling restrictions. Note: The command only controls Join request duty cycling; it does not influence retransmission randomization which is always in effect.
Warning: All LoRaWAN-compliant devices must implement Join duty cycling and retransmission randomization. Please exercise caution when disabling Join duty cycling.
Join duty cycling is enabled by default in all regions, irrespective of whether the region (band) enforces RF duty cycling. This settings is independent of AT+DUTYCYCLE. Disabling one does not disable the other and vice versa.
AT+JOINDC?
+OK=1
AT+JOINDC=0
+OK
Supported since: 1.1.0
See also: AT+JOIN, AT+DUTYCYCLE
Perform a link check between the modem and the network.
This command sends a LoRaWAN LinkCheckReq MAC command to the network server. The command can be sent either immediately or together with the next regular uplink transmission. By default, when AT+LNCHECK is invoked without parameters or as AT+LNCHECK=0, the modem sends the LinkCheckReq MAC command immediately in a dedicated unconfirmed uplink to port 0 with no payload. If you wish to send the request as part of the next regular uplink instead, invoke the command as AT+LNCHECK=1.
Upon receiving the request, the network server sends a LinkCheckAns MAC response back which includes the link margin and the number of gateways that received the request. The modem notifies the application with +EVENT=2,1 followed by +ANS=2,<margin>,<gw-count>. If no response is received, the modem only sends +EVENT=2,0 to indicate that the MAC request timed out.
The <margin> value represent the strength of the device's signal relative to the demodulation floor at the gateway. The value is in dB. A value of 0 indicates that the gateway can barely receive uplinks from the device. A value of 12 indicates that the uplink was received 12 dB above the demodulation floor. The range of the margin value is 0 to 254.
The <gw-count> value represents the number of gateways that successfully received the uplink carrying the LinkCheckReq MAC command. If multiple gateways received the uplink, this margin value discussed in the previous paragraph represents the margin of the gateway selected by the network server for downlinks to the device, usually the gateway with the best margin.
Note: Link check requests are not retransmitted. The modem will send only one link check request for each AT+LNCHECK.
AT+LNCHECK
+OK
+EVENT=2,1
+ANS=2,26,2
Query or configure RF channel parameters.
When used as a getter, this AT command returns a list of all currently active RF channels. The format of the data is as follows:
<count>[;<number>,<freq>,<min_dr>,<max_dr>[;...]]
The field <count> represents the total number of RF channels in the output. Individual RF channels are delimited with a semicolon. Each RF channel starts with the logical channel <number> counted from 0, followed by the channel's frequency in Hz, the minimum allowed data rate, and the maximum allowed data rate.
When used as a setter, this AT command can be used to configure the parameters of an individual RF channel. The setter takes three parameters delimited by commas: <number>,<freq>,<min_dr>,<max_dr>, where number is the logical number of the channel counted from 0, <freq> is the center frequency of the channel, <min_dr> is the minimum data rate and <max_dr> is the maximum data rate. Note that not all channels can be configured. Each region reserves a small number of channels with low logical numbers that cannot be reconfigured.
To configure a new RF channel, pick a logical channel number that does not appear in the output of AT+RFPARAM?.
To delete an existing channel, specify only the channel's logical number and omit all other parameters: AT+RFPARAM=<number>. This operation is a custom extension of the open firmware and may not be supported by the original Murata Modem firmware.
The maximum number of active RF channels is region-specific.
AT+RFPARAM?
+OK=3;0,868100000,0,5;1,868300000,0,5;2,868500000,0,5
AT+RFPARAM=3,867100000,0,5
+OK
Supported since: 1.2.0
Get or set the RF output power used to transmit LoRa uplink messages.
The Type ABZ module contains a SX1276 transceiver chip from Semtech. The transmitter in the chip supports three modes of operation controlled by two SX1276 registers: RegPaConfig and RegPaDac. The former controls whether the transmitter operates in RFO or PABOOST mode. The latter can additionally activate a high-power 20 dBm duty cycled mode. The following table summarizes the minimum and maximum transmit powers achievable in each mode.
| Mode | RegPaConfig | RegPaDac | Minimum TX power | Maximum TX power |
|---|---|---|---|---|
| RFO (low power) | RFO | - | -4 dBm (0.4 mW) | 15 dBm (31.6 mW) |
| PABOOST continuous | PABOOST | 20DBM_ON | 2 dBm (1.6 mW) | 17 dBm (50 mW) |
| PABOOST 1% dutycycle | PABOOST | 20DBM_OFF | 5 dBm (3.2 mW) | 20 dBm (100 mW) |
The modem firmware selects the appropriate mode automatically based on the output power requested by the LoRaMac stack or by the application. For transmit powers between -4 dBm and 14 dBm, the firmware uses the RFO mode. For transmit powers higher than 14 dBm the modem activates the PABOOST mode. For transmit powers higher than 17 dBm, the modem additionally activates the high-power 20 dBm mode. Note that the high-power 20 dBm mode requires 1% duty cycle and VSWR at the antenna port better than 3:1.
The syntax of the value expected and returned by AT+RFPOWER is <mode>,<index>. The first parameter controls the transmitter mode (0 for RFO, 1 for PABOOST). Since the open firmware selects the transmitter mode automatically, this value is unused, but the syntax has been retained for compatibility with the original firmware. When queried, the modem always returns a mode of 0.
The meaning of the index value is region specific.
In the US915 region, the index value selects the maximum RF output power relative to the fixed maximum of 30 dBm. Please note that in the US915 region the maximum allowed RF output power also depends on the number of active channels (channel mask) and the selected data rate. Thus, the actual RF output power may actually be lower than the values listed in the following table. With SF8/500kHz the RF output power is limited to 25 dBm. With less than 50 channels active, the output power is further capped to 21 dBm.
In all other regions, the index values selects an RF output power relative to the MaxEIRP value configured through the AT command AT+MAXEIRP. Please note that not all values may be available in all regions.
| Index | Maximum output power in US915 [dBm] | Output power in other regions |
|---|---|---|
| 0 | 30 | MaxEIRP |
| 1 | 28 | MaxEIRP-2 |
| 2 | 26 | MaxEIRP-4 |
| 3 | 24 | MaxEIRP-6 |
| 4 | 22 | MaxEIRP-8 |
| 5 | 20 | MaxEIRP-10 |
| 6 | 18 | MaxEIRP-12 |
| 7 | 16 | MaxEIRP-14 |
| 8 | 14 | MaxEIRP-16 |
| 9 | 12 | MaxEIRP-18 |
| 10 | 10 | MaxEIRP-20 |
| 11 | 8 | MaxEIRP-22 |
| 12 | 6 | MaxEIRP-24 |
| 13 | 4 | MaxEIRP-26 |
| 14 | 2 | MaxEIRP-28 |
The range is from 0 to 14. In regions with a lower maximum power, higher index values are not supported. Only up to 2 dBm.
Upon factory reset, the device is configured for the EU868 region, with maximum EIRP set to 16 dBm, and with an RFPOWER index of 1. This configuration translates to the default transmit power of 14 dBm (25 mW).
AT+RFPOWER?
+OK=0,1
AT+RFPOWER=0,0
+OK
See also: AT+MAXEIRP, AT$RFPOWER
Configure whether the device is connected to a LoRaWAN-compatible network or some other private network.
Each LoRa packets begins with a preamble used to synchronize the transmitter and receiver. The preamble includes a synchronization word which indicates the network(s) the packet is intended for. One synchronization word has been standardized for LoRaWAN networks, both public such as The Things Network and private such as commercial LoRaWAN networks. Networks that are not LoRaWAN-compatible should use a different synchronization word. A different synchronization word ensures that packets destined to LoRaWAN will not unnecessarily wake up private networks operating in the same region and channels and vice versa.
This AT command can be used to configure the synchronization word used by the device. A value of 1 selects the synchronization word for LoRaWAN (0x34). A value of 0 selects the synchronization word used for private networks (0x12). In most cases, if you are connecting to LoRaWAN-compatible network, you should use 1 here. This is also the default value.
AT+NWK?
+OK=1
AT+NWK=0
+OK
Enable or disable adaptive data rate (ADR).
When set to 1, the device indicates support for ADR in uplinks and will adjust the data rate, transmit power, and number of retransmissions based on ADR requests from the network server. When set to 0, ADR requests to adjust these parameters from the network server are ignored.
The default value is 1 (ADR enabled).
AT+ADR?
+OK=1
AT+ADR=0
+OK
[1] LoRa Developer Portal, "Implementing Adaptive Data Rate (ADR)", Accessed: April 2022
[1] LoRa Developer Portal, "What is an Adaptive Data Rate?", Accessed: April 2022
[1] LoRa Developer Portal, "LoRa Device Mobility: An Introduction to Blind ADR", Accessed: April 2022
Get or set the data rate to be used by the device for uplink messages.
The command accepts an integer index value within the range of 0 (inclusive) to 15 (inclusive). Each index value maps to a combination of modulation type, spread factor, and channel bandwidth. The mappings are defined in LoRaWAN regional parameters RP002-1.0.3:
| Index | AS923 | AU915 | CN470 | CN779 | EU433 | EU868 | KR920 | IN865 | US915 | RU864 |
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | LoRa SF12/125 kHz | LoRa SF12/125 kHz | LoRa SF12/125 kHz | LoRa SF12/125 kHz | LoRa SF12/125 kHz | LoRa SF12/125 kHz | LoRa SF12/125 kHz | LoRa SF12/125 kHz | LoRa SF10/125 kHz | LoRa SF12/125 kHz |
| 1 | LoRa SF11/125 kHz | LoRa SF11/125 kHz | LoRa SF11/125 kHz | LoRa SF11/125 kHz | LoRa SF11/125 kHz | LoRa SF11/125 kHz | LoRa SF11/125 kHz | LoRa SF11/125 kHz | LoRa SF9/125 kHz | LoRa SF11/125 kHz |
| 2 | LoRa SF10/125 kHz | LoRa SF10/125 kHz | LoRa SF10/125 kHz | LoRa SF10/125 kHz | LoRa SF10/125 kHz | LoRa SF10/125 kHz | LoRa SF10/125 kHz | LoRa SF10/125 kHz | LoRa SF8/125 kHz | LoRa SF10/125 kHz |
| 3 | LoRa SF9/125 kHz | LoRa SF9/125 kHz | LoRa SF9/125 kHz | LoRa SF9/125 kHz | LoRa SF9/125 kHz | LoRa SF9/125 kHz | LoRa SF9/125 kHz | LoRa SF9/125 kHz | LoRa SF7/125 kHz | LoRa SF9/125 kHz |
| 4 | LoRa SF8/125 kHz | LoRa SF8/125 kHz | LoRa SF8/125 kHz | LoRa SF8/125 kHz | LoRa SF8/125 kHz | LoRa SF8/125 kHz | LoRa SF8/125 kHz | LoRa SF8/125 kHz | LoRa SF8/500 kHz | LoRa SF8/125 kHz |
| 5 | LoRa SF7/125 kHz | LoRa SF7/125 kHz | LoRa SF7/125 kHz | LoRa SF7/125 kHz | LoRa SF7/125 kHz | LoRa SF7/125 kHz | LoRa SF7/125 kHz | LoRa SF7/125 kHz | LoRa SF7/125 kHz | |
| 6 | LoRa SF7/250 kHz | LoRa SF8/500 kHz | LoRa SF7/500 kHz | LoRa SF7/250 kHz | LoRa SF7/250 kHz | LoRa SF7/250 kHz | LoRa SF7/250 kHz | |||
| 7 | FSK 50 kbps | FSK 50 kbps | FSK 50 kbps | FSK 50 kbps | FSK 50 kbps | FSK 50 kbps | FSK 50 kbps | |||
| 8 | LoRa SF12/500 kHz | LoRa SF12/500 kHz | ||||||||
| 9 | LoRa SF11/500 kHz | LoRa SF11/500 kHz | ||||||||
| 10 | LoRa SF10/500 kHz | LoRa SF10/500 kHz | ||||||||
| 11 | LoRa SF9/500 kHz | LoRa SF9/500 kHz | ||||||||
| 12 | LoRa SF8/500 kHz | LoRa SF8/500 kHz | ||||||||
| 13 | LoRa SF7/500 kHz | LoRa SF7/500 kHz | ||||||||
| 14 | ||||||||||
| 15 |
Note: When ADR is enabled, the network server may change the value configured through this AT command.
The default value after factory reset is 0.
AT+DR?
+OK=2
AT+DR=0
+OK
Get or set the time offsets of various receive windows.
This AT command can be used to query or set the time offset of the JoinAccept window 1 (JoinAccept RX1), and JoinAccept window 2 (JoinAccept RX2), receive window 1 (RX1), and receive window 2 (RX2). The times are encoded into a comma-delimited value as follows: <JoinAccept RX1>,<JoinAccept RX2>,<RX1>,<RX2>. All times represent the number of milliseconds since the end of the preceding uplink transmission.
The network server can change these values remotely using the RXTimingSetupReq MAC command.
Note 1: If you change any of the values manually, make sure to communicate the new values to the network server out of band, otherwise your device may not be able to communicate with the network.
Note 2: The RX2 value must be greater than RX1. The JoinAccept RX2 value must be greater than JoinAccept RX1.
The default value upon factory reset is 5000,6000,1000,2000.
AT+DELAY?
+OK=5000,6000,5000,6000
AT+DELAY=5000,6000,5000,6000
+OK
See also: AT+JOIN
Configure how often to verify that the network can still hear the device.
With the adaptive data rate (ADR) enabled, the network server can configure a lower transmission power or a more efficient data rate into the end-device, e.g., to optimize power consumption or channel utilization. In this case, the device needs to periodically verify that the network can still receive its uplinks by requesting periodic confirmations. To request a confirmation, the device sets the ADRAckReq bit after every ADR_ACK_LIMIT unconfirmed uplinks. The network is required to respond with a downlink within the next ADR_ACK_DELAY frames. If the downlink is not received, the device assumes the network cannot receive its transmissions and reverts the settings configured through ADR.
This AT command can be used to get or set the ADR_ACK_LIMIT and ADR_ACK_DELAY parameters. The command takes and returns two comma-delimited values. The first value represents ADR_ACK_LIMIT. The second value represents ADR_ACK_DELAY. Both values are in terms of number of uplink frames.
The default value is 64,32, i.e., the device requests a downlink every 64 unconfirmed uplinks and expects the downlink to arrive within the next 32 frames.
Note: The network server can override the values configured with this AT command through ADR.
AT+ADRACK?
+OK=64,32
AT+ADRACK=64,32
+OK
Supported since: 1.2.0
See also: AT+ADR
Get or set the channel frequency and data rate of receive window 2 (RX2). This command expects two comma-delimited values: <frequency>,<datarate_index>. The frequency value is in Hz. The datarate_index value is one of the values from the table in section AT+DR, depending on the currently active region.
The network server can update these values remotely through the RXParamSetupReq MAC command.
The default value upon factory reset is 869525000,0 (the default region is EU868).
AT+RX2?
+OK=923300000,8
AT+RX2=923300000,8
+OK
Enable or disable duty cycling in regions that enforce duty cycling.
If your device operates in a region that enforces duty cycling, this command can be used to disable duty cycling with AT+DUTYCYCLE=0 and re-enable it with AT+DUTYCYCLE=1. Please note that the command cannot be used to enable duty cycling in regions that do not enforce it. Using AT+DUTYCYCLE=1 in such regions will do nothing.
The default value depends on the currently active region. It is 1 in regions that enforce duty cycling and 0 in regions that do not use duty cycling.
AT+DUTYCYCLE?
+OK=1
AT+DUTYCYCLE=0
+OK
Configure whether the microcontroller in the modem should enter a low-power sleep mode when idle. When this parameter is set to 1 (the default), the MCU will go to sleep. When set to 0, the MCU will never sleep.
This setting only affects the MCU. It does not prevent the SX1276 transceiver from being put to sleep.
Warning: Disabling sleep will have a negative impact on the battery life of the device. This setting is intended for development and debugging purposes only. During normal operation it should always be on.
AT+SLEEP?
+OK=1
AT+SLEEP=0
+OK
Configure the default port number used by AT+UTX and AT+CTX. These two commands send an uplink to the default port number configured through this command. The former sends an unconfirmed uplink, the latter sends a confirmed uplink.
The value must be in <1, 222>. The default port number is 2.
AT+PORT?
+OK=2
AT+PORT=2
+OK
Get or set the number of unconfirmed uplink transmissions.
Each unconfirmed uplink is transmitted up to AT+REP number of times. The retransmissions stop as soon as the device receives a confirmation (any downlink) from the network server.
Note: This parameter overrides the number of retransmissions remotely configured by the network server through adaptive data rate (ADR) when ADR is active.
The configured value must be in the range <1, 15>. The default value is 1.
AT+REP?
+OK=1
AT+REP=1
+OK
See also: AT+RTYNUM
Configure the format of message payload.
This command controls the message payload format expected by AT commands that send uplinks such as AT+PUTX and AT+PCTX, and generated by the event notification +RECV for received downlinks. If this parameter is set to 0, the modem expects and sends message payloads in binary form. If set to 1, the modem expects and sends message payloads encoded in a hexadecimal format. The hexadecimal format is primarily useful for applications or transports that cannot handle full 8-bit ASCII data.
Note: With the hexadecimal format turned on, the payload length in AT+PUTX, AT+PCTX, AT+UTX, AT+CTX, and +RECV is still in bytes, even though twice as many characters need to be sent over the UART port (two hexadecimal characters for each byte).
The default value is 0 (binary format).
AT+DFORMAT?
+OK=0
AT+DFORMAT=1
+OK
See also: AT+UTX, AT+CTX, AT+PUTX, AT+PCTX
Get or set message payload transmission timeout.
The AT commands AT+UTX, AT+CTX, AT+PUTX, AT+PCTX all expect that the application transmits the uplink payload immediately after the AT command. To prevent the modem from locking up due to transmission errors, it expects that the entire payload arrives within the time configured through this AT command. If not, the modem responds with +OK and sends an incomplete uplink with only the data that arrived within the time.
The minimum value for this parameter is a function of the baud rate of the UART port, the maximum size of the payload, whether or not hexadecimal payload encoding is in use, and on the current LoRaWAN data rate.
The value must be in the range <1, 65535> (milliseconds). The default value is 1000 milliseconds.
AT+TO?
+OK=1000
AT+TO=10000
+OK
See also: AT+UTX, AT+CTX, AT+PUTX, AT+PCTX
Send unconfirmed uplink message to the LoRaWAN network.
The syntax of the command is: AT+UTX <bytes> CR <data>, where <bytes> is the number of bytes in the payload (<1, 242>), CR is carriage return (ASCII 13), and <data> is the payload. That is, the commands takes one argument which is the size of the payload in bytes. The payload follows immediately after the carriage return character that terminates the AT command.
The uplink will be transmitted up to AT+REP times. The modem notifies the application of each retransmission by +EVENT=2,2. Any downlink message received by the modem from the network stops the retransmissions. Note that no +ACK or +NOACK will be generated even if an acknowledgement is received from the network. The value of AT+REP overrides retransmission count configured by the network server through ADR.
The uplink will be sent to the port number configured through the AT command AT+PORT. The default port number is 2. If you wish to send the uplink to a different port number, use the command AT+PUTX instead.
The application must sent the entire payload over the UART port within the time configured through AT+TO (1 second by default). If the modem does not receive the whole payload in time, it respond with +OK and sends an incomplete uplink payload consisting of all the bytes received before the timeout. This behavior matches the Murata Modem firmware.
If AT+DFORMAT is set to 1, the application is expected to transmit the payload encoded in a hexadecimal format. The parameter <bytes> still represents the size of the payload in bytes in this case, not the number of hexadecimal characters.
The maximum size of the payload depends on the current LoRaWAN data rate. The size could be reduced further if the modem needs to piggyback any MAC commands onto the uplink. If the payload does not fit in the uplink, the modem responds with +ERR=-12. If any MAC commands waited to be piggybacked, the modem internally sends an empty uplink to "flush" the MAC commands even when it returns +ERR=-12 to the application. This is to ensure that the next uplink transmission will have as much space as possible dedicated to application payload.
AT+UTX 5\rhello
+OK
+EVENT=2,2
+EVENT=2,2
+EVENT=2,2
See also: AT+PORT, AT+TO, AT+PUTX, AT+REP, AT+DFORMAT
[1] LoRa Developer Portal, "Data Packet Transmissions", Accessed: April 2022
Send confirmed uplink message to the LoRaWAN network.
The syntax of the command is: AT+CTX <bytes> CR <data>, where <bytes> is the number of bytes in the payload (<1, 242>), CR is carriage return (ASCII 13), and <data> is the payload. That is, the commands takes one argument which is the size of the payload in bytes. The payload follows immediately after the carriage return character that terminates the AT command.
The uplink will be transmitted up to AT+RTYNUM times. The modem notifies the application of each retransmission by +EVENT=2,2. Any downlink message received by the modem from the network stops the retransmissions and the modem sends +ACK to the application. If no acknowledgement is received after AT+RTYNUM transmissions, the modem generates +NOACK. The value of AT+RTYNUM overrides retransmission count configured by the network server through ADR.
The uplink will be sent to the port number configured through the AT command AT+PORT. The default port number is 2. If you wish to send the uplink to a different port number, use the command AT+PCTX instead.
The application must sent the entire payload over the UART port within the time configured through AT+TO (1 second by default). If the modem does not receive the whole payload in time, it respond with +OK and sends an incomplete uplink payload consisting of all the bytes received before the timeout. This behavior matches the Murata Modem firmware.
If AT+DFORMAT is set to 1, the application is expected to transmit the payload encoded in a hexadecimal format. The parameter <bytes> still represents the size of the payload in bytes in this case, not the number of hexadecimal characters.
The maximum size of the payload depends on the current LoRaWAN data rate. The size could be reduced further if the modem needs to piggyback any MAC commands onto the uplink. If the payload does not fit in the uplink, the modem responds with +ERR=-12. If any MAC commands waited to be piggybacked, the modem internally sends an empty uplink to "flush" the MAC commands even when it returns +ERR=-12 to the application. This is to ensure that the next uplink transmission will have as much space as possible dedicated to application payload.
AT+CTX 5\rhello
+OK
+EVENT=2,2
+ACK
See also: AT+PORT, AT+TO, AT+PCTX, AT+RTYNUM, AT+DFORMAT
[1] LoRa Developer Portal, "Data Packet Transmissions", Accessed: April 2022
Configure active multicast addresses and related security keys.
When used as a getter, this AT command returns a list of all currently active multicast addresses:
AT+MCAST?
+OK=1;0,00E4304D,2B7E151628AED2A6ABF7158809CF4F3C,2B7E151628AED2A6ABF7158809CF4F3C
The format of the data is: <count>[;<number>,<address>,<nwkskey>,<appskey>[;...]], where <count> represents the total number of addresses in the output. The data related to individual multicast addresses are delimited by semicolons. The field <number> represents the logical number of the address counted from 0, <address> is the 32-bit multicast address in a hexadecimal format with the most-significant byte printed first, <nwkskey> is the network session key and <appskey> is the application session key used for that address.
When used as a setter, this AT command can be used to add, modify, or delete individual multicast addresses. To add a new multicast address, pick a logical number not shown in the output of AT+MCAST? and provide the multicast address and both keys, for example:
AT+MCAST=0,00E4304D,2B7E151628AED2A6ABF7158809CF4F3C,2B7E151628AED2A6ABF7158809CF4F3C
+OK
The first parameter is the logical number of the multicast address starting from 0. The second parameter is the 32-bit multicast address in a hexadecimal format with the most-significant byte sent first. The third parameter is the 128-bit network session key in a hexadecimal format. The fourth parameter is the 128-bit application session key in a hexadecimal format.
To delete an active multicast address, specify only the address' logical number and omit all other parameters:
AT+MCAST=0
+OK
Note 1: The original Murata Modem firmware supports up to 8 multicast addresses. The open modem firmware supports only up to 4 multicast addresses.
Note 2: The ability to delete a multicast address is an extension of the open firmware. This feature does not appear to be supported by the original Murata Modem firmware.
Supported since: 1.2.0
Send unconfirmed uplink message to the LoRaWAN network.
The syntax of the command is: AT+PUTX <port>,<bytes> CR <data>, where <port> is the destination port number (<1, 223>), <bytes> is the number of bytes in the payload (<1, 242>), CR is carriage return (ASCII 13), and <data> is the payload. That is, the commands takes one argument which is the size of the payload in bytes. The payload follows immediately after the carriage return character that terminates the AT command.
The uplink will be transmitted up to AT+REP times. The modem notifies the application of each retransmission by +EVENT=2,2. Any downlink message received by the modem from the network stops the retransmissions. Note that no +ACK or +NOACK will be generated even if an acknowledgement is received from the network. The value of AT+REP overrides retransmission count configured by the network server through ADR.
The application must sent the entire payload over the UART port within the time configured through AT+TO (1 second by default). If the modem does not receive the whole payload in time, it respond with +OK and sends an incomplete uplink payload consisting of all the bytes received before the timeout. This behavior matches the Murata Modem firmware.
If AT+DFORMAT is set to 1, the application is expected to transmit the payload encoded in a hexadecimal format. The parameter <bytes> still represents the size of the payload in bytes in this case, not the number of hexadecimal characters.
The maximum size of the payload depends on the current LoRaWAN data rate. The size could be reduced further if the modem needs to piggyback any MAC commands onto the uplink. If the payload does not fit in the uplink, the modem responds with +ERR=-12. If any MAC commands waited to be piggybacked, the modem internally sends an empty uplink to "flush" the MAC commands even when it returns +ERR=-12 to the application. This is to ensure that the next uplink transmission will have as much space as possible dedicated to application payload.
AT+PUTX 1,5\rhello
+OK
+EVENT=2,2
+EVENT=2,2
+EVENT=2,2
See also: AT+TO, AT+UTX, AT+REP, AT+DFORMAT
[1] LoRa Developer Portal, "Data Packet Transmissions", Accessed: April 2022
Send confirmed uplink message to the LoRaWAN network.
The syntax of the command is: AT+PCTX <port>,<bytes> CR <data>, where <port> is the destination port number (<1, 223>) <bytes> is the number of bytes in the payload (<1, 242>), CR is carriage return (ASCII 13), and <data> is the payload. That is, the commands takes one argument which is the size of the payload in bytes. The payload follows immediately after the carriage return character that terminates the AT command.
The uplink will be transmitted up to AT+RTYNUM times. The modem notifies the application of each retransmission by +EVENT=2,2. Any downlink message received by the modem from the network stops the retransmissions and the modem sends +ACK to the application. If no acknowledgement is received after AT+RTYNUM transmissions, the modem generates +NOACK. The value of AT+RTYNUM overrides retransmission count configured by the network server through ADR.
The application must sent the entire payload over the UART port within the time configured through AT+TO (1 second by default). If the modem does not receive the whole payload in time, it respond with +OK and sends an incomplete uplink payload consisting of all the bytes received before the timeout. This behavior matches the Murata Modem firmware.
If AT+DFORMAT is set to 1, the application is expected to transmit the payload encoded in a hexadecimal format. The parameter <bytes> still represents the size of the payload in bytes in this case, not the number of hexadecimal characters.
The maximum size of the payload depends on the current LoRaWAN data rate. The size could be reduced further if the modem needs to piggyback any MAC commands onto the uplink. If the payload does not fit in the uplink, the modem responds with +ERR=-12. If any MAC commands waited to be piggybacked, the modem internally sends an empty uplink to "flush" the MAC commands even when it returns +ERR=-12 to the application. This is to ensure that the next uplink transmission will have as much space as possible dedicated to application payload.
AT+PCTX 1,5\rhello
+OK
+EVENT=2,2
+ACK
See also: AT+TO, AT+CTX, AT+RTYNUM, AT+DFORMAT
[1] LoRa Developer Portal, "Data Packet Transmissions", Accessed: April 2022
Return current uplink and downlink frame counters.
The format of the returned value is: <uplink>,<downlink>. Each counter is an unsigned 32-bit integer. The downlink counter is selected based on the LoRaWAN protocol version used by the network server for the device. If your device uses LoRaWAN 1.0 then the downlink counter contains the value of FCntDown which increments for all downlinks in LoRaWAN 1.0. If your device uses LoRaWAN 1.1 then the downlink counter contains the value of AFCntDown which is only incremented for downlinks with a non-zero port number, i.e., downlink messages carrying application payload.
The downlink counter value of 4294967295 (UINT32_MAX) indicates that no downlink has been received yet. Since 1.1.0 the firmware returns 0 instead to remain compatible with the original Murata Modem firmware.
AT+FRMCNT?
+OK=1,0
Return the maximum length of payload for the current data rate.
This AT command returns the maximum length of payload in bytes that can be sent in uplinks with the current data rate. The value will be generally between 11 and 242 bytes. Please note that the returned value does not take into account MAC commands scheduled to be piggy-backed onto the next uplink. Thus, if stack has MAC commands scheduled to be sent, you may still receive an error even if your payload fits into the length returned by this AT command. In that case, the stack will send an empty uplink (with only the MAC commands) internally. Thus, if you try to resend your payload, the second attempt should succeed.
AT+MSIZE?
+OK=11
See also: AT+DR
Return the received signal strength indicator (RSSI) and signal to noise ratio (SNR) of the most recently received packet.
This command returns two integer values delimited by a comma: <rssi>,<snr>. The <rssi> value is a measure of the power of the incoming RF signal expressed in the unit dBm, measured at the input of the LoRa receiver. The greater the value, the stronger the signal from the gateway. The <snr> value represents the ratio of the signal power to the channel noise power expressed in the unit dB. Note that since LoRa can receive packets below the noise floor, the SNR value can be negative.
The returned values correspond to the most recently received packet. This can be any packet: application downlink, JoinAccept, ADR request, device status request, or confirmed uplink acknowledgement.
AT+RFQ?
+OK=-27,8
Configure whether the modem should respect LoRaWAN dwell time in selected regions.
This command can be used to enable or disable the LoRaWAN dwell time enforcement in the AS923 and AU915 regions. The format of the value is <uplink>,<downlink>, where uplink and downlink can be either 0 (disabled) or 1 (enabled). Please note that the network server can also configure this parameter remotely via a MAC command sent to the device.
The default value is region-specific:
| Region | AS923 | AU915 | CN470 | CN779 | EU433 | EU868 | KR920 | IN865 | US915 | RU864 |
|---|---|---|---|---|---|---|---|---|---|---|
| Default value | 1,0 | 1,0 | 0,0 | 0,0 | 0,0 | 0,0 | 0,0 | 0,0 | 0,0 | 0,0 |
AT+DWELL?
+OK=0,0
AT+DWELL=1,0
+OK
Get or set the upper limit on RF output power.
Please note that this parameter is only effective in regions other than US915. It is ignored in US915.
This AT command can be used to inspect or set the upper limit on RF output power. This is the maximum RF output power that the LoRa transmitter will not be allowed to exceed. The value is expressed in the units of dBm. Please note that the value of this parameter can be remotely changed by the network server using a MAC command or ADR. The default value is region and channel plan specific:
| Region | AS923 | AU915 | CN470 | CN779 | EU433 | EU868 | KR920 | IN865 | US915 | RU864 |
|---|---|---|---|---|---|---|---|---|---|---|
| MaxEIRP [dBm] | 16 (13 in JP) | 30 | 19.15 | 12.15 | 12.15 | 16 | 10 (14 above 922.1 MHz) | 30 | 32.15 | 16 |
When calculating the RF output power for an uplink transmission, the modem subtracts the value configured through AT+RFPOWER and antenna gain (2.15 dBi by default) from the MaxEIRP value configured through this parameter. In US915, these values are subtracted from the fixed value 30 dBm and the resulting value is further limited according to the selected data rate and the number of active channels (channel mask). The resulting RF output power is then programmed into the LoRa transmitter.
Note that the MaxEIRP can be larger than the actual maximum transmit power of the LoRa transmitter, i.e., there is no guarantee that the transmitter will be capable of transmitting with MaxEIRP.
The AT command returns the current MaxEIRP value which can be a value configured by the network server via ADR. When used to set MaxEIRP, the command updates both the current and default MaxEIRP values. The default MaxEIRP is the value that will be used when ADR is inactive or disabled.
AT+MAXEIRP?
+OK=32
AT+MAXEIRP=30
+OK
See also: AT+RFPOWER
Configure the RSSI free channel threshold for the listen before talk (LBT) feature.
In regions that employ the listen before talk (LBT) feature (KR920 and selected AS923 channel plans), this AT command can be used to get or set the RSSI free channel threshold value in dBm. The RF channel is considered free (without carrier) if its RSSI is below the threshold.
If the currently active region does not use LBT, this AT command returns +ERR=-17. If the currently active region uses LBT but the selected channel plan does not (this is the case for most AS923 channel plans), the AT command returns 0.
AT+RSSITH?
+OK=-65
AT+RSSITH=-60
+OK
Supported since: 1.2.0
See also: AT+CST
Configure carrier sense time (CST) for the listen before talk (LBT) feature.
In regions that employ the listen before talk (LBT) feature (KR920 and selected AS923 channel plans), this AT command can be used to get or set the carrier sense time (CST). The CST value represents the duration in milliseconds for which the receiver will listen on the channel to determine whether it is free before transmitting.
If the currently active region does not use LBT, this AT command returns +ERR=-17. If the currently active region uses LBT but the selected channel plan does not (this is the case for most AS923 channel plans), the AT command returns 0.
AT+CST?
+OK=6
AT+CST=7
+OK
Supported since: 1.2.0
See also: AT+RSSITH
Query the duty cycling state.
If the end-device is configured in a region with duty cycling, has duty cycling enabled, and is currently enforcing a duty cycling quiet period, this AT command returns the number of milliseconds until the end of the quiet period. In all other cases the command returns 0.
The end-device cannot transmit as long as this AT command returns a non-zero value.
AT+BACKOFF?
+OK=0
Available since: 1.2.0
See also: AT+DUTYCYCLE
Get or set the LoRaWAN channel mask.
The LoRaWAN channel mask determines the set of channels the modem is allowed to use to transmit uplinks. The length of the channel mask (maximum number of supported channels) depends on the active region. Most regions can activate up to 16 channels, AU915 and US915 can activate up to 72 channels, CN470 can activate 96 channels. See the table below for channel mask sizes and default values for each region.
In the AT interface, a channel mask is represented with a hexadecimal string where each bit corresponds to one channel. When the bit is set to 1, the corresponding channel is enabled. When the bit is set to 0, the corresponding channel is disabled. The left-most byte in the string represents channels 0-8. The least significant bit within the byte represents channel 0. Thus, the channel mask 0300 enables channels 0 and 1 only. A channel mask must have at least two channels enabled in order to be valid.
Please note that the channel mask can be updated by the network server in a Join answer.
The size and default value of the channel mask depending on the active region:
| Region | Default channel mask | Max. channels |
|---|---|---|
| AS923 | 0300 | 16 |
| AU915 | FFFFFFFFFFFFFFFFFF | 72 |
| CN470 | FFFFFFFFFFFFFFFF00000000 | 96 |
| CN779 | 0700 | 16 |
| EU433 | 0700 | 16 |
| EU868 | 0700 | 16 |
| KR920 | 0700 | 16 |
| IN865 | 0700 | 16 |
| US915 | FFFFFFFFFFFFFFFFFF | 72 |
| RU864 | 0300 | 16 |
AT+CHMASK?
+OK=FFFFFFFFFFFFFFFFFF
AT+CHMASK=00FF00000000000000
+OK
See also: AT$CHMASK
Get or set the number of confirmed uplink transmissions.
Each confirmed uplink is transmitted up to AT+RTYNUM number of times. The retransmissions stop as soon as the device receives a confirmation from the network server.
Note: This parameter overrides the number of retransmissions remotely configured by the network server through adaptive data rate (ADR) when ADR is active.
The configured value must be in the range <1, 15>. The default value is 8.
AT+RTYNUM?
+OK=8
AT+RTYNUM=4
+OK
See also: AT+REP
Get or set the LoRaWAN network ID (NetID).
The NetID is a 24-bit integer. In the AT command interface the value is encoded as a 32-bit integer in a hexadecimal format with the most significant byte (MSB) transmitted first.
The default value is 00000000.
This parameter is primarily used in LoRaWAN roaming. When a device wishes to Join its home network while it is roaming, i.e., the Join uplink will be picked up by a forwarding network, the device needs to specify the NetID in the Join request in order for the forwarding network to forward the message to the network server in the device's home network.
Upon OTAA Join, the ID of the device's home network is encoded in DevAddr which is assigned to the device by its home network. Thus, the forwarding network knows where to forward the uplink based on the device's DevAddr and NetID is no longer used.
AT+NETID?
+OK=00000013
AT+NETID=00000013
+OK
Return a list of available channels and their parameters.
This AT command provides additional information about each channel currently configured in the modem. The output is provided line-by-line, with one channel per line, and is terminated with +OK. The format of each line is as follows:
<enabled>,<frequency>,<RX1 frequency>,<min data rate>,<max data rate>,<band>, where:
-
<enabled>is 1 if the channel is enabled and 0 if it is disabled; -
<frequency>represents the center frequency of the channel in Hz; -
<RX1 frequency>will be non-zero if an alternative RX1 frequency has been defined for the channel; -
<min data rate>represents the minimum data rate allowed on the channel; -
<max data rate>represents the maximum data rate allowed on the channel; -
<band>represents the logical band within the region the channel belongs to.
Please note that the output may not include all channels. The channels that are not enabled upon factory reset will have their center frequency initially set to zero and such channels will be omitted from the output. They will show up once re-enabled.
AT$CHANNELS?
1,868100000,0,0,5,1
1,868300000,0,0,5,1
1,868500000,0,0,5,1
+OK
Note: In firmware versions <= 1.1.3 each output line was prefixed with "$CHANNELS: ". The prefix was dropped in later firmware versions.
See also: AT+CHMASK
Show extended modem firmware version.
This command returns an extended version string which provides additional information about the firmware. The string consists of nine comma-delimited components, from left to right:
1. Modem firmware version. This component contains the version of the modem firmware. The version string has the following format: 1.0.2-10-g08e86e66 (modified). 1.0.2 represents the firmware release version. If the firmware is based on unreleased code from the git repository, a suffix like -10-g08e86e66 will be present. The suffix includes the number of commits since the most recent release and the git commit id of the most recent commit (following g). The optional (modified) suffix indicates that the git clone the firmware was built from contained local (uncommitted) modifications.
2. Build date. This component represents the build date and time of the firmware.
3. LoRaMac-node version. This component represents the version of the embedded LoRaMac-node library. The string has the same format as the modem version string. The number of commits and the git commit id of the most recent commit represent custom modifications applied to vanilla LoRaMac-node in our fork of the library.
4. Supported LoRaWAN 1.1 (or newer) version. This component represents the most recent LoRaWAN 1.1 (or newer) protocol version supported by the modem. This is the protocol version that will be used when the modem is joined to a LoRaWAN 1.1 (or newer) network server.
5. Supported LoRaWAN 1.0 fallback version. This component represents the most recent LoRaWAN 1.0 protocol version supported by the modem. This is the protocol version that will be used when modem modem is joined to a network server that only supports LoRaWAN 1.0.
6. Supported LoRaWAN ABP version. Since the modem cannot negotiate a mutually-supported LoRaWAN protocol version with the network server, the protocol version to be used in ABP mode must be manually configured. This component represents the LoRaWAN protocol version the modem will use in ABP mode.
7. Supported version of LoRaWAN Regional Parameters. This component represents the version of the LoRaWAN Regional Parameters specification supported by the modem.
8. Enabled regions. This component lists all regions enabled in the modem firmware. Please note that this does not necessarily mean that all the listed regions are supported by the hardware (LoRa radio). If a region is listed here, its regional parameters are included in the modem firmware and the region can be activated with AT+BAND. It does NOT mean that the LoRa radio can operate in the band.
9. Build type. This component shows the build (compilation) mode of the firmware. It will be set to "debug" if the firmware has been compiled in debugging mode and to "release" if the firmware has been compiled in release mode. If the compilation mode cannot be determined, e.g., in custom builds, the string will be set to "?".
AT$VER?
+OK=1.0.2-10-g08e86e66 (modified),2022-May-07 16:11:42 EDT,4.6.0-20-g0e4d8127,1.1.1,1.0.4,1.0.4,RP002-1.0.1,AS923 AU915 CN470 CN779 EU433 EU868 IN865 KR920 RU864 US915,release
Note: In firmware versions <= 1.1.3 the modem firmware and LoRaMac-node version strings are prefixed with "v".
See also: AT+VER
Show debugging information.
This is an internal AT command meant primarily to aid debugging. The output shows whether or not the MCU is allowed to enter the low-power Sleep or Stop mode, as well as the state of the LoRa transceiver.
AT$DBG
sleep_lock=0 stop_lock=8 radio_state=0
+OK
Note 1: This AT command is only available in debug builds of the firmware.
Note 2: In firmware versions <= 1.1.3 the output line was prefixed with "$DBG: ". The prefix was dropped in later firmware versions.
Halt the modem.
Upon receiving this AT command, the modem will stop processing AT commands and incoming LoRa messages and will enter a low-power mode. The modem must be rebooted via the external reset pin or power-cycled to resume operation. The modem sends +EVENT=0,3 to the application prior to halting.
AT$HALT
+OK
+EVENT=0,3
This AT command is an alias for AT+APPEUI.
AT$JOINEUI?
+OK=0101010101010101
AT$JOINEUI=0101010101010101
+OK
See also: AT+APPEUI
Get or set the LoRaWAN 1.1 root network key (NwkKey). The NwkKey is a 128-bit symmetric key that is used to derive a network session key (NwkSKey) during LoRaWAN OTAA Join.
This AT command is designed for LoRaWAN 1.1 activation. Unlike AT+APPKEY, this command configures the NwkKey only. It does not touch the AppKey. If you wish to configure both keys simultaneously for LoRaWAN 1.0 activation, use AT+APPKEY instead.
You can generate a new random NwkKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2
The key is encoded in a hexadecimal format. The default value after factory reset is 2B7E151628AED2A6ABF7158809CF4F3C.AT$NWKKEY?
+OK=2B7E151628AED2A6ABF7158809CF4F3C
AT$NWKKEY=2B7E151628AED2A6ABF7158809CF4F3C
+OK
See also: AT+APPKEY, AT$APPKEY
Get or set the LoRaWAN 1.1 root application key (AppKey). The AppKey is a 128-bit symmetric key that is used to derive an application session key (AppsSKey) during LoRaWAN OTAA Join.
This AT command is designed for LoRaWAN 1.1 activation. Unlike AT+APPKEY, this command configures the AppKey only. It does not touch the NwkKey. If you wish to configure both keys simultaneously for LoRaWAN 1.0 activation, use AT+APPKEY instead.
You can generate a new random AppKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2The key is encoded in a hexadecimal format. The default value after factory reset is 2B7E151628AED2A6ABF7158809CF4F3C.
AT$APPKEY?
+OK=2B7E151628AED2A6ABF7158809CF4F3C
AT$APPKEY=2B7E151628AED2A6ABF7158809CF4F3C
+OK
See also: AT+APPKEY, AT$NWKKEY
Get or set the LoRaWAN 1.1 forwarding network session integrity key (FNwkSIntKey).
In LoRaWAN 1.1, the key used to check the integrity of LoRaWAN messages was split into two: FNwkSIntKey and SNwkSIntKey. This arrangement enables LoRaWAN network roaming where the device communicates with its "serving" LoRaWAN network by the way of a "forwarding" LoRaWAN network. The forwarding network then uses the FNwkSIntKey to verify the integrity (MIC) of uplink messages before it forwards the message to the serving network. The serving network then uses the SNwkSIncKey to verify the integrity of the network and to compute the MIC of downlink messages sent to the device.
The FNwkSIntKey is a 128-bit symmetric key. In LoRaWAN 1.1 OTAA activation, the FNwkSIntKey is automatically derived upon a successful Join. In ABP activation the key must be manually configured into the device and the network.
You can generate a new random FNwkSIntKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2The key is encoded in a hexadecimal format. The default value after factory reset is 2B7E151628AED2A6ABF7158809CF4F3C.
AT$FNWKSINTKEY?
+OK=2B7E151628AED2A6ABF7158809CF4F3C
AT$FNWKSINTKEY=2B7E151628AED2A6ABF7158809CF4F3C
+OK
See also: AT$SNWKSINTKEY, AT$NWKSENCKEY
Get or set the LoRaWAN 1.1 serving network session integrity key (SNwkSIntKey).
In LoRaWAN 1.1, the key used to check the integrity of LoRaWAN messages was split into two: FNwkSIntKey and SNwkSIntKey. This arrangement enables LoRaWAN network roaming where the device communicates with its "serving" LoRaWAN network by the way of a "forwarding" LoRaWAN network. The forwarding network then uses the FNwkSIntKey to verify the integrity (MIC) of uplink messages before it forwards the message to the serving network. The serving network then uses the SNwkSIncKey to verify the integrity of the network and to compute the MIC of downlink messages sent to the device.
The SNwkSIntKey is a 128-bit symmetric key. In LoRaWAN 1.1 OTAA activation, the SNwkSIntKey is automatically derived upon a successful Join. In ABP activation the key must be manually configured into the device and the network.
You can generate a new random SNwkSIntKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2The key is encoded in a hexadecimal format. The default value after factory reset is 2B7E151628AED2A6ABF7158809CF4F3C.
AT$SNWKSINTKEY?
+OK=2B7E151628AED2A6ABF7158809CF4F3C
AT$SNWKSINTKEY=2B7E151628AED2A6ABF7158809CF4F3C
+OK
See also: AT$FNWKSINTKEY, AT$NWKSENCKEY
Get or set the LoRaWAN 1.1 network session encryption key (NwkSEncKey).
In LoRaWAN 1.1, the network session encryption key (NwkSEncKey) is used to encrypt and decrypt MAC commands sent in FOpts or FRMPayload fields of a LoRaWAN message, i.e., in LoRaWAN messages with port 0 that contain no application payload.
The NwkSEncKey is a 128-bit symmetric key. In LoRaWAN 1.1 OTAA activation, the NwkSEncKey is automatically derived upon a successful Join. In ABP activation the key must be manually configured into the device and the network.
You can generate a new random NwkSEncKey with OpenSSL as follows:
openssl enc -aes-128-cbc -k secret -P -md sha1 2>/dev/null | grep ^key= | cut -d = -f 2The key is encoded in a hexadecimal format. The default value after factory reset is 2B7E151628AED2A6ABF7158809CF4F3C.
AT$NWKSENCKEY?
+OK=2B7E151628AED2A6ABF7158809CF4F3C
AT$NWKSENCKEY=2B7E151628AED2A6ABF7158809CF4F3C
+OK
See also: AT$FNWKSINTKEY, AT$SNWKSINTKEY
Get or set the LoRaWAN channel mask.
The modem maintains two values for each setting that can be remotely controlled by the LoRaWAN network server. The current value represents the value set by the network server via a downlink MAC command or an ADR request. The default value represents the setting's original value obtained from regional parameters. The default value is restored before an OTAA Join.
This is an extended version of AT+CHMASK that makes it possible to get or set the current and default channel masks separately. The first value represents the current value. The second value represents the default value.
AT$CHMASK?
+OK=FFFFFFFFFFFFFFFF,FFFFFFFFFFFFFFFF
AT$CHMASK=00FF000000000000,00FF000000000000
+OK
See also: AT+CHMASK
Get or set the channel frequency and data rate of receive window 2 (RX2).
The modem maintains two values for each setting that can be remotely controlled by the LoRaWAN network server. The current value represents the value set by the network server via a downlink MAC command or an ADR request. The default value represents the setting's original value obtained from regional parameters. The default value is restored before an OTAA Join.
This is an extended version of AT+RX2 that makes it possible to configure the current and default values separately. The format of the values is the same as in AT+RX2. The first two comma-delimited values belong to the current value, the last two values belong to the default (region) value.
AT$RX2?
+OK=923300000,8,923300000,8
AT$RX2=923300000,8,923300000,8
+OK
See also: AT+RX2
Get or set the data rate to be used by the device for uplink messages.
The modem maintains two values for each setting that can be remotely controlled by the LoRaWAN network server. The current value represents the value set by the network server via a downlink MAC command or an ADR request. The default value represents the setting's original value obtained from regional parameters. The default value is restored before an OTAA Join.
This is an extended version of AT+DR that makes it possible to configure the current and default values separately. The first value represents the current value, the second value represents the default value. Please see the section on AT+DR for more information.
AT$DR?
+OK=0,0
AT$DR=0,0
+OK
Get or set the RF output power used to transmit LoRa uplink messages.
The modem maintains two values for each setting that can be remotely controlled by the LoRaWAN network server. The current value represents the value set by the network server via a downlink MAC command or an ADR request. The default value represents the setting's original value obtained from regional parameters. The default value is restored before an OTAA Join.
This is an extended version of AT+RFPOWER that makes it possible to configure the current and default values separately. The first two values correspond to the current setting value, the last two values correspond to the default setting value. Please see the section on AT+RFPOWER for more information.
AT$RFPOWER?
+OK=0,1,0,0
AT$RFPOWER=0,0,0,0
+OK
See also: AT+RFPOWER
Configure the amount of logging information output by the firmware to the USART interface. The following table summarizes allowed values and how they are mapped to log levels:
| Value | 0 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|---|
| Level | DUMP | DEBUG | INFO | WARNING | ERROR | OFF |
Use 0 to output the maximum amount of logging information. Use 5 to disable logging altogether.
The default value depends on the firmware compilation mode. When compiled in DEBUG mode, the default value is 0. When compiled in RELEASE mode, the default value is 5.
Note 1: This setting is not saved in NVM (EEPROM). It will revert to the default value upon reboot.
Note 2: This AT command is only available in debug builds of the firmware.
AT$LOGLEVEL?
+OK=0
AT$LOGLEVEL=2
+OK
Enable or disable the LoRaWAN certification port.
Port 224 is reserved in the LoRaWAN specification for device certification, i.e., compliance with the LoRaWAN specification. This AT command can be used to enable or disable support for port 224 in the modem.
The certification port is disabled by default.
Since version 1.5.0, this AT command is only enabled when the compile-time option CERTIFICATION_ATCI is set to 1. This option is only enabled for selected build targets.
AT$CERT?
+OK=0
AT$CERT=1
+OK
Supported since: 1.1.0
Obtain information about the currently active LoRaWAN network session.
This AT command can be used to obtain the parameters of the currently active LoRaWAN network association, including the network type, activation mode, LoRaWAN protocol version, network ID, and device ID. The command returns a list of comma-separated values.
The first represents the network type and is either "public" or "private". The second value represents the LoRaWAN activation mode and can be one of "None", "OTAA", "ABP", "?". The third value represents the LoRaWAN protocol version being used. The fourth value is the ID of the network. The fifth value is the address of the device (DevAddr). The third through fifth values will only be present if the activation mode is not "None".
AT$SESSION?
+OK=public,OTAA,1.1.1,00000013,260C5A7F
Supported since: 1.1.2
See also: AT+NWK, AT+MODE, AT+NETID, AT+DEVADDR
Start continuous carrier wave (CW) transmission.
This command takes three parameters <frequency>,<power>,<time> and activates the radio transmitter at the given center frequency (in Hz) with the given transmission power (in dBm) for the given number of seconds. The radio will transmit a continuous carrier wave only without modulation. The modem returns a +OK immediately to indicate that all parameters have acceptable values. The transmission continues until the modem emits a +EVENT=9,0.
The modem also performs automatic reboot at the end of the transmission. This is indicated with a +EVENT=0,0.
This command is primarily intended for device certification. Since version 1.5.0, this AT command is only enabled when the compile-time option CERTIFICATION_ATCI is set to 1. This option is only enabled for selected build targets.
The following example starts a continuous CW transmission on the 868.3 MHz channel with a transmission power of 10 dBm for 60 seconds:
AT$CW 868300000,10,60
+OK
+EVENT=9,0
+EVENT=0,0
Supported since: 1.1.3
See also: AT$CM
Start continuous modulated frequency shift keying (FSK) transmission.
This command takes five comma-separated parameters <frequency>,<deviation>,<datarate>,<power>,<time> and starts a continuous modulated FSK transmission of alternating ones and zeroes. The parameter frequency determines the center (channel) frequency in Hz. The parameter deviation determines the frequency deviation for FSK in Hz. The parameter datarate determines the baud rate in Bd (typically 4800). The parameter power indicates the transmission power in dBm. The parameter time configures the transmission time in seconds. The modem returns a +OK immediately to indicate that all parameters have acceptable values. The transmission continues until the modem emits a +EVENT=9,1.
The modem also performs automatic reboot at the end of the transmission. This is indicated with a +EVENT=0,0.
This command is primarily intended for device certification. Since version 1.5.0, this AT command is only enabled when the compile-time option CERTIFICATION_ATCI is set to 1. This option is only enabled for selected build targets.
The following example starts an FSK transmission of ones and zeroes on the 868.3 MHz channel with a frequency deviation of 250 kHz and a 4800 baud rate. The data will be transmitted with 10 dBm for 60 seconds:
AT$CM 868300000,250000,4800,10,60
+OK
+EVENT=9,1
+EVENT=0,0
Supported since: 1.1.3
See also: AT$CW
Manage the contents of NVM user data registers.
The modem provides 64 general-purpose NVM registers to the application. The registers can be used to persistently store arbitrary data in the Type ABZ module's EEPROM. The registers are numbered from 0 to 63. Each register stores a single byte (a value from 0 to 255). All registers are reset back to 0 on factory reset (AT+FACNEW).
To write a value into a NVM register, pass two arguments to AT$NVM. The first argument contains the register number (0-63). The second argument contains the decimal value (0-255) to be written into the register. The following command writes the value 42 into NVM register 0:
AT$NVM 0,42
+OK
To read the value of a NVM register, pass only a single argument with the register number (0-63). The following command returns the value stored in NVM register 0:
AT$NVM 0
+OK=42
Supported since: 1.3.0
Prevent the application from reading LoRaWAN security keys.
This AT command can be used to prevent the application from reading LoRaWAN security keys over the AT command interface. After this command has been invoked, any attempt to read LoRaWAN security keys via the ATCI will return an error (-50, access denied). This setting remains in effect until the next reset to factory defaults.
After AT$LOCKKEYS has been invoked, the following AT commands return +ERR=-50: AT+APPKEY?, AT+APPSKEY?, AT+NWKSKEY?, AT$NWKKEY?,
AT$APPKEY?, AT$FNWKSINTKEY?, AT$SNWKSINTKEY?, AT$NWKSENCKEY?
Note: This command provides only minimal accidental protection. If the application has access to USART1, USART2, or SPI ports on the modem, it could simply downgrade the modem's firmware to read the keys, or it could switch into the STM32 bootloader mode to directly read the EEPROM. LoRaWAN security keys are stored in the EEPROM in an unencrypted form.
AT$LOCKKEYS
+OK
AT+APPKEY?
+ERR=-50
Supported since: 1.3.0
See also: AT+APPKEY, AT+APPSKEY, AT+NWKSKEY, AT$NWKKEY, AT$APPKEY, AT$FNWKSINTKEY, AT$SNWKSINTKEY, AT$NWKSENCKEY, AT+FACNEW
Detach (disconnect) from the GPIO ports used by the AT command interface.
The AT command interface uses the STM32 LPUART1 peripheral which is connected to GPIO ports PA2 and PA3. These ports are mapped to pins 23 and 24 on the TypeABZ module. The Arduino MKR WAN 1310 modem, which contains an TypeABZ module, shares the PA2 and PA3 lines with a SPI interface. The MKR WAN 1310 host MCU uses the SPI interface to communicate with an on-board flash memory. During normal operation, i.e., while LPUART1 is connected to the GPIO pins, the host MCU cannot use the SPI interface and thus cannot communicate with the on-board flash.
This AT command can be used to instruct the TypeABZ module to detach (disconnect) from the GPIO ports used by LPUART1. Before detaching, the module checks the state of the GPIO pin PB12. If the pin is high, the module detaches and confirms the operation with an +OK response. If GPIO PB12 is low, the module generates an error (+ERR=-51). The AT command interface (LPUART1 port) remains detached until the host MCU pulls GPIO PB12 low.
When the AT command interface is detached, all data written to the module is lost. All data to be transmitted by the module over the ATCI, e.g., received downlinks, is buffered. The buffered data will be transmitted as soon as the port is attached again. While in the detached state, the TypeABZ module eventually enters a sleep mode to conserve power.
Follow these steps to communicate with the on-board flash on the MKR WAN 1310 board:
- Set TypeABZ's GPIO PB12 high
- Send
AT$DETACHto the TypeABZ module - Wait for
+OK - Communicate with the on-board flash via SPI
- When done, set TypeABZ's GPIO PB12 low
Note: This AT command is only available in the build variants for the Arduino MKR WAN 13100 board.
AT$DETACH
+OK
Supported since: 1.3.0
Configure the modem to work in synchronous/asynchronous mode.
The modem can send a variety of asynchronous messages to the host. These include asynchronous +EVENT notifications, +RECV messages containining incoming (downlink) messages, +ACK and +NOACK, and +ANS. The host must be ready to receive such messages at any time, typically seconds or tens of seconds after the most recent AT command. An +EVENT=0,0 message emitted after a modem reset can arrive at any time and typically requires some response from the host, e.g., to reconfigure the modem.
Handling asynchronous modem notifications requires that the host keeps its UART peripheral active at all times. This can be problematic on platforms where the UART peripheral consumes significant amounts of power while running as the timings to receive downlinks can be quite large depending on the spreading factor, leading to large windows of high power consumption.
When set to 1 (the default), the modem works in asynchronous mode, meaning it can send asynchronous messages to the host at any time.
When set to 0 with AT$ASYNC=0, the modem switches into a polling mode of operation. In the polling mode, the modem buffers all asynchronous messages for the host. The buffered asynchronous messages will only be transmitted upon receiving an AT command from the host. Upon receiving any AT command, the modem first sends all buffered asynchronous messages before sending the final response (+OK or +ERR) to the AT command. After sending the final response, the modem guarantees that no asynchronous messages will be sent until the next AT command. Thus, the host only needs to be ready to receive between the time it sends an AT command to the modem, and the time it receives the final response to the command.
Example for asynchronous mode (AT$ASYNC=1):
AT$ASYNC=1
+OK
AT+JOIN
+OK
(...some amount of time...)
+EVENT=1,1
Example for synchronous mode (AT$ASYNC=0):
AT$ASYNC=0
+OK
AT+JOIN
+OK
(...arbitrary amount of time...)
AT
+EVENT=1,1
+OK
On Asynchronous mode, any AT command will flush all the buffered messages first. To poll for buffered messages, the user can send the AT dummy command as shown above.
The AT$SYNC value is backed in NVM (EEPROM) and survives modem reboots. This is necessary because a host operating in the polling mode could easily miss the modem's reboot indications (+EVENT=0,0).
AT$ASYNC?
+OK=1
AT$ASYNC=1
+OK
Warning: The asynchronous messages that arrive while the device is not in asynchronous mode are buffered in a fixed-size buffer, therefore the buffer should be flushed in order to not risk losing events/downlinks. For Class-A devices, this can be done after an uplink has been sent. For Class-B and Class-C devices, this should be done repeatedly between communications in order to prevent the overflow.
Supported since: 1.4.0
Read or write modem's RTC clock.
This AT command can be used to read or update the time in the modem's RTC clock. The clock is stored in the RTC peripheral and remains operational (across reboots and factory resets) as long as the modem is powered. The AT command always returns and expects GPS time, i.e., the number of seconds since the GPS epoch (00:00:00 January 6 1980). The value is broken down into two integers delimited with a ",". The first integer represents whole seconds. The second integer represents a fraction of a second in milliseconds. The range of the millisecond component is <0, 999>.
Note on GPS time: All time-related AT commands expect and return GPS time because that is the time scale used in LoRaWAN. GPS time differs from UTC time in its handling of leap seconds. GPS time monotonically increments for every SI second that elapsed since the GPS epoch, including all leap seconds inserted between the GPS epoch and now.
To convert GPS time to a UNIX timestamp or UTC time, you need to: (1) make the time relative to the UNIX epoch; (2) subtract negative leap seconds inserted since the GPS epoch. As of May 2023, 18 negative leap seconds have been inserted. Thus, the following formula converts GPS time to a UNIX timestamp: unix_timestamp = gps_time + 315964800 - 18. The UNIX timestamp can then be converted to UTC with standard facilities.
Note: The modem automatically adjusts GPS time values transmitted over the UART port based on how long it takes to transmit the data. The application does not need to compensate for that.
AT$TIME?
+OK=1369450526,382
AT$TIME=1369452473,500
+OK
Supported since: 1.5.0
See also: AT$DEVTIME
Request time synchronization from the LoRaWAN network server.
This AT command issues a DeviceTimeReq MAC request to the LoRaWAN network server. Upon receiving a DeviceTimeAns, the modem updates its internal RTC clock. This synchronization method can achieve an accuracy of +- 100 milliseconds. See this wiki page for a description of time synchronization methods available in LoRaWAN.
The DeviceTimeReq MAC command is only supported on LoRaWAN 1.0.3 or higher.
This AT command is asynchronous. It responds with a +OK immediately. Upon receiving a response (downlink) from the network server, the modem sends a +EVENT=2,1 message followed by a +ANS=... message. If no response is received, the modem only sends +EVENT=2,0. The +ANS message will have the value 13 in the first field. The remaining two fields represent a GPS time (whole seconds and milliseconds).
The AT command takes an optional integer argument that controls when DeviceTimeReq uplink is sent. If the argument is omitted or set to 0, the modem sends an empty unconfirmed uplink with an empty payload immediately upon receiving AT$DEVTIME. If the argument is set to 1 (i.e., the application invokes AT$DEVTIME 1), the DevTimeReq MAC command will be piggybacked on the next regular uplink instead, i.e., the transmission of DevTimeReq MAC request will be delayed until the next uplink sent by the application. The regular uplink must be unconfirmed and must have retransmissions turned off for time synchronization to work correctly.
A note on GPS time: All time-related AT commands expect and return GPS time. That is the time scale used in LoRaWAN. GPS time differs from UTC time in its handling of leap seconds. GPS time monotonically increments for every SI second that elapsed since the GPS epoch, including all leap seconds inserted between the GPS epoch and current time.
To convert GPS time to a UNIX timestamp or UTC time, you need to make the time relative to the UNIX epoch and subtract negative leap seconds inserted since the GPS epoch. As of May 2023, 18 negative leap seconds have been inserted. Thus, the following formula converts GPS time to a UNIX timestamp: unix_timestamp = gps_time + 315964800 - 18. The UNIX timestamp can then be converted to UTC with standard facilities.
A note on the ATCI: The modem automatically adjusts GPS time values transmitted over the UART port based on how long it takes to transmit the data. There is no need for the application to compensate for UART transmission delays.
AT$DEVTIME
+OK
+EVENT=2,1
+ANS=13,1685213814,746
Supported since: 1.5.0
See also: AT$TIME
Configure the LoRaWAN 1.1 device nonce (DevNonce) value.
The DevNonce is a 16-bit counter incremented on each Join. The value is stored in NVM (EEPROM) and is meant to be preserved across factory resets. For security reasons, a device must never reuse DevNonce values across Joins.
AT$DEVNONCE?
+OK=0
AT$DEVNONCE=4
+OK
See also: AT+JOIN
Supported since: 1.5.0
Obtain the unique identifier of the modem's microcontroller (MCU).
This AT command can be used to obtain the unique identifier of the modem's microcontroller (MCU). The value is a 64-bit read-only unique integer assigned to the STM32 MCU by the manufacturer. The AT command interface transmits the value encoded in a hexadecimal format.
Upon factory reset, the modem uses the microcontroller identifier to generate a unique DevEUI. However, the DevEUI value can be changed by the application.
AT$MCUID?
+OK=3632313961398608
See also: AT+DEVEUI
Supported since: 1.5.0
List all supported AT commands.
This AT command displays a list of all supported AT commands, one per line.
AT+CLAC
AT+UART
AT+VER
...
AT$HELP
+OK
Note 1: Although this AT command starts with AT+, it is not part of the original Murata Modem firmware. It is a custom extension of the open firmware and the AT+ prefix has been retained for compatibility with cellular modem AT command interfaces.
Note 2: In firmware versions <= 1.1.3 the output of this AT command was NOT terminated with +OK.
See also: AT$HELP
Show help text for all supported AT commands.
This AT command lists all supported AT commands, one per line, and a short help text for each command.
AT$HELP
AT+UART Configure UART interface
AT+VER Firmware version and build time
...
AT$HELP This help
+OK
Note: In firmware versions <= 1.1.3 the output of this AT command was NOT terminated with +OK.
See also: AT+CLAC