GPS Logger for Mountainbiking

Oi guys!

I just finished my second Arduino Project ( Automatic water system for my garden ) and I am getting familiar with the programming. Since I started proper mountainbiking this year + I want to get deeper in the Arduino world I came up with the Idea of a GPS datalogging system for logging coordinates, time as well as velocity. I did some research on the topic but got very confused when it comes to the gps stuff...

So these are the topics that I need to get fixed first:

  • Which arduino should I use Uno, Mega, nano?
  • Which GPS Module ?
  • Which SD module? or is there a better/faster option then Sd-Card?

Since I´m dooing rather downhill stuff with the mountainbike speed is key. I´ve read that a 10Hz GPS would be suitable for the job. That would give me a position every 0.1 second which sounds more then enough for the top speeds I´m achieving ( arround 60 km/h ).

For sure there are some programming questions further comming but as a start I would thank you guys very much for recommendations on the hardware.


I guess this project will be battery powered, so none of the above.

Maybe Pro Mini, and the 3.3V version of it. Use 3.3V components where possible to fit with that. On the other hand, I hear a lot of complaints on the forum that running an SD card adapter soaks up almost all the ram memory that Pro Mini's atmega328 has, so maybe something compatible with Arduino Zero, i.e. based on a samd21 chip? Something based on that chip would have a much faster CPU clock speed and SPI clock speed, so better able to deal with the speed calculations and SD card writing. Plus it has extra hardware UART to interface with the GPS module.

I'm no expert on GPS modules, so I'll leave others to recommend something.

I built a portable GPS based speed indicator with an I2C running LCD and a NEO-6M GPS. It runs from a phone charging power pack. An UNO was used but as @PaulRB says, likely use a better controller.

A GPS and SD logger is tight on an ATmega328P.

One program I have for that, which includes a SSD1306 OLED display uses;

Sketch uses 24482 bytes (75%) of program storage space. Maximum is 32256 bytes.
Global variables use 1646 bytes (80%) of dynamic memory, leaving 402 bytes for local variables. Maximum is 2048 bytes.

Although it drops to;

Sketch uses 19208 bytes (59%) of program storage space. Maximum is 32256 bytes.
Global variables use 1227 bytes (59%) of dynamic memory, leaving 821 bytes for local variables. Maximum is 2048 bytes.

Without the display.

So something like this would do the job? I would also go for the arduino Due but that thing is huge compared to the older ones... and since I´m using it on a bike size does matter somehow.



Surely a GPS logger is already available for a reasonable price?

(Less than building it?)

Yes, that is one to consider. Also this one perhaps. Combined with this GPS maybe.

Worth considering what you want to do with all that data.

GPSs put out data in what is ineffect a CSV data format, so it would be easy to connect a simple Openlog (there are much cheaper ones) to a GPS and have the openlog collect the bare GPS NMEA sentences for later analysis.

Some of the Ublox GPSs modules have an EEPROM on them to store the configuration, so you can set them up for 10hz, change the baud rate, stop the not wanted sentences and save the configuration with a PC tool called UCenter.

Why do you say the Nano would be unsuitable? Is it the requirement to support an SD drive?

I was meaning the classic Nano 3. Those have a USB-serial chip which is constantly powered up even when the board is not connected to pc/laptop with usb, wasting battery power. Also, the atmega328 is close to its memory limits when using SD card and GPS libraries, as mentioned above

Here's two commonly available design of GPS modules that I've been happily using. These are both low cost.

module with onboard patch antenna and USB connection

module with external patch antenna

The first has an onboard patch antenna. That's safe and secure. The second has an external patch antenna that connects via a tiny uFL connector. The external antenna has to be treated with care as they are easily damaged physically or electrically. I've destroyed several.

The first has a SMA connector (the large brass screwed receptacle) for an external antenna if the onboard antenna isn't performing. On the bike, I'd imagine an external antenna would be an inconvenience. Some are supplied with the connector loose, not soldered in. That would be best as you can solder it in only if the onboard antenna underperforms (which is unlikely).

The first also has a micro USB connection. This is very handy as you can feed the raw GPS output direct to a PC and view it on U-center without any Arduino or custom programming. I think it is essential to be able to readily view the raw GPS output. With the second module you need to feed the raw output thru a TTL/USB converter or an Arduino. That's not hard, just not as convenient as the USB connection.

Thanks. That's a subtlety I wasn't aware of. When you say "classic" Nano 3, does that mean there are Nano versions that do not constantly power the serial chip? I don't know how to distinguish classic from non-classic Nano.

Hi all,

thank you for your answers. The main reason why I was choosing to go with arduino is that I´m also tracking suspensiondata while driving. This set up is perfectly running with my Arduino Uno atm, but I´m not sure If I can switch that to the MKR because it is only 3.3V...
I have a linear potentiometer( VIn, ground and signal ) at the fork and the damper installed that I read via analogread. those values are also saved together with the GPS Data on the SD card.... at least that was the plan. The mkr zero has a built in sd card reader/writer, I found that pretty helpful as I don´t need a extra board. @HillmanImp are your suggested GPS boards working with 3.3V?

I believe they do work with a 3.3v supply, altho I have not done that.

The U-blox Neo chips work at 3.3v and the boards have a regulator to provide that to them. So I power the boards with 5v from either a battery or USB from computer or car's USB outlet.

I do remember that I could not get one to run when supplying it with 3.3v from a Nano. So it might depend on the actual voltage available, not the theoretical spec.

Can anyone else confirm that they can run this type of board reliably with 3.3v supply to the board?

Do you have any need for a display while riding? I would imagine you don't have time to look at a display, so beware of displaying data just because you can.

your right, I don´t have a display. What I used for my suspensiondata was the following:

With my 3D printer I designed a case that contains the arduino, SD Card board and a battery to power it. Then I have 2 connection plugs for the two potentiometers. Then one pushbutton that I´ve mounted at the handlebar to start/stop the measurement. At least I have an LED on top of the case to signal If I´m recording Data or not. This setup was working great for me, so the basic structure of it should remain the same.

I mean there are Nano versions that don't have a serial chip at all, they have native USB capability, so don't need one. Nano 33 BLE, Nano 33 IoT, Nano Every, Nano RP2040... they share the "Nano" name but not much else, different chips, different voltages, different pinouts to the classic 5V atmega328 Nano.

The problem there was, I would think, that the current available from the 3.3V pin of a classic Nano is very small. It does not have a dedicated 3.3V regulator chip like other Arduino, only a 3.3V regulator built into the USB-serial chip, which can only supply a few mA.

To get an idea on what kind of sampling rate you need, most people sample at a rate higher than needed. At a max speed of 60 km/h which is about 17 m/s so sampling at 10 Hz would show a change in position of at most 1.7 m at max speed which is less than the accuracy of the position the GPS will most likely provide, implying a 10 Hz sampling rate is oversampling for no increase in the quality of your final result.

Reducing the sampling rate will give you some extra room for speeds on SD gard storage rate, extra battery life etc.

Just something to think about,

I also suspect that a high GPS output rate might not be needed.

A mountain bike often goes quite slowly at times. At a 10hz sampling rate, and given the normal variations in position errors, the GPS might think its not moved much and thus the indicated apparent speed could drop to very low levels for short periods.

So you will probaly end up having to smooth out the speed part of the data as it may change quite a bit, so why not let the GPS do the smoothing by cutting the refresh rate.

Sounds like you've accomplished quite a lot so far. I doubt the GPS part will stump you.

Would you like to share an example of your 3D printing skills? A photo of your housing?