Timestamp for pulse

[martin1454]

Hello everybody!

I currently working on a project, where I will be using a van to do some different kinds of measurements, and do some processing on that. With that, I need to accurately timestamp the data. For now, I will use an 10KHz trigger input, to start the sensors, and capture data, but I need to know when the data is captured / where.

How would I get an accurate time stamp of the data?

My current thought is to get some hardware to start generating the 10KHz pulse, and get an timestamp of the first pulse, and then add 1/10000 second to the time for each measurement, but I dont know any kind of hardware with possibility for that. Im looking into to hardware that either supports NTP or IEEE1588, but haven't found anything that can give me the timestamp from the pulse.

Do anyone of you guys, know any tool ?

[Richard Crowley]

Does "using a van" imply outdoors?  (vs. indoors, underground, etc.)  Do you have access to a view of the sky?

What do you mean by "accurate"?  Do you mean a frequency as close as possible to 10.00000 KHz?  Is short-term stability or long-term stability more important for your project?

By "time-stamp" do you mean simply counting time from some internal starting point reference?  Or do you mean something coordinated with UTC?

An obvious answer to your questions would appear to be using GPS (or GLONASS or Galileo) which would provide BOTH frequency accuracy (with a GPS disciplined oscillator, GPSDO) and UTC referenced time-stamp.

[martin1454]

Does "using a van" imply outdoors?  (vs. indoors, underground, etc.)  Do you have access to a view of the sky?

What do you mean by "accurate"?  Do you mean a frequency as close as possible to 10.00000 KHz?  Is short-term stability or long-term stability more important for your project?

By "time-stamp" do you mean simply counting time from some internal starting point reference?  Or do you mean something coordinated with UTC?

An obvious answer to your questions would appear to be using GPS (or GLONASS or Galileo) which would provide BOTH frequency accuracy (with a GPS disciplined oscillator, GPSDO) and UTC referenced time-stamp.

van = inside the van -

I will have an large GPS system (Trimble) to host an NTP server, while logging the position.
Since I log my positions with relevance to time, the rest of my measurements will also be referenced to time (using either NTP or IEEE1588).
The "accurate" time I need, is being able to say, that the time is exactly  12:34:25:2523, so I can compare the measurement to my position, by reference in time.

I will be taking measurements for around 1-4 hours at a time, so not that long-term stability.

[Gyro]

You could look at http://www.leapsecond.com/pic/picpet.htm There's a chance that it might fit, or be adaptable to fit, your needs.

... Just read your last post, maybe not then.

[martin1454]

You could look at http://www.leapsecond.com/pic/picpet.htm There's a chance that it might fit, or be adaptable to fit, your needs.

... Just read your last post, maybe not then.

could be adaptable I think!

[awallin]

You could look at http://www.leapsecond.com/pic/picpet.htm There's a chance that it might fit, or be adaptable to fit, your needs.

picpet would be around 100ns resolution and quite cheap to DIY.
If you need <1 ns and can spend $200 then TICC: https://www.tapr.org/kits_ticc.html

[tggzzz]

Consider:

• having a crystal controlled 10kHz clock; you can set/measure the frequency, and you can calculate the maximum amount it will drift given the time and environmental conditions (Do not rely on the accuracy of a crystal on a computer board)
• that 10kHz signal drives your counter
  
• having an enable signal that allows/prevents the clock from reaching the counter
• align the enable with a GPS timestamp, either by using a transition in the GPS time to create the signal, or using the enable signal to capture/latch the GPS time

That cleanly highlights and decouples the two different requirements in your spec: initial timestamp, and incremental time thereafter.

[texaspyro]

With a 10 MHz clock input, the PICPET time stamps wrap every 100 seconds.  Your software needs to handle this.  Also, the 19200 baud rate and message length limits the max event rate to around 100/sec. 

The TAPR TICC has a 60 ps resolution and is also limited to around 100 events/sec, but the time stamp wrap interval is very long... I don't remember the value, but I think it is over 100 days.

What kind of accuracy do your timestamps need to have and what is the rate of the input signal that you want to timestamp?

[martin1454]

With a 10 MHz clock input, the PICPET time stamps wrap every 100 seconds.  Your software needs to handle this.  Also, the 19200 baud rate and message length limits the max event rate to around 100/sec. 

The TAPR TICC has a 60 ps resolution and is also limited to around 100 events/sec, but the time stamp wrap interval is very long... I don't remember the value, but I think it is over 100 days.

What kind of accuracy do your timestamps need to have and what is the rate of the input signal that you want to timestamp?

Even though the TAPR TICC is limited to 100 events / sec, I could still use it to validate time time of the first pulse, and then over time, check the timeinterval between the pulses, to validate the accuracy of the 10kHz.  - Of course the best solution would be if I could get an timestamp pr. pulse(10.000 events pr sec), but if I know the time of the first one, I can just add 1/10000 sec for each sample, and validate it to some degree, by using 100 sps to check the time between each pulse, which gives me the frequency / change in time between pulses