Galmon – Galileo/GPS/GLONASS/BeiDou open source monitoring

Interesting talk.

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?

Thanks for the talk, I enjoyed watching that

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.

I would probably have used the first because it would not have occurred to me I could use the second.

FWIW the following prints 1, so it's probably a matter of taste:

    int main() {
        printf("%d\n", 3.986004418e14 == 3.986004418 * pow(10.0, 14.0));
    }

I prefer the second one for sure.

> It's odd to me that most devices support/trust GLONASS which shouldn't be trusted while not (yet?) supporting/trusting Beidou

Russia requires GLONASS support, so a worldphone needs it. China requires a lot of things, so a worldphone isn't going to work anyway.

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.

Hadn't heard of GPSTest before, thanks!

Annnnd there goes another app into my 'toys for waiting in lines' folder.

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.

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.

https://www.armscontrolwonk.com/archive/1216884/detecting-mi...

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.