Building a simple u-blox F9P data logger with a Sparkfun OpenLog board

Based on the number of views, one of my all time most popular posts is one I wrote nearly three years ago describing how to build a GPS data logger using a Raspberry Pi Zero. Although it specifically describes using a Pi Zero to do nothing except configure the receiver and log raw data to an SD card, the platform itself is quite general and can easily be extended to more complete options including running a real-time RTKLIB solution on the Pi. It is a little out of date now but I think it can still be useful.

However, if what you want is just a raw GPS data logger and nothing more, then, while the above choice may still be the lowest cost solution, it is not the simplest option to implement.

In this post I describe another inexpensive alternative using the very popular OpenLog data logger board available from Sparkfun which currently sells for $15.50. In this particular example, I have used it to log data from an Ardusimple u-blox F9P receiver but with a few minor modifications the design should work with many other popular receivers. For reasons described below it does require the board to have both a USB and a UART port available as well as easy access to 3.3 volts.

Here’s a couple of photos of the front and back of the Sparkfun OpenLog board. As you can see, it is only slightly larger than the size of the microSD card it uses to store the data.

Sparkfun OpenLog board, front and back

The chip on the front side of the board is an Arduino processor which comes pre-loaded with code to automatically log all incoming data from the RX/TX lines directly to the microSD card. The source code is open and available on Github, so if you need to modify it you can, but in most cases it should work fine as is.

To connect the OpenLog to the receiver is very simple. First connect VCC and GND on the OpenLog to 3V3_OUT and GND on the Ardusimple receiver. Fortunately, the pin spacing for the two boards is the same so I was able to use a two pin header to connect power and ground and rigidly mount the OpenLog at the same time. You can see the details in the two photos below. I also added a small piece of double sided foam tape between the two boards to strengthen the physical connection between them.

Back of Ardusimple board with OpenLog. The two boards are physically attached using the two pin header shown on right to connect power and ground. The top right cable is connected to the antenna and the bottom right cable is connected to a USB charger for power or a PC to configure the receiver.
Front of Ardusimple board. The GND/3.3V holes used to connect the two boards are visible just below the u-blox chip. The edge of the microSD card is visible just below the power LED

Then connect the RX/TX data lines on the Open Log to TX1/RX1 on the Ardusimple making sure to swap the two so that RX goes to TX1 and TX goes to RX1. On many boards this will be all you need, but the Ardusimple also has a IOREF input which selects the voltage levels of the GPIO pins. In this case we will connect that to 3.3 volts. You can see these three jumpers on the top photo above.

That’s it for the hardware. The next step is to configure the data logger. To do this you will first need to format a microSD card. Then create a file with the name config.txt, cut and paste the text below into this file and save it to the microSD card.


This is what the data logger uses when it powers up for configuration parameters. The only detail that matters in the above text is the first number which should be set to the same baud rate that UART1 on the receiver is configured to. The maximum baud rate that the OpenLog supports is 115200, so that is what I am using. For more information on the other numbers in this file or about the OpenLog board in general, Sparkfun has an excellent tutorial available here.

The last step is to configure the F9P receiver to output the appropriate messages to UART1. This is where things become much simpler by having both UART and USB ports available on the receiver board. To configure the receiver we will use the u-blox u-center app running on a PC and connected to the receiver through the USB port. Once the receiver is configured and the results saved to flash, we can then unplug the USB cable from the computer and plug it into a USB charger to provide power to the receiver and data logger while they are collecting data.

For this tutorial I will assume you have already downloaded the u-center app from u-blox and are somewhat familiar with using it to configure u-blox receivers. If not, there are many tutorials out there including some of my earlier posts that will help you.

One thing to be aware of is that the messages going out of the receiver to the USB port will generally be different from those going out to UART1, so just because you have the right messages coming out the USB port does not mean they will also be coming out of the UART port. Also be aware that if you use the “Messages View” in u-center to enable and disable messages, this method only affects the active port and so you will be enabling them for USB but not for UART1.

To enable and disable the messages for UART1, you can use the CFG-MSGOUT option from the “Generation 9 Configuration View” which is opened from the “View” tab on the main menu in u-center. I find this method nice for listing which messages are enabled and disabled but rather clunky for actually changing their status, so I used the MSG message from the “Configuration View” ( also opened from the “View” tab) to actually enable and disable the messages. I show this in the screenshot below. If you do it this way, make sure you issue a CFG-CFG message when you are done to save everything to flash.

