- Mon Aug 21, 2006 6:07 pm
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.