Temperature and Relative Humidity

Low power temperature and relative humidity datalogger using SHT15 and DS3234 RTC

// Version 0.03, Last updated on: March 30, 2015

The temperature and relative humidity of indoor air is an important parameter that can influence indoor microbial survival, abundance, and community structure (Ramos and Stephens 2014, and references therein). Temperature and relative humidity can also be used to infer other information about indoor environments, such as whether or not it is being heated or cooled. Data loggers like the Onset HOBO U12 provide a robust solution for logging temperature and relative humidity at specified time intervals ranging from 1 second to 18 hours. A single HOBO costs around $140. Onset’s software, HOBOware, is also required for launching the device and reading data from it and it costs an additional $99.

The following tutorial will guide you through the process of building your own open-source low power T/RH data logger based on the Arduino platform and built on a robust solderable breadboard format, as shown in the pic below. The sensor and data logger combination is designed to measure T/RH with similar accuracy to the Onset HOBO devices and store the data onto an SD card at specified intervals. The goal is to achieve approximately 8-12 months of battery life with 3 AA batteries or over 12 months with a 2,500 mAh Lithium ion polymer battery.

assembly7_mod_pers

Figure 1. Assembled OSBSS temperature and relative humidity logger

Difficulty Level: Beginner, soldering skills required, little to no electronics knowledge required.

Time required: 1-2 hours, depending on experience and skill.

Important:

  1. If you are not familiar with how a breadboard works, check out a simple tutorial by SparkFun. We built our first prototype on a regular breadboard, but this tutorial uses a more robust solderable breadboard which makes the logger more compact and durable.
  2. You will need some soldering skills for this project. If you are new to soldering, check out SparkFun’s soldering tutorial.

 

STEP #1: What you will need:

Parts requirements:
Arduino Pro Mini 328 3.3V/8MHz ($9.95) — we used these less expensive 3.3V clones (< $3.00)
DeadOn RTC DS3234 Breakout ($19.95)
CR1225 coin cell battery for the RTC ($1.95)
SHT15 Humidity and Temperature Breakout ($41.95)
US sensors ‘ultra precision’ thermistor (10,000Ω resistance) ($8.00)
SanDisk microSD memory card 4GB (or any other capacity; we recommend SanDisk because of reliability issues with others) ($6.29)
microSD Transflash breakout ($9.95)
Adafruit Perma-Proto Half-sized breadboard PCB ($4.50)
Transistor – NPN ($0.50)
LED Basic Green 3mm ($0.35)
3 AA batteries and battery holder ($1.95) or one Li-Po 3.7V 2500mAh battery ($14.95)

Note: Headers are not included with some components. You may have to buy them separately.

Total parts cost: between about $90 and $110

(If you are familiar with designing and etching PCBs, buying SMD parts of various components listed above rather than the breakout boards will result in a much lower expense.)

Required accessories:
FTDI Basic Breakout 3.3V ($14.95)
Jumper wire kit ($6.95)
Resistor kit ($7.95) (we will use three resistors: 47Ω, 330Ω and 10,000Ω)
Soldering iron ($44.95 or $9.95)
Various common tools including needle-nose pliers, wire cutters, and solder

Software requirements:
Arduino IDE (1.0.5 or higher)

Arduino libraries required:
SDfat library (by William Greiman) – Pre-Aug. 2014 commit
OSBSS SHT15 library
OSBSS DS3234 RTC library
OSBSS PowerSaver library

*You can view and download OSBSS libraries from GitHub.

Note: The SHT15 sensor is a very accurate, pre-calibrated temperature and relative humidity sensor from Sensirion. Similarly, the DS3234 is an extremely accurate real time clock from Maxim and the US sensor thermistor is ultra precise, providing 0.05°C accuracy. There are less expensive and less accurate alternatives for these products, but our tutorial is aimed towards people who are interested in gathering data for research applications that require high precision and accuracy. This means that any specific hardware setup and software setup (libraries, program code) is strictly meant for the specified products only.

If you are interested in a much simpler, albeit less robust, temperature and relative humidity datalogger, check out our detailed tutorial using the DHT22 and Arduino Uno.

 

STEP #2: Assembly

The assembly of the board is straightforward, especially if you already have some experience in soldering electronic components. We will be using Adafruit’s Perma-Proto half-sized breadboard. This is board has the same layout as a typical half-sized breadboard, but requires all components to be soldered on it. This gives us the advantage of having strong connections and ensures the robustness of the data logger.

assembly1

Figure 2. Solderable breadboard from Adafruit

This is what we want to achieve:

assembly7_mod

Figure 3. Top view of an assembled OSBSS temperature and relative humidity logger

Start by placing all the wires first, as some larger parts will sit on top of them. Cut the wires in appropriate sizes and arrange them as shown. Be careful to leave just the right length of insulation around each wire such that the wires can remain relatively flat against the breadboard while also not shorting across other wires or connections. You can use various sized jumper wires from the kit or cut your own to the appropriate lengths. Use the numbers marked on the protoboard to help arrange the wires at the exact location. The arrangement of the wires will start making sense as we progress further in the tutorial.

assembly2_mod_1

Figure 4. Wiring arrangement (top view)

Turn the board upside down and arrange two more wires as shown. The numbers indicate those marked on the protoboard to help locate the position. The great thing about this protoboard is that you can wire components from the top and bottom, effectively making this a “partial” dual-layer board.

assembly2_plus_mod

Figure 5. Wiring arrangement (bottom view)

The outline of the wires shown in Figure 6 below indicate where the two wires actually go under the board.

assembly2_mod_2

Figure 6. Wiring outline (top and bottom)

Bend the ends of the wires to ensure that they stay in place. Be sure to bend as you go so the wires stay held tightly. Now you can solder each wire to the breadboard, while making sure each pin hole is completely filled with the solder. You can solder the holes from either side, whichever is easier, but make sure not to melt the wire insulation when soldering from top. Tools like the Third Hand are very helpful here to hold the board in place. We use SparkFun’s Special Blend solder. We feel that 0.020″ (0.5mm) solder wire works best for prototyping.

assembly4

Figure 7. Soldering the wire connections

Once all wires are soldered from the bottom, let the board cool down for a minute or two. Now clip off the ends of the wires that you bent earlier. We don’t need those anymore. Be careful when clipping wires as they can shoot off quickly. We recommend wearing safety goggles and clipping wires in an enclosed area (such as under a desk or into a boxed enclosure).
assembly5

Figure 8. Clipping the wires

Now we can start placing smaller electrical components, like the transistor, the LED, and the three resistors. The transistor is used to control power going to the microSD card breakout, the thermistor and to the SHT15 sensor for reducing overall current draw of the data logger. SparkFun has a detailed and well-explained tutorial showing how a transistor works. Be careful to orient the transistor exactly as you see it in Figure 10, with the flat part facing away from its accompanying 330Ω resistor (which is connected in series to the transistor’s middle pin). The LED is used as a visual indication of whenever data is written to the SD card. Be very careful with the polarity of the LED when installing. The 47Ω resistor is connected to the positive side of the LED (the curved end with a longer pin), while the other end of the LED goes to ground (this is the shorter wire closer to the flat edge of the LED). The 10,000Ω resistor is used in series with the thermistor (which will be placed later). Note that the resistors used are not polarized; i.e., they can be placed in any orientation without worrying about which leads are positive or negative.

