Open Source Data Logger Project Using the Arduino?

everything is cleaned up and its not too embarrassing

I would like to start a campaign on these forums for people to start releasing code when it's still at the "embarassing" stage. The number of times a thread ends with a post saying "I'll release it when it's tidied/not embarrassing/perfect" and no further code seems disturbingly high.

Embrace your code's imperfections in the face of its utility, release now!

In a month's time untidy, embarrassing code is still going to be a lot more useful to others than no code--it also probably won't impact your future employment/dating opportunities too much. :slight_smile:

I agree! I think few of us are real professionals here and we're all here to learn, even a brain dump of imperfect information thrown back into the cloud is better than nothing at all, and we can all benefit from dissecting and optimizing what you've got so far. :slight_smile:

It's great that you brought this up. I'm actually working on using an Arduino to store data off to a USB thumb drive. I'm logging from one USB port and saving to the thumb drive. Just need to get the closing of files working correctly.

I'm a co-op student working for a company right now and am highly interested in working on this project. I do have some questions about the actual operation of the data logger though.

  1. How good is the resolution? I know it's 10 bit, but what is the max value for the analog input? Our main need here is thermocouples and 1 mV can be 20 degrees difference or more.
  2. How could we get more inputs? I know you can get more boards or more A/D converters and then put them on the digital ins, I was just wondering if there was an easier way to do this?

My main goal is to get as many thermocouple inputs as possible. Any code I write, no matter how "dirty" would be posted back.

Sorry if most of the questions have been answered elsewhere, I'm just now getting into the arduino board community. Most of my experience is with Linux based microcontrollers.

Thanks.
Ryan
Tenn. Tech U.

Hi Ryan, by default the arduino uses 5 volts for the ADC reference. As I recall from the datasheet, you can use an internal reference of 1.1 volt giving about 1mv resolution. The guaranteed accuracy is plus/minus 2 bits.

There are six analog inputs and you can add an external multiplexer if you need more.

Has anybody taken on this project? I have a few ideas for a modular system. I think better resualts could be gained by using standalone ADC chips, combined with a modular system, you could just plug in the modules you need!

hey Ryan,

Maxim has a couple of thermocouple interfaces (MAX6674 MAX6675) that would attach to the Arduino via SPI. Since SPI is a bus, requiring a separate chip select for each device, you could easily put a dozen or so on an Arduino as-is. With an IO expander IC you could add even more.

I've got these on my list to play with, but haven't had time yet.

-j

