Re: Compairing the phase drifts between two PPS signals
Hey Thomas and Others,
Thanks for your input!
I could explain my background and goals a bit more in-depth.
So we here at my university are building a balloon-borne VLBI station that will observe a bright radio source at K-band simultaneously with a large ground-based radio dish. Our balloon will be flying 35-40kms in the stratosphere.
To do a correlation of the signals later on( and hence interferometry/VLBI) we would need to be able to track the position of our balloon to a fraction of the wavelength at which we are observing (which is 1.3cm). Our positional tracking requirements are down to a few millimeters. For such position tracking requirements, we are using a high-precision GPS unit with differential correctional services (ex: Hemisphere GNSS, etc). For the shorter timescales, we are using a Kalman filter to fuse accelerometer and gyroscope solutions.
Of course, a key aspect of doing interferometry would be to be able to timestamp our data very precisely. For that reason, we are using a pretty expensive RAKON OCXO(RK409) having an ADEV of about 6*10^-11.
Another important requirement will be to have excellent phase offset information for our own clocks. The plan over here is to be able to measure and record the phase drifts between our onboard OCXO with the GPS. Initially, I was planning to implement this in our FPGA board that we are already using for our IF signal processing (we are using the RFSoC). However, a lot of people quickly pointed out that this could be a problem as I would need to manually override the internal clocks of the RFSoC FPGA, and even then there might be jitters.
To completely avoid that I wanted to use a TDC solution. Hence I thought of asking you all!
From what I understand going through Thomas's (and John's) email and please correct me if I am wrong, I would be using our stable OCXO clock to run the TICC and then feed that same signal(10 MHz) into one of the input signal ports. In that case, would I also need to square the sine wave output of my OCXO? for that purpose would an LTC 6957 (with a CMOS logic output) be useful?
And do I just insert the 1 PPS from the GPS into the other signal port of the TICC? Won't there be an issue as I am trying to measure two signals with different frequencies i.e 10MHz and 1 PPS? I guess I didn't quite understand that well.
Also, do you think overall the TICC would fit my case? Would I be able to measure the phase drift information well enough using this setup?
I would then just feed this phase drift information through my FPGA and simply store them in the disks.
Also, any input on the position tracking system would be also highly appreciated!
Thanks for your time and help!
Regards,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca
[Queen's University Logo]https://www.queensu.ca/
From: Thomas Abbott thomas@reversebiased.com
Sent: Tuesday, October 4, 2022 2:16 AM
To: Mayukh Bagchi mayukh.bagchi@queensu.ca
Subject: Re: Compairing the phase drifts between two PPS signals
Hi Mayukh,
I've done this recently and can make a few suggestions.
But first - what's your real goal here?
If you're looking to get good data about the OCXO or the GPS and have a several thousand dollar budget, then you should just buy the necessary professional equipment. My previous company did this:
- OCXO and divider logic
- GPS receiver in a case, with PPS & 10 MHz coaxial output
- Pendulum or Keysight time interval counter
- GHz oscilloscope for sanity check of evrerything
- Laptop etc.
But if you're looking for the minimal set of equipment to do some basic time-nut experiments, (more like me now), then you can learn a lot by hooking up
- 10 MHz OCXO
- basic ebay / amazon GPS board
- some sort of time interval counter / timestamping counter
- computer for logging things.
- 100 MHz oscilloscope
In this case you'll spend much more time debugging the equipment and its issues, than characterising the OCXO and/or the GPS.
I've used both the TDC7200 Click demo board, which is fine but you have to deal with its quirks, and also Marek Dorsic's PicoPEThttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdorsic%2FPicoPET&data=05%7C01%7Cmayukh.bagchi%40queensu.ca%7Cb89cdbac409e49a92b4e08daa5d00352%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C638004610069460879%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B96GgMXvg%2BXc7m2M71EMXhP21g%2Ft2wdZjR9pUC2Rf%2FQ%3D&reserved=0 (see the list from a year ago) which is a raspberry pi pico modified to accept an external clock and used to timestamp the GPS PPS signals. You need some electronics common sense to avoid issues like spurious signal pickup (false PPS signals) and dropped clock pulses, and also coupling between channels leading to pulling of the TDC results. Breadboard construction is OK to get started but will drive you crazy when trying to get real data, it will be full of glitches when someone turns on a printer two offices away.
I recommend clocking the PicoPET (or the TICC) directly from the 10 MHz OCXO, not dividing it down to 1PPS and then capturing the timestamps of the 1PPS of the GPS. Otherwise the two PPSs drift apart until you have whole microseconds of difference, and then the accuracy of the TIC clock starts to matter too. Or worse, the pulses cross over and the TIC stops counting because Stop happens before Start.
If you use a TDC7200, I suggest squaring up the OCXO if it isn't already a square wave, and using it as the "stop" channel. Then you have a Stop signal every 100 ns, and it will count from the GPS pulse to the soonest available clock edge (within its limits), This way it's never counting too long, so its timebase doesn't matter too much. I got to this point when I realised the clock sine wave wasn't triggering the TDC reliably, and that I had bad coupling between channels, leading to very non-uniform distribution of time values. Hence the recommendation about soldering everything and using proper ground planes and metal boxes.
Finally you need to capture and use the TIM_TP messages from the GPS, telling you how far ahead/behind the true 1 second edge the next PPS will be.
I plotted everything in Timelab, after some manual repair of the files, glitch removal etc, in python. It's not difficult to learn, accepts all kinds of input formats and plots many files easily.
Hope this helps for starters, I'm happy to answer more questions off-list.
Regards, Thomas
Thomas Abbott
thomas@reversebiased.commailto:thomas@reversebiased.com +1 604 365 7671
On Mon, 3 Oct 2022 at 13:43, Mayukh Bagchi via time-nuts <time-nuts@lists.febo.commailto:time-nuts@lists.febo.com> wrote:
Hello,
I am trying to compare the phase drifts between a 1PPS signal generated by a GPS receiver with a 1PPS from an OCXO( using a frequency divider to convert 10MHz to 1 PPS).
I was thinking of using a TDC like the texas instruments TDC7200 boards.
Do any of you have an idea for doing this?
Let me know if you need more background on the kind of work I am trying to achieve.
Thanks,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca<mailto:mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca>
[Queen's University Logo]https://www.queensu.ca/
time-nuts mailing list -- time-nuts@lists.febo.commailto:time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.commailto:time-nuts-leave@lists.febo.com
On 10/4/22 16:29, Mayukh Bagchi via time-nuts wrote:
Hi Mayukh! See below...
From what I understand going through Thomas's (and John's) email and please correct me if I am wrong, I would be using our stable OCXO clock to run the TICC and then feed that same signal(10 MHz) into one of the input signal ports. In that case, would I also need to square the sine wave output of my OCXO? for that purpose would an LTC 6957 (with a CMOS logic output) be useful?
And do I just insert the 1 PPS from the GPS into the other signal port of the TICC? Won't there be an issue as I am trying to measure two signals with different frequencies i.e 10MHz and 1 PPS? I guess I didn't quite understand that well.
There are two main ways to use the TICC for this kind of timing: (a) as
a traditional time interval counter with one DUT and one reference PPS
input plus a 10 MHz clock input, or (b) as a timestamping counter with
one (or two) PPS input, and a 10 MHz clock that also acts as the reference.
In case (a) you measure the (changing) interval between the two PPS
sources, and the 10 MHz clock is used as a transfer standard -- its
performance does not need to be anything special because you are using
it to measure such short time periods that the clock noise is irrelevant
(within reason). You analyze the changes in time interval over time to
determine frequency offset and stability.
In case (b) you measure a series of timestamps from one PPS source and
compare the second-to-second variations of the PPS source compared to
the 10 MHz clock. In that case, the clock is important. The
timestamps might look like this (lots of decimal places removed for
simplicity):
5.000 103
6.000 054
7.000 005
7.999 953
8.999 902
To extract phase data from this, you subtract the prior timestamp from
the present one, and then subtract the nominal period to get the
relative phase of the PPS compared to the 10 MHz clock, and analyze how
that varies over time. [ In this case, the TICC can measure timestamps
from each of its two channels independently, so you can compare two
oscillators against a common reference, if you want. ]
Case (a) is the traditional method and works just fine if you have two
PPS sources; the 10 MHz source doesn't need to be anything too fancy.
Case (b) is more convenient if you already have a 10 MHz output from
your reference; it avoids a divider. With the TICC, case (a) also gives
you a two channel measurement system instead of just one. In theory you
can argue that the timestamp method might have slightly better
performance than time interval, but in practice it's very hard to see
the difference.
Also, do you think overall the TICC would fit my case? Would I be able to measure the phase drift information well enough using this setup?
The TICC noise floor is something better than 1e-10 at tau=1 second and
goes down decade per decade with increasing tau. With the rule of thumb
that the noise should be a decade below the measurement, you should be
able to measure <1e-9 at 1 second with good confidence. You'll have to
decide whether that's sufficient. If it's not, you'll probably need to
go with a different and likely 17 dB more expensive measurement system.
Hope this helps!
John
On 10/4/22 1:29 PM, Mayukh Bagchi via time-nuts wrote:
Hey Thomas and Others,
Thanks for your input!
I could explain my background and goals a bit more in-depth.
So we here at my university are building a balloon-borne VLBI station that will observe a bright radio source at K-band simultaneously with a large ground-based radio dish. Our balloon will be flying 35-40kms in the stratosphere.
To do a correlation of the signals later on( and hence interferometry/VLBI) we would need to be able to track the position of our balloon to a fraction of the wavelength at which we are observing (which is 1.3cm). Our positional tracking requirements are down to a few millimeters. For such position tracking requirements, we are using a high-precision GPS unit with differential correctional services (ex: Hemisphere GNSS, etc). For the shorter timescales, we are using a Kalman filter to fuse accelerometer and gyroscope solutions.
Of course, a key aspect of doing interferometry would be to be able to timestamp our data very precisely. For that reason, we are using a pretty expensive RAKON OCXO(RK409) having an ADEV of about 6*10^-11.
Another important requirement will be to have excellent phase offset information for our own clocks. The plan over here is to be able to measure and record the phase drifts between our onboard OCXO with the GPS. Initially, I was planning to implement this in our FPGA board that we are already using for our IF signal processing (we are using the RFSoC). However, a lot of people quickly pointed out that this could be a problem as I would need to manually override the internal clocks of the RFSoC FPGA, and even then there might be jitters.
have you looked at using JPL's GipsyX processing service - they will
take raw observables from your receiver, including tick counts from your
onboard oscillator, and generate a report that has the precise x,y,z and
xdot,ydot,zdot, but even better, they can generate a TDP (which I can't
remember what it stands for Time something)) which gives the estimated
frequency offset and offset rate for your oscillator. What's nice is
that it takes a week or more worth of data and builds the position vs
time model against the precise ephemeris, and out of that comes the
local clock offset, bias, and rate.
https://gipsy-oasis.jpl.nasa.gov/
Having a 2 frequency receiver is something you'll need although if
you're close enough maybe the ionospheric stuff washes out as a common
error.
We're using it to measure positions and time differences for 6
satellites spread over 20 km, and we're not at the mm level, but we are
at the cm level and 0.1 ns timing (for an interferometer at 23 MHz)
To completely avoid that I wanted to use a TDC solution. Hence I thought of asking you all!
From what I understand going through Thomas's (and John's) email and please correct me if I am wrong, I would be using our stable OCXO clock to run the TICC and then feed that same signal(10 MHz) into one of the input signal ports. In that case, would I also need to square the sine wave output of my OCXO? for that purpose would an LTC 6957 (with a CMOS logic output) be useful?
And do I just insert the 1 PPS from the GPS into the other signal port of the TICC? Won't there be an issue as I am trying to measure two signals with different frequencies i.e 10MHz and 1 PPS? I guess I didn't quite understand that well.
Also, do you think overall the TICC would fit my case? Would I be able to measure the phase drift information well enough using this setup?
I would then just feed this phase drift information through my FPGA and simply store them in the disks.
Also, any input on the position tracking system would be also highly appreciated!
Thanks for your time and help!
Regards,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca
[Queen's University Logo]https://www.queensu.ca/
From: Thomas Abbott thomas@reversebiased.com
Sent: Tuesday, October 4, 2022 2:16 AM
To: Mayukh Bagchi mayukh.bagchi@queensu.ca
Subject: Re: Compairing the phase drifts between two PPS signals
Hi Mayukh,
I've done this recently and can make a few suggestions.
But first - what's your real goal here?
If you're looking to get good data about the OCXO or the GPS and have a several thousand dollar budget, then you should just buy the necessary professional equipment. My previous company did this:
- OCXO and divider logic
- GPS receiver in a case, with PPS & 10 MHz coaxial output
- Pendulum or Keysight time interval counter
- GHz oscilloscope for sanity check of evrerything
- Laptop etc.
But if you're looking for the minimal set of equipment to do some basic time-nut experiments, (more like me now), then you can learn a lot by hooking up
- 10 MHz OCXO
- basic ebay / amazon GPS board
- some sort of time interval counter / timestamping counter
- computer for logging things.
- 100 MHz oscilloscope
In this case you'll spend much more time debugging the equipment and its issues, than characterising the OCXO and/or the GPS.
I've used both the TDC7200 Click demo board, which is fine but you have to deal with its quirks, and also Marek Dorsic's PicoPEThttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdorsic%2FPicoPET&data=05%7C01%7Cmayukh.bagchi%40queensu.ca%7Cb89cdbac409e49a92b4e08daa5d00352%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C638004610069460879%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B96GgMXvg%2BXc7m2M71EMXhP21g%2Ft2wdZjR9pUC2Rf%2FQ%3D&reserved=0 (see the list from a year ago) which is a raspberry pi pico modified to accept an external clock and used to timestamp the GPS PPS signals. You need some electronics common sense to avoid issues like spurious signal pickup (false PPS signals) and dropped clock pulses, and also coupling between channels leading to pulling of the TDC results. Breadboard construction is OK to get started but will drive you crazy when trying to get real data, it will b
e full of glitches when someone turns on a printer two offices away.
I recommend clocking the PicoPET (or the TICC) directly from the 10 MHz OCXO, not dividing it down to 1PPS and then capturing the timestamps of the 1PPS of the GPS. Otherwise the two PPSs drift apart until you have whole microseconds of difference, and then the accuracy of the TIC clock starts to matter too. Or worse, the pulses cross over and the TIC stops counting because Stop happens before Start.
If you use a TDC7200, I suggest squaring up the OCXO if it isn't already a square wave, and using it as the "stop" channel. Then you have a Stop signal every 100 ns, and it will count from the GPS pulse to the soonest available clock edge (within its limits), This way it's never counting too long, so its timebase doesn't matter too much. I got to this point when I realised the clock sine wave wasn't triggering the TDC reliably, and that I had bad coupling between channels, leading to very non-uniform distribution of time values. Hence the recommendation about soldering everything and using proper ground planes and metal boxes.
Finally you need to capture and use the TIM_TP messages from the GPS, telling you how far ahead/behind the true 1 second edge the next PPS will be.
I plotted everything in Timelab, after some manual repair of the files, glitch removal etc, in python. It's not difficult to learn, accepts all kinds of input formats and plots many files easily.
Hope this helps for starters, I'm happy to answer more questions off-list.
Regards, Thomas
Thomas Abbott
thomas@reversebiased.commailto:thomas@reversebiased.com +1 604 365 7671
On Mon, 3 Oct 2022 at 13:43, Mayukh Bagchi via time-nuts <time-nuts@lists.febo.commailto:time-nuts@lists.febo.com> wrote:
Hello,
I am trying to compare the phase drifts between a 1PPS signal generated by a GPS receiver with a 1PPS from an OCXO( using a frequency divider to convert 10MHz to 1 PPS).
I was thinking of using a TDC like the texas instruments TDC7200 boards.
Do any of you have an idea for doing this?
Let me know if you need more background on the kind of work I am trying to achieve.
Thanks,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca<mailto:mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca>
[Queen's University Logo]https://www.queensu.ca/
time-nuts mailing list -- time-nuts@lists.febo.commailto:time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.commailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi Mayukh,
I implemented an SDR-based (USRP N210/X310 w/ LFRX daughterboards)
solution for simultaneous measurement of sine and pulse signals ~5 years
ago. It achieved 360 fs 1\sigma accuracy for 10 MHz signals and 16.6 ps
1\sigma for pulse signals. [1]
We also work with the RFSoC. I believe you should be able to implement a
similar, sampling-based solution with it if you have ADC channels to
spare. If your RFSoC board implements multi-tile synchronization (MTS)
you could coherently sample the 1PPS, your down-mixed interferometry RF
signal, and any associated reference signals. With a shared, low phase
noise sampling clock that approach should enable the best possible
accuracy and precision compared to using additional external sensors.
Best regards,
Carsten
[1] https://arxiv.org/abs/1803.01438
On 04.10.22 22:29, Mayukh Bagchi via time-nuts wrote:
Hey Thomas and Others,
Thanks for your input!
I could explain my background and goals a bit more in-depth.
So we here at my university are building a balloon-borne VLBI station that will observe a bright radio source at K-band simultaneously with a large ground-based radio dish. Our balloon will be flying 35-40kms in the stratosphere.
To do a correlation of the signals later on( and hence interferometry/VLBI) we would need to be able to track the position of our balloon to a fraction of the wavelength at which we are observing (which is 1.3cm). Our positional tracking requirements are down to a few millimeters. For such position tracking requirements, we are using a high-precision GPS unit with differential correctional services (ex: Hemisphere GNSS, etc). For the shorter timescales, we are using a Kalman filter to fuse accelerometer and gyroscope solutions.
Of course, a key aspect of doing interferometry would be to be able to timestamp our data very precisely. For that reason, we are using a pretty expensive RAKON OCXO(RK409) having an ADEV of about 6*10^-11.
Another important requirement will be to have excellent phase offset information for our own clocks. The plan over here is to be able to measure and record the phase drifts between our onboard OCXO with the GPS. Initially, I was planning to implement this in our FPGA board that we are already using for our IF signal processing (we are using the RFSoC). However, a lot of people quickly pointed out that this could be a problem as I would need to manually override the internal clocks of the RFSoC FPGA, and even then there might be jitters.
To completely avoid that I wanted to use a TDC solution. Hence I thought of asking you all!
From what I understand going through Thomas's (and John's) email and please correct me if I am wrong, I would be using our stable OCXO clock to run the TICC and then feed that same signal(10 MHz) into one of the input signal ports. In that case, would I also need to square the sine wave output of my OCXO? for that purpose would an LTC 6957 (with a CMOS logic output) be useful?
And do I just insert the 1 PPS from the GPS into the other signal port of the TICC? Won't there be an issue as I am trying to measure two signals with different frequencies i.e 10MHz and 1 PPS? I guess I didn't quite understand that well.
Also, do you think overall the TICC would fit my case? Would I be able to measure the phase drift information well enough using this setup?
I would then just feed this phase drift information through my FPGA and simply store them in the disks.
Also, any input on the position tracking system would be also highly appreciated!
Thanks for your time and help!
Regards,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca
[Queen's University Logo]https://www.queensu.ca/
From: Thomas Abbott thomas@reversebiased.com
Sent: Tuesday, October 4, 2022 2:16 AM
To: Mayukh Bagchi mayukh.bagchi@queensu.ca
Subject: Re: Compairing the phase drifts between two PPS signals
Hi Mayukh,
I've done this recently and can make a few suggestions.
But first - what's your real goal here?
If you're looking to get good data about the OCXO or the GPS and have a several thousand dollar budget, then you should just buy the necessary professional equipment. My previous company did this:
- OCXO and divider logic
- GPS receiver in a case, with PPS & 10 MHz coaxial output
- Pendulum or Keysight time interval counter
- GHz oscilloscope for sanity check of evrerything
- Laptop etc.
But if you're looking for the minimal set of equipment to do some basic time-nut experiments, (more like me now), then you can learn a lot by hooking up
- 10 MHz OCXO
- basic ebay / amazon GPS board
- some sort of time interval counter / timestamping counter
- computer for logging things.
- 100 MHz oscilloscope
In this case you'll spend much more time debugging the equipment and its issues, than characterising the OCXO and/or the GPS.
I've used both the TDC7200 Click demo board, which is fine but you have to deal with its quirks, and also Marek Dorsic's PicoPEThttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdorsic%2FPicoPET&data=05%7C01%7Cmayukh.bagchi%40queensu.ca%7Cb89cdbac409e49a92b4e08daa5d00352%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C638004610069460879%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B96GgMXvg%2BXc7m2M71EMXhP21g%2Ft2wdZjR9pUC2Rf%2FQ%3D&reserved=0 (see the list from a year ago) which is a raspberry pi pico modified to accept an external clock and used to timestamp the GPS PPS signals. You need some electronics common sense to avoid issues like spurious signal pickup (false PPS signals) and dropped clock pulses, and also coupling between channels leading to pulling of the TDC results. Breadboard construction is OK to get started but will drive you crazy when trying to get real data, it will b
e full of glitches when someone turns on a printer two offices away.
I recommend clocking the PicoPET (or the TICC) directly from the 10 MHz OCXO, not dividing it down to 1PPS and then capturing the timestamps of the 1PPS of the GPS. Otherwise the two PPSs drift apart until you have whole microseconds of difference, and then the accuracy of the TIC clock starts to matter too. Or worse, the pulses cross over and the TIC stops counting because Stop happens before Start.
If you use a TDC7200, I suggest squaring up the OCXO if it isn't already a square wave, and using it as the "stop" channel. Then you have a Stop signal every 100 ns, and it will count from the GPS pulse to the soonest available clock edge (within its limits), This way it's never counting too long, so its timebase doesn't matter too much. I got to this point when I realised the clock sine wave wasn't triggering the TDC reliably, and that I had bad coupling between channels, leading to very non-uniform distribution of time values. Hence the recommendation about soldering everything and using proper ground planes and metal boxes.
Finally you need to capture and use the TIM_TP messages from the GPS, telling you how far ahead/behind the true 1 second edge the next PPS will be.
I plotted everything in Timelab, after some manual repair of the files, glitch removal etc, in python. It's not difficult to learn, accepts all kinds of input formats and plots many files easily.
Hope this helps for starters, I'm happy to answer more questions off-list.
Regards, Thomas
Thomas Abbott
thomas@reversebiased.commailto:thomas@reversebiased.com +1 604 365 7671
On Mon, 3 Oct 2022 at 13:43, Mayukh Bagchi via time-nuts <time-nuts@lists.febo.commailto:time-nuts@lists.febo.com> wrote:
Hello,
I am trying to compare the phase drifts between a 1PPS signal generated by a GPS receiver with a 1PPS from an OCXO( using a frequency divider to convert 10MHz to 1 PPS).
I was thinking of using a TDC like the texas instruments TDC7200 boards.
Do any of you have an idea for doing this?
Let me know if you need more background on the kind of work I am trying to achieve.
Thanks,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca<mailto:mayukh.bagchi@queensu.camailto:mayukh.bagchi@queensu.ca>
[Queen's University Logo]https://www.queensu.ca/
time-nuts mailing list -- time-nuts@lists.febo.commailto:time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.commailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com