Before soldering the 10kΩ resistor, we can measure its actual resistance with a multimeter. We observe that it’s not exactly 10,000Ω, but varies slightly. Note this value down, as we will use it in the code in Step #4. While this step is optional, since the resistance displayed by the multimeter itself may be a little skewed depending on its accuracy, in most cases it may help in slightly increasing the accuracy of the readings given by the thermistor.

assemblypre6_mod

Figure 9. Measuring resistance with a multimeter

Place the small components and repeat the same procedure with these as well: insert components, bend the wires, solder the parts and finally clip off the leftover wire.

assembly6_mod

Figure 10. Adding base components

Now that we have our base circuit ready, we can start placing the main components, which are the microSD breakout, the DS3234 RTC breakout, the SHT15 temperature and relative humidity sensor breakout, the thermistor and the Arduino Pro Mini 3.3V.

assembly_pre_7_1

Figure 11. The main components: thermistor, RTC breakout, SHT15 breakout, microSD breakout, and Arduino Pro Mini

First, we will need to solder some headers on the components with through-holes (except the thermistor). The Arduino Pro Mini requires the top 6 pin headers to be soldered facing upwards or on the side, since these pins are what you will use to program it. SparkFun has a neat tutorial explaining how the Pro Mini works and how to use it.

amp

Figure 12. Arduino Pro Mini with headers

Important Note: We have disconnected the red power LED and green status LED on the Pro Mini by cutting out the traces connecting them. This neat tip was provided by a user on SparkFun for disconnecting the voltage regulator (do not disconnect the voltage regulator however – more on this below) and we used the same technique on LEDs. The LEDs significantly increase the current draw and since we want to control our own LED, we don’t really need them. Be careful when you do this — you need to cut the trace with a sharp blade until the circuit is physically broken. But you don’t want to damage any other adjacent components while doing so. You may actually want to try this step before soldering the Pro Mini to the breadboard. Removing the green status LED from the circuit is important for low power, but also becomes necessary when using Pro Mini clones and SPI devices. If you look closely, some clones have a 470Ω resistor, while some even have a 1,000Ω resistor connected in series with the LED. In comparison, the original Arduino Pro Mini has a much lower 330Ω resistor. Since this LED is connected to pin 13 (SCK) on the Arduino, having a large series resistance on this pin can interfere with data transmission between some components on the SPI bus and may result in partial data loss.

Cut the traces for both LEDs as indicated by the red lines in Figure 13 below.

cut

Figure 13. Cutting the traces to onboard LEDs on the Arduino Pro Mini

Now, let’s place each component on the board in the appropriate place and solder them one by one. Refer to the overlay of the larger components and the completed datalogger below (Figure 14 and Figure 15) to give you an idea of exactly where to place the wires on the board. The pins marked in blue will help you locate them properly. Be careful when soldering the US sensor’s thermistor – it has extremely fragile leads.

Note: When soldering the boards, if you are having trouble getting them to line up nicely (i.e., the boards aren’t parallel to your main breadboard and your headers aren’t at a 90° angle), you may want to start by soldering just one pin to anchor the board first. Then you can hold the entire piece in one hand while applying heat from the soldering iron in the other hand to briefly melt the solder until you can position it correctly. (Sparkfun has a nice tutorial on header installation).

pos_mod

Figure 14. Main component overlay

The last step involves installing a 2-pin female header next to the GND and RAW pins on the Pro Mini. This is where we can connect our power source, i.e., a battery pack.

Important Note: Using the RAW pin on the Pro Mini means any external voltage (from a battery pack for example) will go through the on-board voltage regulator to provide a regulated 3.3V from the VCC pin to all components. The voltage regulator on the Pro Mini (revision 14) draws about 0.1mA of current while the logger is in sleep mode. If you already have a regulated 3.3V power source, you can disconnect the voltage regulator by cutting out the trace as explained previously and connect the battery directly to the GND and VCC pins instead. Any current going through the VCC pin now will not go through the voltage regulator. While not using the on-board voltage regulator on some boards significantly reduces power draw and gives great battery life, using any voltage slightly higher than 3.3V in this particular setup may cause damage and reduce component life. The components may also fail to work; the microSD card reader in particular may corrupt the memory on the microSD card especially if the voltage exceeds its maximum rating, forcing you to manually format the card on the computer. If you are new to low power applications using an Arduino, we recommend supplying a regulated voltage, 3.3V in particular, to all components in order to ensure maximum lifetime of the components, avoid potential failure and data loss. In short – use the RAW pin. There are some Pro Mini clones with a more efficient voltage regulator on board, which may prove very useful here.

assembly7_mod

Figure 15. Completed temperature and relative humidity data logger

Once it is soldered, clip off the excess header pins from under the board. Be careful again to wear eye protection while clipping the pins from underneath the board. Repeat this procedure with the microSD, RTC, and SHT temperature and relative humidity breakouts and the thermistor to complete the hardware part of this tutorial.

Ensure the components align properly with the wires. A simple check is to follow the ground pin from the Arduino (GND) and make sure all the components’ GND pin are on the same connection. You can do the same with all other pins on the Arduino.

Now you are ready for the software part of the tutorial.

 

STEP #3: Setup IDEs and libraries

Before we get to the actual programming, first we need to set up the Arduino IDE (Integrated Development Environment). This is where you will be putting your main program code. Download and install Arduino IDE (make sure it’s v1.0 or higher; we used v1.6.0).­­­­­­­ It is available for Windows, Mac OS, and Linux.

Next, you will need the DS3234 RTC library and power saving library for the ATmega328. We specifically developed these libraries for our low power dataloggers. You will also need the SHT15 library and the Sdfat library by William Greiman. You can download all the libraries from GitHub.

Installation of these libraries is as simple as extracting all files from the zip file into the “libraries” folder located inside your Arduino IDE installation directory. For example, in Windows, this may be located in C:\Program Files\Arduino 1.0.5\libraries\ or C:\Program Files (x86)\Arduino 1.0.5\libraries. On a Mac, the default directory is user\documents\Arduino\libraries. After extraction, you will have four new folders in your libraries directory: DS3234lib3, PowerSaver, SdFat, and SHT15libmod2.

Note: The library file and folder names should appear exactly as listed above. If the folder name has an extra word such as “-master” at the end, rename it by removing that part.

 

STEP #4: Programming the datalogger

Now that we have our IDE ready and our libraries installed, let’s program the datalogger. You can get the .ino file and download the entire code from GitHub. Our code is still being tested extensively and we try our best to keep it simple while eliminating bugs. If you have any comments about it, please let us know.

Note: An explanation of how the circuit works is given at the end of the tutorial.

Keep the .ino in the same folder as the file name (e.g., Arduino\osbss_trh_v_0_01\osbss_trh_v_0_01.ino). Open up the .ino file in the Arduino IDE.

