No subject

Gain Positioning Antenna" ("AN_GNSS_401") which has the same
constellations, is allegedly UV hardened, and most importantly the coaxial
comes through a M12 screw, so you can drill an M12 hole somewhere (e.g. on
a permanent fixture outdoors), seal it, and have a weather-tight solution.
It was the same price as the other when I bought it, however now it appears
to be selling for $36.

I am not sponsored by "Maswell", I just think these two antennas aren't
ugly like many of the other chinesium ones, and upon examining them
first-hand, they appear to have fine build quality for the price. Also if
you have an SMA dedicated GNSS receiver, you could track all
constellations' L1 band signals using these antennas.

Anyways, that $61.95, and if you swap the "Maswell" antenna for a cheaper
one, $42.95. What can you do with these ~$50? Receive GPS signals!

There is software such as GNSS-SDRLIB (Windows) and GNSS-SDR (Linux) which
can get a GNSS fix using your SDR, GNSS-SDRLIB seems to work better
initially but is dated and has issues, while GNSS-SDR takes more tinkering
and editing configuration files but is very flexible and works really well
once you get it to work.

The final question is, what is the quality of the time fixes with SDR?
Obviously, processing baseband GNSS signals (~2 MHz sample rate, 3.2 if you
have a USB interface with superior jitter that doesn't drop samples) has a
higher load and latency than a narrowband Loran or NIST timecode, but when
I look at the USB traffic on my Linux machine when utilizing my RTL-SDR, it
appears to poll (64 bytes) and then get a signal back, here are the packet
sizes I found at the following sample rates:
3.200 MHz: 15936
2.880 MHz: 14400
2.560 MHz: 12864
2.400 MHz: 11840
2.160 MHz: 10816
2.048 MHz: 10304
1.920 MHz:  9792
1.792 MHz:  9280
1.536 MHz:  7744
1.024 MHz:  5184
0.250 MHz:  1088

It appears it also sends ~375 packets/second no matter what sample rate I
choose, except 0.250 MHz (don't choose that), so like ~2 milliseconds of
buffering? Which is terrible, yes, but if you can find a way to sync a
precision PC clock measurement (such as POSIX clock_gettime) to the start
of the buffer, and then again at the end of the processing chain, and then
retroactively looking to see what the PC clock offset would be at the start
of the buffer, I think it would be feasible to get microsecond or even
nanosecond precision time synchronization. Also, you could run this for a
while against something like all of NIST's NTP servers (which I currently
do because I haven't implemented this, and I don't have a dedicated
GPS-locked NTP server or anything yet, with my PC's 20 ppm clock and Chrony
it keeps it to within ~154.5 us 75% of the time using all of NIST's NTP
servers except the university ones which appear to have inferior jitter,
with my PC power cycling (I put it to sleep at night))

In addition to GPS I have also gotten GPS+Galileo locks using GNSS-SDR,
however since the E1 signal is BOC, ~4 MHz receiver bandwidth minimum is
required to practically use it (that is, for it to help the quality rather
than hurt it).
Theoretically L1 QZSS should be identical to L1 GPS, but I live in Idaho
and they never get above 5 degree elevation for me.

This has been my two cents, I didn't go nearly as much into depth about
this as I possibly can, I hope to send another e-mail about my findings
regarding time synchronization using cheap SDR hardware, and possible
investigations into the method I outlined above.




On Wed, Mar 6, 2024 at 7:10 AM JOHN HARTZELL via time-nuts <
time-nuts at lists.febo.com> wrote:

> Fellow time nuts,
>
> Has anyone played around with SDR radios ability to see and use Loran-C
> and WWV signals?
>
> Kind regards,
>
> John
>
> https://linkedin.com/in/john-h-6a131b12/
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>