121GW SD card logging bug

[greyltc]

Please could someone let me know if there's a better place to file a firmware bug report for the 121GW multimeter.

I'm on firmware v2.05.
When I set logging interval to "0" (maximum ADC speed, apparently ~200ms interval) and record some data, the resulting CSV file doesn't have unique timestamps for each of the samples collected/rows in the resulting CSV log file. This is probably because the timestamps only have 1s resolution. So a bunch of the data points have duplicated timestamps, of course that's horrible if you want to try to plot or analyze this data later. Is firmware v2.05 source code available so that I could attempt to fix this issue myself?

For example:

Code: [Select]

START,2005/04/22,12:40:38,
ID,170800000,
INTERVAL,000,sec,
,,,MAIN,,,SUB-1,,,SUB-2,,,Remark,
No. ,Date      ,Time    ,Func. ,Value,Unit,Func. ,Value,Unit,Func. ,Value,Unit,
1,2005/04/22,12:40:39,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
2,2005/04/22,12:40:39,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
3,2005/04/22,12:40:39,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
4,2005/04/22,12:40:39,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
5,2005/04/22,12:40:39,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
6,2005/04/22,12:40:39,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
7,2005/04/22,12:40:40,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
8,2005/04/22,12:40:40,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
9,2005/04/22,12:40:40,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
10,2005/04/22,12:40:40,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
11,2005/04/22,12:40:40,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
12,2005/04/22,12:40:41,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
13,2005/04/22,12:40:41,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
14,2005/04/22,12:40:41,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
15,2005/04/22,12:40:41,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,
16,2005/04/22,12:40:41,DCVA,00000.0,mVA,DCV,00.0000,V,DCA,0000.00,mA,,

[Kean]

Dave has stated that the firmware is not open source.

It should not be hard to post process the collected CSV file to add increments of 0.2 seconds to get unique timestamps.

[Whales]

That's annoying.

Some thoughts on a workaround for right now:
* Assume the interval between readings is constant
* Run captures for as long as possible
* Take the first timestamp and the last timestamp, then linearly interpolate all inbetween timestamp values.
* Compare this will the actual timestamps to validate the assumption in my first bullet point (difference should always be less than 1 second).

[BILLPOD]

I'm curious if the micro SD card is the one that came in the meter, or if it isn't, was it the recommended size and formatted properly.   I have used my 121GW to record several times and didn't notice any discrepancy in the results, (using the SD card that came with it).   Forgive me for not giving any concrete advice, but hopefully my experience may be helpful. I'll be watching this thread closely.   Thanks for listening

[joeqsmith]

It's been several years since I looked at one and don't remember the 121GW having a real time clock.   Looking at CSV files I had saved, none of them have a time stamp. 

Are you using one of their applications to collect the data over the wireless interface, or are you recording to the SD card then reading the card with a PC or something?  I can believe with the cell phone or PC applications, they would support a time stamp.  They used to have that source code available.

[J-R]

Of course the 121GW has an RTC, powered by a CR1220 battery.  If your clock freezes when the DMM is off, you'll need to replace the battery.  A CR1216 also fits fine, and in a pinch you can force a CR1225 in there, although not recommended.

Seconds simply aren't logged to the SD card.  It has nothing to do with the type or formatting of the micro SD card.  There isn't a way around this at the moment unless someone wants to reverse engineer the firmware or write their own.  UEi owns whatever secret sauce is in the firmware and because they also use it for other DMMs, they aren't going to release it.

The best option is to use one of the available apps via Bluetooth.  If you insist on using the SD card, set the logging for 1 second instead.

Whales' interpolation suggestion seems like a good idea as well.  All of my logs have five entries per second, so that should be easy enough to deal with.

[sleemanj]

Dave has stated that the firmware is not open source.

It should not be hard to post process the collected CSV file to add increments of 0.2 seconds to get unique timestamps.

Excepting that the first group of timestamps in that example export (12:40:39) has 6 entries.

So can't rely on the records being 0.2 seconds apart.

[J-R]

Dave has stated that the firmware is not open source.

It should not be hard to post process the collected CSV file to add increments of 0.2 seconds to get unique timestamps.

Excepting that the first group of timestamps in that example export (12:40:39) has 6 entries.

So can't rely on the records being 0.2 seconds apart.

I think that is only going to happen at the beginning or end of the logging.  I tested it multiple times with my 121GW and always observed groupings of five.

[sleemanj]

Well if we assume that the first reading will be at 000 milliseconds and that each reading within a group is an equally divided number of milliseconds after the first, here is Gemini produced PERL to convert the file to add milliseconds

Code Only: https://g.co/gemini/share/3d0d02e8e99e

Conversation: https://g.co/gemini/share/760cb775b5cf

Tested, works.

Code: [Select]

#!/usr/bin/perl

