1 of 100

OpenCollar

OpenCollar Dashboard

OpenCollar solutions are modular trackers built to be used in most advanced nature conservation use-cases, pushing the technology further and enabling new applications. Overall design is based on a single electronics solution and single firmware solution, which are then configured into full or partial feature implementations. The design choices are to be made such that simplicity is favored over complexity to allow for a minimal barrier to entry for forking or modifications.

Priorities

Use cases

Definition and description of all OpenCollar tracker use cases

1. The Basic animal tracking device

The device is built as a global tracker for wild-life animals. It is attached to the animal that moves in constricted space, such as national parks, with LoRaWAN network coverage. The device can track an animal using low power passive GPS data scanning with an LR1110 solution from Semtech. Raw GPS data is sent to the Semtech proprietary cloud solution, using the LoRaWAN network, where GPS position is calculated. In addition to LoRaWAN data collection and configuration, the device also has Bluetooth LE connectivity so it can have the same features for users that are near the device. In addition to that device firmware can also be upgraded over Bluetooth, while this can not be done using LoRaWAN.

Device Settings

Device configuration settings

Device settings are divided into three layers. This is enabling easier user configuration and still providing full control over the device.

Device profile Settings

This is the highest level of device settings available to the user. Here the user can define the purpose of the tracker and all the settings for the device will be generated based on the device profile and several mail parameters. This can be done from a Web/Mobile application and then the configuration can be uploaded with a precompiled binary image when manufacturing, over the Bluetooth, when deploying, and over LoRa, remotely when the device is in the field. An example of the application user interface is in the picture below. The user can change High-Level settings of each profile by expanding the advanced configuration in the user application if it is something that does not suit its needs.

L1: Device High-Level Settings

Shadow settings in the second level L2 are changed by the Device profile and device profile setting. Every Device profile has the same set of High-Level settings and has its own default values that are stored on the device in the separate default configuration. This config from the default configuration will be overwritten if the device shadow config has value. This layer has a maximum of 30 settings IDs.

L2: Device Low-Level Settings

All the settings in the L2 are in relation to the physical device. Settings in the second level L2 are changed by the L1 level setting, when user change the device profile, or manually by the manufacturer of the devices.

All the settings currently are just for demonstration, the real need to be determined

when sending LoRa -> ID, LEN, VAL
decoder TTN same as in the BLE app

Milestones

Technology

Hardware

Manufacturing

Firmware - Edge tracker

Instructions

Main screens

Main screens are all screens that can be reached without actually connecting to a tracker. User can navigate between them by pressing the menu icon in the top left corner or swiping right from the left side of the screen.

These screens are:

Device list
Demo devices
Application settings
About

Device list

This is the first screen user will see when launching the aplication from stopped state. It provides the ability to use BLE to scan for all suitable devices that are in close proximity. BLE scan is started automatically when user navigates to this screen. Scan can be started or stopped by touching the text in the top right.

Below the header is the list of devices that were found by the phone. The list is updated in real time (new devices are added and data for existing ones is updated), application does this every 3 seconds. It can also be refreshed (cleared) with swipping down from the top of the list, which also restarts the BLE scan. Application will stop scanning after 60 seconds and user needs to restart the scan if he wants to continue searching for devices.

