On 4/25/21 6:40 AM, Bob kb8tq wrote:
Hi
On Apr 25, 2021, at 9:31 AM, Lux, Jim <[email protected]> wrote:
On 4/25/21 6:02 AM, Bob kb8tq wrote:
Hi
The thing that I find useful about a GPS simulator is it’s ability to calibrate
the
time delay through a GPS based system. In the case of a GPSDO, there may be
things beyond the simple receiver delay that get into the mix. Getting the
entire
offset “picture” all at once is nice thing. Yes, that’s a Time Nutty way to
look at it…..
So far, I have not seen anybody extending this sort of calibration to the low
cost
SDR based devices. Without digging into the specific device, I’m not sure how
well a “generic” calibration would do. Indeed, it might work quite well. Without
actually doing it … no way to tell.
So if anybody knows of the results of such an effort, I suspect it would be of
interest to folks here on the list.
Bob
A double difference kind of relative measurement might be useful - compare two
(or three) GNSS receivers. Then the absolute timing of the test source isn't
as important.
Well …. it is and it isn’t. If you are trying to get “UTC in the basement” (or
even
GPS time) to a couple nanoseconds, then you do need to know absolute delays
of a number of things. Is this a bit crazy? Of course it is :)
Bob
Good point..
For many SDRs, it's tricky to get the output synchronized to anything -
a lot were designed as an RF ADC/DAC for software SDR (like gnuradio).
The software SDRs are sort of a pipeline of software, with not much
attention to absolute timing, just that the samples come out in the same
order and rate as samples go in, but with a non-deterministic delay.
Partly a side effect of using things like USB or IP sockets as an
interface. And, to a certain extent, running under a non-real time OS
(where real time determinism is "difficult programming" - although
clearly doable, since playing back a movie requires synchronizing the
audio and video streams ).
If your goal is "write software 802.11" you don't need good timing - the
protocol is half duplex in any case, and a millisecond here or there
makes no difference.
A SDR that has a FPGA component to drive the DACs might work pretty
well, if you can figure a way to get a sync signal into it. One tricky
thing is getting the chips lined up with the carrier - most inexpensive
SDRs use some sort of upconverter from baseband I/Q, and even if the I/Q
runs off the same clock as the PLL generating the carrier, getting it
synced is hard.
The best bet might be a "clock the bits out and pick an appropriate
harmonic with a bandpass filter". If the FPGA clock is running at a
suitable multiple of 1.023 MHz, maybe this would work? Some JPL
receivers use 38.656 MHz as a sample rate, which puts the GPS signal at
something like 3/4 of the sample rate.
I'd have to work it backwards and see if you could generate a harmonic
that's at 1575...
_______________________________________________
time-nuts mailing list -- [email protected] -- To unsubscribe send an
email to [email protected]
To unsubscribe, go to and follow the instructions there.