Once in the code, we need to do a few things:

1. Manually edit the variables interval, dayStart, hourStart and minStart  to your preference. Make sure that the interval is set in seconds only. The other three variables are pretty self-explanatory – enter the day, hour and minute time of when you want the logger to start logging data. The hour should be set in 24-hour clock.

2. Now Edit the variable filename whose value is given in quotations in the code. Make sure that the filename follows the proper format. You can use any combination of letters and digits in your file name as long as it’s less than 8 characters, does not have any spaces and does not start with a number. This is because the SdFat library uses a slightly restriction version of short names for files. Examples would be: filename.csv, log.csv, data_2.txt. Remember that the filename must also have an extension.

3. (Optional) Remember the resistor’s actual value we noted down? We can go in the code and add this value. Scroll down to the line:

Here, you can replace 10,000 with the true value of the resistor. In our case, it was 9,870Ω. If you forgot to measure the actual value of the resistor or don’t have access to a multimeter, you can leave it as 10,000Ω. You don’t need to change anything else in the code.

Now go to Tools > Board and select Arduino Pro or Pro Mini as shown in Figure 16. Make sure the processor’s voltage and clock speed are set to ATmega328 (3.3V, 8MHz).

Ard_ide_scrnsht

Figure 16. Setting up the Arduino Pro Mini in Arduino IDE

The Arduino Pro Mini uses an FTDI adapter for programming. You will need to download the latest drivers for the FTDI adapter. The FTDI is connected to the PC via a common mini-B USB cable. Connect the FTDI to the Arduino as shown in Figure 17 below.

Note: Some Arduino Pro Mini 3.3V clones in the eBay link provided above have the programming pins reserved. Make sure the pins on the FTDI align with the pins on the Arduino Pro Mini you are using.

ftdi

Figure 17. Connecting to the Ardunio Pro Mini via FTDI adapter

Once the FTDI is connected via USB, go to Tools > Serial Port and you will see a new COM port listed (ignore COM 1). This is the FTDI detected by the computer. Select this COM port (on a Mac it will be labeled with a ‘tty’ prefix). Click the Verify button to verify that the code contains no errors. If any errors do pop up, check if you installed the libraries properly. The Arduino IDE needs to be restarted after the installation of the libraries, if it was previously open. If you notice errors in the code, leave a comment and we will try our best to fix it.

Now click the Upload button. You should see “Uploading” at the bottom status bar and the FTDI’s LEDs will start blinking rapidly to indicate data transfer. Once the upload process is complete, you should see the LED on the datalogger blink once. This means the code works fine and data is being written to the SD card. Click on the Serial Monitor button. At the bottom of the new window that pops up, verify that the baud rate is set to 19200.

Once your code is uploaded from the Arduino IDE the Pro Mini retains that information in memory and it won’t need to be re-uploaded unless you need to relaunch the logger at a different time and set a different interval. If the code is significantly updated later, we will post it here and you can re-upload the entire code again (making sure you edit the launch variables).

Note: Mac OS users might have a problem during uploading. If you receive an error such as avrdude: stk500_recv(): programmer is not responding, it is likely an FTDI driver issue. You many need to download the latest Virtual COM Port Drivers from FTDI. Try that and restart the Arduino IDE. If you are still getting a similar error after that, follow the instructions provided in this stackoverflow thread: (1) Go to the Arduino IDE preferences pane and select Verbose output during upload, (2) during the uploading process you will see avrdude send three packets (avrdude: Send: 0 [30] [20]). There’s a trick: if you hit the reset button on your Pro Mini just before these 3 packets are sent the program will likely be uploaded successfully. Hopefully this issue will be resolved in a later version of the Arduino IDE.

Important Note: The DS3234 RTC breakout from SparkFun does not come with its own battery. In addition to buying a battery, you will have to set the current date and time when you use it for the first time. Once it’s set, the RTC maintains the date and time on its coin cell battery for several years, just like any other clock. Check our blog post about configuring the RTC’s date and time. Unless you connect the RTC incorrectly or remove its backup battery, you won’t have to set the date and time again. Be sure to do this first, and then launch the datalogger.

You are now ready to use the temperature and relative humidity datalogger!

 

STEP #5: Test Run

Now you can take the FTDI cable off and connect your battery. The positive (red) end of the battery pack should go into the RAW pin on the Arduino, while the negative (black) end goes into the GND pin. Be VERY CAREFUL not to get this wrong or you can easily damage the components! You can either use a 3 AA battery pack,  Lithium Ion Polymer battery or any other power source you want.

Timestamped temperature and relative humidity data will be recorded at the interval you selected for as long as the logger has power. To retrieve data, simply eject the microSD card and place into a microSD adapter and read directly from your computer as if it you were downloading photos from a digital camera. You’ll see your .csv file with all logged data up until the point that you removed the microSD card or the logger lost power (whichever comes first). One thing is for sure – you probably will never ever run out of memory while writing data. During our tests, one of our loggers was logging data at 1-minute intervals for about 3 months (over 100,000 measurements) and the filesize was around 4.86MB only. At this rate, it would take about 415 years to completely fill up a typical 8GB microSD card.

As an indication, when the microSD card is out, the datalogger blinks the LED three times at every time interval to indicate a missing card. Data will not be logged during the time the SD card is out of the datalogger and logging will resume once you insert it back in. Alternatively, you can relaunch the logger with different launch parameters.

Understanding how the circuit works:

Now that the circuit is ready and you have successfully launched your logger, we can take a look at the layout and begin to understand how it all works. The Arduino is the main microprocessor to which every other component is connected. If you noticed while wiring, the microSD card breakout and the RTC have some pins in common, namely, MOSI (or DI), MISO (or DO) and CLK (or SCK). These three pins are shared by all SPI devices. in a circuit. They connect to pin 11, 12 and 13 on the Arduino respectively. Each SPI device has a unique SS (or CS) pin on the Arduino through which it can be identified, and the microSD card breakout’s and RTC’s are pin 9 and 10 respectively. To learn more about Serial Peripheral Interface (SPI) and how it works between devices, check out a nice guide by SparkFun.

The SHT15 is an accurate relative humidity sensor from Sensirion. It uses a 2-wire serial interface for communication and provides a 14-bit digital output which is converted into actual RH reading. Pins 3 and 5 on our datalogger are used for communicating with the SHT15. The GND pin on the sensor’s breakout board is connected to the transistor’s collector pin, so we can power the sensor off while it’s not taking any measurement.

The thermistor is a simple analog component. Common thermistors like the one we’re using have a negative temperature coefficient. This means that as temperature increases, their resistance decreases and vice versa. This change in resistance can be easily measured if we convert it into a voltage reading. The Arduino Pro Mini is based on Atmel’s Atmega328P processor, which has a 10-bit ADC (Analog to Digital Converter) that can read a range of voltage input. The pins A0 to A7 on the Pro Mini are all analog input pins that can read voltage outputs from various sensors. The two wires that go under the board connect the thermistor in the circuit. The green wire connects the thermistor to Arduino’s A0 pin to read its value and the white wire connects the other lead of the thermistor to the transistor’s collector pin, so we can power the thermistor off while it’s not taking any measurement.

