https://www.lairdconnect.com/wireless-modules/lorawan-
solutions
13
© Copyright 2019 Laird. All Rights Reserved
Americas: +1-800-492-2320
Europe: +44-1628-858-940
Hong Kong: +852 2923 0610
If the Laird packet format is configured and the sensor fails to successfully transmit data to the network server, this data is
logged to FLASH. Each backlog log or alarm includes the time that reading was taken. Separate areas in FLASH are
maintained to store alarm and normal (non-alarm) data. During data retrieval, the alarm section is prioritized over the non-
alarm data. Each section can store 4096 records.
The backlog data can be retrieved via the LoRa interface or the Bluetooth interface. Note that in some situations, such as the
lowest data rate in the US or AS regions, it may not be practical to retrieve backlog data over LoRa due to bandwidth
limitations.
There are separate commands for retrieving the backlogs in FIFO or LIFO mode. With FIFO, the oldest log is retrieved first.
With LIFO the latest log is retrieved first. Both commands are identical as described in the sections below.
Once you start retrieving logs using a certain mode, you
must
clear ALL logs using that mode or reformat (erase all of the logs)
the flash memory once you retrieve all the logs you require using that mode. Using the LIFO option means there can be gaps
of already retrieved logs in flash. The LIFO option can handle this; FIFO cannot.
Note
: The backlog feature only functions if the sensor has received a timestamp from the server. In situations where the
timestamp is not available, any logs that are not successfully acknowledged by the server are lost.
The backoff period is one of the LoRa messages that you can send to the sensor from the server (see the
RS1xx LoRa
Protocol Guide
). Because retrieving the backlog may consume a large
percentage of the bandwidth, it may be wise to make use of the backoff message. This message can be used to stop the
sensor from sending data for a period of time, thus opening more bandwidth for the sensor. While a unit is in the backoff state,
it continues to read the sensor, but it stores its data to FLASH. The backoff period could be assigned to the sensor from which
the backlog is extracted, other sensors in the network, or both, depending on the application.
Normally the sensor attempts to package up to six backlog readings into a single backlog uplink message. This keeps the total
number of bytes in the packet less than 51 bytes, which is the limiting factor in the EU.
See
for details. Only 11 payload bytes are available when operating at DR0 in the 902-928 (NA) band. At
this data rate, the sensor only sends one backlog message at a time as this is all the data that can be fit into an 11-byte
message.
Measuring humidity accurately in certain circumstances can be difficult. Temperature swings, dew points, and other factors
can lead to condensation on the sensor, leading to inaccurate humidity readings. To combat this, there is a heating element on
the sensor itself which can be turned on to burn off this condensation and restore the sensor to proper operation. This is
activated by means of a downlink command, with the heater being switched on as soon as the command is received. See the
RS1xx LoRa Protocol document for more information on this command.
This allows the API server (see
) to implement an algorithm that is appropriate for the sensor environment while
minimizing the power used in order to maximize battery life. Refer to the
Control Register.
The read period defines how often the sensor is read. For example, for a setting of 60, the sensor is read every 60 seconds.
The aggregate number is used to aggregate or bundle multiple sensor readings into a single RF packet. For example, with an
aggregate number of two and a sensor read period of 60, a RF message is sent every (60 seconds x 2) 120 seconds.
Obviously setting the aggregate count has a big effect on the battery life of the device; the less the device talks, the longer the
batteries will last.
Содержание 455-00060
Страница 1: ...A Version 1 7 ...
