2 ‐ Overview
The CLS GenTracker is to be largely based on the existing V3 Arribada tracker design, in terms of component selection, with the exception that it is designed on a single PCB with a smaller overall footprint. Additionally, it is equipped with a wireless charging circuit using the STWLC68 part (and a solar panel manager with the SPV1050).
A reduced package size GPS receiver chip is used in the ZOE-M8Q. This device variant has no internal flash memory and must therefore be programmed with its configuration each time it is powered on.
The IS25LP128F part is retained which provides 128Mbit of flash memory and the ARTIC_R2 transceiver is identical to that used on the previous satellite board.
The main system processor is the ISP1807-LR which uses the nRF52840 core and BLE technology which built-in antenna.
Whilst a USB port is to be provisioned for on the hardware, the primary use-case for device programming will be via BLE.
The image below showcases the top face of the Linkit CORE v3 board, highlighting its various constituent elements.
- The REED switch element is dedicated to controlling the state of the device with the help of a magnet. The effect of the magnetic switch is visible on the STATUS LED.
- The D4 LED is an RGB status LED indicating the state of the device.
- The LED D8 is a charging status LED:
- Blue for wireless charging
- Green when device is fully charged
- The LED D10 is another charging LED and turns RED when the device is charging.
- SW1 is the only physical button dedicated to resetting the board.
- SWA is the DIP switch for selecting the antenna output.
- SWA OFF / SWA ON => SMA output (J9)
- SWA ON / SWB OFF => u.FL output (J8)
- SWA ON / SWB ON => Pad (SP1)
- The Flash memory (IS25P128) is a 128 Mbits flash memory used configured with LittleFS.
- Coil + / Coil - is the output connector dedicated to the wireless charging coil.
- AMT02 is the patch ceramic antenna dedicatedly connected to the ZOE-M8Q Ublox GNSS.
The image below showcases the bottom face of the Linkit CORE v3 board.
- J4 is the DEBUG trace connector:
- DBG provides trace output at (460800-8-N-1-NoFlow),
- GND pin serves for debugger connectivity,
- VRECT pin: Acts as the synchronous rectifier output and input from the wireless chipset (STWLC68) for the main LDO linear regulator.
- J1 is the GNSS connector, useful for debugging or configuration with the uBlox application.
- J10 is the PV solar input, where you connect the positive (+) and negative (-) terminals of the solar panel.
- J7 is the battery connector (2.54mm header), with a warning about the absence of reverse polarity protection.
- J5 is an external connector useful for adding other sensors or peripherals.
- Battery voltage output
- 3 External GPIO, which could also be configured as I2C,
- One UART output (RX/TX),
- Two ground pins.
- The four small squares at the edge of the board are used for the saltwater pins (1 input and 1 GND on one side, and 1 output and 1 GND on the other side).
- U8 is the pressure sensor, but you can add a small PCB (available with Arribada) to enable an I2C output.
The following image shows the state machine of the firmware :
- BOOT State: transient state required to prepare the system, initialise all devices, format the file system, etc
- CONFIGURATION State: state that is only ever activated by the reed switch
- OPERATIONAL State: state that is entered when not configuring and post-boot if the configuration is present and correct
- ERROR State: state that is entered on unrecoverable error
Note that it shall always be possible to activate CONFIGURATION state once the system has booted.
The Scheduler class serves as a vital component for managing and executing tasks within embedded systems. It operates by maintaining a priority-ordered queue of tasks, guaranteeing that tasks with higher priority are executed before those with lower priority. Tasks can be added to the scheduler with specific priorities and optional delays, allowing for precise control over task execution timing. The Scheduler utilizes interrupts to ensure thread safety when modifying the task queue and employs a timer mechanism to handle delayed task execution efficiently.
In this cooperative scheduling paradigm, tasks are executed sequentially based on their assigned priorities. Unlike preemptive scheduling, there is no mechanism for preempting lower priority tasks. Instead, tasks are processed one after the other, with each task completing its execution or yielding control before the next task in the queue can run. This cooperative approach ensures that each task has the opportunity to execute fully without interruption, contributing to the overall stability and predictability of the embedded system.
The firmware embeds two higher-level modules dedicated to managing Argos communication and GPS acquisition. Both modules are configurable and offer various modes and options controlled via the parameters file. For instance, in the case of Argos communication:
- It can be disabled altogether.
- It can transmit data along with GNSS acquisition.
- It can transmit data along with position and satellite pass prediction.
- It can transmit data only at specific allowed times or with a predetermined periodicity.
The Service scheduler is the scheduler part dedicated to manage event from sensors or actuator.
Satellite prepass prediction is a vital component of efficient data transmission and reception in satellite communication systems. Its purpose is to optimize the utilization of satellite passes, ensuring that data transmission occurs exclusively during these periods, thereby conserving power and maximizing the probability of successful reception by the satellite. Access to satellite pass predictions can be facilitated through the use of specialized software or services provided by satellite communication providers like Kinéis. These predictions are typically generated based on input parameters such as the terminal's geographical position (latitude and longitude) and UTC date and time.
There are two primary strategies for satellite data transmission:
-
Random Periodic Transmission: In this strategy, the device transmits data randomly without considering satellite passes. While simple, this approach may result in unnecessary transmissions, potentially leading to increased power consumption.
-
Transmission on Satellite Passes: By predicting satellite passes, the terminal can strategically schedule data transmissions during these periods. This approach significantly reduces power consumption and increases the likelihood of successful data reception. Two sub-strategies exist within this approach:
a. Interactive Communication: This strategy enables terminals to receive acknowledgment of successful data reception from satellites equipped with downlink capabilities. To implement interactive communication, terminals compute satellite pass predictions based on orbital parameters and other input data. b. Receive Downlink Messages: Terminals can periodically listen for downlink messages from satellites, enabling them to determine satellite availability and schedule transmissions accordingly.
To compute satellite pass predictions, terminals require accurate input data, including their position, UTC date and time, and orbital parameters of the satellites. This information can be obtained from sources such as GNSS receivers, predefined downlink messages, or manual input. Once computed, the predictions provide valuable insights into upcoming satellite passes, allowing terminals to optimize their data transmission strategies for efficient communication with satellites. It's imperative for terminals to regularly update their input data and compute pass predictions to ensure accurate and reliable communication with satellites.
With the incorporation of the saltwater switch, the functionality of Argos communication and GNSS acquisition is intelligently controlled based on the device's state—submerged or emerged. The saltwater switch consists of two pins: one emitter and one receptor. Its operation is straightforward:
- When a pulse is sent across the two pins:
- If the pulse is received on the receptor pin, indicating conductivity, the device is recognized as submerged. In this underwater state, communication via Argos and GNSS acquisition are inhibited to prevent data transmission errors or signal interference.
- Conversely, if the pulse is not received, suggesting a lack of conductivity, the device is identified as emerged, indicating that it is at the surface. In this state, communication via Argos and GNSS acquisition are permitted, enabling data transmission and positioning updates.
Moreover:
- The firmware parameters govern the pulse's frequency and the threshold for detecting multiple high states of the pulse. These parameters are crucial for ensuring accurate detection of the device's state and for correlating the pulse frequency with changes in salinity and temperature.
- Additionally, it's essential to maintain the effectiveness of the saltwater switch by applying antifouling painting to the device's surface. This preventive measure helps prevent fouling or buildup that could compromise the switch's ability to accurately discern between submerged and emerged states.
Underwater detection can also be achieved using the pressure sensor. In this scenario, a threshold value in units of pressure (default 1.1 bar) is utilized to determine whether the device is at the surface or submerged.
The firmware incorporates the concept of GNSS zones to facilitate geofencing functionality, allowing for the definition of geographical areas based on GPS coordinates (latitude and longitude) and a specified radius. Each zone is uniquely identified by an ID number, and any number of zones can be defined within the system. During operation, the firmware continuously evaluates the current GPS position against the defined zones to determine whether the device is inside or outside a particular zone. The system maintains a global state variable, CURRENT_ZONE, which tracks the active zone ID. When a zone match occurs, indicated by meeting specific criteria such as enable monitoring and activation data settings, the zone is considered entered. The firmware logs events when transitioning between zones, applying default configuration parameters associated with the entered zone. If the device is not within any defined zone, the default parameters are applied. Additionally, the firmware initially supports one zone file, acting as an exclusion zone, with underwater battery mode taking priority. The zone format specifies the longitude, latitude, and radius for each defined area.
Pylinkit, a Python script, serves as a versatile tool for configuring devices and retrieving data via Bluetooth Low Energy (BLE) communication. Its primary objective is to facilitate the configuration process by allowing users to adjust parameters, update firmware, manage GNSS settings, and perform prepass operations, among other tasks. Additionally, Pylinkit enables users to efficiently retrieve data logs from sensors and the system. At the start, Pylinkit initiates by scanning nearby devices to identify target devices and offers a range of commands for various operations, including reading and writing configuration parameters, sending pass predictions from JSON files, downloading sensor and system log data, performing factory resets and software updates, and resetting counters. Pylinkit also provides an option to enable debug trace for troubleshooting purposes. With its user-friendly interface and comprehensive functionality, Pylinkit simplifies device management and data retrieval processes.
Gentracker is a mobile application designed to provide users with seamless control and monitoring capabilities for their devices. Functioning akin to Pylinkit but tailored for smartphones, Gentracker facilitates device configuration and data retrieval via a user-friendly interface accessible on mobile devices. Its primary purpose is to empower users to efficiently manage device parameters, update firmware, configure GNSS settings, and execute prepass operations, among other tasks, all from the convenience of their smartphones. Additionally, Gentracker enhances user experience by offering features such as access to a map interface for location-based tracking, personalized profiles for customized device settings, and alert notifications to keep users informed of critical events or anomalies. With its intuitive design and comprehensive functionality, Gentracker serves as an indispensable tool for users seeking convenient and efficient device management on the go.