navigation math

The search term is LORAN. I think the last ones were decommissioned years ago - replaced by GPS.

Yes. If you know the delta between the distances to two known locations, that places you on a hyperbola whose focii are those two known points. Plot the hyperbola on your map.

Repat for the other two pairs of points. Hopefully there's one point where all three intersect.

You can do it analytically instead of graphically if you want:

Actually coastal navigational maps had/have those LORAN hyperbolas printed on them. So all you really had to do was read the delta value off the receiver, and then interpolate between two lines with dividers... rinse, repeat.

Modern LORAN receivers know where the transmitters are, do all the math internally, and just show you longitude/lattitude or display a map just like a GPS receiver.

--
Grant

You will be dealing with families of "concentric" hyperbolae (as the equation for a hyperbola involves maintaining a constant difference between lengths of vectors to foci).

LORAN was renowned for using this -- on a global scale. It has since been decommissioned in the wild but there's an abundance of information regarding its use and deployment.

Note, however, that there are many subtleties buried in the LORAN implementation that make it differ from a theoretical approach. E.g., there are intentional delays introduced to make the numbers cleaner.

If you are truly looking to navigate on a *large* scale (hundreds of miles), then you will have to consider things like changes in propagation delays over different types of terrain and the "shape" of that terrain (e.g., the Earth is an oblate sphere). Again, LORAN has these covered but you'll have to dig for details.

Similar problems exist "in the small" for position resolution within a structure! (I use similar technology to determine where, in an "arena" -- home or office, in my case -- the user is sited)

[If you look at a preprinted maritime map augmented with LORAN "lines of constant time difference", you'd see that they differ from what you would otherwise expect from a more naive mathematical/geometric treatment]

See if this helps:

The word to look for is multilateration. Wikipedia has an article on it:

Calculating the time differences based on a known position is relatively simple. Once you try to solve the equations to go the other way, the math gets ugly.

Years ago, when I was playing with this, I resorted to a numerical solution.

--
RoRo

Thanks Dennis. That points me in the right direction.

Hul

Dennis wrote:

Thanks Grant - that's whats needed.

Hul

Grant Edwards wrote:

Don - At this point just the basics are of need, but the various subleties are worth looking at. Thanks.

Hul

D> > Anyone know the method for calculating a reciever's position from the time

Thanks Paul, I'll take a look.

Hul

Paul Rub> > Anyone know the method for calculating a reciever's position from

As folks depended on LORAN for their livelihood (no way to easily and reliably locate a particular spot in the middle of the ocean), a lot of effort was expended to make it as useful and useable as possible -- for "average joes".

And, the technology required in the receiver was very low (think

1970's and earlier). We didn't start putting MPUs into receivers until the late 70's. And, converting between TD & lat-lon wasn't practical -- in real time -- until the same time frame! Folks would talk in terms of TDs, not lat-lons!

A few important implementation issues to consider. Because LORAN was designed so the Master drove the timing of its chain, there was less need for all stations to share a common sense of time. When each Slave received the Master's transmission (which would occur at different ABSOLUTE times because the propagation delays from Master to each Slave would differ based on geographical distance, etc.), it would initiate its own "local" transmission timing sequence (Slaves didn't immediately emit their beacons but waited for a specific coding delay). So, the RATE of time progressing was important to each Slave -- but not the *actual* time (of day).

In addition to having the Slaves' transmissions sync'd to the arrival of the Master's beacon, the time between Master transmissions was fixed -- Group Repetition Interval (GRI). So, a receiver could find a particular chain's transmissions by looking for this GRI (in the time domain).

Also, a station could act as Master for one chain -- and (a) Slave in another. Running the chains at different GRIs allowed their transmissions (and time differences) to be sorted out remotely.

For example, the 9960 (99600 microseconds between Master transmissions) chain had a station on Nantucket Island (SSE of Massachusetts). As this is a prime area for maritime traffic (servicing NYC, Boston, Maine, etc.), it was heavily used.

Note the geometry of the "lines of constant time-difference" ("grid lines") near Nantucket (for that LORAN chain): Notice how common it is to have *two* locations which resolve to the same pair of TDs? For example, the brown "80" (13880 microseconds) crosses the green 6060 (6060 microseconds time difference) almost within

*sight* of each other (an exaggeration as horizon is about 4 miles).

Note, also, how the spacing between grid lines varies? E.g., along the baseline (the dashed line connecting slave to master) the distance between lines is at its minimum.

So, a given change in time difference (delta-TD) correlates to the smallest physical distance (greatest positional resolution). As one moves off of this baseline, the distance between grid lines increases (lower positional resolution). Remember, you're *measuring* time-differences so you want a unit of TD to represent the smallest physical distance.

Likewise, note how the angle between grid lines from different secondaries (slaves) varies. In some cases, they are close to "normal"; in others, they cross at very shallow angles. (Geometric Dilution of Precision -- GDoP).

(Amusingly, you can also see how the LORAN overlay isn't perfectly aligned with the mercator projection overlayed!)

In addition to the "basics", there are lots of subtle details in LORAN that made it usable even in really poor conditions. E.g., the "pulses" sent by the Master and Slaves were actually pulse *trains* and could encode information. Additionally, as each individual pulse was a burst of carrier in a tightly controlled envelope, the receiver could easily identify and track a specific portion of that burst (IIRC, third positive zero-crossing). And, could be told to track a different portion -- with a corresponding fixed temporal offset in the TD displayed for that Secondary.

*Lots* of design detail that was impressive for its time! Cherry-pick the aspects of the design that are most appropriate for your application.

The US Coast Guard published a great reference on LORAN (decades ago). I'm too lazy to hunt for it in my collection... :<