Hi

> On Apr 25, 2021, at 10:13 AM, Lux, Jim <[email protected]> wrote:
> 
> 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...
> 

I think that coming out of a “one bit DAC” on the FPGA is the most likely way 
to generate
the signal. Run that at carrier / N and away you go. I don’t think you want to 
get N to 
terribly high. Having all those images running around may not be a good idea. 
Something
in the 5 to 10 range seems about right. Is there enough “harmonic” to make it 
work or do
you need some sort of SRD-ish thing to womp it up? ….. My guess is that there 
still will 
be a bunch of little delay ambiguities That pile up on you. 

The bigger issue is: do you want to make this a “lifetime project” ? It’s only 
one of many
things that need attention if you want to get to the final goal. Spend enough 
time on each
little step and this all becomes a “many decades” sort of adventure. 

In this case I’ll let Said worry about the details and just use his gizmo :)

Bob


> 
> _______________________________________________
> time-nuts mailing list -- [email protected] -- To unsubscribe send an 
> email to [email protected]
> To unsubscribe, go to and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected] -- To unsubscribe send an 
email to [email protected]
To unsubscribe, go to and follow the instructions there.

Reply via email to