OpenLog, SparkFun's open source serial data logger and its four generations of firmware

A logger that writes serial data to a microSD card

OpenLog is described as an open source data logger that works over a simple serial connection and supports microSD cards up to 64GB.

That is the whole device concept, and it is a deliberately narrow one. A microcontroller streams bytes out over serial, the OpenLog writes them to a microSD card, and you pull the card out and read the file. There is no radio link, no cloud service and no configuration protocol beyond a serial command set.

Two hardware variants are documented in the README, the SparkFun OpenLog with the part number DEV-13712 and the SparkFun OpenLog with Headers, DEV-13955, both linked to SparkFun product pages. The product pages are the place to buy the assembled boards.

For a maker, the appeal is that the logger is not a black box. The firmware is in the repository, the hardware design files are in the repository, and the libraries the firmware uses are in the repository. Someone who has ever been annoyed by a logger that dropped characters at the higher baud rates can go and fix it, and the version history suggests exactly that kind of iteration happened many times over.

Five directories: firmware, hardware, libraries, production and documentation

The repository is organised as an open source hardware release, and the directory list is effectively the parts list.

The Documentation directory holds data sheets and additional product information. The firmware directory holds example sketches for the OpenLog itself, and for an Arduino connected to the OpenLog, which is the interesting part for anyone using it as a sensor sink. The hardware directory holds the hardware design files for the OpenLog PCB, and the README notes these were designed in Eagle CAD. The Libraries directory holds libraries for use with the OpenLog. The Production directory holds production panel files in .brd format.

There is also a Binaries directory, which tells you the prebuilt firmware images are committed rather than left to the user to build.

Two external resources are linked rather than duplicated. The SparkFun Fritzing repo holds Fritzing diagrams for SparkFun products, the SparkFun 3D Model repo holds 3D models, and the Graphical Datasheets repo holds graphical datasheets for various SparkFun products. A hookup guide is linked separately on the SparkFun learn site, described as the basic hookup guide for the OpenLog.

So the pattern is clear: everything needed to rebuild the device is here, and everything needed to draw it in a schematic or a 3D model is one repository over.

Which firmware generation matches your card and your baud rate

The version history section is the most useful thing in the README for anyone about to build one, because the firmware generations differ in ways that are not backward compatible.

OpenLog v4 is refactored with better RAM utilisation for better performance at higher record speeds of 115200 and 57600. OpenLog v3 is stable, supports FAT32 cards up to 64GB, and also supports the higher record speeds. OpenLog v2 is described as a bit buggy but supports FAT32 and SD cards up to 16GB. OpenLog v1 is stable but only supports FAT16 and up to 2GB.

That last point is the one that catches people. A 64GB card is FAT32, so v1 will not work with it, and v2 tops out at 16GB.

The change log also shows the shape of the work. v1.6 added the ability to configure the device via a config.txt file. v2.0 was the massive overhaul, ported to sdfatlib with support for FAT16, FAT32, SD and SDHC. v2.3 migrated to v10.10.10 of sdfatlib and moved to an inline RX interrupt and buffer, and v2.2 had already increased the HardwareSerial.cpp buffer to 512 bytes. v3.0 was the migration to Arduino v1.0 with better recording speed, and v4.0 was re-worked to be compatible with Arduino v1.6.x, freeing RAM to increase the RX buffer size.

The single listed release is v4.3, described as adding a rotating log feature, published on 2021-10-14, and a full view of changes is in the CHANGELOG.md in the repository.

The licence needs reading, and two libraries are GPLv3

The licence information section is short, which means it is your job to read the file.

The product is described as open source, with a pointer to the LICENSE.md file for licence information and an invitation to contact [email protected] with questions or concerns on licensing. The distribution terms are stated as distributed as-is, with no warranty given.

The licence field GitHub shows for the repository is one it cannot classify, so the custom terms are in LICENSE.md rather than in a standard identifier. For a hardware design, that usually means something beyond a software licence, covering the board files, the firmware and possibly the trademark, and a team building a commercial product from these files needs to read it rather than assume.

One component is named explicitly. SDFatLib-beta and SerialPort are written by Bill Greiman and released under GPLv3, and both are bundled in the Libraries directory. That is a copyleft obligation inside an otherwise permissive-looking project, and it is the sort of thing that changes how you distribute a modified OpenLog.

The practical advice is narrow and specific: read LICENSE.md, and note that the GPLv3 terms on the two bundled libraries are separate from whatever the rest of the repository uses.

Getting a logger, and the first thing to check before you build

There is no installation step in the sense a software project would recognise. The device is hardware, so what you need first is the board itself, either assembled from the SparkFun product pages for DEV-13712 or DEV-13955, or built from the design files in the hardware directory, and the second thing is a microSD card.

Before you commit to a build, the README's own version history answers the two questions that decide whether it works: which firmware generation, and which card format. If you have a modern card of 32GB or 64GB, v1 is out and v2 will not take it either, so you are on v3 or v4, and if your microcontroller streams at 115200 or 57600 baud you want v3 or v4 for the higher record speeds and the better RAM utilisation.

Then read the hookup guide linked in the README, since the basic wiring is the thing most likely to produce a logger that records nothing.

The remaining preparation is the firmware side. The repository ships Binaries, so if you want to run the current v4.3 on an existing board you can flash the built image rather than set up a toolchain. If you want to modify the firmware, the example sketches for both the OpenLog and an Arduino connected to it are the place to start, and the Arduino version compatibility in the version history, v1.0 and then v1.6.x, tells you which board support you are compiling against.

Where this sits against a closed logger, and what the limits are

The comparison worth making is with a commercial USB or serial logger, since those are what people usually reach for first. A commercial logger arrives as a sealed box with a vendor utility, it records reliably at the baud rates you care about, and you cannot change its file format, its buffer behaviour or its record rotation. OpenLog gives you all three, at the cost of having to understand the firmware and the card format, and at the cost of the support situation that comes with an open hardware product that a hobbyist maintains.

The failure modes are visible in the changelog rather than hidden. v2.1 records that power save was not working and that characters were dropped at 57600bps. v1.4 mentions pinning down URU errors. v1.5 lowered average power consumption to about 2mA. v2.4 merged ringp updates because the commands cd, rm and ls had stopped working. v3.1 was better handling of recording during power loss, and v2.41 fixed a power loss bug. Logging through a power interruption is a recurring theme, and it is exactly the situation a field logger lives in.

The second limit is the one the licence creates. The custom terms and the GPLv3 libraries mean you cannot simply take this design, strip the branding and sell it without reading what you are agreeing to.

The third is time. The firmware work that made v4 the sensible choice happened in 2021, and the newest listed release is v4.3 from that October. The last push to master was on 2026-04-28, so the tree is not abandoned, but there is no release cadence behind it to count on.

Editorial conclusion

Adopt OpenLog if you need a serial data logger you can modify, since the firmware, the Eagle design files and the libraries are all in the repository and the card and baud rate constraints are documented per firmware generation. Do not adopt it if you want a maintained product with a support team behind it, because the last release was v4.3 in 2021 and the last push was on 2026-04-28, and the README itself describes the shipped state as distributed as-is with no warranty. Before you build one, pick the firmware generation that matches your card, since v1 only handles FAT16 up to 2GB while v2 and above reach FAT32 and 64GB, and read LICENSE.md yourself, because the licence is one GitHub cannot classify and the bundled SDFatLib-beta and SerialPort code is under GPLv3.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sparkfun/OpenLog on GitHub