If you're capturing a few events over a short period of time it's easiest to capture in the emulator and manipulate the data directly or in something like Excel.  Even then I find it annoying to convert the elapsed time in the log record to chronological time. 

So why didn't I just maintain chrono time?  Simple:  overhead.  I figured large data sets would be processed on a PC using Excel, script, or some other custom program.  That's what this log is about:  if you're logging a lot of data over a long period of time, say several days, then something better is needed.

I've included a C program (PVLOG) I wrote to log charge / discharge data from my pilot PV system over a week or more.  It's a good example of how you can automate data collection from logger.  I'll describe the setup, operation, and considerations.

Setup.  PVLOG is written in ANSI C and should compile & run without without modification on most U/L*ux distributions including OS X (there are pragmas to set controlling include file locations & data structures).  It has not been tested on Windows.  It can run interactively and process a file containing the binary mode output of logger or it can attach to a character device and log data real-time.

I have a laptop setup running FreeBSD that I use for a bunch of stuff.  It has Bluetooth on it and is in range of the PV setup so that was used to run PVLOG.  Logger was paired with the BSD host and then setup as a character (terminal) device:  >rfcomm_sppd -a 99:99:99:99:99:99 -t.  You might have to change permissions on the device so PVLOG doesn't have to run with elevated permissions.

The Call Up (CU) utility is used to start an interactive session with logger to configure the channels:

• CH2=current from charge controller (to battery)
• CH4=current from battery (to load)
• CH5=battery voltage

All three channels are set to poll on ten second intervals.  Set the output to binary and make sure LVS < Vdd.

That's all the setup that's required.  The epoch will be set when PVLOG is run.

Operation.  To start PVLOG for real-time capture:  >pvlog (device-path) log (output-file path & prefix).  The device-path is the full path to the character device, 'log' is the command, and output-file is where the data should be written.  PVLOG will create three files.  A log file to record termination events, a raw (r) file containing the raw data with the ADC values converted to amps/volts, and a process (p) file containing more advanced calculations and averaging.

When PVLOG starts it connects to the logger thru the character device and expects two-way communication.  It uses the ID command to confirm logger is there and ensures it is in command mode.  It then sets the epoch and issues the start logging (SL) command.

PVLOG will continue running until terminated by the user or when it encounters a communication or data error.  The termination cause will be written to  the log file.  If left to run for several days it will create new process & raw files for each day, starting at 00:00.

The program writes two log files.  The raw file contains each channel record with only the ADC value converted to amps or volts.  The process file includes power calculations and averages over two time intervals:  A=1 minute and expects six samples / minute (e.g. every 10s) and B=15 minutes.  This is done for trending and to get rid of some noise.

Considerations.  PVLOG is a good demonstration of how logging can be automated and it serves as a good template for other data logging tasks.  I thought about writing a generic engine that would also program the channel setup but I haven't had the need.

This said, if you want to create your own logging programs beware.

• Character devices block.  They also don't let you check for an unread byte in the stream very easily (unless you use OS-specific hooks).  This is why PVLOG goes thru some seemingly strange contortions to communicate with logger - it's about establishing context and starting from a 'known' location.
• Continuing the previous bullet, PVLOG will appear to hang or write 0 records if the config isn't just right.  This could be improved.  Things to check are LVS & binary mode settings.
• Use the ADC 1V value in the analog record to convert ADC values.  The ADC's positive reference is Vdd so this will change.  This value is updated by the control loop on every pass.