In order to minimise supply current in battery logging applications I suggest an LED state config word (on/off). This could be included in the CONFIG.TXT file. The Blue LED takes a fair bit of current...
Good point. Not a bad idea and reasonably easy to add. My worry is that one of the LEDs is controlled via SPI/SD library (not really controllable) and the other LED is flipped on/off with each loop of the receive buffer check,
I worry that by adding a variable check
if(statLEDOn) STAT1_PORT ^= (1<<STAT1); //Toggle the STAT1 LED each time we record the buffer
to this line we will add a few cycles to an already sensitive loop.
We're also pretty thin on remaining code space. This feature will make the problem worse. I've been thinking about the need for a baud rate parser instead of fixed rates or a menu system. Perhaps we can free up some codewords by removing the baud rate menu system and just have the user input '4800' or whatever baud they need. I'll start the ticket.
Hmmm - looking at the schematic (12/6/2009 issue) there are 1k resistors to two LEDs (both labelled as Green). If correct it would only save a mA or so. From measurement I reckon it's more like 10mA for the Blue LED so I'm guessing the current OpenLog hardware has a much lower value series resistor for the Blue LED. It's quite difficult to establish the mean current being drawn - I'm using a current probe + oscilloscope. I also found that the current profile (waveform) meant that I needed to use ferrite suppression on the supply to prevent EMI appearing on what was being logged [RF receivers] :-)
I'm doing some current measurements with an OpenLog with a blue LED. When in command mode, LED off, unit pulls 4.79mA. With LED on, unit pulls 5.42mA. I'm going to mark this as a doesn't need fixing unless you discover something else, please let me know.