Low-cost/power/size temperature logger

A low cost ultra-low-power small-sized high accuracy temperature logger for use in scientific research.

Similar projects worth following
This project's goal is to develop and build a temperature logger that can:
• Sense temperature with close to 0.1°C accuracy,
• Sample temperature every 10 minutes exactly,
• Store records for at least 180 days,
• Operate for at least 180 days on a coin cell battery,
• Easily transfer data to a computer via cable,
• Fit in a dirt-cheap watertight case,
• Cost per unit less than €5, including case.
I will make two of each prototype designs and then produce a batch of fifty for sea turtle nest incubation research.
The MCU chosen for this project is the Atmega328PB simply because I'm familiar with it and it fits the requirements. I could also use the Attiny817 but the cost difference isn't worth the learning time.

Temperature is one of the primary factors for sea turtle egg incubation success as well as sex determination. While a lot is already known, the onset of climate change makes more research a priority to mitigate the impact of increasing temperatures and changing climate patterns across sea turtle nesting habitats.

One of the challenges is the collection of enough data for statistically robust results. Deploying a large number of loggers is only an option for large institutions. Even there, researchers want to stop using them after they've lost a few in the field.

While I'd still recommend buying a commercial logger for anyone who just needs a few, I specifically started this project with the goal of building 50 units without the need to seek external funding.

Temperature Sensor

The temperature sensor used in this logger fits four requirements: High accuracy, digital output, small footprint, and low cost. The MAX30205 has an I2C interface. A sensor with an analogue output would require a small army of external components to achieve anything over the AVR's 10-bit resolution. This wouldn't fit with the size restrictions but would also consume too much power. The above sensor can achieve 16-bit resolution at a fraction of consumption and cost. While choosing, I was also considering Silicon Labs' Si7051 and Texas Instruments' HDC1080. I preferred the MAX30205 because it had more details on accuracy over its operating range, which is preferable for scientific research.


The temperature sensor gives its reading in two bytes. 180 days of ten-minute readings need 414720 bits plus some extra, so a 512kbit memory will do. The cheapest memory chip that's not a SOIC8 is Adesto's AT25DN512C. That comes in a TSSOP-8 package, which is small enough. The same package is available in up to 4Mbit versions, so extra memory can be used if needed.

Gerber files for second prototype plus uart and ISP adaptors.

Zip Archive - 160.32 kB - 01/13/2018 at 19:54



Pdf export of firmware flow diagram using dia.

Adobe Portable Document Format - 29.85 kB - 12/23/2017 at 17:22



Firmware flow diagram using dia.

x-dia-diagram - 5.50 kB - 12/23/2017 at 17:22


Gerber files of the first prototype. I've made updates since then, so please wait till I test and publish improvements, don't produce from this file.

Zip Archive - 38.71 kB - 12/13/2017 at 03:06


Eagle files of the first prototype. I've made updates since then, so please wait till I test and publish improvements, don't produce from this file.

