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.
