Leon Steenkamp

Building small satellites on the tip of Africa. My other ride is a CubeSat.


Open water swim tracker - project overview

The project goal was to build a tracker for open water swimming. The project started as a holiday project, therefore one of the goals was to build something that was fairly quick to implement without ordering a lot of parts and have fun doing it.

This post is an overview, with more of the technical details in followup posts. I’ll add links to the posts below as they become available.

image
First test of the tracker hardware

Introduction

According to FINA “open water swimming shall be defined as any competition that takes place in rivers, lakes, oceans or water channels…”. The swim from Robben Island to Big Bay (~ 7km) is a popular local example of an open water swimming route.

Initial consideration was given to a device that could somehow be attached to the swimmer, but it was decided that the scope for a solution to that problem would fall outside what I wanted to do for this project.

Swimmers on routes like the one mentioned above are almost always accompanied by a boat. Sometimes the boat is quipped with an AIS (Automatic Identification System) transmitter which allows the boat and the swimmer to be tracked on websites like MarineTraffic. In these cases there is little need for an additional tracking device, other than the improved user friendliness provided by a simpler web page. But this is not always the case especially on smaller boats, which are often not equipped with an AIS transmitter.

It was decided that a boat based tracker would be good compromise. This allows for a number of possible solutions while still being useful.

Need, goals and requirements

The identified need was to provide the swimmers’s position, with the goals of providing a solution that could be implemented relatively quickly (weeks), inexpensive (mostly use parts on hand) and as simple as possible.

The following high level requirements were identified:

  1. The device shall supply location data for up to eight hours
  2. The device shall supply the swimmer’s location every 30 seconds
  3. The device shall supply the swimmer’s location to an accuracy of 50 meters
  4. The device shall supply the swimmer’s location in 30 seconds from the measurement being taken.
  5. The device shall be boat based.
  6. The device shall be self sufficient.
  7. There shall be a public Internet facing web page to display the tracking data.

The other goals (cost, time and complexity) are quite subjective and were not flowed into requirements, which I am fine with. In terms of success criteria, I would be happy with receiving at least some location data for the duration of the swim, with the device functioning without intervention.

The concept

From requirement 4 is it clear that the device will need some form of connectivity. The most accessible that had a high likelihood of probably working in this application was to use a cellular LTE modem. Other options are discussed in a later post.

An GNSS (Global navigation satellite system) receiver was used to determining the tracker’s position. The specific receiver model used is capable of receiving a single constellation, in this case the GPS (Global Positioning System - United States) constellation (as opposed to Galileo, BeiDou, GLONASS or QZSS).

To tie the different elements together the venerable Raspberry Pi 4 was used. The initial idea was to use a Raspberry Pi Zero, but I was running out of time and had an issue with devices attached to the USB hub not being recognised after rebooting. I have ordered a different hub and might give the RPi Zero a go again at some point.

To power everything I tried a USB power bank, which seemed to work well enough that I kept using it.

To enable monitoring and logging of “engineering” type data, Tailscale was used to connect the tracker to a Raspberry Pi on my LAN that is running InfluxDB and Grafana. A Grafana dashboard was made to display details on the functioning of the GPS receiver (satellites used, fix mode and speed) and the LTE modem (various signal strength values and amount of data used).

To display the tracker location to general users over the Web a Django web application was developed. The Django REST Framework was used to build APIs that could be used to both ingest data and for the mapping application to retrieve location data.

Everything was glued together with a mix of gpsd, systemd, Python and Bash script.

Technology stack:

  • u-blox GPS evaluation board from RF Design
  • Alcatel LTE modem
  • Raspberry Pi 4
  • Django, Django REST Framework, Mapbox
  • Python
  • Bash
  • AWS EC2, Amazon Route 53
  • Traefik Proxy
  • Docker / compose
  • Tailscale
  • Influx/Grafana on another RPi 4 for internal logging

Conclusion

Spoiler - I built it and it worked pretty well. The LTE modem is a passable solution but has its limitations the further you go offshore, which is expected.

In the upcoming posts I’ll share some more details on the implementation and also show some of results from three real world tests (including a ~34 km swim).

The end goal of the whole project would be to modify and build on the current solution to get to something that can be used as an English Channel Swim Tracker.

Coming soon - still marinating for maximum flavour!

  1. Open water swim tracker - project overview - Link
  2. Tracker hardware - Coming soon
  3. Tracker embedded software - Coming soon
  4. Software for internal monitoring and logging - Coming soon
  5. End user web application - Coming soon
  6. Other hardware options and future developments - Coming soon
  7. Open water swim tracker testing - Coming soon
  8. End goal tracker - Coming soon