Creative Commons images are CC BY-NC-SA 3.0

Description: The SparkFun OpenLog is an open source data logger that works over a simple serial connection and supports microSD cards up to 64GB. The OpenLog can store or “log” huge amounts of serial data and act as a black box of sorts to store all the serial data that your project generates, for scientific or debugging purposes.

The SparkFun OpenLog runs off of an onboard ATmega328, running at 16MHz thanks to the onboard crystal.The OpenLog draws 6mA when recording a 512 byte buffer, but as that process takes a fraction of a second, the average current draw is closer to 5mA. Keep in mind though that if you are recording a constant data stream at 115200bps, you will approach that 6mA limit. All data logged by the OpenLog is stored on the microSD card that involve the features of 64MB to 64GB capacity and FAT16 or FAT32 file type.

Note: The latest version of the firmware (included with this board) does not compile in Arduino 1.6.7. You will need to compile in 1.6.5.


  • VCC Input: 3.3V-12V (Recommended 3.3V-5V)
  • Log to low-cost microSD FAT16/32 cards up to 64GB
  • Simple command interface
  • Configurable baud rates (up to 115200bps)
  • Preprogrammed ATmega328 and bootloader
  • Four SPI pogo pins
  • Two LEDs indicate writing status
  • 2mA idle, 6mA at maximum recording rate


Recommended Products

Customer Comments

  • I don’t use arduino. I have PICs. Can anyone tell me what the GRN and BLK lines go to? I assume that GRN is some sort of reset and BLK is just another ground pin, but the schematics I’ve seen are not clear on this.

    • The GRN and BLK labels on our boards actually stand for green and black since those are the colors of the outer wires on the FTDI cable. A lot of our boards will have that standard 6 pin header even though all 6 pins are rarely used. The GRN label is the DTR pin and goes through a capacitor to the reset pin of the ATMega328. The BLK label is GND.

  • Are there any plans to make a version of this that uses a full sized SD card instead of this micro sd?

    • Not at this time. Part of the power of OpenLog is minuteness.

      Why do you want a full sized SD card? More storage space for cheaper? A 4GB microSD will allow you to log for…

      4,000,000,000 bytes = 32,000,000,000 bits / 9600bps = 3,333,333s = 55,555min = 925 hours = 38.6 days

      38.6 days straight before you really run into capacity problems.

  • Is it possible to record video using OpenLog? I have one and want to use it to record videos and or pictures. Is there a way to do this? In all the examples that I have seen, it is only used to record characters.

    • Probably not. Really the OpenLog is an Arduino with a uSD card slot so you can program it to take different data on those pins and save it to the uSD card. As for video or pictures that depends on the source. Based on the fact that commercial video recorders and cameras already have storage slots I’m guessing you are going with a bare camera. We do have cameras that output data over serial and you could probably use this although you’d likely need to modify to firmware to correctly close out a file at the right time. Really it is hard to say without knowing anything about your source. If you have any other questions feel free to contact our techsupport team.

      • I am using your CMOS camera module; so the output is RCA.

        • That module outputs NTSC which does 29.97 interlaced frames per second each with 525 scan lines. If you modify the OpenLog to just save every bit (you will need to figure out the timing for each bit) you can save it and read it back with something that takes NTSC. I’d double check to make sure the Arduino chip can read at that frequency with enough free clock time to also write. It is one of those things that is likely technically possible, but as this is well outside of the intended scope of the board you would basically need to rewrite the firmware to meet your needs. I’d look for something that is designed to read an NTSC signal and convert it to a more usable format (like mp4).

  • obtained 20 pcbs of a weird variation of these as a ding & dent product. what i mean by weird variation is that the ones i have are different by appearance… strange…

  • I was wondering if you could shed some light on the pins for Proteus' microSD card package. I’m looking at the MicroSD card as given in this schematic: and am having trouble correlating the pins to the package as given by the microSD in my device library (I’m designing a board in Proteus and would like to incorporate OpenLog directly). I think they largely match up however I’m having trouble working out where your CS/CD pins connect to?

  • I’m looking for a data logger that will just run continuously when power is applied, with no need to do anything else but take out the SD card every now and then and copy the log.

    Two questions. Does this device come with firmware re-installed so that it can start data logging out of the box at 9600bps? Can it just always log when power is applied, and reapplied? If so how does it handle power interruptions while writing to file.

    • Answer to first question: Yep, board comes pre-programmed and ready to use. Just insert a microSD card, attach power and it will log by default at 9600bps

      Answer to question two: Correct. A new log is created and logged to after each power cycle.

      Answer to third question (how does it handle power interruptions): OpenLog has a buffer of ~500bytes. Once that buffer is full it is recorded to microSD. Also, if more than 500ms go by without new incoming serial the buffer contents is recorded. So if you send a bunch of stuff to OpenLog, then pause for a second, and then lose power, everything will be recorded correctly. You can see this action on this line of code.

      • Open log looks like what I need to use in an application to log data from a Venus GPS receiver. I currently use logomatics (which work great!) but I need a much smaller package. I like the logmatics because I can just hook the serial lines from the receiver to the logmatics and it works. May I assume that if I set the Venus GPS to a bound rate of 9600 I can log on the open log right out of the box without modifying the software?

        • Yes, that should work out of the box.

          As a side note, it’s very easy to change the baud rate on OpenLog: put a microSD card in, power on OpenLog. This will cause OpenLog to create a configuration file. Now insert the SD card into a computer and edit the config.txt file. You will see the baud rate setting in the file. Change it to 57600 or whatever baud rate for the GPS module you’d like to use. Save the file, then re-insert the SD card into OpenLog and you should be good to go without having to change the settings on the GPS module.

  • In addition to the comment about “overclocking” below, the RXI input on OpenLog (advertised as 3.3-6V) is 3.3 V ONLY. The schematic shows no RXI series resistor or level shifting, so it is presumed unsafe to connect this line to 5V TX pins. I’ve complained about this irresponsible advertising to SparkFun, but the engineers can’t seem to get the web pages corrected.

    OpenLog does work very well. My approach, when connecting OpenLog to a 5V TX line, is to put a 4.7K resistor in the line to protect the input clamp diode and the uSD card.

  • Why would I want to use this over the MicroSD Breakout with level shifting?

    • It depends on your application. If you have an application with plenty of memory and want to add logging code than you can go with the MicroSD Breakout. If you don’t have extra memory or don’t have access to the code this is a quick and easy solution for logging. I believe the code as is takes up most of the memory of an ATMega328 although a lot of that could be removed when added to code for specific application.

  • Being a troll is not my really my thing. My observation, however, running the 328p at 16MHz on 3.3V is just a little out of spec, isn’t it? Not that you can’t overclock a bit and see what happens. You’d need at least 3.78V by my math to run within spec at 16MHz. That said, you could use a 3.8V regulator (TPS70938DBVT or similar) to make the processor happy at 16MHz and still be within absolute maximum voltage for uSD cards (in the range of 4.6V). Still though, the uSD card would be running above it’s nominal high voltage of 3.3V.

    My motivation is using a configuration like this in more extreme environments where high (and low) ambient temperatures and humitidy are prevalent. This makes running the components within spec a bit higher priority for reliability.

    Another solution could be to substitute something like a ATxmega32E5 for the 328p which will run happily up to 32MHz on 3.3V

    • You are correct, 16MHz/3.3V is out of spec for the ATmega328. The decision to run these at 3.3V 16MHz was made many years ago, but we’ve not had any issues with it.

  • Are there any major changes between this version and the previous version? (besides the prices, thanks btw)

    • Nevermind, I watched the video and answered my own question. No major changes but some nice minor ones.