(TTU class of '90)

Has anybody taken on this project? I have a few ideas for a modular system. I think better resualts could be gained by using standalone ADC chips, combined with a modular system, you could just plug in the modules you need!

I'd be interested in making one if it was a competition or something.
I just dont have any need for a data logger myself though.

kg4wsv I2C would be a better candidate.
Up to 128 sensors with only two wires.

kg4wsv I2C would be a better candidate.
Up to 128 sensors with only two wires.

SPI has two distinct advantages: SPI is much much faster that I2C (25MHz vs 400kHz, IIRC), and, in this case, the thermocouple interface ICs are only available in SPI. :slight_smile:

On the number of nodes on the bus issue, I have noticed many ICs that have fixed addresses, or allow only a few bits of the address to be set by the designer, so practically this limit is usually much lower than 127. For example, the DS1631 that was discussed on the forum recently has 3 pins (3 bits = 8 possible addresses) available.

-j

SPI can hit 25mhz theoretically but the Arduino doesnt go that fast anyway.

Apparantly you can get I2C hubs which allow more.

I have been looking for I2C thermocouple ICs and I just can't seem to find one. Like K said, only SPI. Since the MAX chips are more expensive than an analog mux, I think I'm going to use one MAX6675 and then just mux all my inputs through it. It's easy and dirty but should work. I have a few other ideas I'm still messing around with before I start ordering samples.

This method also leaves open my analog inputs since we may need to take voltage/current readings at some point.

By the way, speed is not a priority for me since most of our measurements are 2 hours apart, but I will try to make it as fast as possible.

Hi everyone,

I am a biologist from a wildlife research group in Australia. I have next-to-no experience with electronics, but I am wondering whether a novice like me could learn to build a simple GPS datalogger based on Arduino boards (preferably the Arduino Mini) for use in wildlife tracking? I would appreciate comments from the community here as to whether this is something a newbie like me could attempt, and whether anyone might be willing to assist? Obviously any progress made will be posted here for others to use. Look forward to comments.

Thanks

Yes a newbie could do it.

All you need is the processor (Mini), a GPS module and some form of memory (I2C EEPROM is easiest).
Whack them together and you have a basic datalogger.

If you want to monitor birds or small animals, I'd leave it to the experts though.
It wouldnt be the smallest datalogger in existence. :wink:

Hi everyone,

I am a biologist from a wildlife research group in Australia. I have next-to-no experience with electronics, but I am wondering whether a novice like me could learn to build a simple GPS datalogger based on Arduino boards (preferably the Arduino Mini) for use in wildlife tracking? I would appreciate comments from the community here as to whether this is something a newbie like me could attempt, and whether anyone might be willing to assist? Obviously any progress made will be posted here for others to use. Look forward to comments.

Thanks

I think that kind of depends on what you're a novice at, but it's not outside the realm of possibility at all. Start small. Get an Arduino and start playing with it. Then find a suitable GPS receiver and start playing with that. Figure out how to get the position and other data out of it that you want and send it back to the computer over serial. Then find a way to log your data to some kind of storage device (probably the hardest thing to do right now, from what I've seen) and tie it all together. I think if you break it down into smaller pieces, you'll be ok. I'd recommend you find a good tutorial on C and C++ if you're not already conversant in it, however.

The easy part is connecting the GPS, there is some information on connecting a GPS in the [u]Arduino playground[/u] , this one is a good place to start: Arduino Playground - GPS

The challenge will packaging the complete system to be small and robust with a suitable power source, a practical means to get the data out, and an antenna layout that has sufficient visibility to GPS satellite data when attached to wildlife.

You may want to start a new thread where you can say a little more about your requirements and encourage contributions on various solutions. I would definitely think its worthwhile pursuing further.

Hi Cheater, blalor and mem,

thanks for the tips and encouragement. I guess it's a case of diving in and giving it a go. A separate post might be a great idea if there is enough interest.

We've been trialling the latest GPS dataloggers from Sparkfun, and as much as they're great little units, the "sleep" mode has a 1.5mA draw, that really takes its toll on battery life. Getting the sleep draw down to the lowest possible level is a major goal of a new logger. A recent post on the Arduino playground discusses sleep draw: (Arduino Playground - ArduinoSleepCode).

From what we can tell, a major portion of active draw in the SF logger seems to be related to NMEA sentences being written to the SD card. Fast(er) fix acquisition and a less intensive approach to writing/storing fix information is another goal.

As you guys have pointed out, size is also a limitation. We can probably work with a final board measuring ~50mm x 50mm and ~30mm high (although the smaller the better). The Sparkfun board measures 38.1mm x 44.5mm x22.9mm), which is close to ideal. Patch antennas are a bit of drama to work with and ultimately we'd like to mount the GPS logger complete with antenna and battery on the underside of collars. At the moment, either the antenna or both the logger and the antenna have to be top mounted, which makes fitting in teh field a drama.

Thanks very much for the replies guys, and I look forward to more discussion.

GPS units, by default, write out a set of sentences once a second, but this default can be changed. Perhaps the Sparkfun unit would be less power hungry if you reduced the number of NMEA sentences to the minimum that you need, then reduce the rate at which the devices transmits sentences?

Having said that, I would assume the GPS receiver itself is probably the biggest power hog in the system. The Garmin GPS18 is 50 to 65mA (depending on which model you choose).

-j

I would think everything but a timer would be powered down between readings if battery drain is a critical factor. Perhaps WHEB could say at what frequency he would like to log readings.

Hi kg4wsv,

Thanks for the reply. According to the manufacturer's specs (USGlobalsat Inc.) power consumption of the GPS engine board (model EM-406a SiRF III) used in the Sparkfun GPS logger is 44mA. However, Sparkfun list it as 70mA (?). Sparkfun list the total power consumption on the GPS datalogger as 160mA, so I figured that the bulk of the difference was due to logger itself (I could be way off however).

You raise a really interesting idea with the notion of limiting the sentence output. We've discussed the idea here but our utter lack of electronics/programming knowledge meant it was a bit of a pipe dream. Many of the sentences are of little use to us and we really only need date, time, lat/long and HDOP values (possibly satellite number as well to help determine fix quality). Almost all of our projects require reasonably long deployment periods (from two weeks to many months), so fix logging intervals are usually set to between five minutes and one hour, with the unit being in sleep mode the rest of the time. Intermittent operation obviously boosts battery life/deployment (although we're finding some interesting results in terms of the benefits of longer intervals - - i.e. there doesn't seem to be many), but do you think reducing sentence output would have much of a positive impact? Would certainly make things easier when transferring data over at the end of deployment, regardless.

I am wondering how difficult it would be to interface the same GPS engine board above with an Arduino board to play around with sentence output etc? I realise this is all a bit ambitious for a newbie, but I am happy to jump in and try, particularly if there are other people interested.

Cheers

Hi Mem,

I probably covered fix rates a bit in my last post, but to clarify, we're definitely keen on hourly (or less) fixes. Our static tests are revealing some intriguing battery life projections for five minute fixes, which seem to be the best of both worlds in terms of accuracy (very good average DOP values & Sat #) and operational time (~8secs - 10secs to get a fix with a hold-off value of five). We've run the logger for 7 days at a five minute fix rate using two Duracell DL123 batteries in series (~1550mA capacity) and voltage only dropped from 6.4v to 5.89v. The SF GPS logger tolerates voltages between 4v and 7v, so we were very pleased with these preliminary results, as we might get a couple of weeks of deployment at least out of this set-up. Sleep draw of the SF logger really seems to be the major limiting factor (1.5mA) in deployment projections.

Cheers

WHEB,

Does the thing you're measuring ever stop moving??? If so, you can wire things up to power down with no movement. Your last GPS reading would be the location that the thing stopped. If there is constant motion, then this wouldnt help. I just did something similar and it seems to be working great so far.