[time-nuts] tube GPS receivers

Magnus Danielson magnus at rubidium.dyndns.org
Sat Jun 22 19:38:30 EDT 2013


On 06/23/2013 12:59 AM, Jim Lux wrote:
> On 6/22/13 3:28 PM, Magnus Danielson wrote:
>> On 06/23/2013 12:04 AM, Jim Lux wrote:
>>> I think that doing the PN code and correlator is something that could be
>>> done with tubes (especially if you didn't want to go P-code).
>>>
>>> I suppose you could use a counter to record the changes in code phase as
>>> you scan for the correlation peak, so that gets you your numeric code
>>> phase.
>>>
>>> Getting doppler as a number for computation might be tricky, but you
>>> could probably solve for the position and clock offset without using
>>> doppler.
>>>
>>> Decoding the nav message at 50bps should be straight forward.
>>
>> All that is relatively trivial... compared to
>>
>>> Hmm. what about implementing the nav calculation as an analog computer.
>>> ANalog multipliers were built using vacuum tubes.
>>
>> You will need more ummpf to do the trigonometry. If you go
>> electromechanical you can do it, but it will be rough estimation
>> regardless. CORDIC was made for these circumstances, to let a weak
>> processing mechanism do navigation processing for airplanes. You could
>> do CORDIC in tubes or relays. Bunch of transistors and diodes could make
>> minor wonders in compactness.
>>
>
>
> electromechanical.. like omega receivers. rotary transformers can do
> very high quality trig functions, but do you actually need trig
> functions assuming you're just solving for X,Y,Z,T.

Oh yes. Check IS-GPS-200F, clause 20.3.3.4.3 User Algorithm for 
Ephemeris Determination, found on page 113 and forward. The Table 20-IV 
contains the actual formulas. The Kepler's Equation for Eccentric 
Anomaly is a bit annoying, since it is not in closed form, so one way or 
another of approximation iteration is needed.

Quite a bit of trigonometry goes on just to have each tracked satellites 
current position estimated, such that the pseudo-range value taken for 
the bird can be diffed out with the position. That process becomes 
trivial if the position is known and only time is needed, given that we 
cranked out the birds X, Y, Z and T position, which requires trigonometry.

> Are you allowed to externally supply the almanac, in the form of a
> electromechanical system. The satellites are in circular orbits and
> fairly stable, and with multiple satellites in the same plane.

You could naturally cheat in several interesting ways, but you need 
fairly accurate X, Y and Z values for the birds at any given time.

> You'd only need trig to convert X,Y,Z into lat/lon, and for us timenuts
> types, do you really need lat/lon? In fact, do you even need to solve
> for earth centered coordinates? Why not work in inertial space (whether
> your receiver happens to be moving in a circle at 1 rev/24 hrs or flying
> in a plane at something else is sort of immaterial)

Once you come to having a X, Y, Z and T, the remaining trig operations 
is trivial to what you already have done, so you might as well do them.

> I envision something with a common shaft running at 1 rev/12 hours that
> drives N rotors (one for each satellite). there's a small motor that
> sets the offset of the rotor relative to the shaft to account for small
> movements along the orbit plane. That, plus some other transformers
> would give you X,Y, and Z for each satellite.

You have a sick mind. What worse is, I understood what you actually meant!

> Actually, how bad would your time estimate be if you just assumed
> perfect circular orbits with no higher order corrections?

Grabbing a modern set of data, doing the calculations with and without 
the proper values would tell you. I would not be surprised if it where 
way over the km off. On the other hand, the precision we talk about in 
general already throws us off sufficiently, so who cares.

One should realize that we talk about tens of Mm numbers in pseudo-range 
distances.

Cheers,
Magnus


More information about the time-nuts mailing list