The Edge devices are able to send and receive small messages using the messaging feature.
Within the Smart Parks stack this features is used to send and receive messages in EarthRanger. For this to work there needs to be a proper integration between the LoRaWAN server and the EarthRanger messaging API.
By default Bluetooth advertisement is enabled. To disable, set setting "ble_adv" with id 0x08 to false. Interval of the advertisement is governed by the "ble_advertisement_interval" setting with id 0x18 and with default value of 500 milliseconds.
When you disable the Bluetooth advertisement, you are no longer able to connect to the device over Bluetooth! So only do this when you have a stable and working LoRaWAN connection which allows to re-enable the Bluetooth advertisement if needed.
The device will advertise in the following format:
Device can be protected with password that it set by "device_pin" setting with id 0x2A. It must be 4 bytes long. Only digits 0-9 are supported. If pin is set to: 0000 - default setting, pin is disabled. User can observe in the app if device is protected with pin, by looking for lock-key symbol, next to the device name.
Tracker needs to obtain pin 5 seconds after the Bluetooth connection is established, otherwise it will disconnect. If pin is forgotten or unknown, user can unlock the device with 16 bytes long AppKey.
Besides offering Bluetooth communication, the egde devices can perform Bluetooth scanning to detect other Bluetooth devices, including other Edge devices in particular.
The BLE scanning modes or designed to work as a “contact tracing” application. For PAX (person) application, we still need to add this capability in the firmware.
The Bluetooth scan is controlled by the following settings:
To ensure the Bluetooth single scan and Bluetooth aggregated scan will be send and stored, ensure they are enabled in the “lr_send_flag" and “flash_store_flag”. With the App this can we done in the Configure data sending and storing section.
Note: The device remains discoverable when it is performing a Bluetooth scan itself.
Besides Bluetooth scanning, the egde devices can perform WiFi scanning to detect Wifi devices, including smartphones in particular.
The WiFi scan is performed by the LR1110 and has a fixed scanning duration.
The WiFi scan is controlled by the following settings:
To ensure the WiFi single scan and WiFi aggregated scan will be send and stored, ensure they are enabled in the “lr_send_flag" and “flash_store_flag”. With the App this can we done in the Configure data sending and storing section.
The WiFi scan settings are static and are currently define as:
Hence, the WiFi scan goes twice through 14 channels with max duration of 110 milliseconds per single channel scan, giving a maximum total scan duration time of 3080 milliseconds (+ 3 seconds).
Currently the LR11xx module is controlled using the so called Modem-E firmware developed by Semtech. With this we can offer standard support for the following LoRaWAN Frequency plans:
The downside of using this Modem-E firmware is that is does not offer full control of all the newer features and other Frequency plans. We are looking for ways to migrate to a new firmware that no longer uses Modem-E, but a different framework to fully utulize all the new features of the LR11xx, including additional LoRaWAN frequency plans.
The LR11xx module supports GNSS position data acquisition. The interval of when this position data is obtained is governed by the setting "lr_send_interval" with id 0x01. When this setting is set to 0, the LR11xx GNSS feature is disabled.
On each pre-defined "lr_send_interval" or when sending command "cmd_send_lr_fix" with id 0XAE, device will perform assisted GNSS scan, using latest obtained position and time, either provided by successful Ublox GPS fix or user input. To enable optimal LR GPS operation, provide latest device position and time via app when first starting to use it on a new location.
After the GNSS scan is performed, NAV message, containing scan status and position data will be send via LoRa to server to be resolved. More on the message structure can be found in subsection LR GPS Messages.
Error codes:
To successfully perform assisted GNSS scan, recent enough Almanac data needs to be provided. The almanac data is valid for up to 90 days. Latest Almanac age can be obtained with command get value, requesting value with id 0XEC. Almanac age is represented as uint16 value, nr. of days since last GPS 0 time i.e. since 7th April 2019.
If the GNSS scan results in an error 0X08, the Almanac is outdated and needs to be updated.
Due to its length, a full Almanac needs to be updated in several chunks. The total Almanac consists of 20 Bytes (Header) + 128 (number of SV) * 20 Bytes = 2580 Bytes. Using the command: "cmd_almanac_update" with id 0xB6, the user can provide parts of the Almanac data to the device either via LoRa or Bluetooth communication. The Smart Parks Connect App has a function to do all of the automatically.
Each command must be send to port 32 and must be of the form:
On received header with id 128, the firmware will perform Almanac update. The Update will take place only if provided date of the new Almanac is more recent than the already stored one.
To get more insight in the LR GPS performance, satellite data from latest scan can be obtained. Message "msg_lr_satellites" sent to port "port_lr_sat_data" contains satellite data, signal strength and other parameters. More on the message structure is written in the LR satellite data message section.
For movement and orientation detection, we are using a 3-Axis accelerometer. We have been using the different accelerometers in different device hardware versions, however we are standardizing this currently to using only the LIS2DW12.
To get a better understand of how movement and motion is detected with an accelerometer, please check this Accelerometer Basics post from SparkFun:
The LIS2DW12 has user-selectable full scales of ±2g/±4g/±8g/±16g and is capable of measuring accelerations with output data rates from 1.6 Hz to 1600 Hz.
We are using the follow low power settings:
Currently the Edge devices are taking a sample reading at each status interval
and the firmware can set to trigger a Ublox GPS reading controlled by a motion threshold and a motion duration.
The status message (port 4) reports the accelerometer readings on the X, Y and Z axis.
The interpretation of the X, Y and Z axis depends on the actual Edge device being used:
The current Edge devices are all equipped with 32 megabit of Flash memory:
With the setting flash_storage_flag
the user can control which messages will be stored in the flash memory.
The flash storage uses a FIFO (First-In-First-Out) principle. This means that once the memory is full, the oldest messages will be replaced by new messages.
We are in the process of upgrading Flash memory size per PCB. For RangerEdge PCB this is 256 megabit and for RhinoEdge PCBs this is 128 megabit.
By default a port 2 - GPS location message is 32 bytes long. When we adding it to the flash storage, a timestamp and message ID is added, making the total size 37 bytes. This means we can store 4.000.000 / 37 = 108.108 port 2 - GPS location messages.
By default a port 4 - status message is 16 bytes long. When we adding it to the flash storage, a timestamp and message ID is added, making the total size 21 bytes. This means we can store 4.000.000 / 21 = 190.476 port 4 - status messages.
The size of real-time BT-scan message depends on the number of BT devices scanned by the process. This means a Real-Time BT-scan entry can be of maximum LoRaWAN payload size, which is 52 bytes. Adding the 5 additional bytes, the total port 11 message can take up to 57 bytes of storage. This means we can store 4.000.000 / 57 = 70.175 port 11 - Real-Time BT-scan messages (when all scans are using the maximum message size). The key here is to ensure the BT scan filters are optimized to what the device is intended to scan, so that flash storage and other communication traffic is minimized.
Some of our Edge devices are equipped with an acoustic sensor. We currently have not released any features based on this sensor, but our aim is open up many new use-cases. On of the best examples here is the use of acoustics on the ElephantEdge devices. This is inspired by the Elephant Listening Project.
Most Edge devices have a magnetic switch to enable and disable the hibernation mode (sleep). This way the magnetic switch also serves as a reset/reboot function.
During various hardware revisions (version) we had to use different magnetic switch components, which has resulted in the inconvenient situation that some hardware versions require a different magnetic field orientation of the used magnet to function properly. In general we will aim to use axial (parallel to height) magnetized magnets. The following table can be used to identify what magnet works for your Edge device version:
This feature is currently under review, so please do not use this feature on devices that can not be manually reset like CollarEdge and RhinoEdge.
The hibernation mode will:
To ensure the Edge device is put into hibernation mode the cmd_set_hibernation_mode
command can be send:
32 195 0
Port 32
C3 0
wwA=
The device can be activated again by triggering the magnetic switch with a magnet.
The Edge devices have build in support for adding a plug-and-play RockBLOCK satellite module. Once this module has been properly connected to the Edge device, the satellite feature should become available for configuration.
The Edge device advertises if the satellite functionality is currently enabled or disabled in the status in byte features
(byte 15 if 0. and 1. byte are count as header), bit 1 (enabled/disabled). In the firmware, the satellite functionality is stored as the global sys_features.satellite_com
and is set false
on boot.
The user can enable or disable the satellite functionality by controlling the following setting:
"satellite_enabled": {
"id": "0x3A",
"enabled": true,
"default": true,
"min": false,
"max": true,
"length": 1,
"conversion": "bool"
}
The internal communication with the satellite module is done in the satellite_thread
, which is created only if CONFIG_SATELLITE
is selected.
Sending messages via the satellite module is governed similar to the LoRaWAN communication feature. The user can control which message type will be send via satellite using the following settings:
"sat_send_flag": {
"id": "0x39",
"enabled": true,
"default": 138,
"min": 0,
"max": 4294967295,
"length": 4,
"conversion": "uint32"
},
This setting determines if messages on port 1 to 32 will be send via satellite or not. If for a specific port the bit is set, the message type will be transferred to the satellite thread that indefinitely waits for a new command message to arrive. New messages are added to the satellite send buffer of maximum length 340 bytes. In a similar way to storing messages to the flash memory, the message is added to the buffer as:
If there is not enough space in the buffer (340 bytes), the oldest message in the buffer is removed and the new message is added.
When set correctly, the satellite send buffer is send periodically. The internal communication thread checks if the satellite buffer needs to be send. The send interval is determined by the following setting:
"satellite_send_interval": {
"id": "0x04",
"enabled": true,
"default": 3600,
"min": 0,
"max": 86400,
"length": 4,
"conversion": "uint32"
},
If the satellite module is enabled and the interval is reached, the satellite module will try to send the buffer.
When the send command is received in the satellite thread, the device checks if the send buffer is empty or not. If the satellite send buffer is empty, a standard status message is added to the buffer. The satellite module then enters into sending mode by enabling the satellite module. The message is queued and the satellite send/receive loop is entered. The number of retries is defined by the following setting:
"satellite_retry": {
"id": "0x3B",
"enabled": true,
"default": 10,
"min": 1,
"max": 15,
"length": 1,
"conversion": "uint8"
}
A delay between retries is determined at random by the formula:
In the same send/receive loop, the module also tries to receive messages, that are parsed in the same way as other messages received via LR or BT.
The current number of retries is also reported in the device status message in byte 15.
The user can initiate an immediate send of the satellite buffer by calling the command:
"cmd_send_sat_buffer": {
"id": "0xC6",
"length": 0,
"conversion": "uint8",
"value": 0
},
The Edge devices have build in support for adding a plu-and-play FenceEdge module. Once this module has been properly connected to the Edge device, the Fence monitoring feature should become available for configuration.
Edge devices have a primary power supply.
Do not confuse the primary power supply with the charging pins of the RangerEdge / FenceEdge. The charging pins can only be used in combination with selected rechargeable batteries.
RhinoEdge Cube: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
RhinoEdge Puck 34: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
RhinoEdge Puck 50: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
CollarEdge: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
RangerEdge: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
FenceEdge: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
WisentEdge: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
ElephantEdge: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
ElephantFree: Min - 2.8V, Max - 5,5V. Battery measurement will max out at 4,3V
This feature is currently in experimental state. Please report bug to the Smart Parks team.
From RangerEdge Hardware version 1.7 and Firmware version 6.0 there is support for LoRaWAN over S-band to satellite. We are testing with the following satellite, supported by Lacuna Space and Omnispace using the following satellite:
The current test setup is using The Things Network as the LoRaWAN server for delivering the LoRaWAN payloads.
Currently there is no user friendly interface available in the Smart Parks Connect App to control this feature. This will be added soon. For now you can use Actions > Management > Write custom command to control this feature.
Send regular S-Band LoRaWAN uplink:
3 32 4 44 1 0 0
3 32 4 0 0 0 0
Send single S-Band LoRaWAN uplink:
32 189 0
Keep in mind that the Smart Parks Connect App will disconnect from the RangerEdge whenever the device tries to send the S-Band LoRaWAN uplink. This is to prevent any signal disruption. You will be able to reconnect the Smart Parks Connect App to the device once the S-Band LoRaWAN uplink has been send.
The S-Band LoRaWAN uplink consists of a Status message (port 4) and a Last known position message (port 13). If the GPS of the device is turned OFF and there is no last known positions stored in the device yet, there will be no GPS information in the S-Band LoRaWANu uplink message. Please ensure the GPS interval is enabled when you want to see (recent) GPS updates.
To ensure the device does not run out of power unexpectedly, please turn OFF the S-Band LoRaWAN uplink interval after testing and if needed, also turn OFF the GPS interval if enabled.
The LoRaWAN S-Band uses a separate provisioning then the terrestrial LoRaWAN. Provisioning of the LoRaWAN S-Band is done via the following settings:
s_band_app_key
- 0x44
- 16 byte array containing AppSKey for correct message encoding.s_band_network_key
- 0x45
- 16 byte array containing NwkSKey for correct message encoding.s_band_dev_adr
- 0x46
- 4 byte array containing Device address for correct message encoding.All test devices have been provisioned with the correct credentials already.
The current firmware uses a separate LoRaWAN provisioning for the terrestrial traffic, which is configured through the regular steps in this Wiki. Note that the regular LoRaWAN messages will not show up in the same LoRaWAN application as the S-Band LoRaWAN messages.
Edge devices running firmware +v6 have support for specific Cardiac Monitoring Devices called Q (CMDQ) using the BT protocol.
This feature is currently in BETA, which means it is only used in specific projects.
The following settings are to control the CMDQ feature.
Enable/Disable CMDQ:
"cmdq_enabled": {
"id": "0x49",
"default": true,
"min": false,
"max": true,
"length": 1,
"conversion": "bool"
}
CMDQ scan duration:
"cmdq_scan_duration": {
"id": "0x4A",
"default": 10000,
"min": 1,
"max": 10000,
"length": 4,
"conversion": "uint32"
}
CMDQ search interval:
"cmdq_search_interval": {
"id": "0x4B",
"default": 180,
"min": 1,
"max": 10000,
"length": 4,
"conversion": "uint32"
}
CMDQ wait duration:
"cmdq_on_no_detection_wait_duration": {
"id": "0x4C",
"default": 1800,
"min": 1,
"max": 10000,
"length": 4,
"conversion": "uint32"
}
CMDQ mac:
"cmdq_searched_mac_address": {
"id": "0x4D",
"default": "{0xD8,0x10,0x68,0xAC,0xDA,0xE4}",
"min": "{0x00,0x00,0x00,0x00,0x00,0x00}",
"max": "{0x00,0x00,0x00,0x00,0x00,0x00}",
"length": 6,
"conversion": "byte_array"
}
CMDQ reporting interval:
"cmdq_reporting_interval": {
"id": "0x4E",
"default": 30,
"min": 1,
"max": 10000,
"length": 4,
"conversion": "uint32"
}