Generic LoRaWAN® documentation
Are you looking for the generic LoRaWAN® documentation?
Here you can find the generic LoRaWAN® documentation👇
Join behavior of the LoRaWAN® sensors
Before telemetry data can be transmitted via LoRaWAN®, the device must first establish a connection with the network. To achieve this, the device repeatedly sends join requests until a join accept is successfully received.
To balance energy consumption and join speed, the transmission intervals between join requests increase over time. In parallel, the data rate is varied — starting with a higher data rate (lower spreading factor) and gradually decreasing to a lower data rate (higher spreading factor). This behavior strictly follows the specifications and recommendations of the LoRa Alliance®.
Sentinum sensors implement this behavior using join bursts, where the spacing between bursts increases over time.
Join bursts
A join burst consists of up to six join requests with decreasing data rate (DR5 → DR0) or increasing spreading factor (SF7 → SF12). The intervals between the individual join requests increase quadratically in order to comply with the duty-cycle restrictions defined by the LoRa Alliance®.
Duty-cycle limits for join requests
| Time window | Duty cycle |
|---|---|
| < 1 hour | 1 % |
| < 11 hours | 0.1 % |
| > 11 hours | 0.01 % |
This means that in the first phase (< 1 hour), the same total transmission budget is available as in the second phase (< 11 hours), even though the allowed transmission time is ten times shorter. To make optimal use of this budget, Sentinum sensors start with short intervals between join bursts, which become longer as time progresses.
Phases of the join process
- Phase 1: 2 bursts with short intervals (burst length approx. 10 minutes)
- Phase 2: 2 additional bursts with longer intervals (burst length approx. 100 minutes)
- Phase 3: 1 burst per day with very long intervals (burst length up to 16 hours)
EUIs and keys
All Sentinum LoRaWAN® sensors are supplied with the following identifiers:
- DEVEUI
- APPEUI
- APPKEY
- Product number
The 8-byte DEVEUI is a unique identifier selected from the Sentinum OUI block FC84A, which is assigned exclusively to Sentinum sensors.
The 8-byte APPEUI is also assigned from Sentinum’s own number range. Each product line shares the same APPEUI, enabling clear identification of the product series within the Sentinum product portfolio.
The 16-byte APPKEY is a cryptographic key generated individually and randomly for each device. It is used for secure authentication and encryption during the LoRaWAN® join procedure.
Each product also has a unique product number (for example APOQXXXX, FEBRXXXX), which is permanently associated with a specific DEVEUI and APPKEY.
These three keys (DEVEUI, APPEUI, APPKEY) are always included in the delivery package of each LoRaWAN® sensor and are also provided securely via the cloud. The APPEUI can be viewed when reading the device using the Sentinum LinQs app.
This documentation applies to all sensors with a module key of 0x22XX or 0x2211.
The downlinks of the LORA modules are all executed on port 4 and commands to be executed (EXEC) on port 5. These are marked with "(EXEC)" after the respective resource.
LoRa – module overview
| Module | Module key | Group | Group ID | Description |
|---|---|---|---|---|
| LoRa | 0x2211 | Network resources | 0x00 | DEVEUI of the device (read only) |
| LoRa | 0x2211 | Transmission settings | 0x01 | Transmission settings such as adaptive data rate (ADR), confirmed uplinks, etc. |
| LoRa | 0x2211 | Rejoin settings | 0x02 | Settings for network testing and automatic reconnection in case of connection loss. |
| LoRa | 0x2211 | GNSS group | 0x03 | Settings and timings for localization options (for sensors with tracking feature) |
| Supervisor | 0x3211 | System | 0x00 | Reset or restart device |
Tables for cross-product modules can be found in the Generic NFC and Downlink documentation.
For more information on configuring sensor communication, refer to the respective generic LoRaWAN® or Mioty® documentation, depending on the version.
The current settings for a parameter can be queried by not sending a configuration value with the downlink.
Example:
To read the current setting of the ADR parameter, the following downlink can be used:
11 22 11 01 02
This downlink queries the current ADR value without changing it.
The downlink must be sent to port 6. The sensor responds here on port 3
LoRa – group network resources (0x00)
| Resources | Resource ID | Key (NFC/BLE) | Min | Max | Factory setting | Unit | Module key |
|---|---|---|---|---|---|---|---|
| DEVEUI | 0x00 | dev_eui | 16 | 16 | 16 | 22XX | |
|
READONLY Parameter: DEVEUI of the sensor. This parameter cannot be read via downlink. |
|||||||
LoRa – group transmission settings (0x01)
| Resources | Resource ID | Key (NFC/BLE) | Min | Max | Factory setting | Unit | Module key |
|---|---|---|---|---|---|---|---|
| Confirmed | 0x00 | conf | 0 | 3 | 0 | 22XX | |
|
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: everything confirmed |
|||||||
| Confirmed retries | 0x01 | retry | 1 | 5 | 3 | 22XX | |
| Maximum number of retries in "CONFIRMED" mode. | |||||||
| ADR | 0x02 | adr | 0 | 1 | 1 | dr | 22XX |
|
ADR on/off: • 0: ADR off • 1: ADR on |
|||||||
| Data rate | 0x04 | drmax | 0 | 5 | 0 | dr | 22XX |
| Fixed data rate (SF) used when ADR is disabled. | |||||||
| Activate downlink response | 0x05 | dresp | 0 | 1 | 0 | 22XX | |
|
Specifies whether a downlink outside the "CONFIRMED" range is acknowledged. When enabled, the downlink triggers an uplink. • 0: off • 1: on |
|||||||
LoRa – group rejoin settings (0x02)
| Resources | Resource ID | Key (NFC/BLE) | Min | Max | Factory setting | Unit | Module key |
|---|---|---|---|---|---|---|---|
| Rejoin strategy | 0x00 | rejstr | 0 | 2 | 0 | 22XX | |
|
Re-entry strategy: • 0: never rejoin • 1: all x transfers → link check • 2: all x transfers → confirmed uplink |
|||||||
| Connection check all | 0x01 | chkev | 1 | 48 | 4 | 22XX | |
|
Determines the number x (for rejstr) after which a connection check is performed. Depending on rejstr, the check is: • a link check (rejstr = 1) • a confirmed uplink (rejstr = 2) |
|||||||
| Error until rejoin | 0x02 | rejaft | 0 | 5 | 4 | dr | 22XX |
| Specifies after how many failed checks the sensor should perform a rejoin. | |||||||
LoRa – gnss group (0x03)
| Resources | Resource ID | Key (NFC/BLE) | Min | Max | Factory setting | Unit | Module key |
|---|---|---|---|---|---|---|---|
| GNSS mode | 0x00 | lmode | 0 | 4 | 0 | 22XX | |
|
Specifies the order of localization technologies: • 0: off • 1: GNSS scan • 2: WIFI SSIC scan • 3: GNSS scan followed by WIFI SSID scan • 4: WIFI SSID scan followed by GNSS scan |
|||||||
| GNSS update period | 0x01 | gper | 1 | 43200 | 1440 | min | 22XX |
| Update period for device localization in hours. | |||||||
| Almanac data download | 0x02 | gnssal | 0 | 1 | 0 | 22XX | |
|
ALMANAC data is downloaded (increases power consumption but localization is faster and more accurate): • 0: no data is being downloaded • 1: ALMANAC data is downloaded |
|||||||
| GNSS in mobile applications | 0x03 | gnssmb | 0 | 1 | 0 | 22XX | |
|
Localization methods are optimized depending on the application: • 0: optimized for static objects • 1: optimized for moving objects |
|||||||
| Execute scan (EXEC) | 0x04 | ||||||
|
Start scan. Example downlink on port 5: 11 2211 03 04
|
|||||||
Supervisor – group system settings (0x00)
| Resources | Resource ID | Key (NFC/BLE) | Min | Max | Unit | Module key |
|---|---|---|---|---|---|---|
| Reboot (EXEC) | 0x00 | reboot | 0 | 43200 | s | 32XX |
|
Reboot the device — settings are retained. After the resource ID, 2 bytes must be added to the command. These specify the time after which the reboot will be performed. • Time is specified in seconds • May be 0 • Must always be specified as 2 bytes (e.g. 00 00) • Minimum: 0 • Maximum: 43200 |
||||||
| Reset (EXEC) | 0x01 | reset | 0 | 43200 | s | 32XX |
|
Reset the device — settings are reset. After the resource ID, 2 bytes must be added to the command. These specify the time after which the reset will be performed. • Time is specified in seconds • May be 0 • Must always be specified as 2 bytes (e.g. 00 00) • Minimum: 0 • Maximum: 43200 |
||||||
Example: Reboot the device after 0 seconds:
Port 5:
11 3211 00 00 00 00
If the 2 bytes are not appended, the downlink will fail!
Example downlinks
| Resource | Description | Downlink |
|---|---|---|
| Reboot | Reboot the device after 10 seconds. Settings are retained. | 11 3211 00 00 00 0A |
| Perform scan | Perform GNSS scan. | 11 2211 03 04 |
| Confirmed | All uplinks should be executed as confirmed uplink. | 11 2211 01 00 00 00 00 03 |
| ADR | Disable ADR. | 11 2211 01 02 00 00 00 |
Specifications subject to change without notice. All information provided without guarantee.

![]()