Sensor Operation

This page tells how the device samples and reports the onboard temperature sensor and the onboard humidity sensor. It also tells how the device keeps failed confirmed uplinks with the Data Caching function, and how battery depassivation works.

Supported Sensors and Functionality

The device supports these sensors through the LoRaWAN interface:

The device does not have other sensors that operate through the LoRaWAN interface.

Note: To discuss more functions or customization, contact your sales representative.

Sensor Reporting

The Reporting Period makes sure that all active sensors send a reading at an interval that is not longer than the Reporting Period. Each time the device sends an asynchronous report, the device resets the Reporting Period timer. The sections that follow give the conditions for these asynchronous reports.

Note: For the first 30 minutes after a device reset or a power cycle, the Reporting Period is 30 seconds. This helps you to verify the installation and to debug the device.

Analog Sensor Operation

Analog Sensors

• Thermometer (temperature)
• Hygrometer (humidity)

Default Operation

The device samples the analog sensors at the Sample Rate. The device compares the current sample with the previous sample. If the difference between the two readings is more than the configured delta, the device sends a sensor reading. The Reporting Period makes sure that the device sends a sample at the configured period or at a shorter interval.

Sampling Configuration

Sampling Configuration is available in firmware v0.26.0 and later.

The Sampling Configuration sets the parameters of a median average filter. The filter is very useful when you use Delta Thresholds and long Reporting Periods. The filter stops noise. Noise can cause unnecessary reports that decrease battery life.

• The Sample Window must be equal to or larger than the Average Window.
• The Average Window must be in the center of the Sample Window, with an equal number of samples on each side.
• The device rejects configurations that are not valid.

At each Sample Period, the device puts the sample into a FIFO. The Sample Window sets the length of the FIFO. The device then calculates the average of N samples in the center of the Sample Window. The Average Window sets N. The device reports the result with the Delta Threshold and Reporting Period logic.

Confirmed Messages

Confirmed Messages are available in firmware v0.26.0 and later.

Confirmed Messages are a LoRaWAN function. With this function, the Network Server sends an acknowledgement for each message. The device sends the message again until it gets the acknowledgement. This makes sure that the customer application receives the message. If the device loses the network connection, the device can keep the confirmed sensor reports. You can get the reports at a later time. Refer to Data Caching.

Use a bit mask to activate Confirmed Messages for each analog sensor. Refer to the Confirmed Message parameter in Configuration.

To get the longest battery life, use Confirmed Messages with the median filter and long Reporting Periods. With this configuration, the device sends important changes quickly and reliably. The device also uses less energy when conditions are stable.

Example

This example uses these settings:

• Temperature Report Delta: 5 C
• Sensor Sample Period: 1 minute
• Reporting Period: 5 minutes
• Sample Window: 1
• Average Window: 1

Data Caching

Data Caching V1 is available in firmware v0.60.0 and later. Data Caching V2 is available in firmware v0.136.0 and later.

The Data Caching function keeps failed confirmed uplinks on the device. You can get these uplinks at a later time.

• Set configuration parameter 0x0D to activate Data Caching. Refer to Configuration.
• Data Caching supports only MQPS uplinks at this time.
• Data Caching V1 keeps only confirmed uplinks. Use configuration parameter 0x0A to set confirmed uplinks.

Caching Operation

When Data Caching is active, the device waits for the acknowledgement of each confirmed uplink. If the device does not get the acknowledgement in 30 seconds after it sends the uplink, the device keeps the uplink. For the first 30 minutes after power-on, this time is 15 seconds. The device keeps each uplink with a timestamp in non-volatile memory.

• Data Caching V1 uses UTC time for the timestamp. Data Caching V2 uses GPS time.
• The device keeps more than 3000 records.
• When the record memory is full, the device deletes the oldest records first to keep new records.
• Operations such as FUOTA delete all records.

Note: The time limit is 30 seconds after the device sends the uplink. For the first 30 minutes after power-on, the time limit is 15 seconds.

Note: Under good RF conditions, Data Caching has no appreciable effect on battery life. If the PER is high, confirmed messages cause the device to send more often to make sure that the LNS acknowledges the messages. In extreme conditions, the device joins the network again more often. This decreases battery life.

Common Questions

Changes in Data Caching V2

Data Caching Commands

Use downlink commands to:

• Get the number of records in a date and time range.
• Get the records in a date and time range.

All Data Caching messages use FPort 219.

Get Status

The Get Status Request finds records in the range of the timestamps (Unix Epoch) that you give. The end value must be larger than the start value.

• To get a count of all records, use 0x00000000 for the start and 0xFFFFFFFF for the end.
• To find records in a specific time window, use specific values.

Note: 0xFFFFFFFF as an end time is a special value that means "get all records". Also, 0x00000000 is a special start time.

Get Status Request (Downlink)

Get Status Response (Uplink)

The Get Status Response gives the number of records found.

Get Records

The Get Records Request has the same format as the Get Status Request. But the response contains the records found in the range. If necessary, the device sends more than one response uplink to report all of the records in the request window.

There are two opcodes. They use different time formats:

• Opcode 0x01 uses UTC time. This time does not include leap seconds, so it is 18 seconds different from GPS time.
• Opcode 0x02 uses GPS time (seconds since 1980-01-06, no leap-second offset). This opcode is available in firmware v0.136.0 and later.

Get Records Request (Downlink)

Get Records Response (Uplink)

First Record Field

Next Record Field

For opcode 0x01, the Next Record field is the same as the First Record field. For opcode 0x02, the Next Record field has this format:

The Time Offset field has two forms:

• If the MSB is 0, the field is 1 byte. Time = previous time + offset × 10 seconds.
• If the MSB is 1, the field is 2 bytes. Time = previous time + (offset & 0x7FFF) × 10 seconds.

Example: Get All Records

This example requests all available records:

• The first record has the timestamp 1 January 2023 at 00:00. It is a temperature report of 23.0 C.
• The second record has the timestamp 2 January 2023 at 00:00. It is a temperature report of 22.9 C.
• The full report does not fit in one uplink. The device sends more uplinks until it reports all records.

The number of records in one uplink changes with the size of the records. It also changes with the maximum uplink size when the device sends the uplink.

Example: Decoded V2 Payload

This decoded payload has one report:

{
  "data": {
    "cache_records": [
      {
        "data": {
          "payload_type": "sensor_data",
          "temperature": 23.8
        },
        "timestamp": "2026-07-26T23:00:52Z"
      }
    ],
    "payload_type": "cache_records"
  }
}

This decoded payload has more than one report from a cached backlog. The example shows the first 3 of 15 records:

{
  "data": {
    "cache_records": [
      { "data": { "payload_type": "sensor_data", "temperature": 25 },   "timestamp": "2026-07-23T00:27:35Z" },
      { "data": { "payload_type": "sensor_data", "temperature": 25.2 }, "timestamp": "2026-07-23T00:35:35Z" },
      { "data": { "payload_type": "sensor_data", "temperature": 24.8 }, "timestamp": "2026-07-23T00:50:35Z" }
    ],
    "payload_type": "cache_records"
  }
}

Battery Depassivation

The battery looks like a standard alkaline AA battery. But the device uses a high-capacity, long-life, lithium thionyl chloride battery. The property that gives the battery a long shelf life can cause problems at first use. This condition is passivation. Passivation is a thin film that grows around the anode. The film is an insulator that stops the battery from self-discharge.

If the device detects a high level of passivation, the device starts a 2-minute depassivation cycle. During this cycle, the LED gives a slow orange blink. At the end of the depassivation cycle, the device restarts and joins the network again.

What's Next?

• MQPS and Other Data Reporting - Packet format, sensor readings, configuration, reset reasons, and join reasons.
• LoRaWAN Commands and Responses - Device status and device version requests and responses.
• DFU Instructions - Update the device firmware with nRF Connect for Mobile.