[time-nuts] Re: 20210423: Introduction and Request for Spirent GSS4200 User Manual / Help
Lux, Jim
jim at luxfamily.com
Sun Apr 25 14:13:33 UTC 2021
On 4/25/21 6:40 AM, Bob kb8tq wrote:
> Hi
>
>
>> On Apr 25, 2021, at 9:31 AM, Lux, Jim <jim at luxfamily.com> 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...
More information about the Time-nuts_lists.febo.com
mailing list