At the end he casually mentions so many things that he could also talk about, including that apparently the encryption on GLONASS military signals was already hacked, and that many parts of the mil-spec GPS are "securiy through obscurity"... Is this true? If so, where can I find more reading material about this? It was my understanding that the P(Y) code in GPS is encrypted using (basically) a OTP, and not based on obscurity at all? Doesn't GLONASS use a similar system?
Sometimes the interference seen on those maps does affect phones, sometimes it doesn't.
Coincidentally there's a huge region of GPS (at least) interference this week over the New Mexico area, from a military test. My guess is that people on the ground won't be affected, unless maybe they're very close to White Sands Missile Range between 18:30 and 22:30 GMT. See https://twitter.com/lemonodor/status/1611812892969664515 for more info.
If you're wondering what this is, a succinct summary from the projects about page [0]:
"The internet and the availability of stunningly capable chipsets has made it possible to create a monitoring network that spans the world & successfully receives almost every bit transmitted by the close to 100 navigation satellites currently in orbit."
Maybe clarify the above sentence with "an enthusiast-run, open source navsat monitoring network" and perhaps it sums up the project well AFAIUI.
Thank you for summarizing! I think you just saved me and probably many other readers a ton of time, or if we were just going to move on, you provided a good reason to read on.
Yeah, phones seem to have really good GPS receivers, even when you turn off all the network assists. Even with their tiny antennas they're at least comparable and sometimes better than my expensive uBlox GPS with a large active antenna.
On a staggeringly smaller scale I had VERY mixed results with storing data points that look like (satellite ID, timestamp, el, az, signal strength) and then doing a data analysis to map out "anomalous attenuation" by el,az (kind of a bistatic radar display).
"Everyone knows" since day 1 of GPS back in the 80s that tree leaves and rain storms ruin GPS reception, but rather than complaining about it and/or avoiding it, why not use it as a data source?
Turns out I had trouble pulling a useful signal out of the noise. Maybe with a lot more data or a lot more RX running in parallel or ... There are of course inherent limits as discovered by Air Forces over the decades where bistatic radar works best directly overhead whereas I was interested in "storm clouds on the horizon" exactly where it didn't work.
I had some optimistic imagination in that if heavy rain causes 30 dB of attenuation, then extreme data analysis might indicate something as trivial as cloud cover, or even fog, might cause 0.01 dB of attenuation and I could map out regular non-rain clouds or something. That data could not be pulled out of the noise.
Very optimistically, if I placed antennas on corners of my property, I could "edge detect" even if the signal level varied randomly-ish by comparing the multiple RX and doing some trig. I live close enough to an airport that occasionally a plane should be between me and a satellite. That did not work either.
Anyway, the linked distributed project is my merely a thousand times larger than my playing around experiment.
Galmon reveals fun stuff including the horizon around each receiver. I don't have the link handy, but one of the contributors was plotting "where in the sky a given receiver has ever seen a satellite", and it's plain to see which ones are next to mountains and stuff, because the outline of the mountains is vividly traced on the horizon.
However, that's all long-term stuff. Moment to moment, GNSS receivers try very hard to mask momentary blips in data. I think you'd need to be down at the RF/baseband level to see the stuff you're trying to see, rather than taking "cooked" data from the receivers.
The SDR GPS receiver in the KiwiSDR may be a good start.
So, not this data exactly but broadly similar data (Japanese publications of differential GPS corrections) have been used to spot North Korean missile launches in the open source world.
has more info on that. Essentially the corrections for each satellite can give you a map of what the ionosphere looks like, and so having more satellites is better. If there were publicly available dGPS- or dGLONASS/dBeiDou etc. archives available in other countries it would make this even more useful. If China or Russia published these it would be very useful indeed for triangulating the flight path through the ionosphere.
ISTR the genesis of the project was a days-long Galileo outage, back when it was in "testing but probably usable" phase, and a stark lack of transparency or updates from the folks running the network.
But it's not exactly hidden, you can infer quite a lot of things about the satellite status, if you just listen to what they're telling you. The trouble is, they're all over and moving fast, so you need a lot of friends with receivers to feed you the data, then you can put together a picture of the constellation health.
Ergo, Galmon.
Since then, it's turned out that a bit of sunlight on the operation of all four GNSS constellations, not just Galileo, has revealed quite a lot about their inner workings, availability, and health of individual satellites.
One bird in particular was launched into a wrong-but-not-useless orbit by a rocket failure that juuuuust barely got it up there but didn't finish the job. Trouble is, most receiver software assumes the orbits are very nearly circular, and a highly elliptical orbit is both problematic if used for general navigation, and a useful source for testing more robust receiver software that can compensate for it. (Maybe the software wasn't correcting for other satellites' slight ellipsity as well as it could either.) So Galmon provides a view of that satellite's status as observed by receivers all over.
My understanding is that the Blitzortung GPS receiver is the cheapest they could find that provides a good timepulse output, and does not produce the raw packet data dumps that Galmon is interested in.
There might be an alternate firmware for it, or there might be a drop-in upgrade from another model in the series, but at that point you might as well just get a real F9P and make it a separate project sitting on the same shelf.
To one sig fig that's 55 feet difference in location. GPS uses WGS84 and GLONASS uses PZ90. "Officially" the difference is supposed to be less than 45 feet all the time and generally less than 15 feet. So, I don't think that's the problem.
There seem to be issues with stepping time, and long term alignment seems to be deprioritized over short term quality. Better to have better data today than to have better long term drift over a decade. So all the systems kind of "free run" very close to each other but measurably different. It does not seem that very long term drift adjustment was baked into the cake of any nav protocol, probably because its not navigationally useful.
That time is hard, I think. So the network itself has needs, you can't just shift all clocks by 55 ns. So instead, an offset is broadcast that tells you what you need to subtract/add to get to UTC.
I'm one of the feeds. My window has a high bias to west facing so I only provide partial sky coverage for my region. That said, the whole point here would be not to have single actor dependency. Obviously selective coverage could be turned on but I think blatant misreporting would be apparent.
I compiled the git source on my own pi. Bert knows who I am.
Hi! Galmon guy here. This has only once been a problem, someone with a modified firmware, and that produced some exceedingly strange data. In the galmon design, which is quite neat if I say so myself, data is stored per source. If any data is bad, we can throw it out. If someone would really want to mess with us they could of course. But we're probably niche enough that people don't bother.
Are there even any chipsets out there that can receive IRNSS? I don't think the very common u-blox ones can. It seems like only some Qualcom 4G/5G chipsets support it, which are probably difficult to get on a hacker-friendly add-on board, especially outside India?
Digikey lists that module (which is not much different in size/shape from the U-Blox modules) at 675$, so I'm not sure this puts it in the cheap/hobbyist range ...
https://news.ycombinator.com/item?id=21067915
Nice talk about the project by the maker:
https://media.ccc.de/v/mch2022-17-how-do-gps-galileo-really-...
Link to html but ultimately a 49min video
Very interesting, because it is not just the usual gps talk