Re: [time-nuts] chrony vs ntpd
On 10/28/17 2:25 PM, djl wrote: Would a step recovery diode be better? for example http://www.mwrf.com/analog-semiconductors/designing-step-recovery-diode-based-comb-generator Maybe, but that's starting to increase the complexity. I've used various and sundry harmonic mixers using SRDs (aka Sampling Phase Detectors) The SRD has very fast transition times, so getting well up into microwave is easy. For my application, I'm happy down at 15 MHz, and a reasonably fast rise time on a 1 microsecond pulse does it quite nicely. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] chrony vs ntpd
Would a step recovery diode be better? for example http://www.mwrf.com/analog-semiconductors/designing-step-recovery-diode-based-comb-generator Don On 2017-10-28 12:20, jimlux wrote: On 10/28/17 10:34 AM, John Ackermann N8UR wrote: Jim, I thought about using an RF-input sync pulse for alignment during the Solar Eclipse measurement experiment, but ended up running out of time to implement it. But some very crude experiments indicated that it's not hard to generate an edge out of a PPS that creates a comb well past HF. My idea was to do a divide-by-sixty to end up with pulse-per-minute rather than PPS. The lower rate would be less annoying to filter out of the results. I'm interested to hear if you end up doing this, and if so how. Yes, a nice narrow pulse makes a nice comb. I've done it for a single shot wideband gain calibration across the band for my space HF receiver (in ground test). The tricky parts, I have found, are: 1) the rise and fall time have a big effect on the relative heights of the comb vs freq - perfectly square gives you a nice sin(x)/x, but if it starts to be not-square, then it rolls off faster. I've been thinking about how to do something that measures it 2) Amplitude of the pulse - that one seems pretty straightforward - a good switch from a regulated voltage. 3) The effects of the antenna and receiver impedances - well - to a certain extent, that's what I want to measure. So the idea is that if you inject a pulse through a known resistance into the receiver/antenna combination (at the receiver input), and, I do this at two or three different impedances, I should be able to back out the impedance effects (with some TBD uncertainty). So far, I've been experimenting with RF tone bursts from a 33622 function generator - Easy to detect, but I've not found a good way to get a nice sharp marker - you can slide a matched filter along and get a sort of pulse, but it's not what I want. I'm starting to think that some sort of PN code might be the way to go - It makes it easy to integrate over a longer time (e.g. many edges to look at). John On 10/28/2017 12:04 PM, jimlux wrote: Now that I have successfully connected my GPS receiver to my beagle and I'm getting pps ticks into the driver, etc. (thanks to info from several folks on this list!) the question arises of whether to use ntpd or chrony. For my particular application, I'm more interested in synchronizing time on the local machine, not necessarily being a NTP server - all of my beagles have a GPS on them. Of course, there may be times when a GPS doesn't work, or something else comes up where it would be useful for one of the machines to "get time" from somewhere else. What I am doing is using the Beagle to capture RF samples (RTL-SDR) in a distributed array, with wireless connections among the nodes. The processing isn't necessarily real-time (maybe later..), for now, it's "trigger some seconds of capture at approximately the same time" and post process in matlab/octave. There's all kinds of nondeterministic latency issues with the USB/RTL-SDR path, so I'm under no illusion that I can capture samples aligned to the 1pps. However, what I *can* do is generate a "sync pulse" from the 1 pps and feed it into the RTL's RF input in some (TBD) way. And the 1pps might give me a clever way to calibrate the frequency drift of the RTLSDR's clock. Right now, I'm interested in HF signals (so the period is 30 ns at the top end, and 500 ns at the bottom end) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Dr. Don Latham PO Box 404, Frenchtown, MT, 59834 VOX: 406-626-4304 ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] chrony vs ntpd
I don't know much about chrony. jim...@earthlink.net said: > Now that I have successfully connected my GPS receiver to my beagle and I'm > getting pps ticks into the driver, etc. (thanks to info from several folks > on this list!) the question arises of whether to use ntpd or chrony. If you are running on Linux, you can get easy access to the PPS info via something like: $ cat /sys/devices/virtual/pps/pps0/assert 1509220576.90288#60013 $ The stuff in front of the # is the time, the stuff after is the pulse count. So you can setup something to collect the offset and see how well whatever you are using is working. If you want to test the non-PPS mode, you can setup your ntpd/chronyd to not use it. The same measuring software will continue to collect data. - On most OSes, there are 2 ways to use the PPS. There is an API to read the info. You can use that as a source of time to steer your clock with the same sort of logic that you would use if you are getting time from a NTP server. Usually it works better because of reduced jitter. Or, you can set a mode bit in the kernel and it will make the adjustments while you sit back and watch. On Linux, the kernel mode is not available if your kernel is built with the tickless scheduler. You have to build your own kernel... -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] chrony vs ntpd
On 10/28/17 10:34 AM, John Ackermann N8UR wrote: Jim, I thought about using an RF-input sync pulse for alignment during the Solar Eclipse measurement experiment, but ended up running out of time to implement it. But some very crude experiments indicated that it's not hard to generate an edge out of a PPS that creates a comb well past HF. My idea was to do a divide-by-sixty to end up with pulse-per-minute rather than PPS. The lower rate would be less annoying to filter out of the results. I'm interested to hear if you end up doing this, and if so how. Yes, a nice narrow pulse makes a nice comb. I've done it for a single shot wideband gain calibration across the band for my space HF receiver (in ground test). The tricky parts, I have found, are: 1) the rise and fall time have a big effect on the relative heights of the comb vs freq - perfectly square gives you a nice sin(x)/x, but if it starts to be not-square, then it rolls off faster. I've been thinking about how to do something that measures it 2) Amplitude of the pulse - that one seems pretty straightforward - a good switch from a regulated voltage. 3) The effects of the antenna and receiver impedances - well - to a certain extent, that's what I want to measure. So the idea is that if you inject a pulse through a known resistance into the receiver/antenna combination (at the receiver input), and, I do this at two or three different impedances, I should be able to back out the impedance effects (with some TBD uncertainty). So far, I've been experimenting with RF tone bursts from a 33622 function generator - Easy to detect, but I've not found a good way to get a nice sharp marker - you can slide a matched filter along and get a sort of pulse, but it's not what I want. I'm starting to think that some sort of PN code might be the way to go - It makes it easy to integrate over a longer time (e.g. many edges to look at). John On 10/28/2017 12:04 PM, jimlux wrote: Now that I have successfully connected my GPS receiver to my beagle and I'm getting pps ticks into the driver, etc. (thanks to info from several folks on this list!) the question arises of whether to use ntpd or chrony. For my particular application, I'm more interested in synchronizing time on the local machine, not necessarily being a NTP server - all of my beagles have a GPS on them. Of course, there may be times when a GPS doesn't work, or something else comes up where it would be useful for one of the machines to "get time" from somewhere else. What I am doing is using the Beagle to capture RF samples (RTL-SDR) in a distributed array, with wireless connections among the nodes. The processing isn't necessarily real-time (maybe later..), for now, it's "trigger some seconds of capture at approximately the same time" and post process in matlab/octave. There's all kinds of nondeterministic latency issues with the USB/RTL-SDR path, so I'm under no illusion that I can capture samples aligned to the 1pps. However, what I *can* do is generate a "sync pulse" from the 1 pps and feed it into the RTL's RF input in some (TBD) way. And the 1pps might give me a clever way to calibrate the frequency drift of the RTLSDR's clock. Right now, I'm interested in HF signals (so the period is 30 ns at the top end, and 500 ns at the bottom end) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] chrony vs ntpd
Jim, I thought about using an RF-input sync pulse for alignment during the Solar Eclipse measurement experiment, but ended up running out of time to implement it. But some very crude experiments indicated that it's not hard to generate an edge out of a PPS that creates a comb well past HF. My idea was to do a divide-by-sixty to end up with pulse-per-minute rather than PPS. The lower rate would be less annoying to filter out of the results. I'm interested to hear if you end up doing this, and if so how. John On 10/28/2017 12:04 PM, jimlux wrote: Now that I have successfully connected my GPS receiver to my beagle and I'm getting pps ticks into the driver, etc. (thanks to info from several folks on this list!) the question arises of whether to use ntpd or chrony. For my particular application, I'm more interested in synchronizing time on the local machine, not necessarily being a NTP server - all of my beagles have a GPS on them. Of course, there may be times when a GPS doesn't work, or something else comes up where it would be useful for one of the machines to "get time" from somewhere else. What I am doing is using the Beagle to capture RF samples (RTL-SDR) in a distributed array, with wireless connections among the nodes. The processing isn't necessarily real-time (maybe later..), for now, it's "trigger some seconds of capture at approximately the same time" and post process in matlab/octave. There's all kinds of nondeterministic latency issues with the USB/RTL-SDR path, so I'm under no illusion that I can capture samples aligned to the 1pps. However, what I *can* do is generate a "sync pulse" from the 1 pps and feed it into the RTL's RF input in some (TBD) way. And the 1pps might give me a clever way to calibrate the frequency drift of the RTLSDR's clock. Right now, I'm interested in HF signals (so the period is 30 ns at the top end, and 500 ns at the bottom end) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] chrony vs ntpd
Now that I have successfully connected my GPS receiver to my beagle and I'm getting pps ticks into the driver, etc. (thanks to info from several folks on this list!) the question arises of whether to use ntpd or chrony. For my particular application, I'm more interested in synchronizing time on the local machine, not necessarily being a NTP server - all of my beagles have a GPS on them. Of course, there may be times when a GPS doesn't work, or something else comes up where it would be useful for one of the machines to "get time" from somewhere else. What I am doing is using the Beagle to capture RF samples (RTL-SDR) in a distributed array, with wireless connections among the nodes. The processing isn't necessarily real-time (maybe later..), for now, it's "trigger some seconds of capture at approximately the same time" and post process in matlab/octave. There's all kinds of nondeterministic latency issues with the USB/RTL-SDR path, so I'm under no illusion that I can capture samples aligned to the 1pps. However, what I *can* do is generate a "sync pulse" from the 1 pps and feed it into the RTL's RF input in some (TBD) way. And the 1pps might give me a clever way to calibrate the frequency drift of the RTLSDR's clock. Right now, I'm interested in HF signals (so the period is 30 ns at the top end, and 500 ns at the bottom end) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
