[codyd51]

Hi! Yes, "from scratch" is definitely always a bit of a funny term. I also implemented the receiver in Python, which is quite far from "scratch" =). What I mean by it in this context is that I'm taking a piece of hardware that knows nothing about GPS, and just has the ability to sample the EM field, and building up a receiver from there.

Re. slow TTFF, or time-to-first-(position)-fix on older hardware, this essentially stems from advancements in processing power.

Traditionally, GPS receivers would need to download the ‘almanac’ of all the satellites, which takes a minimum of 12.5 minutes (under certain conditions) due to the GPS data transmission format and speed. With modern processing power, though, receivers (including gypsum) can just ‘brute force’ the search space to find the in-view satellites, instead of using the hints downloaded over the air. This is the technique described at the end of Part 1.

[tialaramex]

The fast TTFF on a typical modern device e.g. your phone is because the device has the Internet, and so it can obtain all the information it needs from the Internet up front, it isn't magically brute forcing everything needed, that's not practical at all.

The 12.5 minutes includes a rough multi-week almanac which you could perhaps brute force given available compute and receive capability (original GPS receivers have a single channel receiver and minute compute capability) but they more importantly include the ephemerides, precise data about exactly where the birds are and the atmospheric conditions, replaced hourly by a ground station. You can't "brute force" these - they're parameters measured by someone with objective truth like "I, a massive NASA satellite ground terminal in Florida, am definitely not moving, therefore this GPS bird #14 is 0.08 metres away from where it should be, I will adjust the data for the next hour accordingly".

[codyd51]

Yes, I forgot to mention downloading the orbital parameters over the network! Thanks for mentioning this as well.

In this case, I was meaning to refer to brute-forcing the Doppler-shifts and PRN phases of each satellite, not the orbital parameters themselves. The project in the OP is able to get a position fix in less than a minute because, if the subframe timings are convenient, you can retrieve the necessary ephemeris parameters from the subframes in that span (and down to as little as 18 seconds in ideal conditions, if my back-of-the-napkin is right).

[michaelt]

You don't need to brute force the almanac - why would you?

But it's very much feasible to 'brute force' your initial signal lock by searching for all gold codes at a range of frequency offsets.

And it doesn't take 12.5 minutes to get the ephemerides - the almanac is sent in paginated form which is why it takes so long, the ephemerides are sent more often - they repeat every 30 seconds, and they're enough for a navigation fix.

Although 30 seconds isn't amazing, so cell phones do use their data connection to shortcut that wait.

[aaronax]

Related: Satellite-based augmentation system (SBAS), of which Wide Area Augmentation System (WAAS) is the USA implementation.

https://en.wikipedia.org/wiki/GNSS_augmentation

[Cyph0n]

As an EE grad, I would still consider what you did to be “from scratch”. Yes, the RF side is complex, but for the purposes of GPS, it is also generic enough to abstract out. Nice work.

[AdamJacobMuller]

Please don't take the "from scratch" bit as criticism. It was just amusing trivia :)

Ah, the almanac part I completely forgot about, that makes a lot of sense, I read that part but forgot how it USED to be done when we couldn't just throw cycles at it.