PCR2 LoRaWAN® Payload

V5 | V4 | V3

This document describes PCR2 LoRaWAN® Payload V5 introduced with Firmware V4.0.

PCR2 devices send 3 payloads formats. Each payload has a unique prefix to easily separate them. In addition, different ports are used in each case.

DeviceID Payload (Port 190)

After PCR2 has successfully joined a LoRaWAN® network, a DeviceID payload is sent once via port 190.

The DeviceID payload contains device identification data. This can be useful in large installations to maintain a device inventory with information such as type and firmware version. If this is not needed, ignore this payload data.

Downlink to port 190 will be ignored.

Examples

Format

Total lengths: 9 bytes (18 ASCII characters)

Port

Port used: 190

AppData Payload (Port 14)

Application data is sent at regular intervals or on detection (trigger mode).

To save airtime, the payload has been reduced to 10 bytes. This allows operation in all major LoRaWAN® regions such as EU868, AS923, AU915 and US915.

Examples

Format

Total length: 10 bytes (20 ASCII characters)

Port

Port used for Uplink and Downlink: 14

Config Downlinks (Port 1)

Config downlinks are used to change application and radar settings in the field. Commands and arguments are sent to the device for this purpose.

Important: LoRaWAN® settings cannot be changed via downlink. This is to preventing to unlink the device by misconfiguration.

Communication takes place via port 1. As soon as the device receives a downlink, the arguments are parsed and range-checked. A confirmation uplink will be sent immediately.

V4.0.x: Changed settings need to be saved and applied with the be0100c563ee command. V4.1.x: Settings are applied as soon as downlink is received.

Typical Configuration Sequence

Following example shows a typical sequence to change only one setting.

DL: be 01 00 c5 02 00 0a    <- change interval to 10 min 
UL: be 01 00 c5 02 00 0a    <- uplink showing the value has been accepted
DL: be 01 00 c5 ee          <- send the save&restart command 
.
JOIN                        <- device restarts and joins
.                             
UL: be 01 00 d5 04 00 00    <- DeviceID payload (port 190) after join accept received
.

Starting with firmware V4.0 we made it possible to change single settings rather than sending a 37 bytes long monster payload.

Examples

Commands

This table show a list of all available settings and commands you can use for Config Downlinks.

Note: All changes need to be saved to ROM with the ee command in order to get active

Format

Total lengths: 5-7 bytes (10-14 ASCII characters) depending on the command used

Port

Port used for Uplink and Downlink: 1

Best Practice

A few hints for implementing payload decoders. You can find code examples on our public repository

Check Prefix and Port

In order to stay backwards compatible with future developments we highly recommend checking uplink port and payload prefix to select an encoder

    if ( port == 190 && byte[0] == 0xbe && byte[1] == 0x01 && byte[3] == 0xd5)   
    {    
        // decode PCR2 DeviceID Payload V5            

    }

    if ( port == 14 && byte[0] == 0xbe && byte[1] == 0x01 && byte[3] == 0xa5)  
    {   
        // decode PCR2 Application Data Payload V5    

    }

    if ( port == 1 &&  byte[0] == 0xbe && byte[1] == 0x01 && byte[3] == 0xc5)  //  PCR2 Config Payload (People)
    {           
        // decode PCR2 Config Payload V5 (Acknowledged Config Change)          

    }

Check DCNT

A confirmed uplink message is a message where a LoRaWAN® endpoint (PCR2) is requesting the LoRaWAN® network to confirm the reception of its uplink message. If it receives a message within the first or second RX window, which ‘ACK’ flag set to 1, it will consider the original uplink message delivered.

If there is no message received, it means the network has not received the uplink. In this case PCR2 simply sends the uplink again and again (up to 10 times or according the attempts setting before doing a rejoin). Counting values are only reset when PCR2 received an ACK for not loosing data.

With firmware V4.0 we added a data message counter DCNT to the payload. This works like a serial number for the submitted data. Checking this value allows the application server to determine if the ACK has been received by the device or if a number is missing.

Example Uplink Sequence

Following sequence of uplinks show problems with RX path of the device. Uplinks have been received by the network. But the device did not hear the ACK.

be 01 00 d5 00 00 00 00 00 01   <- This is the first data message
be 01 00 d5 00 01 00 02 00 02   <- This is the second data message, with some counting values
be 01 00 d5 00 01 00 02 00 02   <- Repeated message, ACK has not been received by the device
be 01 00 d5 00 03 00 05 00 03   <- New data message, ACK has been received

Implementation of an algorithm

• App Server should save the last DCNT value received
• When a new uplink is received the decoder should check if DCNT changed. (Compare with save value)
• If changed, save the counting values to the database. If DCNT did not change, a repetition has been received that can be ignored.

Payload Decoder Source Code

Find more example code in our public repository.