Hi

The quick and simple version:

Fire up a clock. Off it goes. Does it do decimal seconds or something else?
That’s up to you and is application dependent. Does it roll over at some point or
does it count on to infinity? Again, application dependent.

You likely start it with some starting value. It could be zero, it also could link to
something like UTC. That link (or lack there of) is very application dependent.

In comes a zero crossing.

Grab the time value from the clock. (possibly to nanoseconds, picoseconds or
some other level of resolution / accuracy),

Stuff that value in a file (or maybe display it, though that’s less common).

Step and repeat for each zero crossing.

Why do this?

1. It’s a zero dead time way to look at things. A “delta time between crossings”
   approach might take a while to get ready for the next zero crossing.

2. It takes out potential cumulative errors (compared to delta time). If each delta time
   short by 1 ns, you are off by 10 ns after ten readings. Yes, that would be a really poor
   delta time measure.

3. You might want to know when an event happened “as received” at various
   locations. That would get you into time sync at possibly a pretty crazy level of
   accuracy.

Is that everything? This is Time Nuts …. it’s never “everything” :) :).

Bob

Another example.  You have say a Raspberry Pi, it has some sensors on it, say pressure, temperature, humidity.  It is connected to the Internet and has an NTP client running so it "knows" the right time.  Every second (say) it gets a signal perhaps from a pendulum sensed by an optocoupler.  When it gets this it pops a record of time, temp, pressure, relhumidity, into a file.  The record is "time stamped".

-----Original Message-----
From: Bob Camp via time-nuts time-nuts@lists.febo.com
Sent: Friday, August 23, 2024 8:14 PM
To: Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Bob Camp kb8tq@n1k.org
Subject: [time-nuts] Re: Time stamping of data

Hi

The quick and simple version:

Fire up a clock. Off it goes. Does it do decimal seconds or something else?
That’s up to you and is application dependent. Does it roll over at some point or does it count on to infinity? Again, application dependent.

You likely start it with some starting value. It could be zero, it also could link to something like UTC. That link (or lack there of) is very application dependent.

In comes a zero crossing.

Grab the time value from the clock. (possibly to nanoseconds, picoseconds or some other level of resolution / accuracy),

Stuff that value in a file (or maybe display it, though that’s less common).

Step and repeat for each zero crossing.

Why do this?

1. It’s a zero dead time way to look at things. A “delta time between crossings”
   approach might take a while to get ready for the next zero crossing.

2. It takes out potential cumulative errors (compared to delta time). If each delta time short by 1 ns, you are off by 10 ns after ten readings. Yes, that would be a really poor delta time measure.

3. You might want to know when an event happened “as received” at various locations. That would get you into time sync at possibly a pretty crazy level of accuracy.

Is that everything? This is Time Nuts …. it’s never “everything” :) :).

Bob

time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-leave@lists.febo.com

Thanks much for the info about time stamping- I now have a better feel.

My usual situation is that I take streaming IQ data from a spectrum
analyzer at a rate of several kSa/s, then run this data through a
process to select a desired BW and analyze the bandlimited data
for phase, amplitude, etc versus time.  The initial sampling rate is
very accurately known (locked to an Rb standard which is manually
"disciplined" to 10 MHz from a GPSDO.  And from this, the final
sample rate is derived by calculation.

I guess my question is, then, is it sufficient to label the final output
data with the accurate time of the first sample?  Or, (heaven forbid)
should I be thinking in terms of time stamping each output sample?

Dana

On Sat, Aug 24, 2024 at 8:49 AM john.haine--- via time-nuts <
time-nuts@lists.febo.com> wrote:

Hi

How much do you trust your SA clock? It sounds like you trust it pretty well.

As long as the answer isn’t something like “I don’t trust it at all”, then that’s your clock and away
it ticks. It might have a really weird tick rate when expressed in fractions of a second. So be it.

Another twist would be running a half dozen SA’s at various sites. They all are looking at the same
signals. You want to combine the results in some way to get an answer of some sort. In this case,
some form of working out both the start time and being able to link up the rates / samples times
becomes part of the picture.

Bob

Hi Dana,

For recovery reasons, you may want a fuller time-stamp every now and
then. Between those a simple sample counter suffice. This can be
arranged in a few different ways. For instance, you can let a sample
counter run and then as it wrap proide a time-stamp as it wraps.

Usually you don't really need absolute time for most processing, more a
presentation issue, but you want your long-term time-stamp to be
consistent within the data as you process it. Thus, being able to track
the number of samples between two samples is usually more important than
knowing which UTC time it was.

I've seen many variants being used, and there is no really correct way
that is universally good, but for the flow of samples doing a continuous
time-scale of arbitrary start usually suffice, and then TAI or UTC type
of time-stamps can be done. As usually, avoid formats that can confuse,
such as time_t.

Cheers,
Magnus

On 2024-08-24 17:59, Dana Whitlow via time-nuts wrote: