Empathy List Archives

J

jimlux

Sat, Oct 28, 2017 4:04 PM

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)

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)

JA

John Ackermann N8UR

Sat, Oct 28, 2017 5:34 PM

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.

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.

J

jimlux

Sat, Oct 28, 2017 6:20 PM

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:

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
Amplitude of the pulse - that one seems pretty straightforward - a
good switch from a regulated voltage.
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.

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.

D

djl

Sat, Oct 28, 2017 9:25 PM

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:

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
Amplitude of the pulse - that one seems pretty straightforward - a
good switch from a regulated voltage.
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.

--
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304

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

J

jimlux

Sat, Oct 28, 2017 9:37 PM

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.

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@lists.febo.com

chrony vs ntpd

John

John

John