Bilirubinometer Hardware

Tracking With Snapshot Gnss

Jonas Beuchert1, Amanda Matthes1, and Alex Rogers1

Abstract

Location tracking with global navigation satellite systems (GNSS), such as GPS, is used in many applications, including the tracking of wild animals for research. Snapshot GNSS is a technique that only requires milliseconds of satellite signals to infer the position of a receiver. This is ideal for low-power applications such as animal tracking. However, there are few existing snapshot systems, none of which is open source.

To address this, we developed SnapperGPS, a fully open-source, low- cost, and low-power location tracking system designed for wildlife track- ing. SnapperGPS comprises three parts, all of which are open-source: (i) a small, low-cost, and low-power receiver; (ii) a web application to config- ure the receiver via USB; and (iii) a cloud-based platform for processing recorded data. This paper presents the hardware side of this project.

The total component cost of the receiver is under $30, making it fea- sible for field work with restricted budgets and low recovery rates. The receiver records very short and low-resolution samples resulting in par- ticularly low power consumption, outperforming existing systems. It can run for more than a year on a 40 mA h battery.

We evaluated SnapperGPS in controlled static and dynamic tests in a semi-urban environment where it achieved median errors of 12 m. Additionally, SnapperGPS has already been deployed for two wildlife tracking studies on sea turtles and sea birds.

Metadata Overview

Main design files: https://github.com/SnapperGPS/snappergps-pcb

Target Group: Biologists Tracking Animal Movement

Skills required: PCB manufacturing and assembly (can be outsourced) -

Advanced;

Replication: This hardware has been replicated by every author. See section “Build Details” for more detail.

Keywords

conservation technology; wildlife tracking; satellite navigation; low power;

Introduction

Animal location trackers most commonly use global navigation satellite systems (GNSS) such as the Global Positioning System (GPS). These systems use con- stellations of satellites which continuously broadcast radio signals containing precise transmission timestamps and their ephemeris data describing their or- bits. A GNSS tracking device on Earth captures these signals and infers its location from this information. A traditional GNSS receiver usually requires more than one minute of data for a first fix (for which it needs to decode both, ephemerides and timestamps), and at least several seconds for subsequent fixes (if recently decoded ephemerides are available) (van Diggelen 2009). However, powering the radio to capture these signals and then the processor to calculate the location is energy expensive, resulting in the need for large batteries with high capacity. This often makes traditional GNSS tags impractical for tracking small animals over long deployment periods (McMahon et al. 2017).

Assisted GNSS (A-GNSS) receivers address this issue by obtaining some of the satellite data in another way, which allows them to reduce their on-time, thereby saving energy. This is done either by pre-loading ephemerides before the deployment or by regularly downloading them via another connection (e.g.

cellular). However, pre-loading data is only possible for short deployments and an additional download link requires more expensive hardware and is energy intensive.

Snapshot GNSS is another alternative GNSS concept, which, by design, has significantly lower energy needs, resulting in small, light-weight, energy-efficient, and low-cost receivers.

Instead of capturing seconds or even minutes of the satellite signals for a fix, a snapshot receiver records just a few milliseconds. This reduces its power consumption by several orders of magnitude compared to a traditional GNSS approach. Additionally, a snapshot GNSS device does not

2

Table 2: Existing snapshot GNSS systems.

No

No

No

No

aData from commercial GPS front-end, not snapshot receiver. aRooftop with good sky visibility. cEvaluation by McMahon et al. (2017).

dEvaluation board. need to calculate its position on-board, saving even more energy and lowering the requirements for its compute hardware. Instead, it can just locally store the raw signal snapshots until the deployment ends. Afterwards, the data processing can be off-loaded to the cloud.

Table 2 details pure snapshot GNSS systems that have been developed in the past. Only Baseband Technologies currently offers its solution for purchase (Baseband Technologies Inc. n.d.). It is available as a proprietary development board and, therefore, not readily available for deployments. Only the ATS G10 module has been evaluated in a realistic scenario, but was found to be unreli- able by McMahon et al. (2017) due to battery and software failures (Morrison n.d.). Furthermore, all existing solutions also use high sample rates and/or long snapshots at multi-bit resolution. This improves the snapshot quality but also requires complex and expensive hardware. For example, the ETHZ receiver records two-bit signals sampled at 16 MHz, which limits their microcontroller choice to one with a parallel input capture interface (PARC) (Eichelberger et al.

2019). The CO-GPS receiver uses additional circuitry to convert its two-bit GPS input stream at 16 MHz into a 16-bit parallel signal at 2 MHz, which a microcontroller then captures using direct memory access (DMA) (Liu et al.

2012). Moreover, the hardware is only part of a full snapshot GNSS solution. A com- plete system also needs a signal processing chain to calculate positions from the raw snapshot data. However, this software is not openly available for any of these systems, which renders users dependent on the technology provider over the whole lifespan of their devices.