Customer Reviews

4.3 out of 5

Based on 6 ratings:

5 star
4 star
3 star
2 star
1 star

1 of 1 found this helpful:

Nice SD card reader/writer, software weak

This is a great little SD card reader/writer. The sample code software is very sparse. I had to write much more elaborate code to make this logger useable and it took some time and experimentation to get it right.

1 of 1 found this helpful:

Just what the doctor ordered

I had been having some intermittent connection problems with a custom esp8266-based board. Devices that were further out from a router would sometimes lose their connection, reset, but then fail to reconnect. I had no way to capture debugging logs while deployed and very limited I/O to add anything else to the board for this purpose.

The OpenLog really fit the bill nicely here. It could reuse the serial TX/RX lines while deployed, so all I had to do was find a reset line. After some trial and error, I found resetting the OpenLog at esp init time was essential for stable operation. In addition, I added some code to check to see if the OpenLog is plugged in and to set the baud rate appropriately, 9600 w/ OpenLog, 115200 for console.

I’m very happy with what I ended up with. $15 for OpenLog, $6 for an SD card, and now I can get logs while the system is deployed.

1 of 1 found this helpful:

OpenLog is a powerful tool for embedded controllers

One of the best modules I ever used. It has all the good features, small, large capacity, simple interface, low price, great documentation, low power, and open source. Need to be considerate of data rate for the higher speed applications. Highly recommend for any data storage project. Worked first time following Sparkfun great hookup guide.

So useful and so easy

I have used this in several professional test situations, and it hasn’t let me down. You can just connect and go, or with some more involved commanding you can take advantage of the file operations to organize your data as you collect it. The only thing that I struggled with is the fact that the command mode needs carriage returns rather than line feeds, which caused me several hours of flailing before I could get the file operations to work. It would be nice if that were configurable in the micro-SD config file.

0 of 1 found this helpful:

Great idea ...

I love this idea …

In it’s current form it has a 1000 and one uses … but I wish there was a version with a barrel power connector and DB9 male connector.

solid logger

I was able to reliably log a stream of approx. 20 chars/record at 200 recs/sec using 57.6k interface. Using arduino pro mini. Very handy!

Related Tutorials

OpenLog Hookup Guide

April 7, 2016

An introduction to working with the OpenLog data logger.