...
The first calibration initiates the join process. The Join procedure follows the Over-the-Air Activation (OTAA) described in the LoRaWAN Specification 1.0.2. Activation By Personalization (ABP) is not supported.
After powering up the car counter device, it will try to join a LoRaWAN Network by sending the join request message. In case the join request is not answered, the sensor will retry as soon as possible, according to transmission time limitations, up to 4 5 additional times (5 6 attempts in total). After the 5th 6th unsuccessful attempt, the sensor will wait with exponentially increasing intervals (see chapter 3.2) and repeat the process 5 more timesagain.
If the Join request message is not answered with a Join Accept message, the sensor retries, according to the following sequence:
Attempt | DataRate |
|---|---|
1 | Next higher datarate after Configured DR or default(DR2)( default is DR3, as the default configured datarate is DR2) but not higher than DR4 |
2 | Next higher datarate after Configured DR or default(DR2)3( default is DR3, as the default configured datarate is DR2) but not higher than DR4 |
3 | DR3 |
4 | DR2 |
45 | DR1 |
56 | DR0 |
In case the Join accept message is received after attempts 3, 4, 5, or 56(so the first 2 attempts using configured datarate failed), and the sensor's configured datarate(DR2 by default) is higher than the next slower data rate to the datarate used in the attempt, the configured datarate will be changed to DR2, DR1, DR0, or DR0 accordingly. This behavior assumes that the configured DataRate does not allow communication with the Gateway.
...
A few examples:
If the join sequence will not successful the sensor retries again with exponentially increasing intervals. The intervals are: 1, 2, 4, 8, 16, 32, 64, 128 minutes. Once reached 128 minutes, the wait time is always 128 minutes. There is also an additional random delay from 0 to 32 seconds added every time to the selected interval.
3.3 Device EUI
...
If the serial number will be 123456, the device EUI is 00 E8 BF 3B 00 12 34 56.
Exchanging the DevEUI of the sensor is not possible.
...
4 Application protocol description
After a successful join (join accepted message is received) the sensor will send a startup message, then starts with the normal operation and sends counter update when necessary. Some application messages (startup message, heartbeat message) are always sent as confirmed. The counter update message is not confirmed by default but can be configured as confirmed. In case of the confirmation is not receivedconfigured data rate was as by default DR2, and Join will be completed in attempts 1, 2, or 3(using datarate DR3 while joining) DR2 will continue to be used as configured datarate.
If the configured data rate was as by default DR2, and Join will be completed only in attempt 5 or 6(using datarate DR1 or DR0 while joining) DR0 will be selected to be used as configured datarate.
This is done to decrease the chances of selecting datarate which does not provide good connectivity.
3.2 Exponentially increasing intervals
If the join sequence will not successful the sensor retries again with exponentially increasing intervals. The intervals are: 1, 2, 4, 8, 16, 32, 64, 128 minutes. Once reached 128 minutes, the wait time is always 128 minutes. There is also an additional random delay from 0 to 32 seconds added every time to the selected interval.
3.3 Device EUI
The device EUI of the sensor is pre-provisioned during production and may be derived from the serial number printed on the sensor casing. The device EUI may be derived from the serial number as in this example:
If the serial number will be 123456, the device EUI is 00 E8 BF 3B 00 12 34 56.
Exchanging the DevEUI of the sensor is not possible.
3.4 Application EUI
The AppEUI is pre-provisioned during production and will be delivered with the sensor zone. Exchanging the AppEUI of the sensor is currently impossible.
3.5 Application Key
The AppKey is pre-provisioned during production and will be delivered with the sensor zone. Exchanging the AppKey of the sensor is impossible.
4 Application protocol description
After a successful join (join accepted message is received) the sensor will send a startup message, then starts with the normal operation and sends counter update when necessary. Some application messages (startup message, heartbeat message) are always sent as confirmed. The counter update message is not confirmed by default but can be configured as confirmed. In case of the confirmation is not received, the sensor will retry 7 more times, adapting the DataRate as recommended in the LoRaWAN v1.0.2 spec(look at 18.4 Data-Rate Adaptation during Message Retransmissions and 18.1 Uplink Timing Diagram for Confirmed Data Messages).
...
Byte | Name |
|---|---|
0 | Major part of version number |
1 | Minor part of version number |
2 | Micro part of version number |
3 | Reset cause 0x00 No reset ( Startup message after re-joining LoRaWAN network) 0x01: Watchdog reset 0x02: Power On Reset 0x03: User Request Reset 0x06 - Brownout Reset 0x07 - Others |
4.2.4 Debug messages
...
1 | Minor part of version number |
2 | Micro part of version number |
3 | Reset cause 0x00 No reset ( Startup message after re-joining LoRaWAN network) 0x01: Watchdog reset 0x02: Power On Reset 0x03: User Request Reset 0x06 - Brownout Reset 0x07 - Others |
4.2.4 Debug messages
The Debug messages use port 6 and they are always unconfirmed. By default, these messages are enabled and have no repetitions, but they may be disabled or increased by the number of repetitions used (see downlink messages). These messages do not have a fixed length as their payload depends on the type of debug message.
The first 2 bytes of the payload represent the debug code in Big Endian format, and the rest of the payload(if any) contains additional parameters which meaning depend on the exact debug code.
Debug code | Meaning | Additional parameters |
|---|---|---|
899 (0x383) | Invalid user request. The downlink command has not been recognised or provided configuration cannot be used. | None |
805 (0x325) | No change in configuration. Provided configuration parameters are equal to the current parameters in use | None |
4.3 Downlink messages
Downlink messages are those sent from the Network to the Sensor. The sensor supports confirmed and unconfirmed downlink messages.
...
To change the data rate to DR0 you need to send one byte in binary representation 00010000 (0x10) to port 52. Many LNS interfaces have Base64 input and you can use an online converter from binary to Base64. 00010000 binary is “EA==” string in Base64.
To set 4 unconfirmed attempts on DR0 send “QA==” (01000000 in binary) to port 52
To change the data rate to DR3 you need to send “Ew==“ (00010011 in binary) to port 52.
...
send 11 to port 52(No ADR, Data Rate DR1, unconfirmed message without repetitions)
send 00 64 to port 53( messages will be sent every 100 seconds even without any new events)
To reset the transmission policy table to default, send 0E 10 10 3C 20 28 to port 53 (3600 = 0xE10, 60 = 0x03c, 40 = 0x028).
It is important to remember, that minimum delay between LoRaWAN messages including Counter Update messages is also defined by LoRaWAN specifications(like duty cycle limitations in EU868 region) and Car Counter abides by these limitations. In the case of low data rates, delays caused by duty cycle limitations can be significant(for example, about 100 s for DR0).
...