I’m thinking of taking this datalogger on a camping trip, and am wondering what the bettery life is like. Do a set of double-AA batteries last the couple weeks it takes to fill up the SD card?
Thanks,
Dave
Hi,
You may need a few packs of batteries. Have tested several runs with two or three Lassen IQ FAT16 Dataloggers in parallel, each fitted with the miniature active patch HFL antenna and a 4-cell series pack of AA alcaline cells. Such a pack will keep one logger/antenna running for 5-10 hours depending on the battery quality. When the battery voltage is running low, the logger will stop saving results to the SD card (status LED stops blinking) several hours before the power LED goes out. Have not tested if it is the Lassen IQ module or the logger CPU that gives up first.
Had some worries initially that the SD card file system could be corrupted when the batteries were running out, but it looks like you can just connect a fresh battery pack and switch on power again (as long as the status LED starts blinking within a few seconds). The standard GGA message will only log the time (not the date), and the logger file system does not set the date/time for the files according to the real date. You may find it difficult afterwards to sort out which file was logged on which day. You should probably mount the Lassen IQ module first on some other card, connect to the IQ-chat or IQ-monitor software on a PC, and enable the RMC or ZDA message to have the actual dates included in your log. Have not tried this yet, as I preferred to log for a few hours only, transfer my data to a PC, and then reformat the SD cards to make sure I started with a clean slate.
Best regards, Terje
Hi Terje,
Thanks for your reply. It’s a pity the battery life is so short. I wonder if it would be possible to change the code so that instead of logging your location every second, it only did it once every five or ten minutes. If you could turn everything off in-between samples that’d save a bunch of power (though this would probably require a PCB change as well as changing the code). And one doesn’t move all that fast when hiking, so that’d really be plenty of data points!
Regards,
Dave
Hi again Dave,
Rather a few things could probably be done in a firmware upgrade from SFE. Like selecting other NMEA messages, setting file datetime, selecting sampling rate, commanding the GPS module into and out of some low power mode, perhaps bringing the logger CPU into and out of some low power mode. All such things could be set up through the configuration file, even if we may not (yet) get direct access to communicate with the GPS module from a PC or another external unit. I would personally also hope for a possibility to inject a DGPS correction data stream.
In short - the traditional evaluation board and breakout board concepts make a lot of sense, and so does the data logger idea - a miniature combination of all of the above could possibly become very popular! Would like it with 100 mil pin rows (as a DIL plug-in module) and possibly USB connectors rather than big clunky DB9 connectors. Serial lines can also be connected via RJ45 or RJ11 sockets… And please include in your arsenal the new FTDI TTL-232R USB to TTL cables with all the electronics integrated into the USB connector (don’t know if it is compatible with 3.3V logic levels). You might even arrange pins for 1-3 such connectors in the above 100mil pin rows, so we can opt to mount the unit in a robot motherboard or just plug in the standard FTDI cables and connect to the nearest PC… And a good driver that converts USB ports into COM1-COM8 could come in handy. Some people may want to migrate from VB to C#express? If this handles USB directly, a short tutorial might spark some interest? Apologies if I’m rambling about things that are already available…
Would appreciate comments from SFE.
Best regards
Terje
Hi Terje,
Well, some of what you’re asking for could might be possible now. If I understand correctly, this could be used to update the code on the datalogger:
http://www.sparkfun.com/commerce/produc … cts_id=714
For my particular application I could modify the firmware available here:
http://www.sparkfun.com/commerce/categories.php
I’ve haven’t ever coded for an ARM before, but the code doesn’t look to bad, so I’m pretty sure I can figure it out. For the particular application of a low-power datalogger Both the ARM and especially the GPS Receiver would have to be switched into a low power mode. From the datasheets I think this is possible with the ARM, but I’m not so sure if it’s possible to shut down the GPS via software. Does anyone have any thoughts on this?
Thanks,
Dave
Interesting!
I haven’t yet seen the possibilities to upload new firmware to the FAT16 datalogger. Is any hardware mod needed to connect? Would generally wait for official updates from SFE, though. There are others on this forum also asking for additional entries in the configuration file. These should be standardized by SFE in an official update, I hope.
Best regards
Terje
Hi Terge,
On the front page they say about this item:
“We’ve also released a little LPC programmer interface board. Use this little board to re-program the GPS Datalogger or use it with your own LPC ARM design and save some serious PCB space.”
http://www.sparkfun.com/commerce/produc … cts_id=714
So you definitely can use it to upload new firmware to the datalogger.
Regards,
Dave
I’ve been lokking at a few options for reducing the power consumption of the logger, it currently sits at 105mA, which seems extremely high. The GPS takes 27mA, the micro and LED’s shouldn’t take much at all, the rest must be the SD card…
Hi Caffeine, that’s interesting, please keep us informed of your progress. It seems strange that the SD card would take so much power; I was assuming that the main power draw was the GPS.
Perhaps the easiest solution would be a small daughterboard with a little PIC which would only enable power to the GPS datalogger every X minutes. The datalogger code could be changed to only get one sample, then the PIC would shut off the power again. As I understand it all the satellite information would be retained via the battery power, so it shouldn’t take the GPS long to reacquire its position each time it is turned on.[/img]
djr7710:
Hi Caffeine, that’s interesting, please keep us informed of your progress. It seems strange that the SD card would take so much power; I was assuming that the main power draw was the GPS.Perhaps the easiest solution would be a small daughterboard with a little PIC which would only enable power to the GPS datalogger every X minutes. The datalogger code could be changed to only get one sample, then the PIC would shut off the power again. As I understand it all the satellite information would be retained via the battery power, so it shouldn’t take the GPS long to reacquire its position each time it is turned on.[/img]
hot or warm start, should take 2 to 15 seconds, depending on how long it’s been powered off.
Reading up on the SD card spec, it seems they take 50 to 100mA when running! Only 8 to 15mA in standby mode though.
It should probably be put in standby mode bwteen writes, as a second is an awefully long period, that would reduce the average consumption.
Has anyone had a chance to play with the firmware to try to reduce the power consumption between samples?
Caffeine:
hot or warm start, should take 2 to 15 seconds, depending on how long it’s been powered off.Reading up on the SD card spec, it seems they take 50 to 100mA when running! Only 8 to 15mA in standby mode though.
It should probably be put in standby mode bwteen writes, as a second is an awefully long period, that would reduce the average consumption.
Hi,
You want to look at the specs of your SD card - some SD cards (e.g. SanDisk) will automatically go into sleep mode after 5msec of no activity, and draw 250 uA. There’s a mention in the SanDisk docs about stopping the clock source: so perhaps power down the SPI block in the LPC. Manufacturers vary: I don’t know what the RiData card supplied by SparkFun does to help power consumption, but I’d suspect they all implement something helpful to one degree or another.
Also, application level buffering will help: the current data logger FAT code is expensive for small writes: it reads a sector, updates it, and writes it back. That can be reduced by writing to FAT in sector sizes. In addition, the current code is very bad for directory updates: fat flush causes some code to walk the directory sectors looking for the directory entry, then to update it: the battery life will be proportionally worse for every 32 files you have on the card!
I’ve written new GPS data logger code (based somewhat on the original code) and implemented a lot of these, including FAT and directory caching (that LPC has plenty of SRAM, why not use it) to reduce hits on the SD card. In addition, I SRAM cache the gps data up to 8K then power up SPI and write to the SD card, then power down SPI - the SD card should take care of itself.
Better power control would also help: the current GPS data logger doesn’t power down unused LPC peripheral blocks (e.g. USB, RTC, etc). In addition, by using RX interrupts on the incoming GPS data, you could sleep the processor in between the nmea strings, then wakeup to process them. The debug port shouldn’t be powered up. Also, the current firmware build is in debug mode without optimisations: I can now build release with O3. Hopefully this speeds up processing before the processor goes to sleep waiting for the next gps update.
The cumulative effect of these changes should improve battery life.
Are you going to release the code? I’m definitely looking for power savings so I can take this thing a long hikes away from the grid, and not have to carry lots of batteries with me
I’ll be releasing the source code, but at the moment it’s still work-in-progress, and I’m about to go away for a two week trip (taking the logger with me). Probably in 3-4 weeks it should be finished and properly tested.
Hello,
Is there any unofficial firmware released yet?
Rgeards,
Srauf