Improved Galileo Time to First Fix | Hacker News Reader

Improved Galileo Time to First Fix

berthub.eu

77 pointstodsacerdoti14 comments

This takes me back to when I was still in the (Dutch) navy, there was a project to replace the submarines and as part of the upgrade they were planning to replace the old periscope mast with an upgraded optronic system. This was basically a webcam on a pedestal that would quickly go above water, take a 360 degree photograph and then dip below the waves again. This would take mere seconds, minimizing the time that the submarine would be visible. The data could then be analyzed at length while safely underwater.

However, the newer system was so much faster that the GPS antenna mounted on the periscope mast could not get a fix in time. If they wanted a position fix as well as a look around, they would need to leave the mast up much longer. (Submarine navigation is much more difficult than navigation for surface vessels, basically all INS. Getting a GPS fix every now and then is really helpful) By the time I left, it was still an open research question on how they would go about it. IIRC, one of the ideas was to simply collect a wide spectrum recording of whatever could be received and do all the analysis later. This would result in a position fix somewhere in the past, which would then be combined with the data from inertial navigation sensors to get an approximate current location. No idea if that system is what they eventually went with though.

The idea of doing a spectrum recording and having something else process it in non-real time was actually used for Mobile Assisted GPS used to locate mobile phone users ringing emergency services.

Iirc it was a stopgap measure to improve cell tower location without requiring handsets smart enough to process GPS or that didn't have enough time to get a fix. It's briefly mentioned in Wikipedia though details are scant: https://en.m.wikipedia.org/wiki/Radio_resource_location_serv...

I love a good technical explanation like this. I don't plan to implement a Galileo position calculator any time soon, but it's still fascinating all the same to know what's going on behind the scenes.

Let me know if you ever plan to, I'm ready to help :-) (OP)

This fault condition -— a 30 second message where the client regularly needs to wait for a complete retransmit due to temporally-local interference —- seems like the perfect case for fountain codes.

hmm not seeing it yet - this is very low bandwidth but fixed rate stuff, where the messages being broadcast also change from time to time. But I may not be understanding fountain codes well enough - they sure seem interesting!

Suppose you want to receive 100 bits, and you have have a 98% chance of receiving each bit. If the message is broadcast in a loop (and you know which bit you're listening to), chances are after one listen you'll be missing a couple of bits, but on a second listen you'll probably get those; so you'll usually take 200 bit-times to receive the message, with a likely range of 100 - 300, with higher values unlikely. (You can do better by not listening to the full message with the last missing bit; this saves you expected ~33 bit times.) With a fountain code, for some small N you have to receive (and identify) any 100+N bits... so for N = 10, say, you expect to take 112 bit times to receive the full message (100+N+misses), with an expected range of 110 - 115 bit times or so. So both the expected value and the deviation go down.

Nice explanation, thank you. I hope this will surface in oss libs soon.

> the Galileo satellites themselves provide properly equipped receivers (not your phone) with near-realtime updates that can be used to achieve very good accuracy.

I have wondered about that. What stops a mobile phone from benefiting from that and RTK?

Hi! So a phone could well benefit from RTK, but this is a local signal, so you have to pick up something that is relevant for your location. Meanwhile, the High Accuracy Service broadcasts realtime corrections, but it does so on a frequency band that is not supported by phone handsets. Also, the RF conditions in most urban environments are such that I'm not sure such corrections would be received well enough to matter in most cases. Phones are moving to dual frequency chipsets which will also improve accuracy without further help. Hope this helps!

Thanks, it being another frequency makes it clear :)

Getting access to local RTK data isn't much of an issue with projects like https://centipede.fr/ and you can always build your own base staion. I was told multiple times that it couldn't work for phones, without elaborating.

> [...] if an important message is missed or too garbled, we have to wait 30 seconds for the next transmission.

> For this reason, most phones attempt to download the orbit and clock details from the cloud.

Pun intended?

No :-)

I think these calculations are done in some specific part of a SoC (at least on mobile phones). So do you need new hardware to take advantage of these upgrades?

That probably varies. I'm not actually even slightly familiar with the design of these chips. At one extreme, I know you can have a software defined radio (possibly with limited range) and do everything in software. But in practice there will be dedicated hardware for at some things, like acquisition hardware that tries to lock onto a specific satellites prng encoding.

I'm not sure if the position calculations themselves usually use specialized hardware, but I would expect that processing of most data frames is handled by a small embedded processor, simply for flexibility. If the position calculations are done in software, then updating to use this data is probably possible in some designs with just a firmware update. Even if the position calculations are done in hardware, I'd bet the parameters are passed in from the software on the embedded processor, so it sounds like the conversion to the traditional parameter could allow that to be reused, as long as the design does not try to reuse these parameters in other ways which could cause trouble. If it does then the new limited Ephemeris data cannot be used, but the parity data might still be usable to improve time to first fix.

But all of this relies on the SOC supporting upgradable firmware for the embedded processor, that the SOC maker actually develop and provide that new firmware, and that the device manufacturer decides to incorporate that firmware update into a device update.

Reply on news.ycombinator.com