Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Development planning and documentation
This documentation system is intended to provide the full technical insight into the solution and is created in real-time during the development process. See OpenCollar Dashboard
Definition and description of all OpenCollar tracker use cases
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.
Accelerometer
Gyro/Magnetometer - IMU
Microphone
uBlox GPS
Semtech LR1110
Tracker internal temperature
WD memory
RF scanning
Wet/Dry sensor
Data
Information
Raw GPS position
Data is sent to Semtech server where the position is calculated
Battery status
Current battery status of the device
Configuration
Information
GPS scan period
LoRaWAN send period
BLE advertising period
Use-case
Sensor
Comment
Poaching Risk monitor
GPS data, motion data to indicate stress
Human Elephant Conflict
BLE/WiFi scan data for proximity of people, GPS data
Elephant Musth detection
Accelerometer data, sound
Elephant Activity monitor
Accelerometer/IMU to detection walking/sleeping/drinking...
Elephant Health monitor
Using activity to detect health
Elephant contact monitor
COVID style contact tracing though BLE
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.
For GPS antenna tuning a MegiQ VNA-0460 VNA was used. VNA and cable were calibrated with custom calibration kit.
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
L4 - DNP
C13 - 15pF
C3 - 1.5pF
C2 - 11pF
L4 - DNP
C13 - 15pF
C3 - 1.5pF
C2 - 6.8pF
L4 - DNP
At this point we saw that we are not getting anywhere.
C13 - 15pF
C2 - 1pF
C3 - 1pF
L4 - 1nF
C13 - 15pF
C2 - 1pF
C3 - 1pF
L4 - 2.2nH
C13 - 15pF
C2 - 1pF
C3 - 2.2pF
L4 - 2.2nH
C13 - 10pF
C2 - 1pF
C3 - 2.2pF
L4 - 2.2nH
C13 - 22pF
C2 - 1pF
C3 - 2.2pF
L4 - 2.2pF
C13 - 10pF
C2 - 1pF
C3 - 3.3pF
L4 - 2.2nH
C13 - 10pF
C2 - 3.3pF
C3 - 3.3pF
L4 - 2.2nH
C13 - 10pF
C2 - 4.7pF
C3 - 3.3pF
L4 - 2.2nH
C13 - 10pF
C2 - 4.7pF
C3 - 4.7pF
L4 - 2.2nH
Solution
Activity
Deliverable
Timing
Horn+implant
Schematic concept based on WisentEdge
Schematic design release
October
Horn
Old rhino tracker performance review
List of design changes
October
Horn+implant
GPS antenna selection and optimization
Selected and tested antenna
October
Horn
LoRaWAN antenna selection
Selected and tested antenna
October
Horn
Battery selection
Selected and tested battery
November
Horn
Hardware design of 1st prototype horn
Hardware design release
November
Horn
1st prototype horn bring-up and testing
Demonstration - 5pcs to be sent to PeaceParks
November
Horn+implant
Firmware development of basic functionality
Demonstration
November
Horn
2nd prototype revision and testing
Schematic and hardware design release
November
Implant
Implant mechanical prototyping
Hardware design
November
Horn
Field testing of horn tracker
Demonstration
December
Implant
Schematic and hardware design of 1st implant prototype
Schematic and hardware design release + send 2pcs to be sent to PeaceParks
December
Implant
Antenna design and selection for implant
Selected and tested antenna
December
Implant
1st prototype implant bring-up and testing
Demonstration
December
Implant
Field-testing non-implanted
Test results
December
Horn+implant
Communication from implant to horn testing
Demonstration
December
Implant
2nd prototype revision
Schematic, hardware, firmware design release
January
Implant
Field-testing implanted domestic animal
Test results
January
Horn
Hardware revision of horn for production
Schematic, hardware, firmware design release
January
Implant
Hardware revision of implant for production
Schematic, hardware, firmware design release
January
3.8.2020
BLE: Nordic Semiconductor nRF52840
Options:
n52840 standalone
uBlox NINA-B30x integrated module
LoRa/GPS/WiFI: Semtech LR1110
GPS: uBlox M8G
Antenna:
BLE/WiFi combined
RF things LoRa antenna suitable for Lacuna
VHF antenna port
GPS ceramic patch tuned antenna
Taoglas or Maxtena
Sensors:
3D Accelerometer: LIS2DW12
6D IMU Accelerometer + Gyro: LSM6DSL
6D eCompass: LSM303AGR
Microphone:
Analog: MP23ABS1
Digital: SPK0415HM4H
Water detect switch
Real-time data storage:
QSPI NOR flash
ML raw data storage:
WD Edge microSD storage SDSDQAB-016G
A short update on the RhinoEdge development
Peace Parks Rhino horn implant and Rhino sub-skin implant are solution under development by Smart Parks and IRNAS with the latest bleeding-edge technology to provide a next generation tracking experience. The core technology used in the Semtech LR1110 LoRa/GPS/WiFi transceiver for low-power positioning introduced in 2020 and just reaching scale production on the market and suitable technical maturity in 2021. Such technology unlocks 10 times lower power consumption for positioning solutions.
The extensive experimentation has demonstrated a number of blocking issues over the past 9 months, however Semtech (the provider of the LR1110 chipset and owner of the LoRa protocol) has in June 2021 opened up the support channels to IRNAS and Smart Parks, such that a more rapid development process can take place.
The following product parameters when suitably optimized will enable a good quality low-power tracker configuration:
GPS antenna orientation towards the sky
GPS antenna gain (subject to dimensions, larger is better)
GPS antenna efficiency (subject to dimensions and surrounding material)
LR1110 almanac up to date (known GPS satellite orbits)
LR1110 supplied accurate time
Given these requirements and to build tracker resiliency, LR1110 has undergone a validation process to enable standalone operation with LoRaWAN messages carrying almanac and precise time, which however requires permanent device network coverage. This may be problematic in remote area LoRaWAN networks like PPF is using.
Further optimization and testing has however shown, that an addition of a true on-device GPS receiver from Ublox can be combined in a compact form-factor. This also unlocks a set of unique options, such as precise time acquisition on device and in the future (subject to Semtech) generating almanac data from Ublox gps position, removing the need for downlinks. Note there is a substantial effort required for implementation.
In July 2021 Semtech shared with IRNAS the documentation on almanac update payload structure as the first partner company in the market. This allows for creating of a unique solution described above.
Implant:
Schematic prototype validated and tested as Open Collar Cat tracker
LR1110 GPS performance optimization in process
UBlox GPS performance goal achieved
Firmware has all the required features implemented
BLE proximity is implemented (horn to implant proximity)
Form-factor:
Square EVE battery option has proven to give poor performance
Round Saft battery is a good option, but rather large for the application
Hardware layout:
Draft completed, subject to battery size configuration and adjustment
Horn:
Schematic completed and tested as Open Collar Cat tracker
LR1110 GPS performance optimization in process
Firmware has all the required features implemented
BLE proximity is implemented (horn to implant proximity)
Hardware layout:
Pending LR1110 optimization
Step
Operation
Location/Other
Result
Expected Result
1
Connect Otii output to tracker edge connector
J4
OK
OK
2
Set output voltage 4.2V
/
OK
OK
3
Otii enable output
/
OK
OK
4
Measure 2.8V power supply
C61
2,799V
2.8V±5%
5
Measure current consumption
/
4.5mA
2-6mA
Step
Operation
Location/Other
Result
Expected Result
6
Connect j-Link to edge connector
J4
OK
OK
7
Ask software dude to program device
SW dude
OK
OK
Step
Operation
Location/Other
Result
Expected Result
8
Enable GPS power (MCU – P0.29)
UART command
OK
OK
9
Measure ZOE-M8G power supply
C86
1.802
1.8V
10
Measure ZOE-M8G supply current
Otii
34.5mA
35mA±10%
11
Measure GPS LAN power supply
C38
2.799V
2.8V±5%
12
Check I2C communication to GPS
UART command
OK
OK
13
Scan for number of visible satiates*
UART command
OK
4 or more
14
Scan for max satellite signal strength*
UART command
OK
42dB or more
15
Disable GPS power (MCU – P0.29)
UART command
OK
OK
Step
Operation
Location/Other
Result
Expected Result
16
Check SPI communication to LR1110
UART command
OK
OK
17
Send test message over LORA
UART command
OK
OK
18
Receive test message over LORA
UART command
OK
OK
19
Perform Wi-Fi scan
UART command
OK
OK
20
Perform GPS satellite scan
UART command
OK
8 or more
21
Scan for max satellite signal strength*
UART command
OK
32dB or more
22
Disable LR1110 power supply (P0.05)
UART command
OK
OK
Step
Operation
Location/Other
Result
Expected Result
23
Measure reed sensor power supply
C82
2.799V
2.8V±5%
24
Put magnet over sensor for trigger
UART command
Detected
Detected
25
Measure accelerometer power supply
C84
2.799V
2.8V±5%
26
Read accelerometer values
UART command
OK
OK
27
Move device
/
OK
OK
28
Read accelerometer values
UART command
OK
OK
29
Enable mic power supply (P1.11)
UART command
??
OK
30
Make loud noise to trigger interrupt
UART command
??
OK
31
Read digital sound with MCU
UART command
??
OK
32
Disable mic power supply (P1.11)
UART command
??
OK
Step
Operation
Location/Other
Result
Expected Result
33
Enable BLE on MCU
UART command
OK
OK
34
Connect with phone to device
/
OK
OK
35
Send command to device
/
OK
OK
36
Disconnect phone from device
/
OK
OK
Step
Operation
Location/Other
Result
Expected Result
37
Measure Flash power supply
C68
2.799V
2.8V±5%
38
Read flash ID
UART command
OK
OK
39
Write data to flash
UART command
OK
OK
40
Read and verify data from flash
UART command
OK
OK
Step
Operation
Location/Other
Result
Expected Result
41
Enable battery monitor (P0.10)
UART command
OK
OK
42
Read analog value of pin P0.04
UART command
4219mV
4200mV±2%
43
Measure voltage on resistor divider
R39
2.693V
2.685V±2%
44
Disable battery monitor (P0.10)
UART command
OK
OK
Step
Operation
Location/Other
Result
Expected Result
45
Enable RED LED diode (P0.24)
UART command
OK
OK
46
Disable RED LED diode (P0.24)
UART command
OK
OK
47
Enable GREEN LED diode (P0.25)
UART command
OK
OK
48
Disable GREEN LED diode (P0.25)
UART command
OK
OK
49
Enable BLUE LED diode (P0.27)
UART command
OK
OK
50
Disable BLUE LED diode (P0.27)
UART command
OK
OK
Step
Operation
Location/Other
Result
Expected Result
51
Apply 24V to charging contacts
/
OK
OK
52
Measure 24V voltage
C72
22.7V
22.7V
53
Measure 24V over voltage divider
C77
1.3V
1.3V
54
Measure 5V from DC/DC converter
C74
4.92V
5V
55
Measure charging current
Power supply
0.125A
0.125A
56
Enable charge disable
UART command
OK
OK
57
Measure charging current
Power supply
0.5A
0.5A
Step
Operation
Location/Other
Result
Expected Result
58
Disable Flash power supply (P0.15)
UART command
OK
OK
59
Disable GPS power supply (P0.30)
UART command
OK
OK
60
Put accelerometer in low power mode
UART command
OK
OK
61
Put LR1110 in low power mode
UART command
OK
OK
62
Put mic to low power mode
UART command
OK
OK
63
Measure power supply current
Otii
??
5uA
LoRaWAN and BLE connectivty both should offer the same functionality though an unified interface.
Special case of LoRaWAN connectivity, has a separate data transmission strategy and protocol due to very limited throughput.
Firmware structure of the device.
Firmware for the Opencollar device needs to be separated into different modules. This will provide better way for testing and give better test code coverage.
Description of tuning potted LoRa antenna on lion tracker
Schematic on bottom picture shows how is antenna wired with Murata IC and digital tunable capacitor PE64102 (DTC). DTC is wired in parallel with C7 to add capacitance and with that lower the antenna resonating frequency.
With recommended component values from datasheet we have antenna frequency that is far below 868MHz.
Frequency response with component values from datasheet shows frequency center at 785MHz which is 83MHz to low.
After tuning with capacitor on antenna band select pin we managed to get right frequency curve. Below on picture you can see frequency curve with different capacitor values with the most suitable 3pF capacitor.
Because the capacity is so small we can't fully use the potential of DTC. DTC has 32 possible combinations of capacity and we are operating at the beginning of this scale (at decimal number 4 witch is 2,98pF.
Can we make efficiency of antenna better when potted?
This page is description how to disassemble partly potted Lion tracker for Antenna tuning.
Lion tracker comes with assembled PCB, soldered EMC shield and soldered battery.
LoRa_setTxContinuousWave_vswr
- Frequency scan from 800MHz to 900MHz
LoRa_setTxContinuousWave_vswr_tune
- DTC scan at 868MHz from 0 to 32 (1,4pF to 13,61)
LoRaWAN_DeepSleep
Every time battery is soldered to board a battery protection circuit needs to be activated.
Make contact from battery negative terminal to EMC shield to activate device.
Connect USB<->UART adapter to device pin as shown in picture above.
All design can be found on github https://github.com/IRNAS/smartparks-lion-tracker-hardware
Firmware upgrade using BLE smartphone connectivity.
To upgrade firmware using DFU:
You need appropriate firmware version for specific tracker. Usually: app_update.bin. Download the file to your smartphone.
You will need nRF Connect app. It is available via app store on your smartphone.
Connect your tracker to the power supply. You can check that the tracker is discoverable by smartphone the Smart Parks Sensors app. Take note of the device name.
Open nRF Connect app and scan for available Bluetooth devices.
Connect to tracker device.
When connected you will see DFU icon in the upper right corner. Click on it.
You will see list of last download files. If your firmware file is not on it, locate it in your phone file system.
Select Test and Confirm option.
The DFU upload will begin. DO NOT cancel upload and wait until is finished and app returns you to the main screen!Select the app_update.bin file. The following pop-up window will appear.
DFU profile
Nordic Serial profile (all data communication is via this profile)
Select the best communication protocol for this application. TLV is a good approach.
Shadow approach of settings management is the most straightforward method, similar as in AWS IoT core.
Be able to send each setting entry separately
Research best implementation for settings management.
Specify a good way to include firmware versions in settings and communications
Feature | Details | Status |
BLE beaconing | Sending beacon data with basic values encoded, to allow for the non-connected status acquisition |
BLE connectable | Connect with the device to perform all function of data transmission and settings |
BLE DFU | Firmware upgrade over BLE |
Standard uBLOX GPS.
Persistent data logging.
Research option for best strategy to implement this, check out Arribada Horizon implementation.
Specify a time keepting strategy.
All expansion modules are to be implemented as I2C devices with extra GPIO, should be a separate I2C port to the one for on-board sensors.
Mobile application for connecting to Smart Parks OpenCollar sensors
Github link to the repository: https://github.com/IRNAS/smartparks-connect-app/
Overview of the main features is available in Readme on the above link.
Releases are built locally and uploaded to the above repository, where one could see changelog and download the app bundle or app package files. Files are also available on Synology Drive for backup reasons.
Application is also released on Google Play Store:
Version 1.0.0 was approved by Google for closed testing.
Version 1.0.2 has been released publicly: https://play.google.com/store/apps/details?id=com.smartparks_connect_app
Below is a diagram showing an example flow of user interaction with this application. It shows how one could reach all possible screens. Each screen functionality is described in the following chapters.
Application always starts into Device list main screen, except if it was recently opened (the OS did not stop it yet), then it will continue to last saved state – last opened screen).
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
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.
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.
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.
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.
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.
The process has been described here: https://github.com/IRNAS/smartparks-connect-app/tree/dev#firmware-upgrade-dfu
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
LoRA configuration
WiFi and BLE scanning
Download logs
Firmware upgrade (DFU)
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
number of fixes aquired with LoRa GPS
if PIN is set or not
if device is currently busy (searching for GPS fix) or idle
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)
Initialize location and time (Use phone's data to set device's location and time, which helps the device to find GPS fix faster and gives actual time information to all data being saved or sent to the servers. The application will acquire the position and current time from the phone and send latitude, longitude together with a timestamp in UNIX format to the tracker, who will save it to flash)
Reboot device (Popup will appear, in which the user needs to confirm that he actually wants to perform a reboot. This is to prevent accidental clicks which would trigger it and possibly disturb any ongoing operations)
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)
Success (boolean value showing if device found a fix or not)
Time to fix (Amount of seconds it took to find a fix or reached a timeout defined for when to stop searching for it)
Type (type of the aquired fix, possible values are: No fix, 2D fix and 3D fix. This value is showing if fix acquisition was succesfull or not, if it was, then type of the fix is displayed. There are two types: horizontal - 2D where just horizontal position was found and vertical - 3D where also altitude information is available)
Fix timestamp (exact time of the moment when fix was aquired, this is send from the tracker in UNIX format, but then shown as human readable date and time)
SIV (abbrevation for satellites in view, which is the number of satelites that where seen by the device to be used in fix aqusition)
pDOP (abbrevation for position dilution of precision, which is a description of the uncertainty in a fix. Value is related to the spacing of satellites in the sky above the device)
Estimated horizontal accuracy (accuracy of the position from the acquired fix, shown in meters)
Active tracking (shows if the GPS chip is constantly searching for a fix or only on specifed intervals)
COG (abbrevation for course over ground, presented in degrees, giving the user course of the movement, where zero degress means moving to the North)
SOG (abbrevation for speed over ground, presented in km/h, which is an actual speed of the device in movement, it is very close to zero if it's not moving)
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.
Here user can view and change settings that define how frequently some operation will happen. Configurable intervals are presented in the table below.
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.
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.
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.
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)
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
RSSI value (signal strength of last time this device was scanned)
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: https://github.com/IRNAS/smartparks-connect-app/tree/dev#download-device-logs
Below is an example of a few parsed logs from an actual device.
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
Reset - device is reseting and will boot using the new image
Confirm - device confirmed that it managed to boot
Success - DFU process has finished succesfully
Error - DFU was canceled or it failed
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.
Setting name | Description | Dropdown values |
---|---|---|
LP1 send
send GPS data to LoRaWAN server
off, 1 min, 15 mins, 1 h, 2 h, 4 h
Status send
send status data to LoRaWAN server
1 min, 15 mins, 1 h, 2 h, 4 h
WiFi scan send
send results from device's WiFi scan to LoRaWAN server
off, 1, 3, 5, 7, 10 minutes
BLE scan send
send results from device's BLE scan to LoRaWAN server
off, 1, 3, 5, 7, 10 minutes
WiFi scan
execute WiFi scan
off, 1, 3, 5, 7, 10 minutes
BLE scan
execute BLE scan
off, 1, 3, 5, 7, 10 minutes
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.
It then cancels the connection by sending the disconnect command to the device. Application and device then handle disconnecting independently.
Periodic pooling of status data is stopped and message is displayed to the user, telling him that disconnecting process has finished.
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.
This is described here: https://github.com/IRNAS/smartparks-connect-app/tree/dev#communication-protocol
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 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)
minimum and maximum valid values (if applicable, the same as default otherwise)
length of the value (excluding headers)
conversion (data type of the data)
value (defined only for commands)
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.
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.
The following batteries from manufacturer Fanso have been identified as suitable candidates due to dimensions and capacity for implant operation.
Both battery types have been discharged with a constant load profile for accelerated testing of 50mA for 30s and 1m for 10s. While this is not a realistic case, it should represent the harshest use-case with GPS.
The larger battery has been also tested in 2P configuration, to determine the impact of parallel connection in capacity improvement.
Antenna tuning and testing of RhinoEdge devices.
Test 1 and Test 2 are designed to evaluate GPS RF path performance in two configurations under controlled parameters.
Spirent GSS6100 simulator at RF mon output connected to ceiling patch antenna at 2m distance from DUT
Spirent GSS6100 simulator main RF output, configured to TXP such that uBlox EVK C/N0 is around 40
Wisent edge is based on Lion pcb
List of changes for first revision:
Pin Y2 connect to VBAT. Remove wire between B1 and C51.
Remove resistor R4 on top side of PCB.
Check short circuit on power lines (Vin, Vchrg, VBAT, VDD_NRF52, 1.8V, VLORA)
R22, R25, R43, R44 do not place
Power up 3.6V (I=10mA) on VBAT
Measure VDD_NRF52, 1.8V(Enable), VLORA(2.5V)
Test battery charging
Test connection to NRF via Tag connect
Check I2C lines if HIGH
Check reset if HIGH on both chips
Test LED diode
When enable 1.8V current jump to 10-15mA
Battery measurement enable to measure battery voltage (Supply voltage = 3.6V, R1 = 220R, R2 = 390 R, Output voltage = 2.302 V)
No boot - test blinky (new chip)
Boot up normal, high power consumption
Boot up normal, high power consumption
Boot up normal, low power consumption
Boot up normal, low power consumption
Cell | Nominal | Actual |
---|---|---|
CP502440
1.2 Ah
0.98 Ah
CP502440 2P
2.4 Ah (1.2 Ah/cell)
2.11 Ah (1.05 Ah/cell)
CP252545
0.75 Ah
0.74 Ah
Antenna
G1 C/N0
ublox m8b dk + default active antenna
38
classic rhino with taoglas
30
classic rhino with taoglas + 20cm wire extension
35
synzen 0g02 dk
25 (horizontal), 27 (vertical)
rhinoedge with 12cm wire on gnd
20 (max of all orientations)
Test 1
C/N0
Comment
uBlox M8G EVK + stock antenna
uBlox M8G EVK + RhinoEdge antenna
ElephantEdge uBlox + on-board antenna
ElephantEdge LR1110 + on-board antenna
RhinoEdge LR1110 + on-board antenna
uBlox M8G EVK + 2J78 antena
41
RhinoEdge LR1110 + 2J78 antena
31
LR1110 EVK + on-board antenna
31
Test 2
C/N0
Comment
uBlox M8G EVK
41
ElephantEdge uBlox
ElephantEdge LR1110
RhinotEdge LR1110
41
LR1110 EVK
Change
Description
Status
Replace Murata ABZ with nRF52840
Add LR1110 transceiver with LoRaWAN output on HP port with Antenova antenna
Add u.fl connector to LR1110 LP output for VHF
Combine WiFi and BLE via RF switch on single antenna
Split GPS after LNA to LR1110 and ublox
Test
Results
Short circuits
NONE
Power up
OK
Measure VDD_NRF52
1.8V
Measure 1.8V (expect 1.8V)
1.8V
Measure VLORA (expect 2.5V)
2.5V
Battery charging (connect to 12V (I=500mA))
Measure I2C lines
OK
Check reset pins
OK
Test LED diode
OK
Check battery measurement circuit
OK
Test
Results
Short circuits
NONE
Power up
OK
Measure VDD_NRF52
1.8V
Measure 1.8V (expect 1.8V)
1.8V
Measure VLORA (expect 2.5V)
2.5V
Battery charging (connect to 12V (I=500mA))
Measure I2C lines
OK
Check reset pins
OK
Test LED diode
OK
Check battery measurement circuit
OK
Test
Results
Short circuits
NONE
Power up
OK
Measure VDD_NRF52
1.8V
Measure 1.8V (expect 1.8V)
1.8V
Measure VLORA (expect 2.5V)
2.5V
Battery charging (connect to 12V (I=500mA))
Measure I2C lines
OK
Check reset pins
OK
Test LED diode
OK
Check battery measurement circuit
OK
Test
Results
Short circuits
NONE
Power up
OK
Measure VDD_NRF52
1.8V
Measure 1.8V (expect 1.8V)
1.8V
Measure VLORA (expect 2.5V)
2.5V
Battery charging (connect to 12V (I=500mA))
Measure I2C lines
OK
Check reset pins
OK
Test LED diode
OK
Check battery measurement circuit
OK
Test
Results
Short circuits
NONE
Power up
OK
Measure VDD_NRF52
1.8V
Measure 1.8V (expect 1.8V)
1.8V
Measure VLORA (expect 2.5V)
2.5V
Battery charging (connect to 12V (I=500mA))
Measure I2C lines
OK
Check reset pins
OK
Test LED diode
OK
Check battery measurement circuit
OK
Part name: LR1110
Manufacturer: Semtech
Price:
Supplier:
Part name: NJG1801K75-TE1
Manufacturer: NJR
Price: 0,15€ kos @ 5k kos
Supplier: Rutronik
Part name: NJG1699MD7
Manufacturer: NJR
Price: ???€ kos @ ??? kos
Supplier: Rutronik
Part name: NJG1155UX2
Manufacturer: NJR
Price: 0,175€ kos @ 3k kos
Supplier: Rutronik
LoRa command to drop-off
Periodic status messages
Requirement
Description
LoRaWAN with LR1110
EU868 and US915
BLE connectivity
BLE
Sensors
Accelerometer
Belt
38mm
Weight
100g
Length
<40mm
Thickness
<20mm
Attachment
as cat tracker
Antena tuning frequency: Variant 1 - LoRa 868MHz and WiFi, Variant 2 - LoRa 915MHz and WiFi
GPS tuning frequency: GPS 1575MHz, GLONASS 1602MHz
We have used the drop-off enclosure with flat steel plates for testing. Additional holder was assembled to support the weights. Several steel and aluminium weights were used for gradually applying load during testing.
We have preformed two tests to determine and validate the strength of the drop-off mechanism. In both tests the mechanism broke when subjected to load of approx. 300 N (31,9 kg of weights including the holder).
Additional impact tests and fatigue tests have to be performed to fully validate the strength of the drop-off mechanism.
A set or RhinoPuck units with a range of tuning values has been produced for testing by PeaceParks in the actual rhino horn. The devices were tested in various configuration to acquire as much information as possible on the impact of the actual horn on the RF performance and establish design parameters.
A set of 4 different tests has been established to evaluate various impacts of placement and positioning on the RF performance.
RhinoPuck positionied with sticker (antenna) side inwards to the horn and plugged with a dummy Vettec puck
RhinoPuck positioned with sticker (antenna) side inwards to the horn and no dummy
RhinoPuck positionied with sticker (antenna) side outwards to the horn and plugged with a dummy Vettec puck
RhinoPuck positionied with sticker (antenna) side outwards to the horn and no dummy
The testing conducted over a period of 2 days has shown several key results:
GPS antenna is operating sufficiently well for Ublox GPS, but based on lab results a better performance should be possible which is required for LR1110 GPS
High-power Ublox GPS is working and can provide a reliable GPS fix
Low-power LR1110 GPS is not working due too low GPS satellite signal strength
Rhino horn impact on antenna is significant, thus the antenna tuning must be very well matched to the actual horn.
Best overall performance was observed for sp3a0b5c tracker tuned at 1575MHz with Sticker out + dummy configuration (note however sp0ced81 was expected to have similar performance but it did not), up to 5 LR1110 satellites were observed
Second best overall performance was observed for sp794c39 tracker tuned to 1570MHz with Sticker in + dummy configuration
Notably good performance was observed on Sticker in + no dummy configuration on trackers in 1575MHz, 1580MHz and 1585MHz, however no Dummy is not a realistic solution as the trackers can not be deployed that way.
Based on the best results, the C/N0 metric for Ublox has not exceeded 34, however based on lab results at least 37 should be achieved with better tuning and then LR1110 performance is expected
In VS Code open your folder with the latest firmware and other files.
In "config.yml" define the application ID in line 2 and firmware to upload in line 6 (name.dfu).
To get the access code for TTN Console open "main.py" and ctrl+click on the link in line 18.
Copy the access code in yellow.
In VS Code open new Terminal and type or copy the following line with the access code and press enter.
If you want to manually provision the device with OTAA, use the following line with correct values
Connect STM32 Nucleo to Tag connect programmer adapter.
Enter device name to register and wait for the process to finish.
Device name can NOT be changed in The Things Network Console.
In The Things Network Console go to device overview to change settings.
Applications -> "Application ID" -> Devices -> Device name
Send confirmed payload with settings to port 3. Under payload choose "fields" and copy the following settings.
{"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}
Go to Application Data. Wait for settings to be applied (green checkmark and "confirmed ack") and check the next message on port 12 for any errors.
To speed up the process of applying settings you can manually reset the device.
To test the GPS function put the device outside. GPS antenna should face upside as seen on the following image.
When you are happy with the results, change settings to save battery. Repeat step 6 with following settings
{"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}
Next message on port 3 should show values 30 for "system_status_interval" and "system_voltage_interval".
PCB visual inspection
Primary test - Otii consumption analysis
Factory test - GPS
Antenna tuning
Tuned GPS test
Charge test (fence test)
Resin encapsulating
Final GPS test
Provisioning
Charging
Engraving
a) Command Prompt: Navigate to your folder with "otii-consumption-analysis" and run:
b) Visual Studio Code: Navigate to your folder with "otii-consumption-analysis" and run command:
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
Send payload via The Things Network Console - Downlink FPort 3
{"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}
{"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}
{"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}
Use Arduino IDE to upload Deep sleep firmware:
receive / assemble electronics
visual inspection
add GPS antenna
Deep sleep
add battery
assemble plastic shield and seal the edges with superglue and hot glue
resin casting in the mould (Electrolube PU resin UR5528, cca. 12g/piece)
engraving of serial numbers (01 0051 - 01 0065, laser parameters: power 30%, speed 150 mm/s)
tune LoRa antenna (120 mm length)
provisioning + send correct settings
final test
packaging
final check on TTN
shipping
Resin casting
1. Electrolube PU resin UR5528
2. cca 14g/piece
Test
Results
Number of satellites (On fix)
Max SNR
Time to fix cold
Test
Results
Number of satellites (On fix)
5
Max SNR
G10 (41dB)
Time to fix cold
50s
Test
Results
Number of satellites (On fix)
5
Max SNR
G10 (37dB)
Time to fix cold
65s
Test
Results
Number of satellites (On fix)
5
Max SNR
G10 (36dB)
Time to fix cold
2min 30s
Test
Results
Number of satellites (On fix)
Max SNR
Time to fix cold
Test
Results
Number of satellites (On fix)
Max SNR
Time to fix cold
Test
Results
Number of satellites (On fix)
10
Max SNR
47
Time to fix cold
33s
Resin casting
1. Electrolube PU resin UR5528
2. cca 7g/piece
Factory Test setup & values
receive / assemble electronics
visual inspection
add GPS antenna
Deep sleep
Value
Min
Max
Comment
alt
200
300
epe
0
50
hdop
DEFINE
lat
46.5535
46.5558
100m R
lon
15.6347
15.6369
100m R
lux
0
0
motion
satellites
3
12
snr
40
50
time_to_fix
5
15
Value
Min
Max
Comment
accelx
-100
100
accely
-100
100
accelz
-1100
-900
battery
3900
4200
battery_low
10
charging voltage
gps_on_time_total
0
1000
Max - end time
gps_resend
pulse_counter
0
pulse_energy
0
pulse_voltage
0
resetCause
external
watchdog-error
system_functions_errors
accelerometer_error
0
charging_status
1
gps_fix_error
0
gps_periodic_error
0
gps_triggered_error
0
light_error
0
system_state_timeout
0
temperature
voltage_fence_v
Value
Min
Max
Comment
gtw_id
eui-fcc23dfffe0a7553
rssi
-110
Number
Antenna frequency [MHz]
IRNAS frequency [MHz]
1
1580
1582
2
1582
1585
3
1584
1587
4
1586
1588
5
1588
1586
6
1590
1593
7
1592
1594
8
1594
1591
9
1596
1597
10
1598
1600
11
/
1602
12
/
1604
13
/
1606
14
/
1608
15
/
1610
Step-by-step production process.
primary testing
add GPS antenna
GPS antenna tuning (1592 MHz in air)
add tag extension 21,4 mm + tag (don't connect ¨batt¨ pins)
tape underneath the tag to protect holes for programming from the resin
add EMI shield (temporarily attached in one corner)
battery 3-pack assembly (3x Saft-14250, 3mm x 0.1mm welding strap)
remove all components from the top part of the board (above the EMI shield/next to antenova)
add zero-ohm resistor (next to antenova)
add foam protection - antenova (12x12x17mm) (note: should be added at the very end)
break off the charger
plastic enclosure production
washing of the enclosure
screw holes indentation on attachment plates
polishing the attachment plates
engraving of serial numbers (laser parameters: power 30%, speed 250 mm/s)
Electrolube PU resin UR5528
cca. 31g/piece
TPU leather flat belt production (BioThane Granite 230 TPU Coated Webbing, colour TN232)
width: 38 mm
length: 0.6 m
logo engraving (cutting: power 100%, speed 10 mm/s, scanning: power 40%, speed 250 mm/s)
Step-by-step production process.
GPS antenna tuning (1590 MHz in air for resin encapsulation)
add PCB spacers
add tag extension 26,6 mm + tag (don't connect "batt" pins)
add tape underneath the tag to protect holes for programming from the resin
add EMI shield (temporarily attached in one corner)
puncturing of batteries
add battery
charging testing
final GPS testing
put the tracker in deep sleep
seal the EMI shield all around with hot glue (the battery should be attached before the glue and the foam protection afterwards)
tape foam protection on the antenova (12x12x17mm)
resin casting in the mould (Electrolube PU resin UR5528, cca. 60g/piece)
engraving of serial numbers (laser parameters: power 30%, speed 150 mm/s)
prepare screws (2x DIN7985 M3x4 rust-free /tracker)
provisioning + send correct settings
final test
charge to 4.0V
packaging
final check on TTN
shipping
Step-by-step production process.
primary testing
add GPS antenna (1592 MHz in air)
add tag extension 25,4 mm + tag (don't connect "BAT" pins)
tape underneath the tag to protect holes for programming from the resin
add PCB spacers
add EMI shield (temporarily attached in one corner)
puncturing of batteries
add battery
add foam protection - antenova (12x12x17mm) (note: should be added at the very end)
plastic enclosure production
washing of the enclosure
screw holes indentation on attachment plates
polishing the attachment plates
engraving of serial numbers (laser parameters: power 30%, speed 250 mm/s)
Electrolube PU resin UR5528
cca. 55g/piece
TPU leather flat belt production (BioThane Granite 230 TPU Coated Webbing, colour TN232)
width: 38 mm
length: 1.0 m
logo engraving (cutting: power 100%, speed 10 mm/s, scanning: power 40%, speed 250 mm/s)
Step-by-step production process.
Irnas Lacuna space modem v0.2
add GPS antenna (1590MHz/1594MHz ??)
other side: RF connector (=elephant)
remove all components from the top - keep antenova
add 0-ohm resistor
add picoblade connector (see images 2-5)
battery 5-pack assembly
add wires to the battery pack
plastic enclosure production
washing of the enclosure
aluminium lid production
anodisation of the aluminium lid
screw holes indentation on attachment plates
polishing of the attachment plates
assembly of electronics inside the hardware
assembly of the hardware - enclosure + lid (screws: 14x DIN7985 M4x12 rust-free /tracker)
engraving of serial numbers (laser parameters: power 30%, speed 250 mm/s)
TPU leather flat belt production (BioThane Granite 230 TPU Coated Webbing, colour TN232)
width: 50 mm
length: 1.2 m
logo engraving (cutting: power 100%, speed 10 mm/s, scanning: power 40%, speed 250 mm/s)
TPU leather flat belt production (BioThane Granite 230 TPU Coated Webbing, colour TN232)
width: 50 mm
length: 1.2 m
logo engraving (cutting: power 100%, speed 10 mm/s, scanning: power 40%, speed 250 mm/s)
Step-by-step production process.
primary testing
add GPS antenna
GPS antenna testing
GPS antenna tuning (1592 MHz in air)
remove 2 components from the charger (positions D3 + U13)
remove all components from the top part of the board (above the EMI shield)
add zero-ohm resistor
add EMI shield (temporarily attached in one corner)
add tag extension 21,4 mm + tag (do not solder right-side battery/2,5V pins on the tag extensions)
tape underneath the tag to protect holes for programming from the resin
enlarge holes on the charger (2 mm drill)
battery 5-pack assembly (5x Saft-14250; 3mm x 0.1mm welding strap)
apply hot glue all around the EMI shield (to prevent the resin flowing underneath it)
add foam protection - antenova (12x12x17mm) (note: should be added at the very end, after the application of hot glue)
plastic enclosure production
washing of the enclosure
screw holes indentation on attachment plates
polishing the attachment plates
engraving of serial numbers (laser parameters: power 30%, speed 250 mm/s)
Electrolube PU resin UR5528
cca. 38g/piece
TPU leather flat belt production (BioThane Granite 230 TPU Coated Webbing, colour TN232)
width: 38 mm
length: 1.0 m
logo engraving (cutting: power 100%, speed 10 mm/s, scanning: power 40%, speed 250 mm/s)
Step-by-step production process.
primary testing
add GPS antenna
GPS antenna tuning (1590 MHz in air)
add EMI shield (temporarily attached in one corner)
battery 6-pack/board assembly (6x Saft-17500)
add connectors (both boards; NOTE: the connectors should be soldered onto the board before the batteries)
remove all components from the top part of the board including antenova
add zero-ohm resistor next to antenova
add connector (RF coaxial 50 ohm / U.FL; position: con2)
LoRa antenna tuning
break off the charger
assembly
provisioning
plastic enclosure production
washing of the enclosure
aluminium lid production
anodisation of the lid
indentation of the screw holes on the attachment plates
polishing the attachment plates
assembly of the hardware - enclosure + lid (screws: 8x M4x12 + 8x M4x16 rust-free /tracker)
engraving of serial numbers (laser parameters: power 30%, speed 250 mm/s)
TPU leather flat belt production (BioThane Granite 280 TPU Coated Webbing, colour BL281)
width: 101 mm
length: 4.0 m
logo engraving (cutting: power 100%, speed 10 mm/s, scanning: power 40%, speed 250 mm/s)
GPS antenna tuning (1590 MHz in air for resin encapsulation)
add PCB spacers
add tag extension 33,6 mm + tag (don't connect "batt" pins)
add fence addon with 26,6 mm tag extension - for initial fence test, connect the fence addon with wires
add tape underneath the tag to protect holes for programming from the resin
add EMI shield (temporarily attached in one corner)
puncturing of batteries
add battery
fence testing
charging testing
final GPS testing
put the tracker in deep sleep
seal the EMI shield all around with hot glue (the battery should be attached before the glue and the foam protection afterwards)
tape foam protection on the antenova (12x12x17mm)
Januar 2021 batch - disconnect 2.5V / remove resistor
For initial fence test, connect the fence addon with wires. (Jan 2021 - only GPIO1 and GND on lion board)
Do NOT perform the fence test when completely assembled without the resin.
Each fence sensor is calibrated to output the same energy level on a reference source. These measurements do not represent measurements in kV and must be scaled to that range in the decoder.
Send to port 93 a 2 byte value with the calibration factor multiplied by 10000; For example, the sensor is returning 1300 (pulse_voltage), we wish to calibrate this to 1800. Calculating from this 1.3846 factor, multiplied is 13856, convert this to hex 0x3616. Send this via downlink. To reset the values send 2 byte value 2710 (hex 0x2710) to port 93.
aluminium casting mould production
resin casting in the mould
engraving of serial numbers (ProductDeliverySerial-SmartParks Excel Worksheet, use ranger .rld file) and high voltage inscription (power 30%, speed 150 mm/s)
manufacturing of fence monitor cover
engraving of inscription on the plastic cover (laser parameters: power 30%, speed 250 mm/s)
Assembly
Electrolube PU resin UR5528
cca. 75g/piece
Final test
Fence test
Provisioning
Calibrating
Charging
Fence monitoring solution is built to measure the energize pulse voltage in real-time, such that various events on the fence can be detected.
The logic is built such that the pulses generated are acquired by the Lion tracker and analysed. A typical pulse is shown below
The measurement algorithm works by detecting the individual pulses and calculating various parameters:
Detect 5 pulses in 10s and use all measurements from each pulse to calculate the average
Peak is calculated as the average peak value of 5 pulse, shown as a raw value 0-255
Peak values can have quite some noise and may not be the best measure
Energy is calculated as the sum of all samples in a pulse, per pulse average is calculated
Energy is a better value as we are evaluating how much energy is delivered across the fence and is what deters the animals.
Each fence sensor is calibrated to output the same energy level on a reference source. These measurements do not represent measurements in kV and must be scaled to that range in the decoder.
Send to port 93 a 2 byte value with the calibration factor multiplied by 10000; For example, the sensor is returning 1300 (pulse_voltage), we wish to calibrate this to 1800. Calculating from this 1.3846 factor, multiplied is 13856, convert this to hex 0x3616. Send this via downlink. To reset the values send 2 byte value 2710 (hex 0x2710) to port 93.
Settings, values, commands and messaging structures.
Settings, values, commands and messages are determined by the settings.json structure, that is parsed in build time to several .h and .c files, as described below.
It contains the following main fields:
fw_version
major
minor
hardware
type - firmware type, for example "wisentedge_nrf52840"
version
major
minor
settings
port - port on which settings are sent and received from
type - settings type, based on tracker type
setting of the form:
setting_name
id - for "basic settings" from 0x01 to 0x0F, for "advanced" from 0x11 to 0x9F
enabled - true or false
default - default value
min - min value
max - max value
length - in bytes
conversion - data type, possible options:
uint8, uint16, uint32, int8, int16, int32
float
byte_array
bool
commands
port - port on which commands are sent and received from
commands of the form:
command_name
id - from 0xA1 to 0xCF
length - length of send command value, if 0 none
conversion - data type of send value, if there is non uint8 is used
value - default value, 0 if none
values
port - port on which settings are sent and received from
values of the form:
value_name
id - from 0xD1 to 0xEF
enabled - true or false
default - default value
min - min value
max - max value
length - in bytes
conversion - data type, possible options:
uint8, uint16, uint32, int8, int16, int32
float
byte_array
bool
messages
messages of the form:
message_name
port - to send message on
id - from 0xF1 to 0xFF
length - in bytes
conversion - data type, possible options:
uint8, uint16, uint32, int8, int16, int32
float
byte_array
bool
Python parser py2h.py
and validation script validate_data.py
are used to convert settings.json
file to c files.
In particular the following files are generated:
hardware_def.h
- containing only definitions from "hardware" field
settings_def.h
and settings_def.c
- containing settings structure and auto-generated functions for access and writing to structure
commands_def.h
and commands_def.c
- commands defines and settings
values_def.h
and values_def.c
- containing main values structure and auto-generated functions for access and writing to structure
messages_def.h
and messages_def.c
- message defines and messages
All auto-generated files are equipped with /* AUTOGENERATED FILE - DO NOT MODIFY! */
comment. Sections below describe content of each generated file and helping files.
Packing process and preparation for shipping.
Auto-generated files values_def.h and values_def.c containing all values defined in settings.json file and functions for getting and setting values.
main_values
struct is auto-generated to contain all values as defined in settings.json file. In addition to value structs containing settings, it contains:
n_values - number of values
values_id - array containing all values ids
values_length - array containing all values lengths
Values are defined using same values structs as are used for settings and defined in settings_types.h
.
Main_values
is global main_values
struct, accessible in all threads and modules that contains all tracker functionality values.
Values_settings
is global values_settings
struct , accessible in all threads and modules that contains settings for receiving and sending values.
void *get_value_struct_by_id(uint8_t id)
- returns value struct, provided ID of value.
int get_value_by_id(uint8_t id, uint8_t *data)
- returns value from the value struct, provided ID of value.
int set_value_by_id(uint8_t id, uint8_t *data, uint8_t len)
- sets value, provided value id, new value in form of a byte array and its length. Function returns 0 if ok and -1 if error in provided length.
For all values defined in settings.json, structs of appropriate type are auto-generated and initialised with provided data. Main_values
struct is initialised with generated values structures.
Described functions definitions are auto-generated.
Interface files for utilising auto-generated settings files from the main thread and firmware modules.
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.
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.
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 - commands are executed in int execute_command_message(uint8_t port, uint8_t id, uint8_t len, uint8_t data, uint8_t *response_message)
function.
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
CMD_SEND_STATUS - returns status message. See Status chapter for detailed description.
CMD_SEND_POSITION - returns gps coordinates values.
After execute_message
returns length of the response, non-zero responses are stacked in single response message, thath is returend via approprite port, determined in execute_message
function. New port is stored as a first entry of final response. parse_message
returns length of the response message or negative error code.
Auto-generated files messages_def.h and messages_def.c containing all message forms as defined in settings.json file.
Auto-generated defines for all messages ID-s. Based on message ID, appropriate message is composed and returend in firmware. All defines are of the form MSG_XXX_ID
.
main_messages
struct is auto-generated to contain all messages of cmd_message
struct type as defined in settings.json file. In addition to message structs containing different message forms, it contains:
n_values - number of values
messages_id - array containing all messages ids
messages_length - array containing all messages lengths
messages_port - array containing all port numbers on which message is sent
Main_messages
is global main_messages
struct, accessible in all threads and modules that contains all defined message types.
status.h and status.c files define status structs and form in which firmware parameters are stored and periodically sent via LoRa and as BLE advertisement.
Status can consit of several building blocks, defined by FW and tracker type. Each building block is a byte array, where each byte reperesents a values as defined in governing status structre.
Total status cannot exceed 24 - DEVICE_NAME_LEN bytes, as this is the maximum length of BLE advertisment packet. Currently max length is set to 19 bytes.
Main building block is defined by statusData_t struct:
that can be compressed in byte array by
Individual values are defined as:
reset_cause - TBD
system_functions_errors - TBD
battery = (battery_mV - 2500)/10
charging_voltage - TBD
temperature - TBD
uptime - uptime in hours, with 255 turnaround
acc_x - abs(acc_x*10)
acc_y - abs(acc_y*10)
acc_z - abs(acc_z*10)
Total length of main status part is 9 bytes.
If #define STATUS_LR
is enabled, additional LR chip status block is added.
where:
satellites - nr. of satellites used in last LR fix
last_fix - TBD
Total length of LR buildning block is 2 bytes.
If #define STATUS_UBLOX
is enabled, additional UBLOX chip status block is added.
where:
lat - latitude defined as:
lat[0] = (lat+90)*1000 >> 16
lat[1] = (lat+90)*1000 >> 8
lat[2] = (lat+90)*1000
lon - longitude defined as:
lon[0] = (lat+180)*1000 >> 16
lon[1] = (lat+180)*1000 >> 8
lat[2] = (lat+180)*1000
time - TBD
Total length of UBLOX status is 8 bytes.
To obtain new status message for either BLE advertisement or LR status send, int get_status_message(uint8_t *message, uint8_t max_len)
function updates all values with int update_status_message(bool lr_status, bool ublox_status)
function and returns message length.
max_len
can be passed as an argument, as maximal length of message depends on the send format. If status message is too long, only max_len
message will be returned.
type_conversion.h and type_conversion.c files define conversion functions that convert all used var types from and to byte arrays, using little endian rule.
Since settings and values are stored in nvs storage in byte array form, as well they are sent via LoRa and BLE messages, functions are used to convert byte arrays to data data format used in firmware and back.
Provided functions for byte array to variable type conversion:
uint32_t bytes_to_uint32_t(uint8_t bytes)
int32_t bytes_to_int32_t(uint8_t bytes)
uint16_t bytes_to_uint16_t(uint8_t bytes)
int16_t bytes_to_int16_t(uint8_t bytes)
int8_t bytes_to_int8_t(uint8_t bytes)
uint8_t bytes_to_uint8_t(uint8_t bytes)
void bytes_to_float(uint8_t bytes, int16_t data[])
uint8_t bytes_to_byte_array(uint8_t* bytes, uint8_t length)
Provided functions for variable type to byte array conversion:
void uint32_t_to_bytes(uint8_t bytes, uint32_t data)
void uint16_t_to_bytes(uint8_t bytes, uint16_t data)
void uint8_t_to_bytes(uint8_t bytes, uint8_t data)
void int32_t_to_bytes(uint8_t bytes, int32_t data)
void int16_t_to_bytes(uint8_t bytes, int16_t data)
void int8_t_to_bytes(uint8_t bytes, int8_t data)
void bool_to_bytes(uint8_t bytes, bool data)
void float_to_bytes(uint8_t bytes, int16_t data[2])
void byte_array_to_bytes(uint8_t bytes, uint8_t data, uint8_t length);
NVS storage system is used for permanent settings and values storage. nvs_storage.c and nvs_storage.h files provide user interface for accessing and storing values.
Values and settings are stored in NVS system by their assigned ID. IDs are ordered as follows:
Each setting, defined in Main_settings struc is stored by setting ID, defined in Settings.JSON file.
Basic settings IDs 0x01 - 0x0F
Advanced settings IDs 0x11 - 0x9F
Other values that needs to be permanently stored for fimware operation are shifted for 8 bits and start with 0x0100.
nvs_storage.h contains list of stored values IDs, that are not part of Main_settings:
STORAGE_unix_time 0x0100
STORAGE_latitude 0x0101
STORAGE_longitude 0x0102
STORAGE_altitude 0x0103
NVS storage is initialised with int nvs_storage_init(void)
function, returning 0 on success or negative error code.
To clear whole NVS system, int nvs_storage_clear(void)
function is used. To delete only single entry by ID int nvs_storage_delete(uint16_t id)
can be used.
To read from NVS by value ID int nvs_storage_read(uint16_t id, const void *data, size_t len)
function returns 0 on sucess.
To write to NVS storage int nvs_storage_write(uint16_t id, const void *data, size_t len)
function attempts to write new or existing value.
Between thread communication.
Zephyr solution with message queue objects is used for between thread communication. Communication interface is defined in thread_com.h
and thread_com.c
files.
Two queues are defined in .c file:
setting_que - handling setting message communication (received messages via BLE and LoRa from user, defining new settings or sending in command messages)
message_que - handling response messages from firmware to user (returning values and requested messages)
Each buffer is equipped with put and get function. Each queue is defined to contain max of 2 messages, defined by a message struct
providing receiving thread with message id, its actual length and byte array message. Max message length is determined by
#define MAX_MES_LENGTH_BYTES 255
Message id-s are defined in definitions.h
file.
When new message is send by a thread, depending on used queue functions
are used. Put function takes id, message and its length and copy them into message_struct, provided message is not to long. If message buffer is full of non-opened messages, function purges the oldest message from the buffer.
Provided there is unread message, function copies its content and id to provided buffers and return message length. Message is deleted from queue.
Function is non/blocking and returns 0 if there is no message or negative error code on error. New message can be retrieved from the buffer by using get functions
Instructions on how to send commands to EdgeTracker from app or via LoRaWAN communication.
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.
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:
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!
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 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:
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:
or
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.
Reboot tracker.
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.
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:
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.
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.
Reboot Ublox GPS module.
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.
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:
Reset initial reference position of the tracker to hardcoded position. (not recommended to use)
Reset initial reference time to hardcoded value. (not recommended to use)
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!
Revert all setting to defoult values. Keep in mind that LR keys are going to be deleted as well!
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.
Obtain LR GNSS message and send it via LoRa communication.
Set reference location and time of the tracker.
Get rf scan - not supported at the moment!
Get aggregated data in wifi scan. Tracker will response with "msg_wifi_scan_aggregated" (see next chapter).
Get aggregated data of BT scan. Tracker will response with "msg_ble_scan_aggregated" (see next chapter).
Get almanac age - not supported at the moment!
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.
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.
Not yet supported
Get BT MAC addres from the device.
Device responds with "msg_mac_id" (see next chapter).
Perform Ublox position fix and returnposition message.
Reset LR module.
Clear all data from external flash.
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.
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.
Send message to device to be send via LR.
Up to 45 bytes are supported.
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.
Send on port 1. GNSS data message. See ttn-decoder for format.
Send on port 2. Message containing Ublox GPS fix and additional fix data. See ttn-decoder for format.
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:
Status message, send on port 4. See ttn-decoder for format.
Message, containing satellite data, used in GNSS LR position fix. Send on port 5. See ttn-decoder for format.
Message, containing satellite data, used in Ublox position fix. Send on port 9. See ttn-decoder for format.
Message containing top-3 scanned wifi results. Send on port 6. See ttn-decoder for format.
Message containing scanned wifi results from single scan. Send on port 10. See ttn-decoder for format.
Message containing top-3 scanned BT results. Send on port 7. See ttn-decoder for format.
Message containing all results from single BT scan. Send on port 11. See ttn-decoder for format.
Not supported.
Almanac age of the format:
Message contating MAC id of the form:
Message containing last obtained position in the form:
Message format for sending flash logs to port 29. See ttn-decoder for format.
Features described individualy
Feature
Description
Device location
The device track location using:
LR1110 quick tracking
uBlox GPS tracking
Bluetooth connectivity
The device is able to connect over BLE to:
send log data
set device configuration
upgrade device firmware DFU
LoRaWAN connectivity
The device communicates over LoRa with a gateway to:
send current data status
send log data
set device configuration
Movement detection
The device detect movement with an accelerometer so the device knows when it is moving.
Battery status
The device periodically measures the battery level for a status report.
V0.1 - Draft of instructions
Open Collar RhinoPuck product developed by Smart Parks and IRNAS is a round implantable disk for use with side-mount method in larger rhino horns. This innovative shape of the tracker allows for use of a round drill along with the epoxy material for installation and as such represents a quick method for tracker installation.
OpenCollar Edge firmware with advanced tracking features
Compatible with SmartParks Connect Bluetooth Android for device configurations
868MHz LoRaWAN connectivity for long range data transmission
OTAA activation with any network
Keys configurable through BLE
Precise GPS positioning with uBlox M8
Precise low-power GPS positioning with LR1110
Large battery capacity with 2x Saft LS17330
Robust potted enclosure for installation into 50mm diameter hole
RhinoPuck tracker unit
Android smartphone with Smart Parks Connect application
Vettec Adhereâ„¢ 210cc Adhesive Color: Black Item No: 47150
Vettec Mixing Tip Item No: 46900
Vettec Diamond dispensing gun Item No: 748-0002-074
Battery powered drill
50mm diameter drill bit for hardwood or similar
Chizzle for hardwood
Prepare for deployment: Test connection between Android app and the RhinoPuck unit
Drill the 50mm hole from the side of the horn about 10cm from the base
Fix the hole outer wall such that the 48mm puck can be inserted easily
Insert RhinoPuck, such that the point up arrow points to the sky when rhino is in normal position
Use the Vettec glue around the outer edge
Fill the hole completely with Vettec. Note you should not stop the dosing process, because it becomes hard very quickly. Note get quite hot.
Configure the RhinoPuck via the BLE app to the
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.
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
Goal: Validate performance of best version by permanently installing
Testing on the real animal
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.
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
Drill the hole in the horn
Install the tracker with the correct side up
Plug the hole with the dummy unit filled with Vettec
Place outdoors for 1 hour duration
Remove and repeat for next unit
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.
Device configuration settings
Device settings are divided into three layers. This is enabling easier user configuration and still providing full control over the device.
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.
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.
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
Testing of EVE EF651625 Lithium Thionyl Chloride Square Battery
Minimal current: 5mA
Peak current: 70mA
Pulse duration: 6s
Peak duration: 150ms
Avg. current: 5,85mA
Nominal capacity: 750mAh
Actual measured capacity: 260mAh
Battery production date: 02-2019
Testing date: 02-2021
Extensive testing has been performed with
EVE EF651625 750mAh cells which have shown very poor performance - 8600 LR1110 GPS positions + LoRaWAN messages (6 days sending a position every minute)
Saft LS14250 1200mAh - 72000 LR1110 GPS positions + LoRaWAN messages (70 days sending a position every minute) Expected difference in capacity at this load profile is 2x, but the performance is 10x difference
ElephantEdge PCB design
EdgeImpulse support
IMU + microphone
Enclosure
Avnet IoT connect
Field testing/demos on animal
BLE: Nordic Semiconductor nRF52840
Options:
n52840 standalone
uBlox NINA-B30x integrated module
LoRa/GPS/WiFI: Semtech LR1110
GPS: uBlox M8G
Antenna:
BLE/WiFi combined
RF things LoRa antenna suitable for Lacuna
VHF antenna port
GPS ceramic patch tuned antenna
Taoglas or Maxtena
Sensors:
3D Accelerometer: LIS2DW12
6D IMU Accelerometer + Gyro: LSM6DSL
6D eCompass: LSM303AGR
Microphone:
Analog: MP23ABS1
Digital: SPK0415HM4H
Water detect switch
Real-time data storage:
QSPI NOR flash
ML raw data storage:
WD Edge microSD storage SDSDQAB-016G
Specs for other purposes
RockBlock option
Use as PiRa
Gunshot detection
Dimensions
50mm x 30-40mm (ideal for LS17500 batteries)
65mm x 30mm (ideal for 18650 batteries)
63mm x 40mm (ideal for current wisent tracker)
68mm x 30mm or 50mm x 35mm (ideal for current elephant tracker)
ideal size: 50mm x 35mm
ideal size: 63(65)mm x 30mm
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.
Very good user experience and reliability
System simplicity
Re-usability and community support
OpenCollar tracker advanced is the evolution of the Lion tracker with additional new features and a solution for long term evolution. Particular hardware implementation of the solution may add or remove various features.
Expansion modules are standalone units without processing that add extra features to the system:
Device profile
Description
Default tracker
Profile with default tracking values.
Lion tracker rechargable
Profile for wild-life Lion tracking
Basic settings
Update interval precise (per hour)
ublox fix interval
almanach update
...
Update interval low-power (per hour)
Motion trigger (threshold or disabled)
Advanced only: true
Advanced setting
z thresholds
motion x z
Cargo tracker
Profile for ship container tracking
Wisent tracker
Profile for wiled-life Wisent tacking
Custom profile
One profile left for the user to customize it as preferred.
etc.
High-Level Settings
ID
Description
Min
Max
Default
GPS scan period
0x002
Scan period of GPS data for the tracker device.
10 sec
1 day
60 sec
LoRaWAN send period
0x002
Send period of position data and battery level over LoRaWAN network
10 sec
10 days
120 sec
BLE advertising period
0x003
Advertising period of BLE data
20 ms
10.24 sec
2 sec
etc
Low-Level Settings
ID
Description
Min
Max
BLE adv strength
0x020
The signal strength of BLE advertising data
8dBm
-20dBm
UART Baud
0x021
UART baud rate speed
9600
115200
etc.
Activity | Description | Status | Month | Media |
ElephantEdge PCB | First revision of hardware with Nordic semiconductor | August | Blog |
EdgeImpulse nRF52 | Integration of EdgeImpulse support | August | Webinar demo |
GPS optimization | uBlox M8G driver development with Zephyr | August | Blog |
Firmware development | Main section of firmware development | September | Blog |
Deliverable | ElephantEdge 0.1 release | September | Blog |
Memory integration | Western digital storage implementation | September | Webinar |
Avnet Iot connect | Integration of AvnetIoTconnect | October | Webinar |
Antenna tuning | Tuning of the selected antenna systems | October | Blog |
ElephantEdge PCB | Second revision of hardware for field deployment | October | Blog |
Smartphone app | Integrate support with the smartphone app | November | Blog/Demo |
Deliverable | ElephantEdge 1.0 release | November | Blog |
Field deployment | Testing on animals | November | Video |
Deliverable | Field testing report and Industrial demo | December | Webinar |
Partner | Engineering support required |
EdgeImpulse/Nordic | Demo integration in Zephyr RTOS and code examples, end-to-end |
Microsoft/AvnetIoTconnect | IoT connect integration support |
uBlox | M8G integration with Zephyr RTOS |
uBlox | GPS power optimization and performance improvements |
Western digital | Memory element support on Zephyr RTOS |
Taoglas | Engineering support for antenna testing |
Expansion module | Description |
Drop-off controller | Drop-off controller implements necessary features to control mechanics of the drop-off mechanism, such that the trackers can detach. |
HV fence monitor | High-voltage monitoring interface to monitor the electric fences |
Marine monitor | Pressure sensor, salt water switch and other sensors |
Biosensors | Sensors to monitor body temperature, heart-rate.... |
Camera | Camera to acquire images |
FW1 Sprints | Due date | Deliverable |
S1: Low-power DFU upgradable NUS firmware on nRF52840
| 31.07. | Codebase with BLE features on new SDK (NCS1.3.0) |
S2: config and drivers:
| 07.08. | Device configuration and driver code |
S3:
| 14.08. | Device with basic main logic and connectivity |
S4: main logic and testing (vid, vojislav, eva) | 21.08. |
S5: testing (vid, vojislav, eva) | 28.08. |
FW2 Sprints | Due date | Deliverable |
S1: HAL operation and settings
| 05.10. | Device working in low power mode with basic tracking and settings (set GPS interval via BLE and LoRaWAN) send data over LoRa and be low power. |
S2:
| 19.10. | Device ready for customer field testing |
Solution | Status | Progress |
Lion tracker basic | Production |
Rhino tracker basic | Production |
OpenCollar tracker advanced | Concept |
Product | Description | Status |
LionPCB | Current Lion solution |
RhinoPCB | Current Rhino solutions |
PangolinPCB | Current Pangolin tracker |
New product |
RhinoEdgePCB | New product |
ElephantEdgePCB | New product |
Product | Version | Content |
Wisent tracker |
Rhino edge horn implant | RhinoEdgePCB |
Rhino edge skin implant | RhinoEdgePCB |
Elephant edge tracker | ElephantEdgePCB |
Industrial edge tracker | ElephantEdgePCB + AvnetIOTconnect |
Milestone | Timeline | Status |
M1 WisentEdge tracker initial prototype development with LR1110 with the basic set of features | 6w |
Test: IRNAS field testing |
M2 WisentEdge tracker fully-featured device ready for deployment | 4w |
Test: SmartParks field testing |
M3 RhinoEdge tracker initial prototype development with LR1110 with basic set of features | 4w |
Test: IRNAS field testing |
M4 RhinoEdge tracker development of Horn and Skin implant | 4w |
Test: SmartParks field testing |
M5 RhinoEdge tracker Horn and Skin implant RF tuning and optimization | 4w |
Test: PeaceParks field testing |
M7 Consolidation of technology across all solutions
| 6w |
Feature | Description | Status | Milestone |
Enables the tracker to be connected via BLE to smartphone and configured via an application. Enables reading logged data and configurations. Enables DFU firmware upgrade | M1 |
LoRaWAN connectivity for low power long-range communications, the primary means of data transmission | M1 |
Special case LoRaWAN connectivity to Lacuna satellite network with an additional antenna for this application | TODO | M6 |
Low-power GPS acquisition for real-time tracking, implemented with LR1110 | M1/M2 |
Standard GPS receiver enabling high-precision real time tracking, almanac updating and other advanced features. Used sparsely to conserve power | M1 |
WiFi receiver in LR1110 to implement beacon scanning to detect nearby WiFi hotspots for positioning | M3 |
Low-power VHF transmitter for legacy animal tracking applications, implemented with LoRaWAN transceiver LR1110 | TODO | M2/M4 |
3 axis accelerometer to detect orientation and motion, triggering events based on results | M1 |
Monitoring of battery status | M1 |
Charging input if used with rechargeable batteries, enables precise voltage monitoring of the input voltage 5-30V DC | M2 |
Support for expansion sensor modules for example high voltage fence monitoring or other solutions (I2C+GPIO port) |
Memory to store measurements over a longer period of time | M2/M4/M6 |
BLE LoRaWAN message communication | Send a short message from the APP via BLE via LoRaWAN and receive it back | TODO |
PAX counter | Enable monitoring of BLE, WiFi to determine proximity of humans | TODO | M2 |
Device-to-device proximity | Determine the proximity between two trackers to trigger actions on separation or contact. Implement with LoRa | TODO | M4 |
EdgeImpulse support | Machine learning EdgeImpuls sensor data processing and evaluation + Smartphone app for training and user workflow | TODO | M6 |
IMU support | 9 axis IMU | M6 |
Microphone | On-board microphone to record sounds and use in conjunction with EdgeImpulse | M6 |
Avnet IoT connector | Connection with the platform | TODO | M6 |
Detect nearby cell-phone activity based on the RF input of LR1110 with advanced algorithms analyzing the data | Idea | HackThePoacher |
Milestone | Due date | Deliverable |
Milestone FW1 | 28.08. |
Milestone FW2 | 19.10. | Basic device ready for field testing |
Milestone | Description | Status |
Upgrade of existing lion tracker with new cpu and lora module |
TBD milestones |
Provisioning firmware files - Keep these files secure as they contain keys
Always use .hex files with this software.
To upload new firmware, go to Step 6, steps 3-5 require manual provisioning
Select the provisioning firmware binary first if you have done steps 3-5.
Step 9 is necessary only when erasing sectors and uploading provisioning binary (steps 3-5 and provisioning in step 6)
+ belt + drop-off
M2
Basic device tracker with the and
STM32 ST-Link Utility software
Firmware release files from
Go to Step 6 and now program the release firmware.
Use to upload Deep sleep firmware:
Auto-generated files commands_def.h and commands_def.c containing all commands defined in settings.json file.
Auto-generated files settings_def.h and settings_def.c containing all settings defined in settings.json file and functions for getting and setting values.
Returns data type for setting with specified ID.
Returns value struct based on setting ID.
main_settings
struct is auto-generated to contain all settings as defined in settings.json file. In addition to value structs containing settings, it contains:
n_settings - number of settings
settings_id - array containing all settings ids
settings_length - array containing all settings lengths
Main_settings
is global main_settings
struct, accessible in all threads and modules that contains all settings data.
Settings_defines
is global settings_defines
struct , accessible in all threads and modules that contains settings for receiving and sending settings.
void *get_setting_struct_by_id(uint8_t id)
- returns setting value, provided ID of setting.
int set_setting_value_by_id(uint8_t id, uint8_t *data, uint8_t len)
- sets value of setting, provided setting id, new value in form of a byte array and its length. Function returns 0 if ok and -1 if error in provided length.
For all settings defined in settings.json, structs of appropriate type are auto-generated and initialised with provided data. Main_settings
struct is initialised with generated setting structures.
Described functions definitions are auto-generated.
Settings module controls stored values, settings and messaging forms. Structures are auto-generated at build time, allowing for convenient modification when new HW or tracker is introduced.
Structure is ilustrated on the diagram below and further explained in the following sections.
Create an application on https://console.cloud.thethings.network/
Register end device on Manual configuration with MAC V1.0.3
Enter device basic settings:
Name is the id as seen via BLEsp******
AppEUI is set to all zeroes 0000000000000000
DevEUI value is what you read via BLE from the app
Frequency Plan: Select as appropriate, Europe SF9 for RX2
Copy the AppKey to the tracker via the BLE app
Register the tracker and reboot the device for it to join
Most files, containing settings, values, commands and messages data and forms are auto-generated at build time, as they depend on Settings.json file and are dependent on specific tracker type.
Python parser py2h.py
and validation script validate_data.py
are used to convert settings.json
file to c files.
In particular the following files are generated:
hardware_def.h
- containing only definitions from "hardware" field
settings_def.h
and settings_def.c
- containing settings structure and auto-generated functions for access and writing to structure
commands_def.h
and commands_def.c
- commands defines and settings
values_def.h
and values_def.c
- containing main values structure and auto-generated functions for access and writing to structure
messages_def.h
and messages_def.c
- message defines and messages
All auto-generated files are equipped with /* AUTOGENERATED FILE - DO NOT MODIFY! */
comment. Sections below describe content of each generated file and helping files.
Structures definitions for usage in settings, values, messages and commands. Defined in settings_types.h file.
settings_types.h
file contains all structures and enums used in settings module, that are used in subsequent files and do not need to be auto-generated at build time.
enum conversion_t
defines all possible data types used in settings:
UINT8_T = 1,
UINT16_T = 2,
UINT32_T = 3,
INT8_T = 4,
INT16_T = 5,
INT32_T = 6,
FLOAT = 7,
BYTE_ARRAY = 8,
BOOL = 9
hw_type
defines all possible HW versions that are supported.
wisentedge_nrf52840 = 1
fw_type
defines all possible FW versions that are supported in FW.
lion_tracker = 1
Structures containing settings governing settings, values, messages and commands communication and fields. Mainly containing port number for specific type.
fw_version
major
minor
hw_version
hw_type
(enum)
major
minor
settings_defines
- settings for basic settings values
port
fw_type
advanced_settings
- settings for advanced settings values
port
commands_settings
port
values_settings
port
Definitions of structs holding values and settings of certain types:
value_uint8
value_uint16
value_uint32
value_int8
value_int16
value_int32
value_float
value_byte_array
value_bool
Each structure is of the same format containing:
uint8_t id
- id of setting or value
bool enabled
- is setting or value enabled
def_val
- default value of certain type
min
- min value of certain type
max
- max value of certain type
uint8_t len
- length of type in bytes
conversion_t conversion
- data type
Note that float values are stored as int16_t array[2]
with encoding:
array[0] = (int16_t) float_val
and
array[1] = (int16_t) (float_val - array[0]) * 10000
Functionality description of OpenCollar Edge trackers.
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:
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.
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
When lora message is sent, tracker will blink 1x GREEN
When magnet is either set or removed, tracker will blink 10x GREEN
When tracker is charging, RED led will blink constantly
When tracker is charging and battery gets full, GREEN led will turn on
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).
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 ...)
Type: data flags (0X01) of length 1
Type: device name (0X09) of length 8 bytes
Device name consist of "SP" and last 3 MAC address bytes, all in ascii 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 BT connection is established, otherwise it will disconnect. If pin is forgotten or unknown, user can unlock the device with 16 bytes long AppKey.
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.
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 send to LoRa or store to flash, 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 send to LoRa or store to flash, real time scan message can be send to LoRa or store to flash.
"ble_scan_duration" with id 0X1B: single scan duration in ms. Keep in mind it needs to be as least as long as advertisement period, to catch other devices signal.
"ble_scan_filter" with id 0X1E: filtering of scanned BT data can be implemented, before data is stored to flash or send via LR. In particular, the following values of this setting are applicable:
0 - no filter is implemented
1 - filter OpenCollar devices
2 - filter smartphones
To disable BT scan, set both "ble_scan_interval" and "ble_scan_send_interval" to 0.
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 store and send flags. More on messages structure and send/store flags can be found under Messages section.
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 store and send flags. More on messages structure and send/store flags can be found under Messages section.
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).
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.
"device_eui" with id 0X11 - 8 bytes device eui, read from lr1110 module on init.
"app_eui" with id 0X12 - 8 bytes app eui, set during the provisioning procedure or later on in app or via user command.
"lr_join_flag" with id 0X22 - uint32 value, where each bit represents flag for respective lora send port. If bit is set to 1, LR module will initiate join procedure when message is send to that port if device is not already joined. If set to 0, device will not attempt to join when sending on particular port.
"lr_confirm_flag" with id 0X23 - uint32 value, where each bit represents flag for respective lora send port. If bit is set to 1, LR module will send message as confirmed. If set to 0, device will send unconfirmed message. NOT active in latest FW version (1.6)!
"lr_max_confirm_fail" with id 0X24 - uint16 value, representing max nr. of times we device can send confirmed message without getting response, before re-initing LR module and re-attempting join process. NOT active in latest FW version (1.6)!
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 here.
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)!
"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 User commands instructions.
Maximum message length is defined by the ADR profile setting and chosen region. To see different ADR options refer to maximum data rate guide. 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 User commands instructions.
Set region affect several region-based settings and operational differences. Difference in join procedure is described in the Join procedure section, while differences in max payload length are outlined in the Message length section. For all regional differences refer to guide.
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 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 LR GPS Messages.
If error code 0X07 is returned, device did not find any satellite during GNSS scan. Error code 0X08 indicates Almanac is to old.
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).
... stack as many as available
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.
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.
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 send to LoRa or store to flash, 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 send to LoRa or store to flash, real time scan message can be send to LoRa or store to flash.
Currently scan type is not user configurable and is pre-set to LR1110_MODEM_WIFI_TYPE_SCAN_B_G_N.
To disable WiFi scan, set both "wifi_scan_interval" and "wifi_scan_aggregated_interval" to 0.
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 store and send flags. More on messages structure and send/store flags can be found under Messages section.
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 store and send flags. More on messages structure and send/store flags can be found under Messages section.
User messaging via LoRaWAN is supported. User can send message of length of up to 45 bytes via app.
Message is send from app via command: C4 Cmd send lr message.
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.
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_count
setting with id 0x32. Repeated send is separated by lr_messaging_retry_interval
setting (id 0x31) in seconds.
Format of the message is msg_lr_messaging
and is send to the lr messaging port.
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 msg_lr_messaging
and must be send to the lr messaging port.
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
Write the command: 90 08 05 41 42 43 44 45 01 01
Press Schedule downlink
Incoming messages, stored on device, can be red by the user via app. Messages are send in the form of msg_lr_messaging_timestamp
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.
On some HW types, RangerEdge v1.4 in particular, RF scanning board can be attached and RF scans performed.
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:
"port_ublox_gps": 2,
"port_settings": 3,
"port_status": 4,
"port_wifi_scan_aggregated": 6,
"port_rf_scan": 8,
"port_ublox_sat_data": 9,
"port_wifi_scan": 10,
"port_flash_log": 29,
"port_values": 30,
"port_messages": 31,
"port_commands": 32
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:
32 bit integer, where each bit determines if messages associated with port on corresponding bit is or is not send via LoRaWAN, when generated.
32 bit integer, where each bit determines if messages associated with port on corresponding bit is or is not stored to flash, when generated.
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
byte 2: destinationID
0X00 - message to the host (errors, warnings)
0X01 - message to the GNSS solver (valid nav message)
byte 3: if message to the host, error code:
0X07 - no satellites detected in the scan
0X08 - almanac to old
byte 3-end: if message to the solver, NAV payload
Message of type
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.
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
byte 3 - end:
id
cnr
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!)
repeated for each included contact, total length of 9bytes per contact:
byte 0 - 2: last 3 bytes of MAC address
byte 3: RSSI (best value measured in interval for specific contact)
byte 4: count - nr. of times contact was observed on BT scan in interval
byte 5-8: timestamp when best rssi value was scanned
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
byte 6: nr. of unique BT scan results during latest ble scan contained in this message
repeated for each included contact, total length of 4 bytes per contact:
byte 0 - 2: last 3 bytes of MAC address
byte 3: RSSI (best value measured in interval for specific contact)
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
byte 6: nr. of unique BT scan results during latest ble scan contained in this message
repeated for each included contact, total length of 4 bytes per contact:
byte 0 - 2: last 3 bytes of MAC address
byte 3: RSSI (best value measured in interval for specific contact)
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
byte 3 - 3+data_len: message data
byte 3+data_len+1: message sequence nr.
byte 3+data_len+2: message retry send count.
byte 3+data_len+3 - +4: timestamp of msg recieved.
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
byte 3 - 3+data_len: message data
byte 3+data_len+1: message sequence nr.
byte 3+data_len+2: message retry send count.
Byte number | V1 (fw < v1.11) | V2 (fw >= v1.11) |
---|---|---|
0
message ID - 0xF4
message ID - 0xF4
1
message length
message length
2
reset byte
reset byte
3
error flags bit 0: LR error bit 1: BT error bit 2: Ublox error bit 3: Ublox busy bit 4: sensors error (acc) bit 5: baterry error bit 6: Ublox fix error bit 7: Flash error
error flags bit 0: LR error bit 1: BT error bit 2: Ublox error bit 3: Ublox busy bit 4: sensors error (acc) bit 5: baterry error bit 6: Ublox fix error bit 7: Flash error
4
battery level
battery level
5
operation flags bit 0: charging status bit 1: implemented pin security bit 2: LR join status bit 3-7: free
operation flags bit 0: unread user message(s) bit 1: implemented pin security bit 2: LR join status bit 3: free
bit 4-7: nr of LR satellites
6
temperature
temperature
7
uptime
uptime
8
accelerometer X
accelerometer X
9
accelerometer Y
accelerometer Y
10
accelerometer Z
accelerometer Z
11
version HW bit 0-3: HW minor
bit 4-7: HW major
version HW bit 0-3: HW minor
bit 4-7: HW major
12
version FW bit 0-3: FW minor
bit 4-7: FW major
version FW bit 0-3: FW minor
bit 4-7: FW major
13
HW type bit 0-3: HW type bit 4-7: free
type bit 0-3: HW type
bit 4-7: FW type
14
number of LR satellites
charging voltage
15
last LR fix
bit 0: satellite com enabled bit 1: rf scan enabled bit 4-7: number of satellite send retries