There are many NMEA messages enabled by default on UART1. You will probably want to disable most or all of these to avoid using unnecessary UART bandwidth and microSD file space.

If you already have raw base observations streaming to the receiver and are using the internal RTK engine to calculate position solutions real-time then you will just need to enable the NMEA GLL messages to log position. These will give you the LLH positions in text format.

If in the more likely case that you are logging raw data for later post-processing, then you can enable either the appropriate RTCM3 messages or the UBX-RXM-RAWX messages to get the raw observations. To minimize the load on the logger, I would suggest using RTCM3 messages for the raw observations and not logging the navigation messages. You only need a single set of navigation messages and in most cases it is easier to log those on the base station. It is simplest to enable the same set of RTCM3 messages for both the USB and UART port. If you need to make these different for any reason, be aware that the F9P does not handle the RTCM3 end of epoch flag independently for both ports, so the last message in each epoch must be the same for both ports or you will have problems.

That should be it. At this point, every time you power up the receiver/logger, it should start a new log file on the microSD card and log all incoming messages from the receiver. The log file names will be in the format LOGxxxx.TXT where “xxxx” increments each run. Simply remove the microSD card from the OpenLog and plug it through an adapter into a PC to transfer the log files. Be sure to be careful when removing the microSD card from the OpenLog. The card locks in with a spring and needs to be pushed in to unlock it. Occasionally I have found that the card catches on the spring and needs to be gently coaxed out or you will break the spring as I found out the hard way.

If using RTKCONV to convert the raw data, you will need to specify the data type (UBX or RTCM3) since the file extension will not be correct for auto format detection.

Here’s a plot of some raw observations I collected this way, then converted to Rinex format with RTKCONV, and then plotted with RTKPLOT, using navigation messages collected separately on my base station.

RTKPLOT of observations collected with the OpenLog logger

The data logger performance is limited by a relatively small buffer size and it is possible that you will see missing samples in your data if the logger buffer overflows while writing to the microSD card. However I did not see any missing samples in my data while collecting dual-frequency GPS, Glonass, and Galileo RTCM3 observations at 5 HZ.

This is the simplest method I am aware of to turn an eval board into a relatively fully functional receiver but if anyone has an easier way, please leave a comment. All it needs now is a 3D printable box to protect it and enclose it from the weather to turn this into a general purpose low-cost dual receiver for real world data collection, at least for post-processing.

For another interesting option, check out this post from the Ardusimple website that describes combining an Ardusimple board with a bluetooth module and smartphone for real-time RTK.


