>> Can other GNSS give usable timestamps? Seems like it'd be tricky for a jammer to target all of them
Actually the opposite; GNSS systems are all purposely designed to operate at virtually the same frequency (check out this figure [1]) while cleverly not interfering with each other. There are sub-bands within each constellation too (L1,L2,L5 etc) but it's very easy to pump out wideband noise across all the GNSS bands.
> Instead of whining we should start jamming Glonass in retaliation
What a ridiculous comment!
All GNSS use similar frequencies for civilian signals. 1575 MHz for Galileo, 1600 MHz for Glonass etc. Since jammers primarily work by sweeping a strong signal across the relevant band (more effective than spot frequency jamming), practically all crude attempts to jam one constellation can just as well jam the lot. (You need to be rather more precise just to jam one).
e.g. A cheap COTS "GPS" jammer will typically work on all four GNSS constelations.
You jam L1 (1575.42 MHz) and you take out a whole bunch of services out.
It's one of the reasons why there's L2, L5/E5, and E6. But everything is in the Aeronautical Radio Navigation Service and Radio Navigation Satellite System bands.
>The most accurate GNSS fixes are obtained from offline solvers that analyze long-duration (e.g. 24 hour) recordings of the GNSS data streams and use computer models to determine the most likely solution accounting for many types of error.
I actually have a receiver that does exactly this! It is a Trimble Resolution T, available for very cheap (I believe they're from old cell towers), and it's intended exclusively as a time reference. You first run a 24 hour data collection, and it precisely determines your location before storing it. From then on, the receiver only calculates the time. Very cool stuff, I'm planning on building a GPS-disciplined rubidium clock and stratum 1 NTP server with it.
>Still, I suspect inexpensive consumer receivers are probably calculating a fix per constellation and then combining those.
This sounds like a reasonable solution now that you mention it, for an inexpensive device. Part of my confusion is based in the fact that the constellations actually use different reference datums [0]. Wouldn't the different constellations give meaningfully different fixes even if the solution was "perfect"?
I mentioned in another comment that I pretty much forgot that this could be a political thing. That's a very good point and I don't know why I didn't think of it. Especially with selective availability, which as far as I understand, the US government could just turn on again at a moments notice.
> can't exactly use GPS time for synchronization if you're measuring GPS interference
Can other GNSSes (Galileo/BeiDou/GLONASS/etc) give usable timestamps? Seems like it'd be tricky for a jammer to target all of them simultaneously. (Of course, since they'd be on a different band, unless your SDR is wideband enough you'd need two RX heads which gives you potential issues with phase drift between the tuning VCOs even if your sampling is coherent).
Perhaps a sufficiently directional antenna/phased array (for getting an actual satellite signal) as well as an omnidirectional one (for picking up the jamming signal) could get you somewhere...
Or perhaps one could look at computing AoA at each receiver site (using MIMO-y techniques, e.g. Kraken/KerberosSDR) and triangulating based on angles instead, which wouldn't require synchronizing physically-distant sites at all...
The problem definitely seems soluble, though I don't have the technical background to know how realistic that is.
> Galileo was originally designed to be on an independent frequency, and the US has pushed to have it so close to the US GPS frequency that jamming will effectively kill both.
This (as I wrote in another comment) is the exact opposite of what actually happened [1].
> There are also military specific parts of GPS that civilian receivers can't access. I don't know if military receivers are ignoring civilian signals, though.
For all intents it's a different system, the packets are encrypted, the right receiver hardware gives you vastly superior accuracy. There's civilian hardware which can use the packets without decrypting them for better accuracy, there's some patents on doing this amusingly.
> Any decent GNSS receiver you can purchase in the US will be able to receive all 4 major global constellations. I know this cause I work with them everyday.
All common handset devices used in CONUS (every iphone, android phone, etc) will ignore BeiDou signals. Would love if someone hacked the GNSS firmware to make it usable, but haven't seen it happen yet. If you travel outside the CONUS geofence these signals will show on the device, but FCC has some mandate requesting a block, so it's blocked.
> I find it hard to believe we will ever [...] care what femtosecond an event happened at
GNSS satellites require precise clocks to accurately calculate ranges. Signals travel at the speed of light so small imprecisions result in large errors: timing differences of one millisecond produce about 300 kilometers of error in distance measurements. It seems GPS satellites have clocks accurate to within 40 nanoseconds. One nanosecond gives around 30 cm of error, 40 nanoseconds would give about 12 meters.
Picosecond resolution would bring those errors down to the millimeter and micrometer ranges. Femtosecond resolution would bring the errors down to nanometers.
> You need a precise clock for any form of GNSS[0] to function
How precise? I assume that inaccuracy in the clock produces imprecision in location - how much time inaccuracy produces how much location inaccuracy?
> And anyway, modern GNSS chips are.. $1? Cheaper? No way you wouldn't use GNSS already deployed and working (and you are not paying for it) in a commercial product.
Rather than using the Starlink satellites as an alternative to GPS - get a location fix using both Starlink and GPS, and compare them. Even given the former is going to be significantly less accurate - suppose GPS is accurate to within 5 metres and Starlink is accurate to within 5000 metres - well, if the two differ by 50,000 metres, you know something is going wrong, and the terminal might decide to disable itself in such a situation.
> These can help against GPS spoofing / jamming by identifying false signals
Hrm, it would definitely stop a spoofer from misleading you about what time it is.
If you care about your position: given the fact that GPS satellites are so far away and the signal is so weak, I don't see how it provides any defense against jamming specifically. If you can't hear the satellites, you can't hear them.
Regarding spoofing, it really only defends against spoofed signals emanating from other satellites. This is a big concern for the military. For everybody else "spoofing" means spoofed signals from other land-based or atmospheric transmitters, which once again are close enough to easily drown out the true signal completely.
TL;DR: useful if threat model includes attacker-controlled satellites.
> Is military GPS more accurate than civilian GPS?
> The user range error (URE) of the GPS signals in space is actually the same for the civilian and military GPS services. However, most of today's civilian devices use only one GPS frequency, while military receivers use two.
> Using two GPS frequencies improves accuracy by correcting signal distortions caused by Earth's atmosphere. Dual-frequency GPS equipment is commercially available for civilian use, but its cost and size has limited it to professional applications.
> With augmentation systems, civilian users can actually receive better GPS accuracy than the military.
Is it fully true ? So the only advantages of the military GPS is that the codes are unknown and that it is more jamming proof ?
it did cover large populations centres, as well as major marine shipping and air traffic routes. Another reason why it didn't the coverage wasn't global was a lot of transmitters (e.g., the continents of South America and Africa).
With regards to timing accuracy, a paper fro 1992:
> The accuracy of time comparison by means of the reception of common time signals, namely, LORAN-C and Global Positioning System (GPS), is examined. Differences of UTC from the emission times of these two radio wave signals measured at four Japanese stations and one U.S. station are analyzed and compared with the clock comparison reports published by the Bureau International des Poids et Mesures. The accuracy of the time comparison via LORAN-C signals of the northwest Pacific chain is about 3.61 µs and that via GPS is 0.14 µs. The accuracy analysis reveals the existence of systematic errors at the individual stations. In LORAN-C, the most serious error comes from those in the delay time calibration of receiving instruments and estimation of the propagation delay over land. Calibration of the clocks by a portable clock improves the accuracy of the GPS method to the accuracy of the GPS signals.
> Also, the GNSS software in most phones is sadly unable to accept the correction data from any of these systems, regardless of whether it's a nationwide network or your personal setup. This is purely a software limitation on the vendor GNSS stack, but sadly there is not enough demand for this. (An app will not fix this, we're talking vendor specific low level system code here.)
I don't think that's true. Android surfaces raw GNSS measurements including carrier phase (sub wavelength measurements) to do centimeter level positioning through the raw measurements API [0].
There's even an API to specify the phone antenna phase pattern to correct the carrier phase measurements (source: I implemented it [1]). For those that aren't familiar, the idea is that the antenna pattern on phones isn't perfectly symmetrical, and depending on the direction of the incoming signal, it may appear longer. Knowing the antenna pattern, you can correct for this.
Actually the opposite; GNSS systems are all purposely designed to operate at virtually the same frequency (check out this figure [1]) while cleverly not interfering with each other. There are sub-bands within each constellation too (L1,L2,L5 etc) but it's very easy to pump out wideband noise across all the GNSS bands.
[1] https://www.researchgate.net/figure/The-spectrum-of-current-...
reply