use strict;
use warnings;
use POSIX qw(round); # Required for the round() function

# Array to store all input lines in their original order.
my @lines;
# Hash to store line indices grouped by their timestamp.
# Key: timestamp (e.g., "12:40:39")
# Value: an array reference containing the original line indices.
my %timestamp_groups;
# Counter for the current line index as we read input.
my $line_index = 0;

# First pass: Read all input lines and group them by timestamp.
while (my $line = <STDIN>) {
    chomp $line; # Remove trailing newline character.
    push @lines, $line; # Store the line.

    # Check if the line is a data row containing a timestamp.
    # A data row starts with a number, followed by a date, then a time.
    # The regex captures the time part (HH:MM:SS) from the third comma-separated field.
    if ($line =~ /^\d+,\d{4}\/\d{2}\/\d{2},(\d{2}:\d{2}:\d{2}),/) {
        my $timestamp = $1; # Extract the timestamp.
        # Add the current line's index to the array associated with this timestamp.
        push @{$timestamp_groups{$timestamp}}, $line_index;
    }
    $line_index++; # Increment line index for the next line.
}

# Second pass: Process each timestamp group and modify the lines.
foreach my $timestamp (keys %timestamp_groups) {
    # Get the array of line indices for the current timestamp.
    my @indices = @{$timestamp_groups{$timestamp}};
    my $group_size = scalar @indices; # Get the number of lines in this group.

    # Calculate the millisecond increment 'f'.
    # 1000 milliseconds divided by the number of rows in the group, rounded to the nearest integer.
    my $millisecond_increment = round(1000 / $group_size);

    # Iterate through each line within the current timestamp group.
    for (my $i = 0; $i < $group_size; $i++) {
        my $current_line_index = $indices[$i]; # Get the original index of the line.

        # Calculate the milliseconds for this specific line.
        # It's the current position in the group (0-indexed) multiplied by the increment.
        my $milliseconds = $i * $millisecond_increment;

        # Format the milliseconds to be three digits, padding with leading zeros if necessary.
        my $formatted_milliseconds = sprintf("%03d", $milliseconds);

        # Split the line into parts using comma as a delimiter.
        # The -1 argument to split keeps trailing empty fields, which is important for CSV.
        my @parts = split(/,/, $lines[$current_line_index], -1);

        # Append the formatted milliseconds to the timestamp part (which is at index 2).
        $parts[2] .= ".$formatted_milliseconds";

        # Rejoin the parts back into a single line string.
        $lines[$current_line_index] = join(',', @parts);
    }
}

# Final pass: Print all modified (or unmodified) lines to standard output.
foreach my $line (@lines) {
    print "$line\n";
}


[joeqsmith]

Of course the 121GW has an RTC, powered by a CR1220 battery.  If your clock freezes when the DMM is off, you'll need to replace the battery.  A CR1216 also fits fine, and in a pinch you can force a CR1225 in there, although not recommended.

As I said, it has been several years since I looked at this meter. 

Seconds simply aren't logged to the SD card. 

If you read OP's first post, they show the meter logging seconds but with a 5Hz sample rate,  they needed tenths.   

[J-R]

Clearly I meant to say nothing more than seconds are logged.

[joeqsmith]

Clearly I meant to say nothing more than seconds are logged.

It does log minutes, hours, date which are more than seconds.  It can't log less than seconds. 

[J-R]

Clearly I meant to say nothing more than seconds are logged.

It does log minutes, hours, date which are more than seconds.  It can't log less than seconds.

Good grief, I'm again struggling to see your contribution to this thread.  Why don't you correct your earlier bona fide incorrect statements that the 121GW doesn't have an RTC or timestamps?  (BTW, "more" can mean in addition, or further and the OP provided a sample which puts us all on the same page at the very beginning.)

And why even post when you couldn't be bothered to check your memory against a real 121GW?  If you would have done that we wouldn't even be in this back and forth pedantic discussion.

[joeqsmith]

Clearly I meant to say nothing more than seconds are logged.

It does log minutes, hours, date which are more than seconds.  It can't log less than seconds.

Good grief, I'm again struggling to see your contribution to this thread.  Why don't you correct your earlier bona fide incorrect statements that the 121GW doesn't have an RTC or timestamps?  (BTW, "more" can mean in addition, or further and the OP provided a sample which puts us all on the same page at the very beginning.)

It's been several years since I looked at one and don't remember the 121GW having a real time clock.   Looking at CSV files I had saved, none of them have a time stamp. 

There is nothing to correct.   You felt the need to point it out for some reason but seem upset when treat you in a similar manor.   

And why even post when you couldn't be bothered to check your memory against a real 121GW?  If you would have done that we wouldn't even be in this back and forth pedantic discussion.

As I stated,

Looking at CSV files I had saved, none of them have a time stamp.

   I'm sure you would find something else to whine about.