Tag Archive for coding

Build Your Own Data Logger – The Software, Telling the Logger to Log

790px-Kaffeetasse_Milchkaffee_Cafe-au-Lait_CoffeeOkay, with the arduino, shield, wiring and sensor complete, we’ve got our stuff together and can get our logger to log. To do that, we need to tell the arduino what it has to do. This is done with the arduino coding language. Now, what’s that and why do we need it?

As we have seen in the last part, an arduino itself is not very intelligent. To every ordinary person you can say “Would you be so kind and fetch me a cup of coffee?” and he or she will be able to execute that task without further ado, given he or she knows where the kitchen is and all necessary tools are available. If you want the same thing from a machine, you have to speak its language (or have a translator, which is called a “compiler”) and you have to think about the task you give it in a way as if that thing doesn’t know anything about this world. Which is, in fact, true for any machine. So, to stay in the example, to code a machine you have to say:

When hearing the command “Would you be so kind and fetch me a cup of coffee?” do the following:

1. Go to the kitchen
2. If the door is locked, open it to go into the kitchen
3. Go to cupboard
4. Open door of cupboard
5. Take out 1 cup
6. Close door of cupboard
7. Put cup under the coffee machine
8. Press first button
9. Wait until fluid has filled cup
10. Take cup in an upright position
11. Bring cup to person who spoke command

Silly, isn’t it? You would go mad with an assistant asking for such precise commands. That’s why some people find it hard to code – it’s very complicated to think so basic. But, anyway, we want our logger to log, so let’s take a look at the necessary code step by step (the complete code can be copied from our Quick Start Guide):

The part that is introduced by /* and ended by */ is a comment, something that is written for humans to read, not for the arduino to understand. Think of it like spelling out certain words so the kids don’t understand. Well, we never can be sure with kids and spelling, but we can be quite sure with /* */ and arduino.

You use this comments to make sure that another human being is able to understand what you wanted to achieve with a section of code. Chances are that human being is you because after some time you won’t remember why you coded some things that way. Comments are a part of good documentation, something we collections folk like, right?

Next up we have a couple of so called “libraries” we include in our code.

We have seen what an arduino mind needs to fetch you some coffee. Well, someone has already defined all the steps beginning with “1. Go to the kitchen…” in a library, so if you want your specific arduino assistant to be able to fetch coffee for you, you just have to write “#include <coffee.h>” at the beginning of your code and whenever you write “Would you be so kind and fetch me a cup of coffee?”, your assistant will be able to do all the necessary steps to bring you a nice, hot cup of coffee. It will also include what to do if the coffee machine is turned off, the water tank is empty, there is no coffee…

Now, I have to admit that I don’t understand all those libraries that are included here, of some I only know as much as that I do need them, and I know that I need them because I saw that they were used in some example codes. I think of it like when we need a conservator – of course we have to know which specific conservator we need, but we don’t have to fully understand what she or he does. Although, of course, the better we understand what she or he does, the more effectively we can cooperate.

For our logger we have included some libraries so it:

  • understands some functions you might need from the programming language C (stdlib.h)
  • knows how to handle time, that is, knowing that there are seconds, minutes, hours, days… (Time.h)
  • knows how to read the Real Time Clock on the logger board (DS1307RTC.h)
  • knows how to communicate with I2Cs (Wire.h)
  • understands what our sensor tells it (DHT.h)
  • knows how to communicate with peripheral devices like the SD card reader (SPI.h)
  • knows how to read from and write to a SD card (SD.h).

Next up we have to define where our sensor is and what type of sensor we use. The DHT library we included is able to handle DHT11, DHT21 and DHT22, so we have to specify that we connected a DHT22 and we connected it to our pin 9. The notations behind the “//” are again comments to be read by humans, not the arduino:

Next our sensor gets a name so we can order it to do something.

To keep things simple, we called it just “dht” in small letters, but we also could have called it “Walter”, “Gretchen” or “sensor1”. It’s only important that it is named consistently and that we are careful in using upper and lower case. For an arduino “Gretchen” is something other than “gretchen”, so the program won’t run if you make a mistake here.

The next line makes sure that we can communicate with the SD-Card although we used a logger shield. In the library, pin 4 is defined for a certain action, but this is already taken by the shield, so the arduino should use pin 10 instead.

So far, we have just made sure that our arduino knows what it needs to know. Next up we enter the “setup”. Think of it as your new assistant walking through the door. Before you can order her/him to do anything for you, you have to show her/him around. Where is the toilet? Where is the kitchen? Where is the coffee machine… This all will happen in the curly brackets after “void setup”.

Actually, the very first thing we do is we tell our imaginary assistant how s/he should communicate with us. Our arduino will be able to tell us what it does when it is connected to a computer using a thing called “serial communication”. It will be able to send information via the USB cable which we can read in the Serial Monitor of our arduino software. The line Serial.begin(9600) is like telling our assistant that s/he should communicate with us in English.

Next up, we tell our arduino that it should use pin 7 and 8 as output. This is where our two LEDs are connected, but our arduino only knows this if we tell it so. There are two possibilities for a pin: it can be an output or an input. If we define it as an output we can send signals to it that will do something with the thing that is connected to said pin. In our case, if we send that pin a “HIGH” signal it will switch the LED on, if we send it a “LOW” signal, it will turn it off.
If we define a pin as an input our arduino will “listen” to what happens on said pin instead. If the arduino receives a signal there, it can do something according to that signal. But in this case, we only need an output for our LEDs.

Next up, we do a couple of checks to see if our SD card works properly. It prints “Initializing SD card…” to the serial monitor so we can see it.
There is again a pin, pin 10, we define as an output, because our SD-Card-Reader needs this (we know this from the example code).

Now, the arduino checks if it can read the SD-Card. If it can’t read it, it sends a message to the serial monitor saying “Card failed, or not present”.
But “in the field” we won’t have an USB cable connected to a computer, only the logger itself. So we use our red LED on pin 7 to send us the same message. If the arduino doesn’t find the SD card reader or the SD card, it switches the red LED on for 5 seconds. In the arduino language this time span is given in milliseconds. So you see that we send the LED a “HIGH” signal, then wait (delay) for 5000 milliseconds until we send it a “LOW” signal to turn it off.
This is a mission for the Q-Tip: If the red light indicates that the SD card is missing or not properly inserted, you can put your SD card in the slot and press the q-tip, which reaches to the reset button inside the case to restart your arduino and try again.

If the arduino can read the SD-Card it will send the message “card initialized.” to the serial monitor. Next it sends “DHTxx test!”. Again, we have no idea if it can read the SD card, so if this is the case, we switch the green LED on pin 8 on for 5 seconds.

With the simple statement “dht.begin();” we tell our sensor that it should start reading.

Now our setup is finished, we can now tell our assistant what s/he shall do all day long. We do this in a function that is called “loop”. This function will repeat itself forever, if we don’t code anything that make it stop (or the plug is pulled).

What we want to do repeatedly is to read how high the humidty and the temperature in our room is, right? To read from our sensor, we call “dht.readHumidity” for the humidity and “dht.readTemperature” for the temperature.
If we want to use these values repeatedly in our code we use a thing called “variables”. A variable is something like a bag. We can store a value in it and carry it around. In our case we call our variables “h” for humidity and “t” for temperature. Bags come in all sorts and sizes, so do variables. You would choose your small, black handbag for a dinner invitation and your rucksack for your day trip so you always got the bag that fits your storage needs. Our sensor readings will come in a form like 14.5 or 34.8, they come as floating point numbers. So we choose the variable type “float” for it. There are a lot of other variable types, but for now, we just learn that “float” is the right type for our sensor values.
To sum up, the following lines of code store our sensor readings in the variables “h” and “t”. Whenever we call those variables in the fllowing parts of the code, they will repeat the sensor values.

But what will happen when the sensor returns something that isn’t a valid value for humidity or temperature? The next part of our code checks exactly this and reacts accordingly.

