Are you looking for the generic LoRaWAN® documentation?
Here you can find the generic LoRaWAN® documentation.
Basics
📢 This document describes the properties and adjustable parameters specific to the LoRaWAN® wireless protocol across all sensors.
Join behavior of the LoRaWAN® sensors
Before telemetry data can be sent via LoRaWAN, the device must establish a connection with the network. To do this, the device sends join requests until a join accept has been successfully received. As a compromise between energy consumption and a fast join, the transmission intervals of the join requests become longer and longer. In addition, the data rate is also varied (initially large data rate or small spreading factor, then smaller data rate or larger spreading factor). The join behavior strictly adheres to the specifications and recommendations of the LoRa Alliance specification. Sentinum sensors implement the specifications through so-called join bursts, the distance between which increasesA join burst consists of a maximum of 6 join requests with decreasing data rate (DR5-DR0) or increasing spreading factor (SF7-SF12). The intervals between the requests increase quadratically in order not to violate the Lora-Alliance specific duty cycle guidelines. The LoRa Alliance prescribes a decreasing duty cycle for join requests according to the following table Time duty cycle <1h 1% <11h 0.1%
11h 0.01%
This means that in the first phase (<1h) exactly the same amount of send budget is available as in the second (<11h), although only a tenth of the time is available. In order to make maximum use of the budget, the intervals between join bursts (consisting of max. 6 join requests) are initially small and then become larger. Specifically, 2 bursts are carried out in phase 1. In phase 2, 2 further bursts are carried out, and from phase 3 onwards, 1 burst is carried out per day. The length of the bursts increases from approx. 10 minutes in phase 1, to approx. 100 in phase 2, to up to 16 hours in phase 3.
EUIs and keys
All Sentinum sensors supplied have
- DEVEUI
- APPEUI
- APPKEY
- Product number
The 8-byte DEVEUI is a unique number selected from the Sentinum OUI block FC84A, which has been assigned to the sensors. The 8-byte APPEUI is also selected from Sentinum's own number range. Each sensor series always has the same APPEUI. This allows the product series to be identified within the Sentinum products. The 16-byte APPKEY is a key randomly generated by a program.
In addition, each product has an individual product number. Each product number (APOQXXXX, FEBRXXXX, ...) is linked to a DEVEUI and an APPKEY.
The scope of delivery includes the three keys listed for each LoRaWAN® sensor and are part of the package. In addition, the keys are provided via a secure cloud.
The APPEUI is displayed when read out by the Sentinum LinQs app.
Default parameters
The default parameters and default settings apply if no other values are specified in the product-specific documentation.
Parameters | Default | Optional (adjustable) |
---|---|---|
Activation | OTAA | ABP |
LoRa MAC version | 1.0.2 | Update takes place if properties of the sensors are positively influenced. |
Join Loop Datarate Start | SF7 (datarate 5) | |
Join Loop Datarate End | Internal temperature | |
Regional Parameters | RP001 Regional Parameters 1.0.2 revision B |
|
REV | REV B | |
Frequency Plan (for EU) | Europe 863-870 MHz (SF12 for RX2 recommended) |
APPEUI
Configuration options
NFC and downlink commands
Name
|
Descrip-tion
|
json Key
|
Module key
|
Group for downlink
|
ID
|
Default value
|
Min
|
Max
|
Unit
|
read(r)/write(w)
|
Module Key/SE Version
|
---|---|---|---|---|---|---|---|---|---|---|---|
APPEUI
|
Specifies the APPEUI
|
app_eui
|
0x1112
|
0x00
|
0x00
|
w
|
|||||
APPKEY
|
Specifies the APPEUI
|
app_key
|
0x1112
|
0x00
|
0x01
|
w
|
|||||
DEVEUI
|
Specifies the DEVEUI
|
dev_eui
|
0x1112
|
0x00
|
0x02
|
r
|
|||||
Confirmed Strategy
|
Indicates whether the sensor is operating in confirmed mode: 0: confirmed off = unconfirmed 1: confirmed INFO messages (status uplinks) => currently not available 2: Alarm uplinks confirmed 3: All confirmed
|
conf
|
0x1112
|
0x01
|
0x00
|
0
|
0
|
3
|
rw
|
||
Confirmed Retries
|
Number of maximum retries (transmission attempts in confirmed mode)
|
retry
|
0x1112
|
0x01
|
0x01
|
3
|
1
|
5
|
rw
|
||
ADR
|
ADR on/off 0: ADR off 1: ADR on
|
adr
|
0x1112
|
0x01
|
0x02
|
3
|
0
|
1
|
rw
|
||
ADR SF min
|
Minimum spreading factor to which the ADR can fall back
|
dr
|
0x1112
|
0x01
|
0x03
|
5
|
0
|
5
|
datarate
|
rw
|
|
Fixed SF
|
Fixed spreading factor if ADR is switched off
|
drmax
|
0x1112
|
0x01
|
0x04
|
0
|
0
|
5
|
datarate
|
rw
|
|
Enable Downlink Response
|
Specifies whether a downlink is confirmed outside the confirmation for downlink confirmed. In this case, the downlink triggers an uplink: 0: off 1: on
|
dresp
|
0x1112
|
0x01
|
0x05
|
0
|
0
|
1
|
rw
|
||
APPSKEY
|
For ABP
|
apps_key
|
w
|
||||||||
NETWSKEY
|
For ABP
|
netws_key
|
w
|
||||||||
DEVADDR
|
For ABP
|
dev_addr
|
w
|
||||||||
ACTMTH
|
0: OTAA 1: ABP
|
act_mth
|
0
|
0
|
1
|
rw
|
|||||
REJSTR
|
Rejoin Stratregy: 0: Never Rejoin 1: Every X transmissions Link Check 2: Every X transmissions Confirmed
|
rejstr
|
0
|
0
|
2
|
rw
|
|||||
CHKEV
|
Check Every determines the number (x for rejstr) after which a check is performed, either by confirmed with ACK or Link Check, depending on how specified in rejstr.
|
chkev
|
4
|
1
|
48
|
rw
|
|||||
REJAFT
|
Rejoin after specifies after how many failed checks the sensor should rejoin.
|
rejaft
|
4
|
0
|
5
|
rw
|
📢 The values of the group for downlink APPEUI, APPKEY, DEVEUI can only be set via NFC!
To change the keys such as app_eui and app_key and perform a REBOOT at the same time
at the same time, please always perform the following:
{
"power": "REBOOT",
"senticom":{
"app_eui": "8XXXXXXXXXXXXXXXXX",
"app_key": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
}
As app_eui and app_key are write-only parameters, they cannot be read by the app unless they have been previously written by the app. We therefore generally recommend leaving the keys permanently in the JSON configuration. If it is required that user-specific keys are set, but these should not be readable under any circumstances, another JSON can be written without these keys after the keys have been set for the first time. In this case, the keys remain in the internal memory. Only when power=RESET are they reset to the factory setting.
💡 rejstr, chkev and rejaft are features to activate a link check.
SF vs. DR
DR
|
SF
|
0
|
SF12
|
1
|
SF11
|
2
|
SF10
|
3
|
SF9
|
4
|
SF8
|
5
|
SF7
|