Re: [ntp:questions] Making ntpd tweak a TCXO
>> I'm assuming your TCXO is driving your A/D. > Yes. It spits out samples at a rate f_osc / 24 = 60 Hz. My ultimate > task is to timestamp these samples in such a way that there are compressions > and dilations in the time scale, but no discontinuities. 60 Hz is pretty slow. The PPS logic will work at that speed. Can you feed the A/D trigger signal into something that the kernel PPS supports? You don't actually need the A/D trigger signal, just something that is derived from your TCXO. You are building a PLL. They have potential stability problems. -- These are my opinions. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Making ntpd tweak a TCXO
Hal Murray [hmur...@megapathdsl.net] wrote: > > > I'm assuming your TCXO is driving your A/D. > > > > Yes. It spits out samples at a rate f_osc / 24 = 60 Hz. My ultimate > > task is to timestamp these samples in such a way that there are compressions > > and dilations in the time scale, but no discontinuities. > > 60 Hz is pretty slow. The PPS logic will work at that speed. > > Can you feed the A/D trigger signal into something that the kernel PPS > supports? You don't actually need the A/D trigger signal, just something > that is derived from your TCXO. The A/D is a sigma-delta type where you set the output sample rate and it runs autonomously (locked to the input clock of course). "Sample ready" is indicated by a falling edge on the SPI MISO line, and I am bitbanging the serial interface from the PRU (Programmable Realtime Unit, a fully deterministic uC core which communicates with the main processor and OS via shared memory and interrupts). So it may be possible to timestamp those falling edges by connecting the MISO line to one of the supported PPS input pins, and arming/disarming the timestamping on every sample (because the line will also have lots of transitions in the course of transferring each 24-bit sample). Another option, since I wait on that falling-edge ready signal in my PRU code, is to timestamp there, programmatically, by reading a timer. This would get me within a single PRU cycle (5 ns), completely deterministic. What I am unclear on is how to take that timer snapshot/timestamp, and convert it into wall-clock time. The latter is only available from inside the OS (Linux). I do not understand, practically speaking, how these single instants in time are carried across the boundary from the realtime world into the nondeterministic world of the OS. Presumably this is what the Linux PPS code does? Mark ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Making ntpd tweak a TCXO
m...@hau.nz said: > The A/D is a sigma-delta type where you set the output sample rate and it > runs autonomously (locked to the input clock of course). "Sample ready" is > indicated by a falling edge on the SPI MISO line, and I am bitbanging the > serial interface from the PRU ... I'd expect some sort of data ready signal but maybe they don't need one if you are running it with a clock derived from your main CPU clock. > What I am unclear on is how to take that timer snapshot/timestamp, and > convert it into wall-clock time. The latter is only available from inside > the OS (Linux). I do not understand, practically speaking, how these single > instants in time are carried across the boundary from the realtime world > into the nondeterministic world of the OS. Presumably this is what the > Linux PPS code does? The PPS code just grabs a time stamp on an interrupt. There is an RFC on the API. It's running on the main CPU rather than a PPU. It's not cycle accurate, just as good as you can get using interrupts. You can get more accurate results if you have a counter/timer that can capture the counter on the edge that makes the interrupt. I don't know if the ARM PPS code does that. -- These are my opinions. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