35 thoughts on “Building a simple u-blox F9P data logger with a Sparkfun OpenLog board”

  1. I’ve noticed that RTKCONV doesn’t convert raw Ublox Galileo data correctly with F9P firmware 1.30. When reverting to 1.13 there is no problem.

    I have a Sparkfun F9P board set up to output RAWX and SFRBX to a data logger for post processing. This has worked well for years, but recently I noticed that Galileo data wasn’t being converted correctly anymore and traced this to the 1.30 firmware update.

    In particular no Galileo NAV data is converted to RINEX and while the Galileo OBS data is created RTKLIB won’t process it even when obtaining a good NAV file from another source. It will display it in RTKPLOT though.

    Has anyone else seen this problem?


    1. Hi JB. Yes, the length of the Galileo navigation messages changed in the new firmware, although not the relevant contents. RTKLIB was rejecting the new messages because they were too short. This is fixed in the latest demo5 b34f code release available on Github


    2. Same for with demo5 b34c. After converting, Galielo sats are not visible in the Skyplot. I also noticed that SBAS were also not visible although only 123 was visible with previous firmware (signals from 126 and 136 were recorded but not visible in early Dec 21).


      1. My apologize. I didn’t saw on my smartphone screen that there was an answer and a new version of demo5 for the Galileo navigation message issue. So, with b34f1, I get Galileo back and 123.


    1. Hi CRHISTIAN. I have not tried this logger at 10 Hz but have had trouble even at 5 Hz if I have too many messages enabled so I suspect you will only be able to send a very small set of messages at 10 Hz at best.


  2. Hi!
    I have connected a sparkfun openlog to an ardusimploe board with a ZED-F9P. Before I connected it I was getting a good fix and could see this through u-center. But I have just plugged the board into my computer after attaching it and while to board LED shows a GPS fix nothing is coming through on u- center. And I’m getting no packets coming through.
    Could I have damaged the board when attaching the logger?
    Please could someone help me solve this issue?


    1. Hi Becky. I would be very surprised if you damaged the USB connection to the board by soldering a wire to the UART pin assuming you have at least basic soldering skills. Whenever my Ardusimple board “stops working” it is always because there are two USB connectors on the board and I plugged the USB cable into the wrong connector. Is it possible you did the same? The only other time my Ardusimple board stopped communicating over USB is when it lost power in the middle of a flash update. I was able to recover that one by following the “unbrick” instructions on the Ardusimple website, so you might want to try that.


  3. Great article, I managed to record the raw data on the SD card, convert them to rinex and post-process in RTKLIB following the guidelines of this post, but I have a doubt, how to insert a name and date in the raw file, eg: “LOG_2021_07_08 .TXT”? Is there any command line that I can add to the text of the file (config.txt)?

    I appreciate if anyone can help!


    1. Hi Mhfernandes. I don’t believe there is an option in config.txt to specify the output file name formats but the logger code is open source and available from Sparkfun. It would not be difficult to modify the code to do what you want.


      1. Thanks for the answer, I already researched and saw that there is a way to format the filename with date and time using a real time battery (RTC) in the openlog module.


  4. Great article! I am having an issue while converting the .ubx using rtkconv where it says “ubx length error” and “ubx check sum error”. I’ve configured the F9P to output only rxm.rawx and rxm.sfrbx on uart 1 and USB and some more NMEA messages to the USB for some navigation info. I have checked the baudrate for both UART1 and Logger to 57600. Any help or suggestion would be greatly appreciated.


    1. Hi Tuan. My best guess is that the baud rate is set too low for the amount of data you are trying to transfer. I would suggest increasing the baud rate to 115200 and/or reducing the amount of data to transfer. You can disable some of the constellations and the sample rate on the F9P to reduce data, at least for debug.


      1. Thanks for the suggestion. I did try it with 115200 to no avail. What sort of number of constellations or how low of a sample rate is minimum for PPK for navigation data on an airplane? This is my first time dealing with PPK so I’m still trying to learn the details.


  5. I am having problems with the data logger. Only four hours of data on the 32GB SD card. Any thoughts about what the problem might be?


  6. I build a logger with the Sparkfun serial OpenLog and a Sparkfun NEO-M8N receiver. All good on that part, data is being written etc. I’m a bit confused as to how to configure the receiver in U-Center and what to disable and enable. I’m looking to get a raw output file that I can convert to Rinex for further post-processing. I would be very grateful if someone can put me in the right direction.



      1. Hi, thanks for the reply. I found that out too. Guess I should’ve paid more attention to the specs. Ah well, what can you do? It still servers is purpose.


  7. I have M8T Drotek boards and am trying to set them up to work with the OpenLogloggers. How to best set up the both UART and USB output? Is there an easy way to send the UBX-CFG commands to the M8T?


    1. Hi Vlad. Although my example used an F9P receiver, most of the information applies equally to an M8T receiver. You can setup the UART and USB outputs independently using the CFG-MSG commands from the configuration view in u-center.


  8. I’m having trouble getting valid logs on my openlog from this. The logs aren’t able to be converted to rinex using rtkconv with the format set to ubx and they look different to the previous logs I was getting out of the m8n using these same openlog boards. I have an ardusimple f9p which is set to output rtcm3 corrections on uart2, and the openlog is connected to uart1. I have configured the f9p board to output the RXM-RAWX and RXM-SFRBX messages via uart1 and have disabled the nmea messages from going to uart1 via configuration view. Under ports uart1 is set to 0+1+5 (ubx + nmea +rtcm3) for protocol in and out. Uart2 is set to 0+1+5 in and 5 out (rtcm3) Not sure where this is going wrong or how to troubleshoot.


    1. Hi Glenn. Do you have IOREF connected to the correct voltage for UART1? If that is OK then I suspect that this is most likely a baud rate issue, either a mismatch between the F9P and the logger, or the baud rate too slow for the amount of data being transmitted. The maximum baud rate for the OpenLog is 115200, so I would use this. To troubleshoot I would connect UART1 to your PC through an FTDI connector and make sure you are seeing the correct messages without the OpenLog.


  9. Great post, Tim!

    I’m using the SparkFun GPS-RTK2 Board – ZED-F9P and it’s a shame that the Qwiic OpenLog can’t be used on its own to log data over I2C. It’s also too bad that UART2 can’t output UBX messages, as the serial version of the OpenLog could have been soldered directly.

    Just a heads up that the code to be pasted into the config.txt file isn’t properly showing up in the post. I took a look at the source code and it looks like the font size is to zero.

    115200,26,3,0,1,1,0 baud,escape,esc#,mode,verb,echo,ignoreRX



    1. Adam:

      You indicated you were using Sparkfun RTK2 board. Are you wiring directly from the Tx, Rx, 3.3v, and GND on the Sparkfun board as Tim did with the Ardusimple? Does this directly log without an additional microcontroller (e.g. Arduino, Pi, etc.)?


      1. Hi Micheal,

        While I am wiring directly to the Tx/Rx pins on the SparkFun RTK2 board, I’m currently using an Adafruit Adalogger M0 rather than an OpenLog. I was inspired by Paul Clark’s F9P RAWX logger ( and have been modifying his code to suit my needs.

        I’m still interested in the OpenLog and have actually just ordered a couple to test, but as far as I can tell there’s no way to split up files over a specified time period. As my loggers will be running 24/7, I need to have more control over how the data is logged, which seems to necessitate the use of a microcontroller.



        1. Hi Adam. The Sparkfun OpenLog board has an Arduino microcontroller and the code is open source so it is not difficult to modify it for tasks like splitting up files. I have done this for some of my consulting projects. It’s also possible to split up a very large file after copying it from the SD card to a PC.


  10. Hello. You can write a 5Hz file with a duration of about an hour, just add event labels. I tried using a similar board, but as soon as the tag messages begin, significant gaps appear in the record. I apologize for my English.


  11. I’ve been using Sparkfun’s Openlog (and the earlier Logomatic) for many years to simply add data logging capabilities to OEM GNSS boards. It’s about as low cost and easy as it gets – and – if you are really price sensitive there are clones available for half the price.

    They work great. With some basic care I’ve had no issues recording thousands of data files on multiple Openlogs.

    I just took a look at a couple CSG Shop M8T boards to which I added an Openlog. These have been in use 3+ years with no issues and are only 2x3x5 cm in size in an enclosure. Add an antenna and 5v regulated and the package still fits in the palm of your hand.

    I’ve had so many GNSS boards over the years I eventually standardized on soldering 6 pins to all the connectors. This makes a solid mechanical connection to a female connector on the GNSS board. Only 3 pins are needed, but 6 make a better mechanical connection. This holds the Openlog quite securely and makes it easy to move to different boards. The last receiver I did this with was a Sparkfun F9P board and that has been working fine for 6+ months.


    1. Just got some of the Sparkfun serial openlog boards in. Like you and Tim are saying, they really work great. I had developed my own logging setup a year ago, but these are much easier.


  12. Hi!
    My first goal was to use a Qwiic Openlog to build a simple datalogger but my Openlog seemed bricked. Then I started to use an Adafruit Feather M0 Adalogger I already had and discovered this code by Paul Clark:
    I’m updating this sketch and now I can
    – log Raw data (gps + glonass + galileo + beidou) at 8hz
    – press a button to program a log stop several minutes later. It’s useful when I park and leave my car.
    – use bluetooth for navigation on my android smartphone

    I’m currently adding a micro Oled screen.

    I have another project, to build simple base station :
    Some slides (in french) used for a presentation :

    BTW : Since a few months, you can import RTKlib position files in Josm editor:

    Liked by 1 person

  13. Great article! A heads-up, though… I have the newer Sparkfun Qwiic OpenLog board, and it apparently won’t work (as is) directly connected to the GPS board, as I found out after trying for a while.

    It’s made to connect via I2C, but it requires a microcontroller to be between the GPS and the Qwiic OpenLog board. On their Forum, Sparkfun says it’d be possible to direct connect the Qwiic OpenLog board but would require someone to modify code (I suspect this means the firmware on the Qwiic openLog).

    So anyway… I just ordered a couple of the same OpenLog boards you used to direct connect (Sparkfun serial OpenLog).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: