The GP3 board is perfect for data logging, but you need to write your own data logging software, right? WRONG!
There are several options for using the GP3 as a data logger. For simple applications using just analog, consider GP3DAQ which can do polynomial curve fitting of raw counts, plots, and writes data to a file. But if you just want data written to a file you'll find that GP3EZ makes it simple to create a custom data logger.
As an example, I hooked up an LM34 temperature sensor to the GP3. You really should have a shielded cable and a little RC filter like they show in the datasheet, but for this demo I just plugged the sensor right in. If you haven't used an LM34 before, it looks like a little plastic transistor. You put 5V on one side and ground on the other. The middle pin produces 10mV for every degree (Fahrenheit) that the sensor experiences.
If you filter and shield it, you should be able to get better than the "worst case" plus or minus 2 degree error the manufacturer quotes for the device, but for this example I'm willing to accept a little slop in the measurement. That's good too because the native resolution of the A/D is 5/1024 or about 5mV. So even 2 stray counts on the A/D is going to give me a degree error either way.
If you were building this for real you could amplify the signal so you used more of the A/D or use a reference voltage to knock the A/D range down (although, unfortunately, GP3EZ doesn't let you get at that capability of the board). But for a lot of purposes +/- a degree or two isn't a serious problem.
The key to writing a data logger with GP3EZ is understanding the execute action. This is a special action that can do several things, but for our purpose we are interested in writing the step information to a new file, or adding it to an old file.
That means I can make a simple logger in about 3 GP3EZ steps. The first step will "wait" for the A/D input to be >= 0V. Guess what? Its always >=0V so the step will always fire. Just to smooth out some of the sensor's noise, I set the script to average 16 samples instead of just reading one sample, but that doesn't really matter -- it just makes the data "smoother" since it filters out high frequency noise.
If the step always runs, why not just set the condition to always? Because setting the A/D condition means the voltage read will become the step's "value" and that value is part of what will be written to the file by the external action. On this first step, the action can be to write to a new file. You can name the file anything you like. However, be aware that any file with that name will get overwritten.
The second step is almost exactly the same. The only difference is action will be to add to the same file, not create a new one. The first line of data and the second one will be spaced close in time, but if that's a problem you can insert a new step to delay after the first sample is logged. I didn't bother.
The third step is the simplest. Just wait for as much time as you want between samples and go back to step 2. Don't go back to step 1 or you will overwrite the log file each time!
Here's the HTML export of the entire script:
Simple data logging script.
|1||Start||(wait) Analog 0>=0 V ( 16 samples)||
External New File: /tmp/testlog.txt||Open the new file|
|2||Log Temperature||(wait) Analog 0>=0 V ( 16 samples)||
External Add File: /tmp/testlog.txt||Create an entry in the log|
|3||After 1000 ms||Start||Wait and start again|
The log file output has the date and time, the voltage value, the name of the step that made the entry, and the current state (which we aren't using in this example).
It is simple to customize the logger. For example, if you changed the condition, you could only log voltages over or under a certain threshold. Changing the time between samples is trivial. You could add more A/D channels easily too. You could log extra channels to a different file, or mix them all together and use the step name in the file to sort them out later. You could even put other conditions on the logging steps. For example, you might only log if a certain digital input is low.
Of course, it is also easy to take action on certain values. In a future article, I show you a variation of this script that turns on a fan when the temperature gets too high and then turns the fan back off again when the temperature is under control.
Site contents © 1997-2014 by AWC, 310 Ivy Glen, League City, TX 77573 (281) 334-4341