Rob

[Preserving this write-up I submitted as an entry in an electronic design competition].

Ultra-endurance cycling events are becoming more and more popular. Events such as the Transcontinental Race (4,000km, unsupported, from Belgium to Turkey or Greece) require cyclists to ride for upwards of 16 hours a day, often catching just a few hours sleep, bivvying at the roadside to avoid wasting time on hotel checkins. Some events, such as the Audax UK “Lumpy End-to-End”, 1,800km in 8 days, require validation by GPS track. Opportunities for charging battery-powered devices are few and far between. While most participants use a dedicated consumer GPS device, or mobile phone, for navigation and capture of their track, there is a serious risk that batteries fail en route. It would be devastating to complete such an event, but not to capture the relevant GPS validation track. The purpose of my device is to provide a very low-power, simple GPS tracker, that can run unattended for days at a time on a single battery charge. It could be used as either the primary, or a backup, GPS tracker for ultra-endurance races.

Requirements

Key requirements for such a device include:

• Low-power. Rechargeable battery powered with ability to run for several days without a charge.
• Weather-proof. There is a high probability of heavy rain at some point on such a long event. The device must exclude water.
• High data storage capacity. Each GPS track point requires 32 bytes, in a suitable binary format. The device must record a point at least every 5 seconds for validation. Hence the device must be capable of storing more than 0.5MB per day in non-volatile storage.

Selection of components

• ESP32. This microcontroller has many advantages which contribute to delivering the requirements outlined above. Low-power: The device can operate in deep sleep mode, consuming 10 µA, for much of the time e.g. for 4.5 seconds in every 5 second sample period. While collecting track points from the GPS device, the device is powered-up, but WiFi and Bluetooth are not required, so the radios can be disabled. Miniature. Even in a development board format (in this case the ESP32-PICO-KIT board), the device is small enough to be housed in a compact, lightweight enclosure that can be carried unobtrusively by the cyclist. WiFi. The device operates standalone while collecting GPS tracks, but at the end of event, we need to retrieve the saved track. This can easily be achieved by activating WiFi and a simple web server, allowing the GPS file to be downloaded. Touch-sensors. By using touch sensors as switches, e.g. to switch between tracking and track-retrieval mode, we avoid the need to open up physical ports on the enclosure, thus minimising opportunities for water ingress.
• U-blox MAX-8C GPS. U-blox GPS devices are cheap and easy to obtain. They provide support for text-based NMEA protocol, as well as proprietary UBX binary format. However, many of the development boards are not designed with low-power in mind. MAX-8C is inherently low-power, and can be built into a low-power board such as this one from Uputronics. Typical current during GPS acquisition is 18mA, but low-power modes provide potential for this to drop to around 4mA post-acquisition and during tracking.
• Winbond W25Q256FVFG External SPI Flash. The ESP32-PICO-KIT provides 4MB of flash memory, but much of this is consumed with firmware and program storage, leaving no more than 2MB available for storing GPS trackpoints. Given our aspiration to record a track for many days at a consumption rate of 0.5MB per day, I identified the need to interface to a further external SPI flash chip. The Winbond W25Q256FVFG provides 32MB of additional flash, which will support 60 days of GPS track recording.
• LiFePO4 battery. All the above components run at a standard Vcc of 3.3V, therefore – with a suitable voltage regulator – many options of battery format are possible, including LiPo (3.7V – 4.2V), Alkaline, NiMH. LiFePO4 batteries are an attractive option, because the nominal voltage is 3.2V, and the discharge curve is very flat, dropping below 3.0V only after releasing around 95% of its total capacity. This means that 3.3V devices can be reliably powered without a voltage regulator, avoiding the associated inefficiencies. A drawback is that these batteries are heavier and more bulky than LiPo batteries of comparable capacity.
• TP5000 LiFePO4 charging module. The LiFePO4 battery, which is sealed inside the enclosure, can be charged with 5V from a typical USB charger, via an internal TP5000 charging module. To prevent water ingress, a 5V DC jack with rubber seal is used in preference to a mini- or micro-USB connector.
• Touch-pad hardware. Touch-pads are implemented with a metallic disc attached on the inside of the enclosure. A steel washer has been used successfully. Further work is required to evaluate alternatives e.g. a copper rivet, for sensitivity and precision.

Design approach

Software is developed in C/C++ using ESP-IDF development framework. Tasks within the framework include:

• GPS. Initialise the GPS device with the sample rate and protocol messages required. GPS location acquisition can be accelerated by using AssistNow Offline (u-blox), meaning that GPS information (ephemeris and almanac) can be downloaded from an Internet site over WiFi for 35 days into the future. Then, when the device is powered-on, the relevant day’s offline data is downloaded to the GPS device. This speeds up acquisition from 30 seconds to around 5 seconds. Once GPS location has been acquired, the GPS device sends a trackpoint via UART to the ESP32 host once every 5 seconds. A binary message, UBX-NAV-PVT, is used, because it encodes the location data in a relatively compact binary format. The received UART data wakes the ESP32, which, with minimal processing, writes the location data in the same binary format, via SPI, to external flash. The ESP32 can then return to deep sleep. This 5 second cycle will repeat indefinitely for as long as the device is in track-recording mode. A simple file system is implemented on the flash (esp32_fatflash by Illucius) to allow tracks to be associated as files, and so that they can be deleted by the user, and the storage occupied by that track can be made available for reuse.
• Touch-pad. A second ESP-IDF task monitors for touch pad events. A long-press on a touch pad triggers a software event, which switches the device to “track-retrieval mode”. This activates WiFi and a simple web server. This will normally only occur when the ride is over; the device may be powered with external 5V supply at this time, and the additional power consumption will not be a problem.
• WiFi / Web server. A third ESP-IDF task, triggered to be created in “track-retrieval mode”, WiFi will activate (could be either as a station on a pre-configured SSID, or as an AP providing a new, temporary SSID). A web server will be started, offering, via a browser page, a list of GPS tracks available for download. Each will be identified according to its start time, which is readily discoverable by decoding the first trackpoints of the binary trackpoint data stored in external flash. When the web client selects a track to download, the web server will decode trackpoints read from external flash, on-the-fly, converting them into the industry-standard GPX file format. The web server will also provide the ability to delete selected files, which will result in an entry being deleted from the list of tracks held in flash, and the flash pages used by that track being returned to a free page pool.

Development status

The hardware elements have been acquired and integrated on breadboard. Each of the main capabilities has been prototyped in software and demonstrated individually, i.e. ESP32-GPS integration, ESP32-external flash (both direct page read/write and via FAT), WiFi and web server, LiFePO4 battery operation and charging, touch sensor detection. The capabilities have not yet been integrated into a single working firmware build; this is work in progress. The current software implementation can be consulted here. Further work is also needed to design the enclosure to accommodate the hardware in a compact, weatherproof format. The build needs to be optimised for power consumption. Initial measurements suggest a current-draw of around 35mA in track-recording mode, but I believe this can be reduced below 20mA with optimised use of deep sleep, and with careful power management of the GPS module. This suggests the device could operate for 3 days on a single 1600mAh LiFePO4 battery, or 6 days on two. I look forward to completing this unfinished work, but wanted to submit an entry for the competition in time for the deadline.

Potential further enhancements

Because the ESP32 is also blessed with Bluetooth, the possibility exists to also track Bluetooth sensors such as heart-rate monitors and pedal-power meters. This would clearly increase power consumption compared to simple GPS tracking, but in certain circumstances it might be an attractive trade-off.