If either the value for humidity which we stored in “h” or temperature which we stored in “t” is not a number, the arduino will inform us by writing “Failed to read from DHT sensor!” on the serial monitor. The expression for something not being a valid number is called “isnan” (for IS Not A Number. Instead of writing “or” between the conditions, we have to use wording the arduino understands, which are the two upright strokes || (there are a few of these, like “and” which is &&, “greater than” which is > or “smaller than” which is < ).

Again, with a free standing logger we won’t see a message on our computer, so we let our red LED blink frantically if the sensor values are nonsense. There might be more elegant ways to code this, but I’m just a collections manager, not an IT professional.

Next up we print our values to the serial monitor for check, in case we have a computer connected. Right now you should be able to understand what happens:

Now, we need the time that comes from our Real Time Clock. Note that to use the Real Time Clock properly, you have to set it to the correct time first, using the example provided with the RTC library. Basically here we say “look at the clock and remember anything you saw in a variable called “tm”). We will be able to call the specific day, month, hour, minute, second… that way later in the code.

What follows next is perhaps a little weird to explain and to look at. We want to store our data on the SD card later, in a form that each data point is separated by a comma. That way, we can use any old spreadsheet software, import the data in a form that is called “comma separated values” (CSV) and process it further. The thing is, our data are numbers. You remember how we defined our sensor readings to be floats? Yep.

What we need to process it further is charcaters, in other words, we need a string. To be more exact, we need a string that incorporates all the data we want to be stored when we read our sensor. We want to have something that looks like this:
“34.8, 14.5, 2017, 04, 14, 2, 45, 23,” that we can have in our spreadsheet software to process a reading of 34.8 % relative humidity, 14.5 degrees Celsius on the 14th of April 2017 at 2:45 p.m (and 23 seconds).

To achieve this, we first open up an new bag called “dataString” to store our values in. I must admit I don’t get what line 116 really does, but it has something to do with defining the size that is available for our values.

What happens next is that we put all our values that we want to store into our “bag” called “dataString”. We do this one by one, as if we open up our bag, put the tape measure in, put the gloves in, put the lipstick in… The tricky thing is that whatever we take, we first need to convert something that is a number into a string. Hmmm… perhaps like if you want to put a fluid into your bag. You first have to put it into a container. Well, perhaps not exactly so, but along these lines.

So, we put our humidity value into a container. We call this container “stringH”. The function “dtostrf” does this with our variable h, which is, as we know a float number of our relative humidity reading. Then we put our container “stringH” into our bag “dataString”:

We said we wanted to have comma separated values in the end, so what we do have to do now is to add a comma. We take our “dataString” bag and put a comma in, useing “+=” as the order to do so. Here we go:

The same goes with our temperature reading:

What does our bag now contain? Something that looks like that: “34.8, 14.5, “. You can make sure by ordering your code to let you know on the serial monitor by adding this line:

We didn’t do that here. Instead we are putting in our bag one by one the values for the day, month, year, hour, minute and second of the reading, each separated by a comma. Note: I later discovered that I wouldn’t have had to separate them all with a comma, but we will discuss this later in the series. For now, we just know it works.

Whew, that’s a lot of code. Our “bag” dataString now looks like that: “34.8, 14.5, 2017, 04, 14, 2, 45, 23,”. Next up, we want to write it to our SD card. To do that, we have to open the file the string should be written to:

If the arduino finds the file called “Mylogger.csv” on the card, it openes it, writes the content of dataString to it (at the end of all other data that is already stored there) and closes the file again. Mission accomplished!

What’s great about this is that if there is no file called “Mylogger.csv” on the SD card, the arduino will automatically create it. Only in the occasions where there is such a file, but it can’t be opened or if the SD card is missing, we will need an error coding which informs us on the serial monitor and lights up the red LED until the next loop:

Finally, we have to define how long the arduino should wait between measurements. The more often you read, the more data you get, which is a plus in detail, but also needs more storage space. In our example, we wait 5 minutes between readings, which are 300000 milliseconds. For 10 minutes, set it to 600000 milliseconds and so forth.

That’s it, that’s the whole code. There is, of course, room for improvements, for example if you need the temperature in Fahrenheit or want to calculate the dew point. But this will be another part of the series…

Read the other posts for this project:

Facebooktwittergoogle_plusredditpinterestlinkedintumblrmail