How do you think the 'instantaneous time-of-flight' computation is done?
There's a lot of math that phrase is hiding. It's not a magic black box. It just often seems that way.
There's a lot of math that phrase is hiding. It's not a magic black box. It just often seems that way.
Your point stands, though... the way it does work is pretty much indistinguishable from magic, from a 1970s perspective. Those guys were wizards.
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).
[0]https://books.google.com/books/about/Surveying_theory_and_pr...
[1]https://books.google.com/books?id=J0fLBQAAQBAJ&pg=PA63&sourc...
[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.
Edit: this article seems to support my view that they don't start with velocities: https://insidegnss.com/wp-content/uploads/2018/01/marapr15-S... "How does a GNSS receiver estimate velocity?"
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.