App displays only those devices that advertise a specific service (by checking it's UUID) and match user defined filters for name and MAC address. When there aren't any devices to be seen, text displaying information about filters is shown (if any user defined ones are currently used or not).

In order to be seen, device needs to advertise a service with the following UUID: 84AA6074-528A-8B86-D34C-B71D1DDC538D. This additional filter was added to the app for security and performance reasons and is hardcoded into the app.

Name and MAC filters can be edited or removed in application settings. If name filters are defined, the device's name needs to contain any of the string values. If MAC filters are defined, device's MAC address needs to match any of the string values.

Each device in the list is presented by an icon of an animal or an asset, showing which type of a device it is. In the middle is the device's name and MAC address, if there is a lock next to the name, that device is locked and user will require to enter PIN when connecting to it. On the right is signal strength (RSSI) value with a text below indicating to the user if it's possible or not possible to connect to this device. App determines this by using hysteresis on the RSSI value with set tresholds, which limits failing connection attempts because of poor signal quality. The limit is set to -80 dBm, with a 5 dBm window.

Below basic information is the status data that is being advertised, which gives the user a quick overview of device's state. Available values are: battery state and voltage, hardware version, firmware version, accelerometer data, temperature and error information of main functions, such as LoRa, GPS or flash chips states.

Demo devices

This feature has not yet been implemented. Currently, it just lists all available tracker types.

It will offer ability to use and test all app features that are otherwise available only if the user has an actual tracker available. There will be a list of dummy trackers of all types with fake data. User will be able to tap on one and the application will show all the screens in the same way as if it's connected to a real device with all fields filled with sample data. This way user will see which features each tracker type provides and which ones can be changed.

Application settings

User can change various parameters of the application. Settings are encoded as a JSON object, offering ability to import/export them from/to a file. User can use a reset button to return all settings to their default values.

Currently available settings are described below.

Scan results filtering

Results returned from BLE scan can be filtered by name or MAC address. Multiple values can be added for each of them, they need to be separated with commas. If no values are written in names or MACs array fields, all devices will be returned, same as if device_filter property is removed. When scan returns the result (found a device), the name filter is checked first. If result doesn't match any name filters, MAC address is checked.

About

Here one can read basic description about the application and Open Collar collaboration. It also features Smart Parks and IRNAS as the creators of it.

Interaction with the tracker

Communicating with the device

Establishing the connection consists of the following steps:

Application sends the request to connect to the device, which responds with connection response.
Negotiation of MTU (maximum transmission unit) happens next. Both entities need to agree on it, application requests it to be 250 bytes and device should accept it.
Connection has been established and application proceeds to discover available services and characteristics.
Exchange of connection ("keep alive") data is started. Phone and device will send it periodically to each other. Application is monitoring this and triggers an event if device disconnects in order to perform needed actions.
PIN (or LoRa App key) is sent, if device requires it. It needs to be done in 5 seconds after the connection is established, in order to not get disconnected from the device. Device will not send any data until the correct key is provided.
Application subscribes to receiving notifications from device. This is the only way to receive data from the device. Data cannot be directly read, because the service used by device implements only notification characteristic.
Periodical polling of status data is started. Application sends two commands to request status and last location and device responds with messages containing latest information.

Application terminates pending connection after 5 seconds and retries 4 times. If it's still unable to connect, it will stop, display an error message to the user and restart BLE scan.

In order to disconnect from the device, the application does the following:

It checks and stops any timeout timers that are still running. These timers are used through the app to stop waiting for specific data after a defined amout of time has passed. Some of them may be running and need to be cleared.
It stops monitoring for the connection state changes. Connection data will stop and the event to handle this data disruption should not be triggered anymore, since disconnection was triggered intentionally.
It proceeds to unsubscribe from receiving notifications, data should not be received from the device anymore.

Data transfer

Data types

Application can send to the device a command or a setting.

Commands are used to trigger a specific operation that should run once and immediatelly. From the application only some of them could be triggered, since some of them are not meant to be used by the user. Application implements commands such as requesting status or last position, triggering a reboot, setting initial position and time (this data is added to the request) and getting a current value of a specific setting (specified also in the request).

Sending a setting is used to directly update it on the device. This is a separate data type, because it doesn't trigger any operation on the device, but it just substitutes the existing value. Device will then use the new value next time it performs an operation that uses it.

Device sends to the application a message, value or a setting.

Message is received as a response to the command and will provide the requested data that can be then parsed to an object. Messages are: status data, last position, Ublox GPS data, etc. There is also a special message named confirm, which is returned to the application after those commands that don't trigger any message or other type of a reply being sent.

Value is a data type, that provides device's certain data information, such as current MCU temperature, number of messages in flash, timestamp of the last succesfull GPS fix, etc. Any available value can be requested by sending a Send single value command with a provided value identifier.

Setting is received by the application after it was requested by Send single setting command. This is used to get settings that need to be displayed in the currently active screen in order for the user to inspect them.

Data transfer protocol

This is described here:

Protocol was designed in a way, that it supports transferring the same data over two different network types: BLE and LoRa. This way we can have the same encoding and decoding procedures in all parts of the system, which consists of the device, LoRaWAN server and this application. There are however some implementation differences between the server and application, but from the device's perspective, data received from or sent to either of those looks exactly the same.

Data validation checks

Data parsing using PILV protocol implements various checks in the application for validation. This is done by putting received data through a series of checks. Additional checks are also done on the device.

These checks use a specific file (settings.json) that contains definitions for all settings, commands, values and messages that device uses. This file is aquired from the firmware release, meaning that a release of the application will match it with a specific release of the firmware. This file also includes this version information, for reference. For each parameter (which is any of the defined data types), the following is defined (note that some parameters are defined only for specific parameters):

ID of the parameter
if is enabled (defined only for values)
default value (defined only for settings and values)

When data is received, application first checks if headers are valid, these are port, ID and length bytes. Then it attempts to decode it acording to the conversion defined in settings file for this parameter ID. If data is of numeric conversion type, it is also checked if it's between minimum and maximum valid values.

When data is being sent, application checks if provided command name actually exists in the settings file, then it checks the defined length, which determines if there need to be any values appended, which are then also checked.

Handling data transfer failures

Application implements timeouts for all features that require waiting for data, which was requested automatically, by the application itself or manually, by the user. This is used to avoid waiting for messages that will never arrive due to connection or communication disruptions. But also to inform the user that data did not arrive in defined time frame and to give him an option to retry getting it again or some other option to handle it.

Connected screens

Connected screens can be reached by tapping on a tracker on the Device List screen, which establishes the connection and displays the Tracker information screen. Connecting takes a few seconds, the application displays an overlay with a spinner to inform the user that it is in progress and he needs to wait. Other connected screens can be reached by pressing the buttons in bottom navigation bar with an exception for DFU, for which the button in located in the navigation header on the right.

These screens are:

Tracker information
Tracker configuration
- Interval configuration
- PIN configuration
- GPS configuration
WiFi and BLE scanning
Download logs
Firmware upgrade (DFU)

Tracker information

This screens give the user an insight to currently connected device's status and offers him to send various commands.

On the top is device status. It displays all the information that the tracker is also advertising, which is: battery state and voltage, hardware version, firmware version, accelerometer data, temperature and error information of main functions, such as LoRa, GPS or flash chips states. Besides that, it gives some additional data:

uptime in hours (since boot)
number of reboots
number of LoRa GPS satellites that it sees

Second element is the last known position where location data from the last successful GPS fix is presented. Labels show latitude and longitude in degrees, altitude in meters and timestamp written in yyyy-mm-dd hh:mm:ss format. Below the labels is clickable text, offering the user to open Google Maps application and show the location as a marker on the map, which gives the user a simple way to visualise this position data.

Device status and last location are periodically refreshed, every 10 seconds. If user wants to get new data immediatelly, he can swipe down from the top of the screen and new data will be immediately fetched from the device.

Third element are device commands, buttons for performing various one time operations. User can click on a button and device will execute it immediately. Currently available commands are:

Send status to LP1 (Device will send its status over LoRa network to the server)
Send raw LP1 GPS data to LP1 (Device will send nonparsed GPS data containing all the details about the current LoRa GPS state over LoRa network to the server)
Get Ublox GPS fix (Device will start to search for GPS fix using Ublox and a popup window will appear with results - described below)

Last element contains two text fields where user can write a custom command and rename this device.

Application supports getting and changing all settings that the user will require, but for developers and administrators it comes very handy to be able to send a command or write a value that is not yet supported by the application. This is what custom command field is for. Data that the developer is sending needs to be in raw format and follow the protocol PILV as any other data that is being transfered. This protocol is described in the next chapter. Raw format means, that data is written as a number of each byte, with spaces in between. Numbers can be in decimal or hexadecimal format (with a prefix 0x).

More information on writing manual commands can be found here:

Devices are preprogrammed with a default name: SPXXXXX. It consists of a prefix (SP), which means SmartParks, and six characters long serial number (XXXXXX), consisting of digits and letters. The name can be changed by using this rename field, the device supports all ASCII characters, excluding control characters. The name can be a maximum of 8 characters long and cannot be empty.

This popup is shown to the user on any connected screen. It appears after device finishes searching for a GPS fix using its Ublox chip and sends data. Here user can see all the details about the operation of the GPS, not just an actual position (latitude and longitude), which helps him to tune parameters in order to get better and faster fixes. Data has the following parameters:

Latitude and longitude (Acquired position in degrees, if no fix was acquired these will be zero)
Altitude (Acquired distance between sea level and the current position in meters, this will also be zero if no fix was acquired)
Hot and cold retry (Number of retries to get a fix of both types of GPS start modes - hot and cold)

Tracker configuration

This screen serves as a menu for all configuration subscreens. Application offers the user to change many tracker's settings, which means they could not be fitted on a single screen. They have been divided into 4 subscreens, grouped by their purpose. Timing related ones are displayed on Interval configuration screen, there is a separate screen for security (PIN) related settings and two for specific connection systems, GPS and LoRa.

Application loads settings when the user navigates to one of the configuration screens, which means only those that are on the selected screen are loaded. On each screen, there is a text informing the user about the current status of loading or saving values, when this is executing, a spinner appears, giving the user a visual element showing that something is in progress and he needs to wait. When the application loads values, it first sets all of them to unknown and when actual data for a value is received, it substitutes the unknown. This way the user knows if a value was not received from the device or parsed successfully and that received ones are actually the same as on the device.

Interval configuration

Here user can view and change settings that define how frequently some operation will happen. Configurable intervals are presented in the table below.

Setting name

Description

Dropdown values

Screen consists of dropdown menus for each interval. When user select the desired value, it immediatelly gets sent to the device. This means that there is no save or send button required. There is however, reload intervals button, located below the dropdown menus, which will refresh data shown in the app with device's settings.

PIN configuration

Here user can see and edit the device's PIN. The code is hidden with symbols **** displayed instead and user needs to press a button to show it. By default, the device won't have a PIN set and the code displayed is going to be 0000, which means that security is disabled and the code will not be asked when connecting to it.

To change it, a user needs to write new numbers to the field and press the Update PIN button. The code needs to be exactly four digits long. If a user wants to disable authentication with the PIN code it should write 0000.

This feature was added to device's firmware in one of the later releases, which means it can't be used on a device which has an old firmware installed, specifically older than v1.6. Application detects this and doesn't render the fields for PIN configuration, but instead displays to the user a message saying that he needs to update device's firmware to a newer version.

GPS configuration

All GPS settings related to Ublox chip are presented here. They are grouped into two categories: fix intervals and fix settings. When user sets all settings to desired values, it needs to press Update configuration button. There is also a reload settings button, which will get all values from the device.

With fix intervals user sets how frequently device will search for a fix. This can be set by a dropdown menu, its available values are: off, 1 min, 15 mins, 1 hour, 2 hours and 4 hours. Application allows the user to use a single interval all the time or to have two different ones, each being used for 12 hours. Two interval configuration can be enabled by ticking a box. When this is enabled, dropdown menu for second interval (with the same values as above) becomes editable, together with a dropdown where user can set the starting time of the first interval (available options are all hours between midnight and noon). Since both intervals are used for equal amount of time (12 hours), setting the start of the second interval is not needed, it's calculated automatically from the first one.

With fix settings user configures other fix related settings. These include changing timeouts and number of retries for both types of fixes, choosing a backoff factor and enabling active tracking.

There are four text fields, two for cold and two for hot fix configuration. Fields provide an option to write number of retries and fix timeout in seconds. Application checks if written values are valid, lowest possible number for both types is 1, highest number for retry fields is 255 and for timeout fields is 600 seconds.

Next element is a dropdown menu for specifying backoff factor, with these options: disabled, 1.5 and 2. This setting specifies what should device do when it fails to get GPS cold fix in specified number of retries. If backoff is disabled, device will continue to search for a fix as specified by the interval value. If this is enabled, device will multiply the set interval by a factor and only search for a fix then.

Below is a check box for enabling or disabling active tracking. If it's enabled, it means that the device has permanently turned on Ublox chip and is constantly searching for a fix. If it's disabled it means that device will turn on Ublox chip only on specified intervals or when it's requested by the user with a command Get Ublox GPS fix.

LoRa configuration

This subscreen has a slightly different name in the app: LP1 configuration. One could also notice that LP1 is used instead of LoRa everywhere in the application. This is due to legal reasons, prohibiting us to use the name LoRa.

Application allows configuring the region and data rate of the LoRa chip. Region configuration is required due to differences in available radio frequencies that can be used by LoRa network, which varies from country to country. Changing data rate gives user an option to fine tune LoRa operations in regards to his specific needs for amount of data that is being trasfered and device's power consumption. Both settings have a dropdown menu, currently available options are:

Region: EU and US
Data rate: 0, 1, 2, 3, 4, 5 and 6

Below these settings are fields for getting and setting authentication keys, which the device needs in order to be able to communicate with a LoRa server. There are three fields:

Device EUI (Has a length of 8 bytes, it's predefined and can only be read from the device. Next to it it's a button, that copies it to phone's clipboard, easing the process of copying it to other applications used for registration of the device)
App EUI (Also has a length of 8 bytes, but it's writable. User needs to get it from a LoRa server and write it when activating the device)
App Key (Has a length of 16 bytes, it's writable. This is device's unique authentication key, user also needs to get it from a server and write it to the device)

WiFi and BLE scanning

Devices also have an ability to scan for nearby WiFi and BLE devices. User can request both of these by tapping on one of the buttons and device will return the results, which can be seen here. Note that BLE scan can't be run when the phone has connection established, device will instead return results from the last scan performed before user connected to it.

Each result contains the following data:

last three bytes of the MAC address
human readable timestamp (showing when this device was last seen)
counter for how many times this device was seen on scan

Download logs

Device saved various information to its storage, these messages are called logs. Logs can be downloaded to the phone using this screen. User can download all or specific logs and clear all of them from the device. The last element shows the status of this operation with a spinner to indicate when downloading is in progress. Information about the size of downloaded logs in bytes is also presented, which updates in real time.

Process of downloading logs is described here:

Below is an example of a few parsed logs from an actual device.

Firmware upgrade (DFU)

One of the core features of this application is to enable upgradability of device's firmware, which can be done on this screen. Application offers to get the payload from two different sources: phone storage (Upgrade from phone storage button) and Memfault service (Upgrade from Memfault server button).

Selecting to load it from phone storage opens document picker where user can select a file containing the firmware upgrade payload. Popup then appears with display of selected file where user needs to confirm that he is sure to start the DFU process.
Tapping on Memfault button downloads and start the DFU automatically. Application waits 15 seconds for server to return data, if it's not returned the process is stopped and fail message is presented to the user.

Below the buttons, current state is shown together with status of the upgrade and its progress percentage. State tells the user if the application is in idle, DFU is in progress, has completed succesfully or has failed. Progress is used to show how much of the payload has been uploaded to the device. Status shows in which step the DFU is, all possible values are described below:

Upload - payload is being uploaded to the device
Test - device is testing if the payload was succesfully uploaded and stored as an image
Validate - device is validating the integrity of a stored image

When the upgrade is in progress, a user needs to wait on this screen. If he wants to go to any other screen by pressing the back button, DFU needs to be aborted, and a warning popup is presented to the user where he needs to confirm this. There is also a message informing the user not to leave the app because it could happen that the upgrade would fail to finish.

More information about the process of checking the loaded file, downloading the payload from memfault and actually performing the upgrade are available in the following chapter Upgrading tracker firmware.

Operation manual

Functionality description of OpenCollar Edge trackers.

Turn ON / reboot

Upon providing power or rebooting Edge tracker, all subsystems will be initialised. Tracker will indicate turning on by fast blinking LED light 5-times. Tracker operation consist of several subsystems:

BT communication
WiFi scan
External flash
GPS module
Sensors
Battery and charging

Functionality and predicted operation of each sub-sytem will be described in following sub-sections.

LED light

Visual LED light is added to most of the Edge trackers, RhinoPucks and RhinoCubes beeing an exception.

For HW versions < 1.4 of the RangerEdge boards (RangerEdge tracker, ElephantEdge tracker and WisentEdge tracker), only RED LED is present on the board. On the HW 1.4 RGB LED is available. Below are described visual aids for the tracker. In the case of HW <1.4 all colors are RED.

Upon turning it on tracker blinks once with all three colors in the order RED-GREEN-BLUE
When initialization process is completed, tracker will blink RED twice
When connected via BT app, tracker is going to blink 5x BLUE

BT communication

Upon turning on, device will initiate BT communication and BT advertising. BT communication will be active, unless BT module or whole device will go into the hibernation mode due to critical battery. More on power modes operation can be found in the section (Operation modes).

BT advertisement

By default BT advertisement is enabled. To disable, set setting "ble_adv" with id 0x08 to false. Interval of advertisement is governed by "ble_advertisement_interval" setting with id 0x18, with default value of 500 ms.

Device will advertise status in the following format:

Type: manufacturer data (0xFF) of length 16 bytes:
- byte 0-1: BT manufacturer data 0X0A61
- byte 2-15: status message (see section ...)

BT security

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 BT connection is established, otherwise it will disconnect. If pin is forgotten or unknown, user can unlock the device with 16 bytes long AppKey.

BT communication

User can communicate with the device via BT app. Se app manual on more information how to use the app.

If communication port is not active for more than a time period defined by setting "ble_auto_disconnect" with id 0X1F and default setting of 10 minutes, device will automatically disconnect to prevent battery drainage.

BT scan

Besides offering BT communication, device can perform BT scan to detect other BT devices, other Edge trackers in particular.

BT scan is governed by the following settings:

"ble_scan_interval" with id 0x1C: period in seconds on which BT scan is performed - can be sett in the App. Depending on set flags for , real time scan message can be send to LoRa or store to flash.
"ble_scan_aggregated_interval" with id 0X1D: period in seconds on which aggregated BT scan data is send via LR/stored to flash - can be sett in the App. Depending on set flags for , real time scan message can be send to LoRa or store to flash.

To disable BT scan, set both "ble_scan_interval" and "ble_scan_send_interval" to 0.

BT scan data

Single scan results in data of the format: "msg_ble_scan" with id: 0XFA. Data is stored to flash and/or send via LoRaWAN, based on. More on messages structure and send/store flags can be found under .

BT aggregated scan data

Each individual scan result is added to aggregated data structure of the format: "msg_ble_scan_aggregated" with id: 0XF9. On specified interval, message is stored to flash and/or send via LoRaWAN, based on . More on messages structure and send/store flags can be found under .

LoRa communication

Upon turning on the device of reboot, LR module will initialise. Modem-E FW is used on the lr1110 module. LR communication is active in all operation modes besides hibernation (more in Operation modes section).

Operation parameters

The following settings control LR operation:

"lr_adr" with id 0X0E - set ADR profile. For correct setting refer to lora communication protocol manuals.
"lr_region" with id 0X0F - set (1 - EU, 3 - US, look at lora communication protocol manuals for other values).
"app_key" with id 0X10 - 16 bytes app key, set during the provisioning procedure or later on in app or via user command.

Join procedure

Upon successful initialisation of lr1110 module, join procedure will start at first attempt to send message or when sending messages the port with active lr_join_flag (see definition above), provided module is not joined yet. By default settings, only sending status message to port 4 will start joining procedure:

If lr module is successfully initialised and FW attempts to send LoRa message, module will check if joined. If not joining sequence will start.
If EU region is set, a single join attempt per sent message will be initiated.
Due to differences in supported channels, lr module will attempt to join on a randomly selected channel in the case of the selected US region. Therefore 10 automatic re-tries are enabled for US region, attempting to join on the correct channel. More on the joining procedure in the US band can be found .

Defined by lr_confirm_flag, messages to some ports are send as "confirmed" - waiting for the server response. If message is sent as "confirmed", counter will count all attempts, where confirmation was not received. If counter reaches lr_max_confirm_fail, re-join procedure will start. NOT active in latest FW version (1.6)!

Sending and receiving messages

"lr_send_flag" with id 0X0C - uint32 value, where each bit represents flag for respective lora send port. If bit is set to 1, LR module will send generated message via LoRa. If set to 0, device will not send message. More about message and port specifications can be found in Messages subsection.

Each time message is send, lr module will wit for downlink messages and parse them. To learn more about device communication and user commands, refer to .

Message length

Maximum message length is defined by the ADR profile setting and chosen region. To see different ADR options refer to . In particular, for the EU region ADR setting 0 - 2 corresponds to maximum payload length of 51 bytes, while in the US region ADR setting 0 gives maximum payload of 11 bytes, ADR setting 1 corresponds to 53 bytes and ADR 2 to 125 bytes.

Standard procedure for changing ADR setting can be used, as described in the .

Region

Set region affect several region-based settings and operational differences. Difference in join procedure is described in the , while differences in max payload length are outlined in the . For all regional differences refer to .

To change region, set different value to the "lr_region" setting with id 0X0F - set (1 for EU and 3 for US). Keep in mind lr module needs to be rebooted, before new region will be set! To reboot lr module use "cmd_reset_lr" (send B9 00 to port 32).

LR1110 GPS

LR1110 module supports GPS acquisition. Interval defining period when position data is obtained is governed by "lr_send_interval" with id 0X01. When set to 0, GPS 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 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 .

If error code 0X07 is returned, device did not find any satellite during GNSS scan. Error code 0X08 indicates Almanac is to old.

Almanac update

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 GNSS scan results in error 0X08, Almanac needs to be updated.

Due to its length, full Almanac needs to be updated in several chunks. Total Almanac consists of 20 Bytes (Header) +128 (number of SV) * 20 Bytes =2580 Bytes. Using the command: "cmd_almanac_update" with ID 0XB6 user can provide parts of Almanac data to device either via LoRa or BT communication.

Each command must be send to port 32 and must be of the form:

byte 0: cmdID 0XB6
byte 1: length of the cmd
byte 2-21: Almanac (id is obtained from first byte, as represents satellite id and 128 - header).

On received header with ID 128, FW will update Almanac. Update will take place only if provided date of the new Almanac is more recent than already stored one.

Satellite data

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 section.

LR1110 WiFi scan

LR1110 module can perform WiFi scan and store obtained data for analysis or send them as LoRa message.

WiFi scan is governed by the following settings:

"wifi_scan_interval" with id 0x19: period in seconds on which WiFi scan is performed - can be sett in the App. Depending on set flags for , real time scan message can be send to LoRa or store to flash.
"wifi_scan_aggregated_interval" with id 0X1A: period in seconds on which aggregated wifi scan data is send via LR/stored to flash - can be sett in the App. Depending on set flags for , real time scan message can be send to LoRa or store to flash.

To disable WiFi scan, set both "wifi_scan_interval" and "wifi_scan_aggregated_interval" to 0.

WiFi scan data

Single scan results in data of the format: "msg_wifi_scan" with id: 0XF8. Data is stored to flash and/or send via LoRaWAN, based on. More on messages structure and send/store flags can be found under .

WiFi aggregated scan data

Each individual scan result is added to aggregated data structure of the format: "msg_wifi_scan_aggregated" with id: 0XF7. On specified interval, message is stored to flash and/or send via LoRaWAN, based on . More on messages structure and send/store flags can be found under .

User messages

User messaging via LoRaWAN is supported. User can send message of length of up to 45 bytes via app.

Sending message from app

Message is send from app via command: .

Send message to device to be send via LR on the command port.

Up to 45 bytes are supported.

Tracker will send message on the next interval to LR.

Sending message from device to server

Up to 5 messages, stored in the local buffer, are sent to LoRa server. Single message can be send multiple times, to avoid data loss, defined by lr_messaging_retry_countsetting with id 0x32. Repeated send is separated by lr_messaging_retry_intervalsetting (id 0x31) in seconds.

Format of the message is and is send to the .

Sending message from server to device

Message can be send to device from LR server. Device will store up to 5 messages to be red by the user from app. If device is rebooted all messages are lost.

Format of the message is and must be send to the .

Message example

If using TTN web console interface, to send the message ABCDE, do the following:

Go to End device and open the desired device
Click on tabs Messaging -> downlink
Set FPort: 28 and payload type to bytes

Reading messages from device via app

Incoming messages, stored on device, can be red by the user via app. Messages are send in the form of

UBLOX GPS

Ublox GPS module is present on all tracker HW types. Basic operation: tracker tries to obtain GPS fix on defined interval time and send in via LoRaWAN as message to port 2. If sending extra data is supported, governed by setting: "gps_sat_data" with id: 0x0A (turn this on: 0A 01 01 or turn this off: 0A 01 00 to port 3) also additional satellite data is send to port 9.

RF scanning

On some HW types, RangerEdge v1.4 in particular, RF scanning board can be attached and RF scans performed.

Messages

During operation, device will produce several messages in various modules. Each message type is associated with specific port. The following ports and message types are supported:

1
"port_ublox_gps": 2,
"port_settings": 3,

Sending and storing messages

Messages associated with each individual port can be either stored to flash and/or send via LoRaWAN. This can be controlled with two individual settings:

"lr_send_flag" ID: 0x0C

32 bit integer, where each bit determines if messages associated with port on corresponding bit is or is not send via LoRaWAN, when generated.

"flash_store_flag ID: 0X0D

32 bit integer, where each bit determines if messages associated with port on corresponding bit is or is not stored to flash, when generated.

Port LR GPS: 1

Message of type "msg_gnss" with id 0XF1 contains NVS message, obtained when LR GNSS scan is performed. Message is of the form:

byte 0: message ID - 0XF1
byte 1: message length
byte 2 - end: NAV payload

Port UBLOX GPS

Message of type

Port status: 4

Messages of type "msg_status" with id 0XF4 is send to port 4. Message contains various status data of the form below.

Status message has changed due to new requirements and has two versions. Starting with firmware v1.11 trackers will have status version 2. Mobile application supports both status versions.

Byte number

V1 (fw < v1.11)

V2 (fw >= v1.11)

Port LR satellite data: 5

Messages of type "msg_lr_satellites" with id 0XF5 are sent to port 5. Message contains satellite data for satellites used in the latest GNSS scan. Message is of the form:

byte 0: message ID - 0XF5
byte 1: message length
byte 2: nr. of satellites

Port ble scan aggregated: 7

Messages of type "msg_ble_scan_aggregated" with ID 0XF9 are send to port 7. Message contains aggregated ble scan data. Only top 5 contacts, sorted by RSSI are send via LR and/or stored to flash. Message is of the form:

byte 0: message ID - 0XF9
byte 1: message length
byte 2: nr. of unique BT scan results during this period (can included number of results in the message!)

Port WiFi scan: 10

Messages of type "msg_wifi_scan" with id 0XF8 are sent to port 10. Message contains data of single wifi scan. When we have more results then can be fitted in single message length, multiple messages are formed. Only first message is send via LR, but multiple can be stored in flash. Ressults are orderd by rssi. Message is of the form:

byte 0: message ID - 0XF8
byte 1: message length
byte 2-5: timestamp when latest scan was performed

Port ble scan: 11

Messages of type "msg_ble_scan" with id 0XFA are sent to port 11. Message contains data of single ble scan. When we have more results then can be fitted in single message length, multiple messages are formed. Only first message is send via LR, but multiple can be stored in flash. Ressults are orderd by rssi. Message is of the form:

byte 0: message ID - 0XFA
byte 1: message length
byte 2-5: timestamp when latest scan was performed

Port LR messaging: 28

Messages of type "msg_lr_messaging_timestamp" with id 0xF0 are sent to and from port 28. Message is of the form:

byte 0: message ID - 0XF0
byte 1: message length
byte 2: data length

Also messages of type "msg_lr_messaging" with id 0x90 are sent to and from port 28. Message is of the same format as the one above, iting the timestamp:

byte 0: message ID - 0X90
byte 1: message length
byte 2: data length

Factory test - GPS

Provision the device to TTN Application: smartparks-factory-test
Device name should be the same as the PCB name after Otii test: "week number"-"device number"
Monitor the device in Grafana: Lion Factory Test / Rhino Factory test

Settings

Send payload via The Things Network Console - Downlink FPort 3

GPS test (GPS on - system status 1 min, GPS periodic 1 min)

{"system_status_interval": 1, "system_functions": {"accelerometer_enabled": false, "light_enabled": false, "temperature_enabled": false, "humidity_enabled": false, "charging_enabled": true}, "lorawan_datarate_adr": {"datarate": 3, "confirmed_uplink": false, "adr": false}, "gps_periodic_interval": 1, "gps_triggered_interval": 0, "gps_triggered_threshold": 10, "gps_triggered_duration": 10, "gps_cold_fix_timeout": 200, "gps_hot_fix_timeout": 60, "gps_min_fix_time": 1, "gps_min_ehpe": 50, "gps_hot_fix_retry": 5, "gps_cold_fix_retry": 20, "gps_fail_retry": 0, "gps_settings": {"d3_fix": true, "fail_backoff": false, "hot_fix": true, "fully_resolved": false}, "system_voltage_interval": 1, "gps_charge_min": 2500, "system_charge_min": 3450, "system_charge_max": 4000, "system_input_charge_min": 10000, "pulse_threshold": 3, "pulse_on_timeout": 60, "pulse_min_interval": 1, "gps_accel_z_threshold": 0}

Charge/fence test (GPS off - system status 1 min, GPS periodic 0)

{"system_status_interval": 1, "system_functions": {"accelerometer_enabled": false, "light_enabled": false, "temperature_enabled": false, "humidity_enabled": false, "charging_enabled": true}, "lorawan_datarate_adr": {"datarate": 3, "confirmed_uplink": false, "adr": false}, "gps_periodic_interval": 0, "gps_triggered_interval": 0, "gps_triggered_threshold": 10, "gps_triggered_duration": 10, "gps_cold_fix_timeout": 200, "gps_hot_fix_timeout": 60, "gps_min_fix_time": 1, "gps_min_ehpe": 50, "gps_hot_fix_retry": 5, "gps_cold_fix_retry": 20, "gps_fail_retry": 0, "gps_settings": {"d3_fix": true, "fail_backoff": false, "hot_fix": true, "fully_resolved": false}, "system_voltage_interval": 1, "gps_charge_min": 2500, "system_charge_min": 3450, "system_charge_max": 4000, "system_input_charge_min": 10000, "pulse_threshold": 3, "pulse_on_timeout": 60, "pulse_min_interval": 1, "gps_accel_z_threshold": 0}

Device Sleep (System status 30 min)

{"system_status_interval": 30, "system_functions": {"accelerometer_enabled": false, "light_enabled": false, "temperature_enabled": false, "humidity_enabled": false, "charging_enabled": true}, "lorawan_datarate_adr": {"datarate": 3, "confirmed_uplink": false, "adr": false}, "gps_periodic_interval": 0, "gps_triggered_interval": 0, "gps_triggered_threshold": 10, "gps_triggered_duration": 10, "gps_cold_fix_timeout": 200, "gps_hot_fix_timeout": 60, "gps_min_fix_time": 1, "gps_min_ehpe": 50, "gps_hot_fix_retry": 5, "gps_cold_fix_retry": 20, "gps_fail_retry": 0, "gps_settings": {"d3_fix": true, "fail_backoff": false, "hot_fix": true, "fully_resolved": false}, "system_voltage_interval": 30, "gps_charge_min": 2500, "system_charge_min": 3450, "system_charge_max": 4000, "system_input_charge_min": 10000, "pulse_threshold": 3, "pulse_on_timeout": 60, "pulse_min_interval": 1, "gps_accel_z_threshold": 0}

Deep sleep (no status - no battery consumption)

Use to upload Deep sleep firmware:

GPS antenna tuning

This page will describe al whole procedure on how the antena was tuned.

https://synzen.com.tw/products/lodestar antenna is used for the Rhino Tracker. This is the tuning process for air.

Schematic

Equipment

For GPS antenna tuning a MegiQ VNA-0460 VNA was used. VNA and cable were calibrated with custom calibration kit.

Measurements with recommended component values

Datasheet recommended component values

Because one of the component was not in stock at office w tried with 10pF instead of 8.2pF on C2

C13 - 15pF
C3 - 1pF
C2 - 10pF

Change recommended components 1

C13 - 15pF
C3 - 1.5pF
C2 - 11pF

Change recommended components 2

C13 - 15pF
C3 - 1.5pF
C2 - 6.8pF

Conclusion

At this point we saw that we are not getting anywhere.

Measurements with new pi network configuration

Measurements 1

C13 - 15pF
C2 - 1pF
C3 - 1pF

Measurements 2

C13 - 15pF
C2 - 1pF
C3 - 1pF

Measurements 3

C13 - 15pF
C2 - 1pF
C3 - 2.2pF

Measurements 4

C13 - 10pF
C2 - 1pF
C3 - 2.2pF

Measurements 5

C13 - 22pF
C2 - 1pF
C3 - 2.2pF

Measurements 6

C13 - 10pF
C2 - 1pF
C3 - 3.3pF

Measurements 7

C13 - 10pF
C2 - 3.3pF
C3 - 3.3pF

Measurements 8

C13 - 10pF
C2 - 4.7pF
C3 - 3.3pF

Measurements 9

C13 - 10pF
C2 - 4.7pF
C3 - 4.7pF

Settings interface

Interface files for utilising auto-generated settings files from the main thread and firmware modules.

Initialisation

Function int init_settings(void), initialises the settings module. It first initialises nvs storage system by calling int nvs_storage_init() and upon success updates all values and settings from nvs storage by calling int update_all_from_nvs().

Settings are updated only if previousy stored in the nvs storage and if stored type is compatible with setting variable.

Parsing BLE and LoRa messages

Upon receiving new BLE or LoRa message in the main thread, message is parsed by calling int parse_message(uint8_t *message, uint8_t message_length) function that takes message and its length as input parameters, then replaces message with response, if there is one, and returns response length. Upon error, negative error code is returned.

Message can consist of several stacked messages, however all need to be sent on the same port. In both BLE and LoRa messages, first message entry is sent port, based on which messages are parsed later on.

New message begins with ID, the length and number of bytes define by length. If length is 0, only message ID is needed for execution. Once new message is red, it is executed by passing it to int execute_message(uint8_t port, uint8_t id, uint8_t len, uint8_t data, uint8_t *response_message) function.

Executing messages

Based on port number, message is treated as:

setting - {setting_id, setting_len, setting[setting_len]} if ID is valid, new value is stored to nvs and replaced in the Main_settings structure
values - currently only outgoing value messages are supported

Command messages

execute_command_message function, executes commands, based on theirs ID number, which are defined in commands_def.h auto-generated file. Currently the following are supported:

CMD_RESET - system reboot
CMD_SEND_SINGLE_VAL - returns response message of the form {val_id, val_len, val[val_len]}.
CMD_SEND_ALL_VAL - return a string of single values, containing all supported values, of total max message length

Response message

After execute_messagereturns length of the response, non-zero responses are stacked in single response message, thath is returend via approprite port, determined in execute_messagefunction. New port is stored as a first entry of final response. parse_messagereturns length of the response message or negative error code.

RhinoPuck validation

Testing with PeaceParks

The following validation process is put in place to validate antenna tuning and performance in a real rhino horn. The results are then used to optimize the final product version for field deployment.

Validation steps

A number of validation steps is put in place in this process, such that the RhinoPuck product is optimal for field deployment.

Fake rhino horn testing at IRNAS, Slovenia - Completed
- Goal: establish antenna tuning parameters
- Goal: define the installation process
- Goal: produce units for field testing by Peace Parks
Temporary testing in fresh and removed rhino horn at Peace Parks, South Africa - In progress
- Goal: Obtain fresh rhino-horn that is removed from the animal and perform testing
- Goal: Validate performance of multiple tuning versions of RhinoPuck by temporarily inserting
Testing on the real animal

Fake rhino horn testing at IRNAS, Slovenia

Based on the information obtained from scientific literature as well as input from field experts, IRNAS has produced a fake rhino horn consisting of horse hair and epoxy in a 5 tonne press, resulting in a hard and compact unit which is assumed to be similar to the actual horn. The similarity is validated by Peace Parks testing.

With the results of the fake horn, antenna tuning has been performed for BLE, LoRa and GPS antenna inside RhinoPuck. The results have been shown to be promising, achieving good antenna efficiency. The following tuning results indicate the antenna performance.

The performance of both uBlox and LR1110 GPS reception have been conducted to validate the GPS reception, which has shown to be very good and comparable with both GPS receivers.

A 5 day test has been conducted with RhinoPuck unit inside the fake rhino horn at a very agressive interval of 1 minute LR1110 fix and 15min uBlox fix. Both position systems worked well, providing accurate positions within 25m range over the 5 day period.

As a result of successful test, the next batch of units has been produced with minimal variations in antenna tuning, such that multiple versions can be tested by Peace Parks to determine the most optimal one.

GPS antenna nominal frequency is 1575 MHz and multiple options were prepared as well with 5 MHz offset. These units are then used by Peace Parks to determine the optimal tuning option.

Temporary testing in fresh and removed rhino horn at Peace Parks, South Africa

The testing by Peace Parks in fresh rhino horn that has been removed from an animal is conducted to validate the tuning and installation method in real-world conditions. Tests are conducted in the following steps, following the main installation instructions with some modifications.

Configure the RhinoPuck tracker with the following settings
- LR position interval: 1 minute
- uBlox position interval: 15 minute

Result evaluation

The test process above is repeated with 5 different trackers: 0 MHz, +10 MHz, +5 MHz, -5 MHz and -10 MHz. Results of each tracker are then evaluated after the test has been conducted.

Parameters to observe:

Successful GPS fix with uBlox and LR
Number of satellites found for uBlox and LR
C/N0 parameter for uBlox and LR

Subject to these results, correct tuning parameters can be determined for the setup and new units produced in larger volume.

User commands instructions

Instructions on how to send commands to EdgeTracker from app or via LoRaWAN communication.

Settings

List of settings, tracker supports, is specified in settings.json file, that can be found in latest FW release on GitHub. All available settings are located under "settings" cluster. Each setting is of the form:

where:

id - unique identifier
length - length in bytes
conversion - setting variable type

To change any setting, a custom command can be send via BT app or using LoRa communication.

Port 3 is used for commands handling.

Change settings via LoRa

Send downlink message to port 3 of the form:

where data in byte array format needs to be little-endian encoded.

To set the above "settingname" example setting to value 1000, first convert 1000 to byte array: E8 03 00 00 and replace id with 01 and length with 04:

Change settings via BT app

Use "Custom command" field to set settings that are not supported in the user interface. The main change when using the app for sending commands is that port needs to be specified as first value.

App supports commands in hex format with "0x" preamble or in decimal format. The above setting can be send either as:

or as

Spaces need to be added!

Commands

Various commands are avaliable for user to interact with tracker. All commands are defined in settings.json file under "commands" cluster. Each command is of the form:

where:

id - unique command identifyer
length - length of additional data send in command
conversion - conversion of additional data send in command

Commands are send in similar way to settings via BT app or using LoRa communication.

Port 32 is used for sending commands.

Send command via LoRa

Send command in the following form to port 32:

Keep in mind that additional value is always litlle-endian encoded. If command length is 0, no additional value needs to be send, hence:

For example to send "cmd_name" test command with value 3, the following string is send to port 32:

Send command via BT app

Same format as defined above is used. Again port needs to be added as first value in the array. The above command can be send in either of the formats:

List of commands and their format

The following commands are supported at the moment. All need to be send to port 32. Below message formats for using LoRa communication are given. To adjust message format, follow the instructions above.

A1 - cmd_reset

Reboot tracker.

A2 - cmd_send_all_val

Tracker will return all values, in stacked format, as described in the following command. Not recomended to use via LR, due to payload size limitations.

A3 - cmd_send_single_val

Obtain value of a single value field, specified by its id. List of all values can be found in settings.json file under "values" cluster

For example, to get value with id D1 send:

Tracker will respond on port 30 in the format:

A4 - cmd_send_status

Status message will be send via LoRa/BT communication to status port 4. For status message structure, see TTN parser: ttn_decoder.js, addeed to lates release on GitHub or next chapter.

A5 - cmd_send_position

Obtain tracker latest GPS position (lat lon, alt). Send command:

Tracker will respond with "msg_last_position" on port 31. For definition see next chapter.

A6 - cmd_reset_gps

Reboot Ublox GPS module.

A7 - cmd_send_all_settings

Tracker will return all settings, in stacked format, as described in the following command. Not recommended to use via LR, due to payload size limitations.

A8 - cmd_send_single_setting

Obtain value of a single setting field, specified by its id.

For example, to get "cmd_name" send:

Tracker will respond on port 3 in the format:

A9 - cmd_reset_initial_position

Reset initial reference position of the tracker to hardcoded position. (not recommended to use)

AA - cmd_reset_initial_time

Reset initial reference time to hardcoded value. (not recommended to use)

AB - cmd_clear_nvs

Clear internal storage. All set values are going to be deleted and set to default. Keep in mind that LR keys are going to be deleted as well!

AC - cmd_reset_to_def_settings

Revert all setting to defoult values. Keep in mind that LR keys are going to be deleted as well!

AD - cmd_send_status_lr

Status message will be send via LoRa communication to status port 4. For status message structure, see TTN parser: ttn_decoder.js, addeed to lates release on GitHub or next chapter.

AE - cmd_send_lr_fix

Obtain LR GNSS message and send it via LoRa communication.

AF - cmd_set_location_and_time

Set reference location and time of the tracker.

B0 - cmd_get_rf_scan

Get rf scan - not supported at the moment!

B1 - cmd_get_wifi_scan

Get aggregated data in wifi scan. Tracker will response with "msg_wifi_scan_aggregated" (see next chapter).

B2 - cmd_get_ble_scan

Get aggregated data of BT scan. Tracker will response with "msg_ble_scan_aggregated" (see next chapter).

B3 - cmd_get_almanac_age

Get almanac age - not supported at the moment!

B4 - cmd_get_lr_satellite_data

Perform LR GPS scanning and return both GNSS message as well as satellite data message, used in the fix. See next chapter for message definitions.

B5 - cmd_get_ublox_satellite_data

Perform Ublox position fix and return both position message, as well as satellite data message, used in the fix. See next chapter for message definitions.

B6 - cmd_almanac_update

Not yet supported

B7 - cmd_get_mac

Get BT MAC addres from the device.

Device responds with "msg_mac_id" (see next chapter).

B8 - cmd_get_ublox_fix

Perform Ublox position fix and returnposition message.

B9 - cmd_reset_lr

Reset LR module.

BA - cmd_flash_clear

Clear all data from external flash.

BB - cmd_flash_get_all

Get all messages stored on specific port. Use port=0 to get messages from all ports.

Tracker will start to return all available messages from head to tail on port 29 via BT/LoRa. When all messages are send, confirmation message, "msg_cmd_confirm", will be received.

BC - cmd_flash_get_from_head

Read specific number of messages, starting from specified message on defined port.

To read 10 messages on port 4, starting from 50th message, send:

Tracker will start to return all available messages from head to tail on port 29 via BT/LoRa. When all messages are send, confirmation message, "msg_cmd_confirm", will be received.

C4 - cmd_send_lr_message

Send message to device to be send via LR.

Up to 45 bytes are supported.

Message formats

Tracker send various message types via LoRa/BT communication and/or store them to flash. All message types are defined in settings.json fil, under cluster "messages".

Each is of the form:

where:

port - specified port on which message is send. Port names are defined in settings.json file, under the cluster "ports"
id - msg id
length - max length of the message

All messages are following same basic format:

If message is send via BT, port is added as first byte:

Total received message length is tehrefore 2 + length on LoRa communication and 3 + length on BT, due to added port before other values.

F1 - msg_gnss

Send on port 1. GNSS data message. See ttn-decoder for format.

F2 - msg_ublox_location

Send on port 2. Message containing Ublox GPS fix and additional fix data. See ttn-decoder for format.

F3 - msg_cmd_confirm

Confirmation message, send on defoult message port 31. This message is returned after any command that does not evoke any other message send or has failed. Format:

F4 - msg_status

Status message, send on port 4. See ttn-decoder for format.

F5 - msg_lr_satellites

Message, containing satellite data, used in GNSS LR position fix. Send on port 5. See ttn-decoder for format.

F6 - msg_ublox_satellites

Message, containing satellite data, used in Ublox position fix. Send on port 9. See ttn-decoder for format.

F7 - msg_wifi_scan_aggregated

Message containing top-3 scanned wifi results. Send on port 6. See ttn-decoder for format.

F8 - msg_wifi_scan

Message containing scanned wifi results from single scan. Send on port 10. See ttn-decoder for format.

F9 - msg_ble_scan_aggregated

Message containing top-3 scanned BT results. Send on port 7. See ttn-decoder for format.

FA - msg_bt_scan

Message containing all results from single BT scan. Send on port 11. See ttn-decoder for format.

FB - msg_rf_scan

Not supported.

FC - almanac_age

Almanac age of the format:

FD - msg_mac_id

Message contating MAC id of the form:

FE - msg_last_position

Message containing last obtained position in the form:

FF - msg_read_flash

Message format for sending flash logs to port 29. See ttn-decoder for format.

OpenCollar

OpenCollar Dashboard

hashtagPriorities

Use cases

hashtag1. The Basic animal tracking device

Device Settings

hashtagDevice profile Settings

hashtagL1: Device High-Level Settings

hashtagL2: Device Low-Level Settings

Milestones

Technology

Hardware

Manufacturing

Firmware - Edge tracker

Instructions

Device Settings

hashtagDevice profile Settings

hashtagL1: Device High-Level Settings

hashtagL2: Device Low-Level Settings

OpenCollar Dashboard

hashtagPriorities

Use cases

hashtag1. The Basic animal tracking device

hashtagElectronic system solutions

hashtagHardware implementations (2020)

hashtagProducts (2020)

hashtagOpenCollar tracker advanced

hashtagMilestones firmware

hashtagMilestones hardware

hashtagDevice configuration

hashtag2. Use case - ElephantEdge Hackster project

Peace Parks Rhino implant update

hashtagPeace Parks Rhino implant and rhino horn tracker technology update.

hashtagStatus

Bluetooth BLE smartphone connectivity

hashtagBLE profiles

hashtagSerial communication protocol

hashtagSettings management

M2

RF system configuration

Main screens

hashtagDevice list

hashtagDemo devices

hashtagApplication settings

hashtagScan results filtering

hashtagAbout

LR1110 features

hashtagGPS quick fix

hashtagWiFi scanning

hashtagVHF output

Upgrading tracker firmware

Interaction with the tracker

hashtagCommunicating with the device

hashtagData transfer

hashtagData types

hashtagData transfer protocol

hashtagData validation checks

hashtagHandling data transfer failures

ImplantEdge Battery

hashtagDischarge tests

Synzen

hashtagAssembled device

hashtagConnection for GPS u.fl connector

LoRa wire

LoRaWAN connectivity

Expansion modules

Accelerometer

GPS positioning

Connected screens

hashtagTracker information

hashtagGet Ublox GPS fix popup

hashtagTracker configuration

hashtagInterval configuration

hashtagPIN configuration

hashtagGPS configuration

hashtagLoRa configuration

hashtagWiFi and BLE scanning

hashtagDownload logs

hashtagFirmware upgrade (DFU)

RhinoPuck

Priorities

1. The Basic animal tracking device

Device profile Settings

L1: Device High-Level Settings

L2: Device Low-Level Settings

Device profile Settings

L1: Device High-Level Settings

L2: Device Low-Level Settings

Priorities

1. The Basic animal tracking device

Electronic system solutions

Hardware implementations (2020)

Products (2020)

OpenCollar tracker advanced

Milestones firmware

Milestones hardware

Device configuration

2. Use case - ElephantEdge Hackster project

Peace Parks Rhino implant and rhino horn tracker technology update.

Status

BLE profiles

Serial communication protocol

Settings management

Device list

Demo devices

Application settings

Scan results filtering

About

GPS quick fix

WiFi scanning

VHF output

Communicating with the device

Data transfer

Data types

Data transfer protocol

Data validation checks

Handling data transfer failures

Discharge tests

Assembled device

Connection for GPS u.fl connector

Tracker information

Get Ublox GPS fix popup

Tracker configuration

Interval configuration

PIN configuration

GPS configuration

LoRa configuration

WiFi and BLE scanning

Download logs

Firmware upgrade (DFU)

Features

Registering the device

Required

Installation

Step 2

The Things Network Console

Step 3

Step 4

Step 5

Testing the device

Step 6

GPS active (interval 1min)

Step 7

Device sleep

Step 8

Device sleep:

Initial provisioning

Rhino electronics - common steps

values_def.h

Main values

Global variables

Functions

values_def.c

commands_def.h

Defines

Global variables

settings_def.h

Defines

SETTING_TYPE(_id) TYPE_##_id

SETTINGS_STRUCT(_id) STRUCT_##_id