Zip Archive - 23.24 kB - 12/13/2017 at 03:06


  • 1 × ATMEGA328PB-MN 8-bit MCU with I2C, SPI, RTC, UART
  • 1 × MAX30205MTA+ 0.1°C accuracy SMD I2C temperature sensor
  • 1 × AT25DN512C-XMHF-B 512kbit SPI EEPROM memory by Adesto in a TSSOP8 package
  • 1 × ECS-.327-7-34B-C-TR Frequency Control / Crystals 32.768kHz 10ppm 7pF
  • 1 × BAT-HLD-001 CR2032 coin cell battery holder SMD by Linx

  • Product ready

    Nikos05/25/2018 at 22:19 3 comments

    There's many photos, videos, and updates I've skipped due to a very hard deadline (turtle nesting season) combined with a happy family occasion that involves sleep deprivation, but this isn't one to miss: The final product made, copy 1 of 50:

    I've been through 3 prototypes to get here.

    P1 was functional but I hadn't made up my low-power connector so the only viable communication was the LED. Not very good for development, but I still have one blinking on my desk.

    P2 was fully functional, and I made 6 copies of it, which I used for extensive and exhaustive testing. One of them had humidity leaked into the case, which taught me to use black silicone instead of clear, so I can see the seal is good. It kept working after reset, but was later crushed by accident (desk-chair wheel) and I assume is not functional. Another lost its battery holder (I had already moved the next design to stronger through-hole instead of SMD), one is logging on my desk for verification of battery life expectancy, one has connectivity issues (I improved the connector in P3), and two of them are currently logging inside a sea turtle nest and I expect full data recovery upon retrieval. I needed some physical improvements such as routing, MCU pin breakout, manufacturing convenience etc. 

    P3 implemented them but needed work on the stencil layer. I tried a different manufacturer (for learning purposes), and found that tight soldermask margins can lead to bleaching over pads. I didn't even assemble one of those. I also learned that white soldermask makes it hard to inspect routing and pads and is too bright for close-up photos.

    P4 is the one seen above, and is the final product. I moved all passives to 0204 to make tight tracing easier and all signal traces are 6 mil, which pushes the low-cost PCB prototyping specs of most PCB manufacturers. I added a soldermask margin around the MCU's pads and widened the 0204 stencil openings so the solder stays on the board. I've also broken every single pin except the two for the crystal oscillator out to the perimeter headers, so this board is completely extendable. It's worked flawlessly for home stencil-skillet assembly.

    I apologize for the GitHub currently being empty, I had planned to reorganize it and haven't had the time to. If anyone wants to start making these, just shoot me a message.

    By the way, I also renamed this temperature logger to NestProbe TL1, with NestProbe being a series of planned scientific research devices and TL1 the model number. 

    TL2 (next year) will use ATtiny814 and no external crystal, and will aim for a $4 BOM. 

    Here's a plot of a beach trial run. I placed six P2 loggers together at 32cm depth. You can see where number 5 stopped due to humidity in the case - the humidity evaporated into the case and made it cooler for a while before the logger stopped.

  • A UART connector for low power designs

    Nikos04/01/2018 at 19:16 1 comment

    Low power devices try to keep all unused peripherals switched off. Even the simplest peripherals, such as UART, can shave months or years off battery life on devices powered by a coin cell if a 'UART receive' interrupt is active. If it isn't, how can the device know when it is connected to another device so it can power the UART up?

    I've come up with a simple, low-cost solution (I'm sure not the first): Add one more wire (INT) to UART's three wires (Rx, Tx, and GND). The MCU keeps this wire at a high state via its internal pull-up resistor. The connector shorts it to GND, which is how the MCU can tell it's connected and initiates data exchange. The device can check that pin's state at regular intervals, e.g. every time the RTC interrupt fires, or in less power consumption-wary schemes it can use a pin interrupt.

    The four wires are arranged it a 'T' formation to eliminate orientation confusion; there's only one obvious way to connect it. For now I'm using an FTDI-based USB to UART bridge board I got off ebay, with four pogo-pins soldered on a piece of stripboard.

    Everyone wishing to use even one of these temperature loggers will need this USB-to-UART-to-T-shape connector, so I plan to make an all-in-one PCB to include in this project's schematics.

    With this connector, I'm comfortably achieving a 1M baud connection. This speed is necessary because the device may need to send up to 64kBytes of data to the host, and this has to be achieved well within the 8 seconds between each Real Time Counter interrupts.

  • First temperature log

    Nikos03/14/2018 at 22:13 0 comments

    Here is the first day-long plus temperature log. X axis is clock time (UTC) and Y axis is temperature in °C. The spikes on the left are from holding the logger and the drops on the right are from opening the window.

    The data are extracted via uart by a python script and the plot is made by another python script, so it's all python on the desktop and all of these are/will be on the project's Github. Input, advice, feature requests from anyone with temperature logger experience or not are welcome!

    I've placed the logger outside and will publish another plot around the end of next week.

    I'll probably be working on this project for another year or so - this is just an early taste.

  • Measuring VCC - why bother?

    Nikos03/13/2018 at 11:08 1 comment

    At the time, it was a why-not decision. I didn't need to use the AVR's analog to digital converter (adc). I thought that was a waste, but had read about its ability to measure VCC. All I had to do was connect the battery to AVCC with a decoupling capacitor, which one should do anyway for stability, but also connect a decoupling capacitor to AREF (ADC reference).

    This design allows the adc to use VCC or the 1.1V internal bandgap as a reference, but you can also set the 1.1V bandgap as an input channel while using VCC as the reference. This configuration allows one to calculate VCC:

    VCC = 1.1V * 1024 / ADC 

    Why is this important for a temperature logger? What can it do if the voltage goes low? Can't you just use the brown-out detector?

    For scientific research there's a real reason to measure voltage and flag when it goes below a threshold. The MAX30205 sensor has a close-to 0.1°C accuracy, but only for VCC between 2.7V and 3.3V. Below that, measurements become less accurate, so it's important to know if and when the voltage dropped below that threshold.

    Given the logger's consumption, this shouldn't happen for at least 6 months, but having verification by the firmware is a bonus!

  • 100 batteries arrived

    Nikos03/13/2018 at 09:02 2 comments

    One of the sweetest aspects of using a CR2032 battery is the price you can get them for. Sure they're a couple of euros/bucks at the local store, but because of their popularity you can get a sweet deal from distributors.

    Because of their fire hazard (technically) serious distributors will only ground-ship them, so my best, and as it turned out quite good, option for Greece was . I got 100 batteries for just €23 plus €7 for ground shipping.

    Not bad for a bunch of Varta coin cells that should each run a logger for more than a year, and Panasonic or Energizers aren't far off.

    Mind you, I also bought a bunch of no-name coin cells off eBay a couple of years ago, but most of them were discharged even before I used them. To be fair, bad storage on my end was partly to blame for that.

    I'm looking forward to start deploying these with the loggers pretty soon!

  • Last prototype ... I hope!

    Nikos03/10/2018 at 15:19 0 comments

    A while ago I got a small batch of the second prototype's PCBs (many thanks to Zequing of Makerfabs). 

    This version was a special Gerber I made to include the temperature logger's board (left), an AVR in-system programming connector adapter (bottom right), and a uart connector meant to be used with surface-mount spring-loaded connectors (top right).

    Changes between prototype 1 and prototype 2

    The main difference between the first and the second prototype designs is that the uart connector includes one more line, which is only used to short a pin to ground so the firmware knows when it's connected and can initiate a transaction. I don't even use an interrupt for that; the firmware just checks whether that pin is high (unconnected) or low (connected) every time it's woken up by the real-time counter. This scheme is a bit boring but saves quite a bit of power.

    This design can use both the surface-mount and the through-hole versions of the CR2032 battery holder by Linx. This allows me to use already-purchased surface-mount uints, but in the future I'd prefer the through-hole because of added mechanical stressed caused by pressing the battery holder to hold the device.

    Other changes include a change in the LED's location and the exposure of the I2C lines on the headers around the PCB. 

    I also changed every component's stencil footprint. I use a steel stencil, and the first prototype had lots of solder knees and bridges. The second prototype, with a stencil opening of half the area for each pad, looks much better with no bridges at all. Everything worked on the first attempt. Below is the first unit cooking on the skillet.

    Connecting to a PC

    Although I added the uart connectors to the design, I haven't actually used them because I didn't add the spring-loaded smd connectors needed to my last order. Instead, I used a piece of stripboard and some generic pogo-pins, along with a 3.3V USB to uart device using FTDI's FT232. In the (not so distant) future, I plan to design a usb-to-serial board complete with pogo pins that you can hold like a pen.

    For now I'm using the serial adaptor's 3.3V output during firmware development.

  • The (very) basics of bootloader development

    Nikos02/10/2018 at 11:30 0 comments

      A temperature logger is a classic example where in-field firmware updates should be an option. I don't particularly plan to add functionality, but users should be able to use the (UART) data cable instead of a development environment and in-system programming to receive bug fixes and optimizations.

      I started reading about bootloaders and very quickly got a headache. The ATmega328PB datasheet has a bootloader chapter, and Atmel has released an AES-encrypted bootloader example specifically for this device. I didn't care about encryption, since this is an open-source project, but I thought I'd learn something... more headaches.

      After watching some youtube videos that mostly didn't explain the basic context, I luckily came upon a pdf put together by the AVR Freaks community a while back (found here at the bottom of the first entry) and finally got it.

      These are the three points I wish I had read first to make sense of all the other details:

      1. A bootloader is a regular firmware program and it's best developed as a stand-alone application. It should be small enough to fit in the bootloader section
      2. You need to set your programming environment to enable the bootloader section and put this application in that section. You can also use fuses to protect it.
      3. An mcu with a bootloader technically has two firmwares. It first runs the bootloader (hence the name)[Edit: depending on the fuse, the AVR starts at main program or at the bootloader, but if you set the fuse and there's no bootloader it will go to the main program, which is nicely forgiving]. Then your main application will run. If you want to, you can program your bootloader to be able to receive a firmware file and write it to the main application flash memory. The main application should be able to reset back to the bootloader to enable a firmware update, unless your device has a reset button.

      I think I've got these basics right. The next step, overwriting the flash, seems easier to grasp.

  • Program to download logger data

    Nikos01/28/2018 at 14:14 1 comment

    Any data logger is useless without an easy way to download recorded data. I'm considering the hardware design complete (for this model), so from now on I'm focusing on writing the firmware. In parallel, I'm writing a host computer program (python script) to setup the loggers before deployment and to download data in a usable format after deployment is complete. The script is available at the project's github. By necessity, I'm also developing the protocol of communication and data download, since I'm not aware of any standard or any open protocol used by already established software.

    Anyone with knowledge of an existing protocol or interested to help out, please let me know and I'll be happy to work together or utilize any advice.

  • Ultra-low consumption reached

    Nikos01/26/2018 at 08:48 0 comments

    I can happily report that the WSTL18 temperature logger can achieve its power consumption target. I had previously calculated a datasheet-based target consumption of 3.22uA during power-save mode, with the real-time counter running. I've currently achieved a power consumption of 2.92uA during power-save. I've already established communication with the temperature sensor and memory chip, and can verify they are operational and can successfully enter their lowest power-save mode.

    This measurement was taken at 3.3V coming from the uart adaptor, and was taken with a simple multimeter, so I don't expect it to be very accurate. I also expect the power consumption to be slightly lower at 2.7-3.1V from the coin-cell battery but higher at 30°C in an incubating sea turtle nest.

    Total power consumption

    Power consumption goes up to slightly under 5mA when all chips and a couple of mcu peripherals are on, but this only lasts for under 0.1 seconds. I'll add another 0.1 seconds for every 10-minute log, because the mcu has to wake up every 8 seconds (75 times per 10 minutes) and check if it's been ten minutes. I'll round it up to 1 second per log, so 6 seconds per hour just to be sure. So in one hour, the device has consumed 3uA + 5mA* ( 6 seconds /3600 seconds/hour) = 11.33uA. I'll round this up to 20uA.

    How much juice is in the battery?

    Most brand-name CR2032 batteries report a total capacity between 200mA and 240mA. It's important to notice that this is the capacity the battery can give until its voltage drops to 2V. Luckily, coin cell batteries maintain their voltage until shortly before they die, so the total capacity isn't reduced much for lower voltage drops. The ATmega328PB can operate at that voltage, but the memory chip needs 2.3V and the temperature sensor needs at least 2.7V. The temperature sensor won't give any warning, but instead its temperature readings will become widely inaccurate. I'd rather stop recording temperatures when the voltage reaches 2.75V. When will this happen?

    A power consumption of 20uA is roughly equivalent to 150kΩ load at 3V. According to Maxell's CR2032 datasheet, this should give more than 10000 hours of operation before the battery voltage starts dropping close to 2.8V. I don't expect the short high-consumption pulses to affect that by much. That's equal to 416 days, which is well over my original target of 180 days.

    Instead of trying to extend the logger's operational time, I'm just going to say that the WSTL18 can safely maintain stated temperature accuracy for 180 days on a new coin-cell battery with a stated capacity of at least 200mA. That's good enough for the salesman.

    Battery-Time test

    I've actually designed the WSTL18 so that the ATmega328PB can measure the voltage of its power supply using its internal 1.1V reference. A capacitor is connected to the Vref pin, which allows the ADC to use Avcc as the voltage reference to measure the 1.1V refrence. This is a power-expensive operation and I won't have the logger do it during regular logging, but I do plan to have a few loggers run a voltage-time log, which will help verify the logger's stated duration of operation.

  • Design a shield with your next coin-cell project

    Nikos01/08/2018 at 21:31 0 comments

    The WSTL18 temperature logger is slightly larger than a CR2032 coin-cell battery. With most of the Atmega328PB's pins broken out to headers around the board's perimeter, it doubles as a coin-cell development board.

    To make expansion shield making easier, I've made a template shield with all pins labeled. The entire board plus shield will fit in a readily available 5ml acrylic jar, as long as common-sized components are used. For anything larger, such as a LoRa module or LCD screen, you'll have to find another casing solution.

    The shield includes a milled opening not seen in this rendering, to allow access to the uart connector pads on the WSTL18 below.

    The shield template is available in Eagle format on the project's Github (go to Eagle -> WSTL18_SHIELD). 

View all 22 project logs

Enjoy this project?



Mikkel Jakobsen wrote 12/30/2017 at 09:58 point

I wondering if gps location logging could be added without compromising the low-power design too much, and if it would provide any value at all. 

  Are you sure? yes | no

Nikos wrote 12/31/2017 at 06:03 point

Hi Mikkel! It depends on the GPS logger, the logging interval, and expected duration. In my experience with a U-blox Neo-6M or similar you're looking at around 40+mA for at least a minute before getting any useful accuracy. That could be stretched to work for a few days, but with the GPS module's size and cost, why not use a 3.6V lithium battery? (apart from the coin cell challenge)

  Are you sure? yes | no

bobricius wrote 12/22/2017 at 08:42 point

great package, axactly I search this for years for my wrist watch. many thanks !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  Are you sure? yes | no

voja wrote 12/21/2017 at 09:54 point

Hi Nikos, this is great project! I would like to build some "expansion shields" for it. Do you maybe have a repository on GitHub or some other place where I can check out the firmware for this device. 

  Are you sure? yes | no

Nikos wrote 12/21/2017 at 18:00 point

Hi Voja and thanks! An expansion shield should be possible with 1.27mm headers. With the current design, the I2C bus won't be accessible on the expansion shields, it only goes to the temperature sensor. I'm currently working on the firmware and will put it up on a GitHub repository once it's doing something useful, hopefully around early January.

  Are you sure? yes | no

voja wrote 12/22/2017 at 09:57 point

Great! My idea is to put Lora communication on your board. It will use SPI. At the moment I am not sure SPI0 or SPI1 because SPI0 is used for memory. Are you using Arduino or something else for firmware programming? I am looking forward to see your firmware, and in the mean time I will send your gerbers to manufacture. 

  Are you sure? yes | no

Nikos wrote 12/22/2017 at 22:13 point

That's a great idea. It should work well with SPI0 as long as we use one of the available pins for 'slave select'. You'll also need a few pins for the various LoRa interrupts. I still think it would be useful to have the I2C pins available for other sensors. It might be nicer to base the shield on a more finalized design, so can you wait for a while so you can manufacture from the updated gerbers?

I use Atmel Studio but I can also work with console-based gcc-avr, both cases using C. I added a diagram of the firmware at the project's files for now.

Do you have any LoRa working code? I've written some code for another project but I've never finalized or tested it. I'll be happy to add it to the source code and see if that works.

  Are you sure? yes | no

msmielak wrote 12/16/2017 at 05:28 point

Thanks for sharing, I've been a huge fan of low cost research equipment, in fact I have buit and used multiple different loggers for my own research (temperature, light and others) and now I am slowly pushing forward an animal-borne movement logger.

  Are you sure? yes | no

Nikos wrote 12/16/2017 at 06:30 point

Thanks! That's interesting, I also made a light meter for very-low light measurements, we've been recording light pollution on the nesting beaches for three years now. I've improved on that and plan to publish the next version. A movement logger will be very useful, I'm looking forward to that!

  Are you sure? yes | no

zakqwy wrote 10/03/2017 at 14:20 point

Excited to see more, especially the dirt-cheap waterproof case.

  Are you sure? yes | no

Nikos wrote 10/03/2017 at 18:45 point

Thanks! At the moment I'm thinking of simple screw-cap containers. These aren't water-tight, but the loggers will be buried for months, which means I can seal the thread with silicone and break the seal when it's time to open them

A second alternative is simple plastic wrap, but I'd rather the screw-caps that can be re-used.

I'll report on field testing after the board design is done.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates