Leon Steenkamp
Building small satellites on the tip of Africa. My other ride is a CubeSat.
Open water swim tracker - testing
This post is part of the series detailing the Open water swim tracker project - more info here.
The implemented web application displays the position reports generated by the tracker hardware to the end user (viewer) over the Internet. The tracker hardware, placed on the boat accompanying the swimmer, periodically sends GPS data via its LTE link to the web application. Internal (not public-facing) monitoring and logging were also implemented using InfluxDB and Grafana.
This section covers some of the real-world testing that was done using the tracker.
Test 1
This was the first real-world test of the tracker, away from the workbench. The first problem discovered was that the network coverage for the SIM card I had on hand and used for bench testing was not ideal. The Rain SIM was swapped for a Vodacom one, which seemed to work much better.
 |
|---|
| Two swimmers with a seal |
At the time of the test, only the internal monitoring and logging had been implemented using InfluxDB and Grafana. This first test was done during a roughly five-hour swim, and the swimmers were accompanied by a small semi-rigid inflatable boat with no AIS transmitter.
 |
|---|
| GPS related data from logging and monitoring backend |
The tracker performed well during the test, with only three short periods (around 5 minutes each) that can be noticed where data points seem to be missing. One oversight with the current tracker software is that data points are dropped if not successfully logged to the server. This can be updated so that data is appended to a queue and only removed once successfully written to the server.
 |
|---|
| LTE modem related data from logging and monitoring backend |
 |
|---|
| GPS position data showing two gaps in location track |
Test 2
The second test for the tracker was a rather big one - a swim across False Bay. The swim is around 32 km in distance and took just over eight hours on this particular day. For this test, the Django web application with map was ready and could be used to track the swim. For this swim, an external power switch was added to the tracker to enable switching the tracker on without having to screw open the box.
 |
|---|
| Swimmer in the middle of False Bay |
LTE connectivity in the middle of False Bay became tricky as reception became spotty. But as we got closer to Rooi-Els (the destination), things started to improve again. Tracking continued to work right across the bay. The current battery bank used with the tracker hardware lasted just long enough to complete the swim.
 |
|---|
| Swim track across False Bay in mobile browser |
Test 3
The last test was during an approximately five-hour swim. In addition to the swim tracker, a Nordic Semiconductor Thingy:91 X was also tested as a possible alternate tracking solution. The Thingy:91 used the stock firmware that comes with the device and was fitted with a Vodacom SIM to make use of their LTE-M network (instead of the LTE used by the tracker).
 |
|---|
| Swim track in desktop browser |
Both devices worked well over the test period. The Thingy:91 is a smaller and more power-efficient device, but the LTE-M network coverage might need some further investigation. Getting an IoT SIM card for this device seems to be tricky at the moment. It was not possible to get these directly from Vodacom or MTN (NB-IoT). RF Design was kind enough to supply me with the Vodacom SIM card that I used for testing. It should be possible to update the Thingy:91 firmware and integrate it with the implemented Django web application in future.
 |
|---|
| nRF Cloud data panel for tracking data from from Thingy: 91 X |