Isn't it about finding the time difference between pseudorandom coded signals. Granted the satellite positions and paths need to be known, which is another part of the puzzle. That involves some calculus, I'm sure.
Yes but measuring diffs in either the pseudocode itself or the underlying carrier wave is basically measuring relative velocities wrt each sat and the observer.
It's all summing dx/dt + dy/dt + dz/dt, for i paths between satellites and ground stations (or more receivers for differential or rtk or vrs style). [2]
Which reduces most of the time to summing DELTA-Xi + DELTA-Yi + DELTA-Zi + delta-t(timeerrors). For i paths between each sat and ground receiver.
Which you should recognize the transformation if you've ever taken calculus. Even if you don't integrate every time you get a fix.
Part of what I describe as math 'magic' is that you can cancel out most of the unknowns and most of the unsolved calculus if you add a second fixed receiver.
Google and Apple location services 'cheat' and do this via subbing a nearby wifi MAC with known coordinates, which for them is good-enough. But augmented gps from FAA or DOT or coastguard etc work the same way, but with real gps receivers on the ground in realtime. Obviously without having to substitute anything.
Either way- the extra known variable greatly simplifies the math via canceling-out terms.
Plus there are both closed and open form solutions developed since initial GPS deployment that allow solving without direct integration.
Chapter 12 of [0] Surveying gets into the math, including transformations, if you want to see the math details.
Or [1] GPS by van Sickle for a good overview of the various methods/ technologies. (Also survey-centric).
[2] despite wgs84 and lat/lon being associated as default 'GPS coordinates', the 'raw' gps system data is xyz Cartesian in feet, then transformed to lat lon or whatever else.
My assumption was that GPS doesn't use dead reckoning to get a fix (other than the satellite paths). Do receivers use the Doppler effect to directly measure velocity?
Dead reckoning isn't really the right term- there are broadcast and published ephemera (ephemeris-es) for the satellites of various qualities. (Both predicted and observed and then even levels of correction days or weeks later, for high precision/accuracy or strictly static obvs. stuff.)
The doppler mostly comes into play with the small delta-t errors, but again, more math magic cancels most of it out in most cases, or what remains is negligible.
It's more of a signals/sync thing that gets into antenna design and (to simplify) getting all signal cycles from the various satellites working within a single aligned synced cycle, if that makes sense.
One reason the old gps units needed a long time to get an initial fix was waiting to download the broadcast, in ~bits/sec. This can now be downloaded much quicker via internet or other methods.
And there are dozens of other similar shortcuts possible depending on receiver capabilities/ connectivity/ observervation methods.
Which is to say that there's no one 'right' way to get a fix- and the 'most' correct original design was the ~hour long broadcast download. And no one does that anymore.
But just about every method (I'm aware of) is derived one way or another from the general eqns I gave above.
(But my exposure is almost entirely geodesy, engineering, and surveying, and my military (encrypted) knowledge comes from my PLS instructor being ex army intelligence, not hands on. But which is also why I am at least aware of so much of the missile tie-in issues.)
And there are signals processing and CS tricks also, which I only barely grasp.
But if something says it starts with baseline (propagating signal path) lengths to get position, it's skipping the step of how it measures/ estimates those initial baseline lengths.
But it's based on the same idea, only getting position as a derivative of velocity. (And some borderline-magic statistics applied.)
And that's before taking into account the absurdity of how low power the broadcast signal is.