The transistor is used to turn off the microSD card, the thermistor and the SHT15 when not in use. Any component connected to the Arduino’s pins can consume some power, even when they’re not taking measurements. While microSD cards are becoming very efficient in standby mode these days, they need proper pin configuration to avoid unnecessary power draw when not in use. For extended logging applications, the standby current consumption can also been seen as significant. MicroSD cards also consume a large amount of power during initializing, reading and writing, from 50mA up to 150mA in some cases. Using a transistor helps in supplying a large amount of current when needed, and turning it off when not required. Arduino’s pins can supply around 30-40mA only, while the total power supplied to all devices by the Pro Mini’s (Rev. 14) voltage regulator is around 200mA. If 150mA out of this is consumed by the microSD card every time we wake it up, then we might be reaching our threshold of maximum current consumed by the circuit and other components might fail, especially if we happen to add more sensors or devices in this footprint. A transistor can overcome this issue and supply a large amount of current when needed. We simply connect the GND pins of the components we want to turn off to the collector lead of the transistor, instead of the actual GND in the circuit. The Transistor’s emitter pin is then connected to the actual GND pin. The transistor basically acts like a switch, but can also allow devices to pull large amounts of current from the power source. To read more about how transistors work and what else you can do with them, check out SparkFun’s tutorial.

The DS3234 RTC keeps the time for our datalogger. Our specially made library for the dataloggers allow reading of time as well as generating an interrupt. The RTC has alarm functions which allow it to generate a square wave at any specific interval or at any given time. More information about how they actually work is given in the RTC’s datasheet. We set up the code in such a way that it detects what interval you specified (in seconds), and then converts it to an actual time in the future to generate an alarm in the form of a square wave. Once the Arduino is in deep sleep mode, some event like a button press, interrupts on a pin or an internal timer can wake it up. If none of these are set up, the Arduino is permanently in sleep mode and never wakes up. The RTC’s SQW pin is connected to Pro Mini’s pin 8 and we set up the code to detect a pin change interrupt on this pin. Let’s say you define the logging interval as 60 seconds. When the Arduino goes to sleep, the RTC sets an alarm for 1-minute in the future and the moment the current time and the alarm time is matched, it generates a square wave on pin 8, which is detected as an interrupt by the Arduino and it wakes up to take measurements and save data. All of this is done almost instantaneously.

The LED gives a visual indication of when data has been written to the card. LEDs can consume a high amount of current, so we want to make sure to limit the current going to the LED by using a resistor in series with it. The LED in our datalogger is connected with a resistor to pin 7, which is turned on and off in code. The LED is turned on for about 10 milliseconds once data is written to the SD card and then turn it off instantly.

 

Summary

assembly7_mod_pers

Figure 18. Assembled OSBSS temperature and relative humidity logger

With the above setup, we can now achieve an idle current draw of around 0.195mA, raising up to several milliamps for a very short duration when the chip wakes up, takes temperature and relative humidity measurements and writes data to the SD card and then goes back to sleep. All of this happens within about 0.05 seconds, before the chip is in power-down sleep mode again. We are using alarm features in the DS3234 RTC, which generate an interrupt using the SQW (Square Wave) pin. The Arduino only wakes up when it detects this interrupt, which happens every time your logging interval is matched.

By using this low power approach, we can get a theoretical lifetime of 8-12 months on 3 AA batteries (assuming logging interval of 1 minute). Alternatively, you can also use one 3.7V 4,400mAh Li-Po battery from Adafruit ($19.95) to get almost two years of battery life. If you are feeling adventurous, you can aim for ultimate power-savings by using the bare ATmega328P chip itself. With no additional peripherals, it can significantly reduce current draw even further, increasing the battery life up to 4-5 years in some cases; but beyond that point, the self-discharge rate of the battery would limit the total time the logger can have power.

You can now put this setup in an enclosure for protection and to improve aesthetics.

assembly8

Figure 18. Lithium ion battery in an acrylic enclosure

We placed a Li-Po battery in a laser cut acrylic box and placed the datalogger on top of it. We also provided some openings on the top for the sensor to measure the air temperature and relative humidity.

assembly9

Figure 19. Completed and powered data logger installed in custom acrylic enclosure

Note that while using an enclosure provides protection, it may also increase response time of the datalogger, as air inside the box can take a while to change relative to the air outside it. It may also skew the readings to an extent, depending on the environment. We are still working on other types of enclosures that have lower thermal mass and are easier to prototype. If you have ideas please send them our way!

If you already have a lot of experience in soldering and developing your own PCBs, you can save some money by buying the SMD parts in bulk instead of the breakout boards. Soldering SMD components is a very delicate process  – any wrong move in the circuit design or soldering, and your entire PCB is toast. Only try it if you know exactly what you’re doing.