3

To address these issues, we developed SnapperGPS, a completely open-source, small, low-cost, low-power snapshot GNSS system designed for tracking wildlife. The algorithmic details of the SnapperGPS cloud-processing chain have al- ready been described (Beuchert & Rogers 2021a).

This Paper Presents The

accompanying hardware. The SnapperGPS printed circuit board (PCB) mea- sures 32.0 mm by 27.3 mm and weighs 3 g. The total weight, including an an- tenna and a 40 mA h lithium-ion polymer battery, is 9 g. With such a battery SnapperGPS can run for more than a year. SnapperGPS works with short 12 ms snapshots sampled at only 4 MHz with 1 bit amplitude quantisation. This unmatched low resolution allows us to use low-cost, off-the-shelf components.

The total component cost adds up to $21 for each device if ordered in a batch of 100, excluding battery and antenna. SnapperGPS tags are used with an open- source web application. The app serves as a tool for configuring the tag and later for uploading the recorded snapshots to the cloud for processing. We evaluated SnapperGPS in controlled deployments, both moving and stationary. With good sky visibility, SnapperGPS achieves a median error of 10 m. Modified versions of SnapperGPS have additionally been deployed on free-ranging sea turtles and sea birds, demonstrating its usefulness for wildlife tracking.

The rest of the paper is structured as follows: Section (1) Overview continues with the Overall implementation and design of SnapperGPS. It includes sub- sections on the Electronics, the Firmware and the Web application. Section (2) Quality Control covers how to safely operate a SnapperGPS receiver and how to test that the system reliably provides accurate location estimates over long periods of time. Examples of use cases are presented in (3) Application and (4) Build Details provides the instructions to replicate SnapperGPS. Section (5) Discussion includes a conclusion and an outlook on future work.

Overall Implementation And Design

SnapperGPS consists of three components: (i) a purpose-built energy-efficient low-cost receiver, (ii) a web application for configuration of the receiver, and (iii) a cloud-based data processing platform.

Electronics

We place all electronic components on a single side of a two-layered PCB to enable low-cost assembly, see Figure 1. The block diagram in Figure 2 shows all core components, which we describe in the following.

The antenna captures GNSS signals in the GPS L1 band, which has a centre frequency of 1.575 42 GHz. There are more GNSS signal bands, but the cheapest ICs work with the L1 band, the oldest civilian band, and we can receive the modernised GPS L1C, the Galileo E1, the BeiDou B1C, and the potential future GLONASS L1OCM signal in this band, too. This allows us to make use of multiple satellite systems and, therefore, to increase localisation reliability by using more satellites.

Sampling and storing satellite signals at a rate of multiple gigahertz is not pos- sible with a low-cost receiver. Therefore, we use the heterodyne method: by mixing the received signal with an unmodulated signal from a local oscillator, we shift the original signal down to a lower, so-called intermediate frequency.

6

Figure 1: Assembled SnapperGPS receiver. For this, we choose an integrated circuit that is designed for low-power appli- cations, is available at very low costs (<$1), and is designed for the GPS L1 band: the SE4150L-R from Skyworks Solutions Inc. This radio includes an analogue-to-digital converter (ADC) and a voltage-controlled oscillator (VCO), which needs a reference frequency of 16.368 MHz from an external temperature- compensated crystal oscillator (TCXO).

To sample the radio’s output signal, we connect it to a low-power microcontroller unit (MCU); a 32-bit Silicon Labs Happy Gecko with an Arm Cortex- M0+ core. To reduce the overall number of components, we operate the MCU on the same clock as the radio when acquiring snapshots. Otherwise, we fall back to an internal 14 MHz RC oscillator.

The MCU stores the sampled signals on an external flash memory chip. Its size is the main limitation for the number of fixes. We use a 512 Mbit flash, which stores up to about 11,000 snapshots, 6 KB each.

To configure the board or download data, it must be connected to a host device. For this, we add a USB-C connector and use the internal USB hardware of the

Mcu.

