Open Source Data Logger Project Using the Arduino?

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.

If you're talking about report intervals to something on the order of tens of minutes to hours with the GPS asleep between events, reducing GPS sentences won't help enough to be noticeable. When I mentioned it, I was thinking of a continuous (e.g. a report on the order of once a minute).

I would check out the GPS start time. Especially with 5 minute intervals, you may be running the GPS a majority of the time, as 5 minutes to first fix from a cold start is not unreasonable to expect.

I like the 123As for physical size, but the Energizer AA lithiums actually have more capacity, if you can stand the four AA form factor to get 6V (compared to the two 123As).

-j

I am a biologist from a wildlife research group in Australia.

There are a number of Australians that hang out here, you might want to be more specific about where you're based--you might be living next door to one. (Although I don't think Aussie Arduino users are required to be registered yet... :smiley: )

On the subject of battery life, you might want to look at:

http://www.faludi.com/projects/arduino-and-xbee-battery-test-results/

Keep in mind that if your processing needs are low you have the option of using lower-power and/or frequency parts.

--Phil.

WHEB,
I gave it some more thought and if your project can withstand an hour or even a half hour between gps pings, then powering down might not be a bad option, even if there is constant motion. Also, you might want to check out batterys like http://www.megabatteries.com/item_details2.asp?id=14282&cat_id=404&uid=1638. You can regulate the voltage and get a lot more mAh out of them. Food for thought.

Hi everyone,

I have to say this is a great forum and thanks for all the responses. I've found little interest in some other non-Arduino forums. I'll try to reply to each point separately.

fornsix
We're tracking dingoes and wild dogs, which are always on the move just about. I guess it would depend on how sensitive the movement "switch" was in terms of extending battery life. For example, if it switches on with head movements, it might never get a rest. If it can be tailored to trigger upon a certain degree of movement, it may well result in some savings. Thoughts?

kg4wsv
I should have qualified my earlier point that the SF logger actually already allows NMEA sentences to be partially restricted to pretty much only those sentences that you want. As far as we can tell, it's not possible to only store parts of sentences though (i.e. it's either a whole sentence or nothing). There are also some issues with the way the data is stored when it comes to importing into something like a spreadsheet app., but this is more of a pain then a major problem. It would be great if we could chop and change individual sentences to get exactly what we want without a lot of messing around, but it is probably easier to do this at the end of a given deployment using existing GPS applications rather than trying to program the board to do it in the field. You're right that the Energizer AAs have more capacity than the 123s, but weight is a bit of an issue for some of our projects. The case we're using in an upcoming project is too small to fit AAs, or even three/four AAAs, but the stocky nature of the 123s, coupled with the fact that we only need two, means we can "cheat" a little and embed the batteries on the side of the case using epoxy and still keep the weight down. The case has to be top-mounted to the collar because the SF loggers have an integrated antenna. Even if they didn't though, I actually like the top-mount, because trying to fit/adjust collars in the field and dealing with a length of coax (or something similar) leading to an antenna is a nightmare. To stop the collar from spinning around, we mount a collar drop-off device and a few other components near the bottom side, which all adds to a little more weight than the GPS case.

We might still end up using AAs for medium term deployments however.

follower
We are based in Brisbane so it would be great if there were a few Arduino aficionados nearby who might be interested in helping. Thanks heaps for those battery life test results as well. Like the SF GPS datalogger I imagine getting the most out of sleep modes could have a lot of impact in terms of battery life.

fornsix
Thanks for the link. We've looked at using similar batteries for long-term deployments, and we still hope to, but there have been some issues relating to the max. current rating of these large capacity D- and C-cells. We were hoping (read pushing our luck) that a single cell would cut it, but the voltage drop/draw when the GPS was operational ended that idea. Using two cells in series seems to work, but we're yet to do proper bench tests to ensure they're going to last in the field. We're just using a diode to drop the voltage of the pack, which seems to work ok.

Cheers everyone, much appreciated.

We are based in Brisbane so it would be great if there were a few Arduino aficionados nearby who might be interested in helping.

Hi
I am your local Arduino expert. :wink:
AFAIK I'm the only one in Brisbane.

You can use a single cell and boost it to 5v fairly easily.
Maxim has a chip which does this which I'm currently using in a project.
It gives a stable 3.3v or 5v from as little as 0.8v.