To see an example of data collected from one of these custom data loggers, check out Prof. Stephens’ post on his first temperature and relative humidity version 0.01 build and his follow-up post on the latest revision of our datalogger.

  • Sean

    This is a great tutorial. I think you may be able to get even greater power savings by using a different pin as an Interrupt from the clock. You are using pin 8 as the interrupt. If you go into SLEEP_MODE_POWER_DOWN instead of just sleep you can save a ton of power BUT it will fail to wake up on pin 8. Only External Interrupt 2 and 3 (only level interrupts on INT0 (pin2) and INT1(pin3)) will wake it up. You would need to move to pin 3 and adjust your code to match the new pin (as well as deep power down and not just sleep)

    One more thing that may be convenient (batteries do need to be replaced/recharged at some point) is if it kept the logging frequency from the GUI. For example I set it to log every 10 minutes starting on some date. On that date it starts logging and keeps logging until the battery dies. At that point you need to “re launch” it after the battery has been replaced/recharged. It would be great if it would power up on the new battery and just start logging again at the 10 minute interval instead of relaunching it.

    It would also be sweet if you shared the GUI building code. I downloaded Processing but it is missing the source files to be able to edit the GUI (I would like to add some other variables that are logged)

    Thanks for your hard work!

    • http://www.osbss.com/ OSBSS

      Thanks for your comments. We are using the power down mode for our datalogger. That’s how we managed to achieve over a year of battery life on these loggers. The logger still wakes up by detecting a pin change interrupt on pin 8. It is not an external interrupt. You can pretty much wake the logger up by generating an interrupt on any pin, as long as you define it as a pin change interrupt. Our PowerSaver library shows how this can be done in just two lines of code.

      Continued logging is a good idea and should be fairly easy to implement. I’ll add it up in the next version.

      The GUI is currently going through some revision changes – If you plan on using our code, I recommend manually launching the logger by editing the launch variables in the code before uploading. We’ll update the tutorial soon.

  • Sean

    I have one question. What are you doing with pin 6?

    #define RTCPOWA 6 // pin 6 supplies power to DS3234 RTC

    Not on the wiring diagram…Looks to me like the RTC gets power from VCC and ground via Ground. You could run the RTC on the same ground as the sensor to reduce the power using the transistor and do the same thing for the SD card. Would that not reduce the power usage without having to turn RTVPOWA on and off?

    Just my $0.02

    • http://www.osbss.com/ OSBSS

      Ah, it seems that some of the cruft is still left over in the code from experimenting. Thanks for pointing that out – It should be cleared now.

      Turning the RTC’s power off requires extra code to make sure it still generates an interrupt in time-keeping mode only and that our Arduino can still detect it, since it’ll be at a very low logic level. We were testing the BBSQW feature of the DS3234 RTCs and that’s what you were seeing in the code. Yes, it does reduce the power usage and you can add around 4-5 months of battery life, but the clock time appears to drift significantly every day due to continuously switching between VCC and internal battery of the RTC. If the RTC is always powered on, the time stays very accurate, with minimal drift, at around 10 seconds per year. Accuracy should always more important than aggressive power-savings. The RTC consumes around 89uA of current when it’s powered by VCC, so we still have around 1 year and 2 months of battery life (assuming 1-min intervals), which will still satisfy most situations.

  • http://www.osbss.com/ OSBSS

    Yes, you are right, there are other peripherals that can be disabled. If you look at the code in Github, we do disable Watchdog timer, Brown-out detection, ADC and two-wire interface before the MCU sleeps, so we can save maximum power. Testing the same code on a bare ATmega328p gives an idle current draw of around 0.0002mA (0.2uA), almost close to Atmel’s specification of 0.1uA in power-down mode. The extra 0.1uA is because we didn’t set the state of all GPIOs in code. External interrupts and Pin-change interrupts differ in the way interrupts are handled in software but are the same when hardware is concerned, so power consumption shouldn’t be any different if you use one over the other.

  • Michael Waring

    I’m putting one of these T/RH sensors together now with the actual Arduino mini (not a clone). Is cutting the traces necessary for data collection purposes still? Or just to keep it low power? If I don’t cut them, how much less time should I expect the sensor to run under one battery set? Thanks!

    • Lambert

      Hey Michael, I am working this project as well. Do you have any trouble in compiling the code? I met some problems which might caused by sdFat libraries. Hope to discuss with you.

      • Michael Waring

        What problems are you having with it? I’m having a hard time getting the SdFat library recognized, though all other libraries are fine. I saw that this was updated on 3/21/2015, so maybe there’s an issue with that?

        • http://www.osbss.com/ OSBSS

          Thanks for pointing this out. The SdFat library had a new core FAT implementation on the date you mentioned. The function that initializes the SD card is updated. The code on GitHub is now updated to reflect the new core implementation. Please try the updated version of the code – it should work now.

          • Lambert

            I am working on the project right now, and I met two problems. First, I saw Important Note reminds us to set RTC before launching datalogger. What is the exact way to set up RTC here? Second, I found that both microSD Transflash breakout and SHT15 are not grounded, only Arduino Mini and RTC are real grounded. Is this a problem?
            I got almost everything done, but datalogger was not created in a real time and there were not temperature and humidity data in the file except for several data tag.

          • http://www.osbss.com/ OSBSS

            To set the RTC, check out this blog post.

          • Lambert

            Thank you, I’ve already got it right.

          • Michael Waring

            I am also now having trouble getting logged readings to show up. My SD card has files with the proper file names and variable headings, but there are no readings. Also, my green LED does not ever light up. I’m trying to trouble shoot the circuit by searching for conductivity issues, etc. Based on the behavior I described, can you tell me where on the circuit to focus my hunting-for-problems efforts? Thanks!

          • http://www.osbss.com/ OSBSS

            Make sure you set the correct launch variables in code for it to start logging. The datalogger always creates an empty file first, with the file name and variable headings you set. If you can see them, that means the microSD card works fine. The logger then waits for the exact launch date and time to start logging. Until the date and time are matched, it won’t log anything. Remember to set the day of the month and the hour (in 24-hr clock) and min for logging. For example, set the following:

            int dayStart = 9, hourStart = 16, minStart = 30;

            To make the device start logging on 9th of the month at 4:30 PM. If you did set this properly and it still didn’t launch, then the RTC time may be reset for some reason. You will have to set it again and ensure that the RTC is maintaining time properly.

            As for the LED, it is a polarized component, so ensure the orientation is exact. The flat edge of the LED contains the ground lead, while the round edge contains the positive lead, as shown below.

            http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/%2B-_of_LED_2.svg/220px-%2B-_of_LED_2.svg.png

            If you have this reversed, it won’t work and you have to clip the LED off and replace with another one in the correct orientation.

          • Michael Waring

            Thanks for all the prompt help. I’m trying to figure out it it’s the RTC. I can upload the RTC code fine. However, when I upload the code, and press the serial monitor, it displays the time starting from the time I put in the upload code (rather than giving me the real time so I can confirm it). If I close the serial monitor and later open it again, it starts at the starting time in the code all over again. Shouldn’t the serial monitor display the real time held by the RTC if all is working properly?

          • http://www.osbss.com/ OSBSS

            Whenever you close and open serial monitor again, it sends a command to reset the Arduino. This implicitly means that the code that is already uploaded on it will run again. If you uploaded the RTC code and open the serial monitor, the “RTC.setDateTime()” command runs again and sets time to the RTC again. To get around this, you only need to set the time once, open serial monitor once to confirm the real time, and without unplugging the Arduino, upload the datalogger code, so the RTC maintains the time and you won’t have to set it again.

            If you only want to check the real time on the RTC, comment out the RTC.setDateTime() line in the RTC code and upload – you should see the current date and time, rather than the one you first set.

          • Michael Waring

            Hey, I’m still having a problem getting this library recognized, though it seems others are not having this problem anymore. The error message I get is:

            TRH.ino:12:19: fatal error: SdFat.h: No such file or directory
            compilation terminated.
            Error compiling.

            Does the version of Arduino software matter (I’m using 1.6.2)?

            thanks.

          • http://www.osbss.com/ OSBSS

            The Arduino version shouldn’t matter as long as it’s 1.0 or higher. When you download the library from Github, it is saved as “Sdfat-master” which contains several files and folders. Copy the folder called “Sdfat” from the zip file (which also contains many more folders) and place this in your libraries folder then restart Arduino IDE.

        • Lambert

          I met the same problem you talked about here. It has been resolved by the updated code.

    • http://www.osbss.com/ OSBSS

      It is not necessary to cut the trace for the green LED on official Arduino Pro Mini. We recommend cutting it to avoid any potential data loss, since we have more than one SPI device connected to it, but for this T/RH build, it should work fine either way.

      The red LED however always stays on, and we recommend cutting this for low power. In one long term test, one of T/RH dataloggers had the red LED on (green LED was disconnected) and it lasted for around 100 days or a little over 3 months. Current consumption of an LED is rather high; disconnecting it by cutting the trace yields significant power savings of several months.

  • Tom

    I’m having trouble compiling the code. I keep getting the following error message:

    bintocsv.cpp: In function ‘int main(int, char**)’:
    bintocsv.cpp:20:31: error: ‘fopen’ was not declared in this scope
    source = fopen(argv[1], “rb”);

    Please let me know what can be done to remedy this issue. Thanks!

    • http://www.osbss.com/ OSBSS

      Are you using the latest SdFat library? Also, check if the Arduino version is 1.0 and higher.

  • Michael Waring

    Thanks for all the help! I’m having problems with the RTC now. I’m trying to upload the RTC code, and I get this message:

    RTC_code.ino:4:20: fatal error: DS3234.h: No such file or directory
    compilation terminated.
    Error compiling.

    The library is in my ‘libraries’ folder, and works fine with the main code upload.

    • http://www.osbss.com/ OSBSS

      Please refer to our blog post about configuring the RTC’s date and time – at this moment, you’ll need the DS3234 library which is only used to sync time and is different than the library used in the main code.

      The sync time function will be merged into the main library eventually.

  • Lambert

    Could you give a detailed and quick way to measure the current draw of the entire project? I was trying to connect a 0.3 ohm resistor in series with RAW pin, and used an oscilloscope to measure voltage across the resistor. At last, the result was not reasonable. Do you have any suggestion?

    • http://www.osbss.com/ OSBSS

      The oscilloscope method will give a current profile. It requires a lot of tweaking to get it right. A quicker method is to use a multimeter in series between the power supply and the RAW pin, and you’ll get real-time current draw of the logger. Connect the + end of the power supply to the positive probe of the multimeter, and the negative probe of the multimeter into the RAW pin. Then connect – end of power supply to GND pin and set the multimeter to read milliamps.

  • Daniel

    We’ve run into a problem with the SD card write function or module. We created four TRH sensor modules and hooked up battery packs for each one. We set them up to run and although they appear to work fine after a little while (between 12 to 260 minutes) each of them starts to fail to write to the SD card and the LED blinks three times. If we take out the card and reinsert them, they seem to work again for a little while (LED blinks only once). It’s strange that this happens to all of them at different intervals even though they have the same components and code. Have you run into this issue?

    • http://www.osbss.com/ OSBSS

      It sounds like a loose connection, bad microSD card or a battery issue. Please verify that the battery is fully charged/brand new. We’ve only seen this issue with a circuit built on a breadboard. Loose connections are more prevelant then, and soldering the entire circuit on a solderable protoboard almost always solves the issue. If all circuits are soldered, use a multimeter set to continuity mode and check for circuit completion or shorts. It’s possible that some of the traces got disconnected due to heat while soldering, and the microSD card works for a while by drawing power through its other pins. Finally, using a fake microSD card may give these issues, although it’s very unlikely. Do a deep format to clear all bad sectors of the microSD card and try logging data again. Touching the device or moving it around is also unlikely to make it fail, although ESD from some people can cause it to stop working.

      Alternatively, you can send the devices to us so we can take a look.

      • Daniel

        Hmm… I’ve checked the cards and they’re ok. The issue occurs even when using USB power. So I don’t think that it is the battery. Could there be a loose connection? Sure. But for all 4 boards, having the same error (built by 4 different people)? Have you considered increasing some of the delay times or SPI communication conflicts with multi devices? I’m going to try to increase some of the delays from 1 to 10 in the code and see if that helps at all. Otherwise we may need to send you these boards.

        • http://www.osbss.com/ OSBSS

          The delay times were started off as 100 ms, going down to 50, then 10 and finally 1. Even 1 ms is a lot, a couple of microseconds is all you really need. You can still try to increase the delay and see if that helps. We have around 5 of these T/RH dataloggers logging data on battery power since a few months now; there shouldn’t any SPI conflicts if you use the exact same code, libraries and hardware setup as given in the tutorial. Did you disconnect the green LED on the Pro Mini?

          • Daniel

            After increasing the delays from 1 to 10 in the code we still ran into the same problem. I believe that we are using the same libraries and hardware. We didn’t disconnect the green LED on the Pro Mini since we thought that was only related to saving power. I’ll try cutting the traces and see if that solves the problem. Have you run any of the Pro Mini’s without cutting the traces and had long term success?

          • http://www.osbss.com/ OSBSS

            No, long-term tests were only successful with the green LED disconnected in all dataloggers. Let us know if disconnecting the LED solves the problem..

          • Daniel

            I cut the traces for the green LED on the Pro Mini, put in new batteries for all the packs, reloaded the original code and within 10 minutes two of the boards are already having the same 3 blink write error for the SD card. I didn’t cut the trace for the red LED on the Pro Mini, is that also required?

          • http://www.osbss.com/ OSBSS

            Red LED is connected to VCC, so it’s always turned on. Has nothing to do with data, just battery power. Can you take a close up pic of the board from the top and bottom? Maybe take a few from other angles as well and email it to us at info @ osbss.com.

          • Daniel

            I’ll try to take pictures of them tomorrow and email them to you. In the meantime, I’m wondering if there have been changes to the required libraries that may result in differences between your compiled code and the one we are running. For example we are using the SDfat library (by William Greiman) as instructed but I noticed in the readme file that this has undergone major revisions recently. Have you recompiled and loaded the code and tested long term stability using the most recent SDfat library (dated March 21, 2015)? Might that be a possible source for the problem? The readme says “This is a major rewrite of core FAT code so bugs and compatibility problems are likely.” Maybe you can email me the libraries that you are using for this project and then I’d know that we have all the same code and hardware. I’ve read that in the past Greiman stated that “You don’t want to power the card off and on. You then need to reinitialize the card and SD.h wrapper for SdFat has a bug that prevents multiple calls to begin().” So you know if this was fixed recently?

          • http://www.osbss.com/ OSBSS

            If you read the discussions below, the new FAT core implementation is already taken care of in our latest code on GitHub. The code doesn’t compile with the older version of the library. What Greiman was talking about “in the past” was referring to the “SD.h” wrapper for his library, which is the official SD library written by Arduino. However, we’re using Sdfatlib, the actual library written by Greiman (not the modified wrapper written by Arduino), so we don’t need to worry about that problem you’re referring to. If you use SD.h instead, the data logger will fail after the first data point and begin() doesn’t work from the second point onwards. Using the original Sdfatlib, you can call the begin() function as many times as you want, and power-cycling the microSD card doesn’t affect it.

            Since your logger works for a while and then stops, the problem is something else. Either the voltage across the microSD card’s pins isn’t 3.3V due to some reason, or there are some wires touctouching eacher (insulation might have melted while soldering).

          • Daniel

            Alright.. I’ll check the wiring again tomorrow and take photos of the boards and try emailing them to you. Quick question though. Has anyone else besides your group at IIT been able to get these boards working with long term stability? The strange thing is that the other sensor modules, CO2 and PM that we have built seem to work fine writing to the card over many hours and days. That’s what really puzzles me.

          • Hugo Silva

            Hi Daniel. I have precisely the same problem. Has you solved it?

            I have a circuit composed by a SHT15 and a HTU21D sensors. If I Just run the HTU21D, the system works fine. But if I run the 2 sensors or just the SHT15, the system works fine by some readings, but then the LED begin to blink 3 times and the data are no longer registered.

            Do you have some solution?

          • http://www.osbss.com/ OSBSS

            The problem is with the latest version of SdFat library. It introduced new core FAT implementation which is apparently buggy. Try using the previous version – it should work fine.

          • Mark

            Do you know if this issue exists in the SdFat link under the parts list at the top of this tutorial? I’m having a similar issue, new Sandisk SD card and rebuilt logger with extra care taken in soldering. I’ll get the SD card error from the LED after a few minutes of working normally and a bunch of junk files written with non-ASCII filenames and no readable data.

          • http://www.osbss.com/ OSBSS

            The SdFat link that’s in the tutorial is the one that works properly with these loggers in this exact setup. Newer versions of the library don’t encourage power-cycling an SD card, since they’re favoring stability at the expense of slightly higher sleep currents.

  • Ryan

    Is it possible to build this with a 5V Arduino Pro Mini rather than the 3.3V? I already have a 5V, and I was hoping to avoid buying another.

    • http://www.osbss.com/ OSBSS

      Unfortunately, no, not directly anyway. The microSD card requires 3.3V logic levels. It’s not tolerant of 5V, and using it may lead to memory corruption. Other components will be alright, so if you do want to use a 5V Pro Mini, you’ll have to use a bidirectional logic level shifter for the microSD card’s SPI bus and VCC pins to bring the voltage down to 3.3V. Alternatively, you can use a microSD card holder which incorporates an onboard a voltage regulator.
      Better to just get a 3.3V Pro Mini. You can save some money by using cheaper $3 clones from eBay.

  • Dwacito

    Would this work with the DS3231 RTC instead of the 3234? I’m asking because they’re a lot cheaper :) Thanks for the great guide!

    • http://www.osbss.com/ OSBSS

      Yes, it should work, but you’ll have to use a custom I2C library for the 3231. DS3231 and DS3234 are essentially the same RTCs; the differences between the two are:
      1. DS3231 uses the I2C (or TWI) protocol for communication, while the DS3234 uses the much faster SPI bidirectional interface.
      2. DS3234 has 256 bytes of battery backed SRAM which can be used to save time/alarm and other data even when VCC is off.
      3. The 32kHz output on the DS3234 is designed to drive low when turned off. The DS3231 is switched to a high impedance state when switched off, so interrupts are handled differently.

      You may have to refer to guides such as this one to set everything up properly so the alarms work with the DS3231.

      • Dwacito

        Thanks again for the very detailed answer. I plan on (actually am) using the watchog timer of the Pro Mini to wake up rather than the RTC so it should make no difference for my project (apart from different wiring to the RTC / different library). Thanks again!

        • http://www.osbss.com/ OSBSS

          No problem. The only two reasons we use the RTC to wake up is because the internal oscillator of the ATmega328P is not very accurate, so you’ll have significant time drifts in your data over a period of time. Using the external RTC gives precise time with minimal drifts. We care a lot about accurate timing, since we’re using these data loggers for research applications.. Also, you can disable WDT and conserve even more battery life in your device.

          Oh, and I’m curious – the bootloader in the original Pro Mini from SparkFun had something wrong with the WDT, it wasn’t working properly, you couldn’t enable or disable it completely, requiring you to manually burn Arduino Uno bootloader instead (this was revision 13 of the Pro Mini, 2014). Not sure if they fixed it now in the newer ones.

          • Dwacito

            It is true that using WDT does not give the most consistent log intervals. For my appllcation, logging at very precise time intervals is not so important, we are logging at 5min intervals but if it’s eg 4m57 or 5m03 it’s no problem as long as the actual time is logged from the RTC.
            I got the Pro Mini clones off Ebay about 1 year ago and didn’t have any trouble with the WDT – I used the awesome guide by Nick Gammon http://www.gammon.com.au/forum/?id=11497 to enter / leave sleep mode. The pro mini itself draws about 10-11 uA while sleeping so I’m very happy with that.

  • Rodolfo Jimenez

    I have a problem with the cirtuit, the RTC DS3234 is not functioning but when i disconnect the MISO connection of the SD card RTC works normally. What would be the problem with the circuit?

    • http://www.osbss.com/ OSBSS

      Verify all connections again. Check if the MISO of the SD card is connected to the MISO of the RTC. Also, check if there are any shorts between the SD card pins.

      • Rodolfo Jimenez

        i have check all the connections SD and RTC has common connection with its MISO,MOSI and SCK.

        • http://www.osbss.com/ OSBSS

          Are you using the same exact hardware setup and the same code published here?

          • Rodolfo Jimenez

            Yes except sd break out board i am using MicroSD Card Adapter made by CATALEX

          • http://www.osbss.com/ OSBSS

            The earlier versions of the CATALEX microsd card adapters work well when used alone on the SPI bus and not when shared with other devices because they don’t release the MISO pin when chip select is HIGH. That’s why it was working when you disconnect MISO. The newer versions of that adapter seems to work fine. Discussion about this is here.

          • Rodolfo Jimenez

            Thank you.How can i check if the RTC is working? can you give me sample sketch to check if the alarm is working.

          • http://www.osbss.com/ OSBSS

            Check our blog post about configuring the RTC’s date and time. If you use our DS3234lib library, and the same hardware setup and code given in this tutorial, the alarms should work fine.

  • Rodolfo Jimenez

    How can i separate file.printing the Date and Time?

    • http://www.osbss.com/ OSBSS

      The DS3234 library separates all parts of date and time into variables that can be called when required. Form your date and time by printing each one and use a comma between them to put them in separate columns like so:

      file.print(RTC.month);
      file.print(“/”);
      file.print(RTC.day);
      file.print(“/”);
      file.print(RTC.year);
      file.print(“,”);
      file.print(RTC.hour);
      file.print(“:”);
      file.print(RTC.minute);
      file.print(“:”);
      file.println(RTC.second);

      Replace the comma with a space to put them back in one line. Alternatively, you can put all of the above in a string and print it once.The RTC.timestamp() function does this automatically.

      • Rodolfo Jimenez

        thank you..

  • Rodolfo Jimenez

    how can i use the GUI?

    • http://www.osbss.com/ OSBSS

      Follow the tutorial to properly setup and launch the datalogger.

      • Rodolfo Jimenez

        where can i see the tutorial. thank you

        • http://www.osbss.com/ OSBSS

          On this page.

  • Rodolfo Jimenez

    Can you send us the link where can i get the GUI code for this.

  • Mark

    This is awesome, I’ve got all the parts but haven’t assembled it yet. I also looked inside a $100 logger and it uses the nearly identical SHT20 sensor. Does anyone have a PCB layout for this project? I’m planning to use 10 or so loggers to gather field data and building a couple of these would probably save me close to $1000!

    • http://www.osbss.com/ OSBSS

      Mark, glad you’re interested in these loggers. A PCB layout will be coming soon, stay tuned! Do let us know how your field test goes.

  • Mark

    “while the other end of the resistor goes to ground ”
    Is that a typo? LED instead of resistor.

    • http://www.osbss.com/ OSBSS

      Yeah, that was a typo – good catch. Tutorial now updated. Thanks!

  • Mark

    This may be a basic question but hopefully can help others out too. I’m using a SHT21 which has pins labeled VIN, GND, SCL, and SDA. Aside from GND, how do they correspond with VCC, DATA, and SCK of the SHT15? Thank you!

    • http://www.osbss.com/ OSBSS

      Data transmission to and from the SHT15 is done via a digital 2-wire serial interface. This isn’t the same bus as the common I²C (TWI) by NXP. For Arduino boards, this means that communication is done via any two digital pins on the board which are defined in the code to be DATA and SCK. The specific sequences of commands, bits set and registers updated for communication are listed in the datasheet of the sensor.

      The SHT21 on the other hand communicates via standard I²C protocol, which requires the use of A4 and A5 pins specifically on most Arduino boards. These are SDA and SCL pins respectively and cannot be changed.

      The two sensors communicate via different protocols and cannot be interchanged with each other. The SHT15 however, can also be used on the A4 and A5 pins, as all analog pins on the ATmega328 can also double as digital GPIOs (with the exception of A6 and A7 on the Pro Mini, which are strictly analog-only by default). However, other I²C devices on the same bus must be disabled while the SHT15 is being used on these specific pins, as it does not share the same protocol with them.

      • Mark

        Interesting, thanks for the explanation of why. Looks like the SHT7X uses the same protocol as SHT15, but with only a difference in accuracy of 0.2%, it seems easier to just stick with a SHT15.

  • Rodolfo Jimenez

    why there are some sd card not working? i am using 2gb micro sd but some brand with same capacity and format are not working?

    • http://www.osbss.com/ OSBSS

      Already mentioned in the tutorial – there are reliability issues with some brands. Check this post for details.

  • Mark

    Almost done with my build (finally)! Why is the thermistor needed if the sensor already measures temperature?

    • Mark

      Wait, I just read the “follow-up post” by Prof. Stephens and I think it answers my question :).

      • http://www.osbss.com/ OSBSS

        Oh, great! Do share your built test results with us!

    • http://www.osbss.com/ OSBSS

      The SHT15 is primarily a relative humidity sensor. The temperature sensor built-in is designed for temperature compensation of relative humidity, since the latter depends a lot on temperature. The goal of this tutorial was to achieve similar or higher accuracy than the commercial Onset’s HOBO T/RH datalogger. The temperature sensor in the SHT15 has an accuracy of ±0.3°C, while the US sensors thermistor has an accuracy of ±0.05°C, making it a better choice.

  • Joren Meesters

    Hi,I have a problem when I compile the code. I get this error every time

    TRH.ino:12:19: fatal error: SdFat.h: No such file or directory
    compilation terminated.
    I’m pretty sure I installed the SdFat library. Do you know what the problem cn

    • http://www.osbss.com/ OSBSS

      Download the SdFat library linked in this tutorial above. Replace it with the one you have and it should work fine

      • Joren Meesters

        I replaced the old folder with a new folder. Now I’m getting this error:

        no matching function for call to ‘SdFat::init(const uint8_t&, int&)’C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:229:8: note: candidate expects 1 argument, 2 provided ^ bool init(uint8_t part);C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:229:8: note: bool FatVolume::init(uint8_t)C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:216:8: note: candidate expects 0 arguments, 2 provided ^ bool init() {C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:216:8: note: bool FatVolume::init() from TRH.ino:12: from C:Program Files (x86)ArduinolibrariesSdFat/SdFat.h:27, from C:Program Files (x86)ArduinolibrariesSdFat/utility/FatLib.h:22, from C:Program Files (x86)ArduinolibrariesSdFat/utility/ArduinoFiles.h:28,In file included from C:Program Files (x86)ArduinolibrariesSdFat/utility/FatFile.h:33:0,TRH.ino:120:38: note: candidates are:TRH:120: error: no matching function for call to ‘SdFat::init(const uint8_t&, int&)’TRH.ino: In function ‘void loop()’:C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:229:8: note: candidate expects 1 argument, 2 provided ^ bool init(uint8_t part);C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:229:8: note: bool FatVolume::init(uint8_t)C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:216:8: note: candidate expects 0 arguments, 2 provided ^ bool init() {C:Program Files (x86)ArduinolibrariesSdFat/utility/FatVolume.h:216:8: note: bool FatVolume::init() from TRH.ino:12: from C:Program Files (x86)ArduinolibrariesSdFat/SdFat.h:27, from C:Program Files (x86)ArduinolibrariesSdFat/utility/FatLib.h:22, from C:Program Files (x86)ArduinolibrariesSdFat/utility/ArduinoFiles.h:28,In file included from C:Program Files (x86)ArduinolibrariesSdFat/utility/FatFile.h:33:0,TRH.ino:50:38: note: candidates are:TRH:50: error: no matching function for call to ‘SdFat::init(const uint8_t&, int&)’TRH.ino: In function ‘void setup()’:Arduino: 1.6.5 (Windows 8.1), Board:”Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)”

        I don’t get any error when I replace this code

        if(!sd.init(SPI_FULL_SPEED, SDcsPin))

        with this

        if(!sd.init())
        but I don’t think this is the right way, Do you now what is wrong with my Library or program?

  • Timmmm

    I’m not sure I’d call the SHT15 “accurate”. When I tested it it was in the “easily 10% out” category of low cost humidity sensors. I recommend the SHT75 instead. It’s more expensive, but it will get you within 2% reliably, has a very fast response time, and very little hysteresis.

    • http://www.osbss.com/ OSBSS

      The SHT15 and SHT75 are the same sensor chip; the only difference is that the SHT75 comes on a pin mount form while the SHT15 is SMD. They perform exactly the same, i.e., 2% accuracy, which has been verified many times by us and others. Check this post here. If you’re not getting good readings, you probably have a defective unit which you should replace.

      • Timmmm

        You are correct! I was thinking of a different chip.

  • Joren Meesters

    When I try to measure the temperature and relative humidity I always get this error:

    ACK error 0
    ACK error 2

    I already know that this is related to de SHT15, do you know how to solve this problem?

    • http://www.osbss.com/ OSBSS

      Check if the wiring is correct. If you have another SHT15, plug that in and verify that the same code & wiring runs. ACK errors suggest either it isn’t powered on correctly, or wired correctly, or on a rare occasion, the sensor you got was a dud. SHT15 is known to have bus errors though in certain odd situations, so it’s also likely that it’s just hanging up at times. But that should give an ACK error occasionally, and not always. Try adding a bit more delay after it does a measurement to see if that helps.

  • Rodolfo

    I have a working data logger for my flow meter and i set logging interval to 15 minutes. My problem is the log time, there is difference between every logging. Flow rate is computed by dividing the period(time) it take one complete revolution which is equivalent to 1000 liters. Consequently, period to take 1 complete revolution is variable. What will I do so that the logging time is not affected by variable period? Please help

  • Juan David

    Hi! Nice tutorial! Do you know if I could include a barometric pressure sensor without lost the battery autonomy? Could you please recommend me a good sensor for this porpoise?

  • Barış Yıldız

    Hi. I am a phd student and this project will make it very easy for me to follow the heat and humidity of the laboratory. But at the same time I need to be able to watch this data from a distance (From home or another place) as well. How can I do that? can you help me?