...
The Car Counter was designed to count the number of passing cars. The maximum speed of cars for counting to be reliable is 32km/h(20mph). The maximum time a car can stay above the sensor is 2 minutes. Motorcycles are not guaranteed to be counted or not to be counted. The probability of passing a motorcycle being counted mainly depends on the relational trajectory of the motorcycle.
Data from the device’s sensors are processed by the device's embedded algorithm. The algorithm output is the number of passing cars. Device configuration defines when the updated number of passing cars will be transmitted to the network.
...
Default sensor firmware was designed to minimize power consumption and radio spectrum usage until the sensor will be installed. When a sensor is installed it is necessary to calibrate it using Nwave Device Management App. Only when the sensor is calibrated it will start a vehicle detection algorithm and LoRaWAN network join procedure.
...
3.1 Join Procedure
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 (To maximize counting quality the minimum distance between cars should be 1 meter. This requirement should be easy to satisfy in case of safe driving as, based on the Two-second rule (https://en.wikipedia.org/wiki/Two-second_rule ), 1 meter corresponds to a speed of 0.5m/s or 1.8km/h or about 1.1mph, and in the places where the car counters are usually installed expected vehicle speed is higher and so should be the distance.
Data from the device’s sensors are processed by the device's embedded algorithm. The algorithm output is the number of passing cars. Device configuration defines when the updated number of passing cars will be transmitted to the network.
2 First commissioning
Default sensor firmware was designed to minimize power consumption and radio spectrum usage until the sensor will be installed. When a sensor is installed it is necessary to calibrate it using Nwave Device Management App. Only when the sensor is calibrated it will start a vehicle detection algorithm and LoRaWAN network join procedure.
3 LoRaWAN Interface
A car counter device is equipped with a LoRa radio operated in Class A. The implemented functionality complies with the LoRaWAN Specification 1.0.3.
The frequencies supported and receive window parameters follow the LoRaWAN v1.0.3 EU868 Regional Parameters rev. a.
3.1 Join Procedure
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:
Counter update message transmission policy is configured via a table that describes the threshold for joint value of elapsed time and number of events since the last counter update message transmission.
Consider a table like this.
...
Number of events since last counter update message transmission
...
Elapsed time since last counter update message transmission
...
0
...
1200
...
1
...
300
...
2
...
200
...
5
...
100
...
10
...
60
The table describes a threshold in 2D space that defines if a counter update message must be sent. If a point lies left from the curve the message must be sent.
...
So this configuration allows to set:
the minimum period between messages. In this case, it is 60 seconds and no matter how many cars passed after the last message a new message will be sent not earlier than 60 seconds after the last message.
the minimum number of events necessary to send the next message. In this case, it is 0, and even if there were no new passing cars after the last message the new one will be sent in 1200 seconds after the last message.
Another example.
Number of events since last counter update message transmission
Elapsed time since last counter update message transmission
Attempt | DataRate |
|---|
...
3.2 Exponentially increasing intervals
...
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
...
1 | Next higher datarate after Configured DR( default is DR3, as the default configured datarate is DR2) but not higher than DR4 |
2 | Next higher datarate after Configured DR( default is DR3, as the default configured datarate is DR2) but not higher than DR4 |
3 | DR3 |
4 | DR2 |
5 | DR1 |
6 | DR0 |
In case the Join accept message is received after attempts 3, 4, 5, or 6(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 configured 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).
Counter update message transmission policy is configured via a table that describes the threshold for joint value of elapsed time and number of events since the last counter update message transmission.
Consider a table like this.
Number of events since last counter update message transmission | Elapsed time since last counter update message transmission |
|---|---|
0 | 1200 |
1 | 300 |
2 | 200 |
5 | 100 |
10 | 60 |
...
Here the minimum number of new events is 2, so if after the last message there were none or only 1 event there will be no new counter update message ever.
There is also another factor that impacts when the counter update message is sent. Cars are counted when they leave the sensor, and even after that, there is an additional delay of 5 seconds to allow the passing car to go farther and check if there is another car following it. It allows avoiding sending messages in unstable conditions or under a car. There is a timeout of 30 seconds for this mechanism too, so if a message was ready to be sent, but conditions were not good for 30 seconds it will be sent anyway(even under a car).
...
By configuring counter update message transmission policy we can indirectly affect how many messages the device will send per day, and by configuring the data rate we define how much energy uses each message.
Here is a table showing the expected lifespan in years of the device vs the number of messages per day and configured data rate(or actual data rate in case of ADR enabled).
...
Data rate\Number of messages per day
...
10
...
20
...
50
...
100
...
200
...
500
The table describes a threshold in 2D space that defines if a counter update message must be sent. If a point lies left from the curve the message must be sent.
...
So this configuration allows to set:
the minimum period between messages. In this case, it is 60 seconds and no matter how many cars passed after the last message a new message will be sent not earlier than 60 seconds after the last message.
the minimum number of events necessary to send the next message. In this case, it is 0, and even if there were no new passing cars after the last message the new one will be sent in 1200 seconds after the last message.
Another example.
Number of events since last counter update message transmission | Elapsed time since last counter update message transmission |
|---|---|
2 | 200 |
5 | 100 |
10 | 60 |
...
Here the minimum number of new events is 2, so if after the last message there were none or only 1 event there will be no new counter update message ever.
There is also another factor that impacts when the counter update message is sent. Cars are counted when they leave the sensor, and even after that, there is an additional delay of 5 seconds to allow the passing car to go farther and check if there is another car following it. It allows avoiding sending messages in unstable conditions or under a car. There is a timeout of 30 seconds for this mechanism too, so if a message was ready to be sent, but conditions were not good for 30 seconds it will be sent anyway(even under a car).
The counter update message can be configured as not confirmed with or without repetitions. It reduces the usage of the duty cycle to acknowledge all messages, but may also reduce the percentage of successfully received messages by the Gateway.
The DataRate is used in the uplink messages by the sensor is DR2 by default but may be configured from DR0 to DR5, ADR(Adaptive Data Rate also can be enabled).
The application protocol may be subject to change. The functionality may be extended in the next versions.
4.1 Expected lifespan of the car counter vs number of LoRaWAN messages per day and configured Data Rate
By configuring counter update message transmission policy we can indirectly affect how many messages the device will send per day, and by configuring the data rate we define how much energy uses each message.
Here is a table showing the expected lifespan in years of the device vs the number of messages per day and configured data rate(or actual data rate in case of ADR enabled).
Data rate\Number of messages per day | 10 | 20 | 50 | 100 | 200 | 500 |
DR0(SF12) | 7.4 | 7.2 | 6.6 | 5.9 | 4.8 | 3.1 |
DR1(SF11) | 7.5 | 7.4 | 7.0 | 6.5 | 5.7 | 4.2 |
DR2(SF10) | 7.5 | 7.5 | 7.3 | 7.0 | 6.5 | 5.4 |
DR3(SF9) | 7.6 | 7.5 | 7.5 | 7.3 | 7.0 | 6.3 |
DR4(SF8) | 7.6 | 7.6 | 7.5 | 7.4 | 7.3 | 6.8 |
DR5(SF7) | 7.6 | 7.6 | 7.6 | 7.5 | 7.4 | 7.2 |
...
To convert transmitted values of battery voltage to mV, use the following formula:
Vbat = (2400+value*5)mV,
where value is Battery voltage value transmitted in the message.
4.2.3 Startup
...
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
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.:
Vbat = (2400+value*5)mV,
where value is Battery voltage value transmitted in the message.
4.2.3 Startup
The startup message uses port 3 and it is always confirmed. It will be sent after every startup/reboot /(re-)join event:
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
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.
...
DataRate configuration uses port 52. The default value is DR2 (0x02) The selected configuration is persistent unless overwritten in the join procedure. Higher DataRates increases the battery lifetime of the sensor but may reduce the reliability of the reception of messages by the Gateway. This is especially the case for unconfirmed messages.
4
Byte | Bits | Name | Default value |
|---|---|---|---|
0 | 2..0 | DataRate configuration | 2 (DR2) |
3 | Enable ADR(Adaptive Data Rate):
| 0 | |
6..4 | Counter update confirmation configuration | 1(Unconfirmed with 1 uplink message(0 repetitions)) | |
7 | Reserved | 0 |
DataRate configuration value
DataRate(Spreading Factor)
0
DR0 (SF12)
1
DR1 (SF11)
2
DR2 (SF10)
3
DR3 (SF9)
4
DR4 (SF8)
5
DR5 (SF7)
6
Reserved
7
Reserved
Counter update confirmation configuration
Description
0
Confirmed(up to 8 repetitions)
1
Unconfirmed with 1 uplink message(0 repetitions)
2
Unconfirmed with 2 uplink messages(up to 1 repetition)
3
Unconfirmed with 3 uplink messages(up to 2 repetitions)
| 0 | |
6..4 | Counter update confirmation configuration | 1(Unconfirmed with 1 uplink message(0 repetitions)) |
7 | Reserved | 0 |
DataRate configuration value | DataRate(Spreading Factor) |
|---|---|
0 | DR0 (SF12) |
1 | DR1 (SF11) |
2 | DR2 (SF10) |
3 | DR3 (SF9) |
4 | DR4 (SF8) |
5 | DR5 (SF7) |
6 | Reserved |
7 | Reserved |
Counter update confirmation configuration | Description |
|---|---|
0 | Confirmed(up to 8 repetitions) |
1 | Unconfirmed with 1 uplink message(0 repetitions) |
2 | Unconfirmed with 2 uplink messages(1 repetition) |
3 | Unconfirmed with 3 uplink messages(2 repetitions) |
4 | Unconfirmed with 4 uplink messages(3 repetitions) |
For example:
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.
To get back to default DR2 send “Eg==”(00010010 in binary) to port 52.
4.3.2 Update transmission threshold configuration
...
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)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).
...
1 (1 byte) to calibrate the device,
2 (1 byte) to reboot the device,
3 (1 byte) to put the device into the initial energy-saving mode (the device sleeps until the next calibration with no detection and no LoRaWAN messages).
5. Changelog
0.6.7 4 January 2023
Features:
The way configured datarate is changed if attempts to join the network using this datarate fail is changed to avoid sensors being able to connect but not send messages later
Known issues and limitations:
None at the moment.
0.1.0 28 June 2021
Features:
...