The PCB also has two LEDs to provide information on the state of the device when it is not connected via USB. The board draws its power from either USB or a rechargeable lithium-ion poly- mer (LiPo) battery. The latter’s high power density allows to reduce weight It provides 3.0 V–4.2 V, while the USB power line is at 5 V. Therefore, we need a power regulator and a MOSFET-based switch to provide a stable 3.3 V sup- ply voltage. There are also MOSFETs to switch offthe radio and the flash to minimise quiescent currents. Finally, we add a circuit to measure the battery voltage.

We expose three general-purpose input/output pins (GPIOs) of the MCU at an edge of the PCB to allow for the connection of external modules to extend the functionality of the device. We also expose the reset pin and the Serial Wire Debug (SWD) pins.

Memory

Figure 2: The main electronic components of a SnapperGPS receiver.

Firmware

The Happy Gecko MCU runs custom firmware written in the C programming language. The state machine in Figure 3 visualises its core functionalities. To minimise the overall energy consumption, we carefully select for each state one of the five energy modes (EMs) that the Happy Gecko offers (Silicon Laboratories Inc. 2015). Almost all the time during a deployment, the MCU sleeps in stop mode (EM3), which consumes only 0.5 µA. A real-time counter (RTC) triggers wake-ups in regular intervals to record a satellite signal snapshot, respectively, and the MCU switches to run mode (EM0) for this. The flow chart in Figure 4 shows the steps that it completes in this mode before it goes to sleep again.

The radio outputs satellite signal samples at 16.368 MHz with two-bit amplitude quantisation. However, we sample the signal at a low 4.092 MHz rate, a quarter of the clock frequency.

Additionally, we use only one bit for the amplitude quantisation. Both together reduce the amount of required memory by a factor of eight. However, the main advantage is that we can capture the one-bit receiver output using the existing device USART configured as an SPI master.

Our

choice gives us 32 clock cycles to acquire an eight-bit sample and write it to RAM. The small RAM size of our low-cost MCU limits the snapshot length to 6 KB, i.e., 12 ms. Afterwards, we write the snapshot together with a timestamp and measurements of the battery voltage and the temperature via SPI to the

Shutdown

Figure 3: State machine of of a SnapperGPS receiver. external flash memory. Subsequently, the MCU goes to sleep in EM3 again or switches to shutoffmode (EM4) if all snapshots have been captured and the deployment is complete. In shutoffmode, the RTC is also powered down and the MCU consumes just 20 nA.

To preserve energy, we switch offthe high-frequency 16.368 MHz oscillator dur- ing sleeping because we only need a high frequency clock while capturing a snapshot and the low-frequency 32.768 kHz oscillator is sufficient to keep track of time between consecutive snapshots and the RTC running.

We configure a GPIO with a pull-up resistor to be pulled low when a USB connector is plugged in. Then, the MCU leaves EM3 or EM4, stops the RTC and, therefore, the recording of further snapshots, and switches to EM0.

A

SnapperGPS receiver provides USB bulk endpoints in both directions to facil- itate fast transfers of larger amounts of data. These enable it to be configured as a WebUSB device, for example, together with the SnapperGPS web ap- plication, which is linked in the USB descriptor. The documentation in the snappergps-firmware repository defines the messages to communicate with a SnapperGPS receiver via USB. The messages can be used to get status infor- mation from the receiver, configure a receiver for a deployment, and transfer snapshots and timestamps to a host computer. We also use USB to send a

Power Offexternal Memory

Figure 4: Flow chart for capturing a snapshot. firmware update via the MCU to the external flash memory and to request a cyclic redundancy check (CRC) afterwards to detect transmission errors. Next, a custom bootloader function that is held in SRAM copies the firmware update from the external flash memory to the flash memory of the MCU before the MCU reboots to complete the update.

Cloud-Processing Back-End

The actual processing of the GNSS signals snapshots, i.e., the location estima- tion, is done in the cloud rather than on the device itself (see Figure 5). For this, we wrap the open-source snapshot GNSS algorithms developed by Beuchert & Rogers (2021a) into an open-source Python back-end that runs on a server. The back-end pulls snapshots that have been uploaded from a SnapperGPS receiver from a relational database, processes them, and puts back location estimates.

Related Journal Articles & DOI Links

Selected peer-reviewed publications relevant to 12 Lead ECG Acquisition. Click the DOI to access the full paper (may require institutional access).

Why Choose Us?

Bangalore guidance for robotics, Spectre and autonomous systems projects.