Hi Charlie,
I'ts probably more accurate to say that 'my' code is exposing about half a dozen forum poster's souls - there's not too much in there that I've written myself but rather cobbled together from this wonderfully supportive community! 
The original rundown of my project was as follows:
- A remote, solar-powered, automated camera system to take photos of key wetlands at specified times each day
- Using a Canon Powershot A720 consumer camera, with modified firmware (see CHDK Wiki | Fandom for more info - I'm sure there are people here who would be interested in what the CHDK community has achieved)
- Thermistor to monitor enclosure temperature, and operate fans when required
- DS1307 mini-board (DS1307 Real Time Clock Mini Board) for RTC
- Arduino to control fans, camera power & solenoid to turn camera on at specific times
- Camera should happily run unattended for around 3 months
So, basically the sketch as originally conceived was designed to:- monitor the time from the RTC, and the temperature from the thermistor. - check the temperature against the previous second's readings; if it is higher than the MaxTemp, make this reading the new MaxTemp; if it is lower than the MinTemp, make it the new MinTemp.
- at midnight, record the date & daily MaxTemp to EEPROM & reset MaxTemp to 0; around midnight, record the daily MinTemp & reset to 40.
- if the temperature is over 35 degrees C, start the fans; if the temp has dropped below 33 degrees 1 minute later, switch the fans off, otherwise leave them running & keep checking each minute.
- check to see if the time matches any of the pre-determined times to take a photo.
- If it's time for a photo: (1) record whether the fans are on or off, and switch them off if they are on; (2) send power to the camera; (3); trigger the solenoid for 100mS, which pushes the camera's power button; (4) leave power on to the camera for 15 seconds so the camera can take a photo then power itself off; (5) return fans to their previous status.
However, on implementing a prototype system, we have found that the enclosure & heat-shield we've employed makes the temperature control functionality redundant - the interior temperature is the same as the external temp, so the fans don't actually provide any cooling effect. I'll now use them to just blow air over the camera aperature a few times a day, in order to remove dust and/or insects.
We thought that it would be helpful to record daily maximum & minimum temperatures, so I set up a sketch which would record the date (dd/mm/yy) & max & min temps in 5-byte chunks once each day in EEPROM. The data dump procedure was initially set up to read the EEPROM & display it in a table-like output like this:
Data dump initiated:
Date MaxTemp MinTemp
1/1/2009 20 12
2/1/2009 21 9
3/1/2009 29 12
4/1/2009 30 11
5/1/2009 25 13
6/1/2009 29 16
7/1/2009 23 14
8/1/2009 21 10
9/1/2009 23 10
10/1/2009 24 12
11/1/2009 22 13
12/1/2009 28 17
13/1/2009 43 18
which I could cut & paste to Excel or a simple text file. However, with uFat I'm thinking that a data dump procedure may be a bit redundant, if I can simply pull out the SD card, plug it into my laptop & copy the file. One thing that I do need to keep in mind in this project is that it won't always necessarily be ME who services these cameras, so I need to keep their operation as user-friendly as possible...
Anyway, the idea with writing data to the SD card is that I may as well use the huge amount of capacity available & write data to it every minute. At this stage, I'm looking at recording data in the following manner:
Date, Time, Temp, VV.vv (Battery voltage), VV.vv (Solar Panel voltage)
where Date = DD/MM/YY (3 bytes)
Time = HH:MM (2 bytes)
Temp = degrees C (1 byte)
VV.vv = voltages to 2 decimal places - (2 bytes each)
So, I'm left with 10 bytes of actual data going onto the SD card. However, in keeping with the spirit of simplicity mentioned above, I'm thinking that ideally the data written to the SD card would be in comma seperated value (.csv) format; that way we can easily import it into a spreadsheet for viewing & manipulation. This would add another 10 bytes or so for /'s, commas, decimal points etc.
My concern here is that 10 or 20 bytes obviously don't divide too well into 512; what happens when the buffer is full? Do I lose some data there? I'm not up to speed on exactly how sectors work, so forgive me if this is a stupid question... Could I make sector_buffer a 520-byte array (for example), write 512 bytes to SD card sector 0, then put bytes 513-520 back into the first 8 bytes of the array, to be written to sector 1 when the array is full again? Will a computer see this as one continuous file?
I think I'll leave it there for now - hopefully this answers most of your questions, and since this post is getting a bit(!) lengthy now I'll let you digest this lot & ask any more questions as required.
Cheers
JB