On 03/01/2013 12:26 PM, Tom Van Baak wrote:
Ok, it´s a relative measurement... now I understand your data. Thank you.
Not sure it's relative measurement. Probably best to call it a time error
measurement, or a phase measurement (in the timekeeping sense, not the 2*pi
sense). Just consider a 60 Hz wall clock; the data is how far wall clock time
differs from true time, measured every zero-crossing. So subtracting successive
data points gives you period (e.g., 0.0166667).
This brings up a very interesting question.
Many of us continuously log data from counters and such. Although cpu speed and
disk capacity are high and costs low, it is still worth considering the format
of data we collect -- especially if it's data collected over months or years.
For example, if I measure 60 Hz zero-crossings for an hour with 100 ns
resolution, what is the most compact way to format the data? That's 216,000
samples per hour; 5.184 million per day. Consider these methods:
1) ctime-like time-stamp of zero-crossing
Fri Feb 22 23:38:00.2279906 2013
Fri Feb 22 23:38:00.2279906 2013
Fri Feb 22 23:38:00.2446570 2013
Fri Feb 22 23:38:00.2613322 2013
Fri Feb 22 23:38:00.2779954 2013
2) fractional unix time_t of zero-crossing
1361605080.2279906
1361605080.2446570
1361605080.2613322
1361605080.2779954
1361605080.2946650
3) ISO 8601-style (see xkcd.com/1179)
2013-02-22 23:38:00.2279906
2013-02-22 23:38:00.2446570
2013-02-22 23:38:00.2613322
2013-02-22 23:38:00.2779954
2013-02-22 23:38:00.2946650
4) Modified Julian Day (bad idea)
56345.9847248610
56345.9847250539
56345.9847252469
56345.9847254398
56345.9847256327
5) UTC time, one file per day (date in filename)
23:38:00.2279906
23:38:00.2446570
23:38:00.2613322
23:38:00.2779954
23:38:00.2946650
6) STOD (seconds time of day), one file per day
85080.2279906
85080.2446570
85080.2613322
85080.2779954
85080.2946650
7) per-cycle period measurement, date/time implied
0.0166664
0.0166752
0.0166632
0.0166696
8) per-cycle frequency measurement (bad idea)
60.00096002
59.96929572
60.01248260
59.98944186
9) period minus some nominal value (0.0166666)
-0.0000002
0.0000086
-0.0000034
0.0000030
10) period - nominal (0.0166666) and scaled to integer 100 ns units
-2
86
-34
30
11) successive difference of period in 100 ns units
166664
88
-120
64
-24
12) time/phase difference between DUT and REF
0.0000003
-0.0000083
-0.0000048
-0.0000077
Most of us with TIC's (time interval counters) use data like #12 because it's
natural, convenient, each datum stands on its own. This time series format can
be fed directly into time/frequency/stability calculations.
The most compact for 60 Hz appears to be #10 or #11, even if awkward to use
(but a program can easily convert among any of these formats).
Aside from cheap tricks like using binary instead of ascii or using file
compression utilities (e.g., g/zip, etc.), does anyone have additional ideas on
a compact streaming decimal data format?
The COMTRADE format is interesting in many ways, but one of the key
details is that is has a line counter (but can store LOTS of data on
each line), which helps to identify if lines are missing or not. The
COMTRADE format has a column for time, but it is redundant as start-time
and sample rate is completely known, so keeping that column to 0 flags
that it should be calculated from the giving info.
COMTRADE files is being shared plentiful and can become very large, but
it is important to identify broken data so it can be discarded.
I have only seen a presentation on it, but it seemed interesting and
good enough for many other uses than the intended use.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
