JL
Jim Lux
Sat, Jun 22, 2013 10:04 PM
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.
Hmm. what about implementing the nav calculation as an analog computer.
ANalog multipliers were built using vacuum tubes.
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.
Hmm. what about implementing the nav calculation as an analog computer.
ANalog multipliers were built using vacuum tubes.
MD
Magnus Danielson
Sat, Jun 22, 2013 10:28 PM
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.
Cheers,
Magnus
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.
Cheers,
Magnus
JL
Jim Lux
Sat, Jun 22, 2013 10:59 PM
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.
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'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)
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.
Actually, how bad would your time estimate be if you just assumed
perfect circular orbits with no higher order corrections?
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.
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'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)
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.
Actually, how bad would your time estimate be if you just assumed
perfect circular orbits with no higher order corrections?
MD
Magnus Danielson
Sat, Jun 22, 2013 11:38 PM
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
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
BC
Bob Camp
Sat, Jun 22, 2013 11:43 PM
Hi
If you are talking about a "tube only" design ( = no solid state diodes) - I doubt you can get a navigation fix (download the almanac etc) before you hit the mean time to failure of the gizmo.That's based on the published remembrances of those who ran them. All of the tube based computers I've worked with were solid state diode / vacuum tube amp designs.
Bob
On Jun 22, 2013, at 7:38 PM, Magnus Danielson magnus@rubidium.dyndns.org wrote:
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
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
If you are talking about a "tube only" design ( = no solid state diodes) - I doubt you can get a navigation fix (download the almanac etc) before you hit the mean time to failure of the gizmo.That's based on the published remembrances of those who ran them. All of the tube based computers I've worked with were solid state diode / vacuum tube amp designs.
Bob
On Jun 22, 2013, at 7:38 PM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote:
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
JL
Jim Lux
Sat, Jun 22, 2013 11:52 PM
On 6/22/13 4:38 PM, Magnus Danielson wrote:
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.
Yes, but that trig can be done VERY slowly, since the cycle time is 12
hours, which is why a resolver/rotary transformer approach seems viable.
(rather, than, say, integrating the satellite state vector)
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.
How accurate?? Resolvers are good to about 16 bit accuracy, so I guess
1 part in 60,000. if the orbit circumference is 163 Mm, then a resolver
can determine the position to a few km.
However, I don't know that that is good enough. If you need to know to
1 chip at C/A code rates, 1 microsecond, that's a pretty small fraction
of one 12 hour rev of 43200 seconds. But maybe not.
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.
So I think you probably can't get a position fix within 10km, but hey,
what a beast it would be.
On 6/22/13 4:38 PM, Magnus Danielson wrote:
>>
>> 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.
Yes, but that trig can be done VERY slowly, since the cycle time is 12
hours, which is why a resolver/rotary transformer approach seems viable.
(rather, than, say, integrating the satellite state vector)
>
>> 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.
How accurate?? Resolvers are good to about 16 bit accuracy, so I guess
1 part in 60,000. if the orbit circumference is 163 Mm, then a resolver
can determine the position to a few km.
However, I don't know that that is good enough. If you need to know to
1 chip at C/A code rates, 1 microsecond, that's a pretty small fraction
of one 12 hour rev of 43200 seconds. But maybe not.
>
>> 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.
>
So I think you probably can't get a position fix within 10km, but hey,
what a beast it would be.
> Cheers,
> Magnus
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
BC
Bob Camp
Sun, Jun 23, 2013 12:06 AM
Hi
Well if the chip rate is at or above 1 MHz, a wavelength is 300 meters or less. A 1 KM error is probably a bit to large.
Bob
On Jun 22, 2013, at 7:52 PM, Jim Lux jimlux@earthlink.net wrote:
On 6/22/13 4:38 PM, Magnus Danielson wrote:
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.
Yes, but that trig can be done VERY slowly, since the cycle time is 12 hours, which is why a resolver/rotary transformer approach seems viable.
(rather, than, say, integrating the satellite state vector)
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.
How accurate?? Resolvers are good to about 16 bit accuracy, so I guess 1 part in 60,000. if the orbit circumference is 163 Mm, then a resolver can determine the position to a few km.
However, I don't know that that is good enough. If you need to know to 1 chip at C/A code rates, 1 microsecond, that's a pretty small fraction of one 12 hour rev of 43200 seconds. But maybe not.
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.
So I think you probably can't get a position fix within 10km, but hey, what a beast it would be.
Hi
Well if the chip rate is at or above 1 MHz, a wavelength is 300 meters or less. A 1 KM error is probably a bit to large.
Bob
On Jun 22, 2013, at 7:52 PM, Jim Lux <jimlux@earthlink.net> wrote:
> On 6/22/13 4:38 PM, Magnus Danielson wrote:
>
>>>
>>> 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.
>
> Yes, but that trig can be done VERY slowly, since the cycle time is 12 hours, which is why a resolver/rotary transformer approach seems viable.
>
> (rather, than, say, integrating the satellite state vector)
>
>
>>
>>> 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.
>
>
> How accurate?? Resolvers are good to about 16 bit accuracy, so I guess 1 part in 60,000. if the orbit circumference is 163 Mm, then a resolver can determine the position to a few km.
> However, I don't know that that is good enough. If you need to know to 1 chip at C/A code rates, 1 microsecond, that's a pretty small fraction of one 12 hour rev of 43200 seconds. But maybe not.
>
>
>
>>
>>> 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.
>>
>
> So I think you probably can't get a position fix within 10km, but hey, what a beast it would be.
>
>
>
>
>> Cheers,
>> Magnus
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
MD
Magnus Danielson
Sun, Jun 23, 2013 12:13 AM
On 06/23/2013 01:52 AM, Jim Lux wrote:
On 6/22/13 4:38 PM, Magnus Danielson wrote:
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.
Yes, but that trig can be done VERY slowly, since the cycle time is 12
hours, which is why a resolver/rotary transformer approach seems viable.
(rather, than, say, integrating the satellite state vector)
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.
How accurate?? Resolvers are good to about 16 bit accuracy, so I guess 1
part in 60,000. if the orbit circumference is 163 Mm, then a resolver
can determine the position to a few km.
However, I don't know that that is good enough. If you need to know to 1
chip at C/A code rates, 1 microsecond, that's a pretty small fraction of
one 12 hour rev of 43200 seconds. But maybe not.
Hmm. You could tabulate it even. It would be quite a bit of core-memory,
but achieveable.
Oh, and it isn't full 43200 s, it's only about 11 hours and 58 min.
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.
So I think you probably can't get a position fix within 10km, but hey,
what a beast it would be.
Oh yes.
With a RAIM algorithm you could use extra channels to overcome
deficiencies in the crudeness of the calculations.
Would be neat if there would be a PLL steering of the revolving calender
to maintain with minimum error. The T error would be a natural detector
to use. Extra grade if individual birds got adjusted.
Cheers,
Magnus
On 06/23/2013 01:52 AM, Jim Lux wrote:
> On 6/22/13 4:38 PM, Magnus Danielson wrote:
>
>>>
>>> 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.
>
> Yes, but that trig can be done VERY slowly, since the cycle time is 12
> hours, which is why a resolver/rotary transformer approach seems viable.
>
> (rather, than, say, integrating the satellite state vector)
Indeed.
>>
>>> 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.
>
>
> How accurate?? Resolvers are good to about 16 bit accuracy, so I guess 1
> part in 60,000. if the orbit circumference is 163 Mm, then a resolver
> can determine the position to a few km.
> However, I don't know that that is good enough. If you need to know to 1
> chip at C/A code rates, 1 microsecond, that's a pretty small fraction of
> one 12 hour rev of 43200 seconds. But maybe not.
Hmm. You could tabulate it even. It would be quite a bit of core-memory,
but achieveable.
Oh, and it isn't full 43200 s, it's only about 11 hours and 58 min.
>>> 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.
>>
>
> So I think you probably can't get a position fix within 10km, but hey,
> what a beast it would be.
Oh yes.
With a RAIM algorithm you could use extra channels to overcome
deficiencies in the crudeness of the calculations.
Would be neat if there would be a PLL steering of the revolving calender
to maintain with minimum error. The T error would be a natural detector
to use. Extra grade if individual birds got adjusted.
Cheers,
Magnus
MD
Magnus Danielson
Sun, Jun 23, 2013 12:20 AM
Hi Bob,
On 06/23/2013 02:06 AM, Bob Camp wrote:
Hi
Well if the chip rate is at or above 1 MHz, a wavelength is 300 meters or less. A 1 KM error is probably a bit to large.
A tube-channel to keep tracking within a chip does not seem too hard.
Utilizing that precision for the rest of the calculation is a challenge.
Each channel would naturally have their own 1.023 MHz crystal
oscillator, tweaked by the feedback loop control. That part would be
pretty straight-forward. There also needs to be a carrier oscillator for
final carrier removal.
Doing this beast in transistors would be enough challenge and a good
exercise in itself.
Cheers,
Magnus
Hi Bob,
On 06/23/2013 02:06 AM, Bob Camp wrote:
> Hi
>
> Well if the chip rate is at or above 1 MHz, a wavelength is 300 meters or less. A 1 KM error is probably a bit to large.
A tube-channel to keep tracking within a chip does not seem too hard.
Utilizing that precision for the rest of the calculation is a challenge.
Each channel would naturally have their own 1.023 MHz crystal
oscillator, tweaked by the feedback loop control. That part would be
pretty straight-forward. There also needs to be a carrier oscillator for
final carrier removal.
Doing this beast in transistors would be enough challenge and a good
exercise in itself.
Cheers,
Magnus
BC
Bob Camp
Sun, Jun 23, 2013 12:35 AM
Hi
How stable a 1.023 oscillator? How much pull range on that oscillator? Hmmmm…..
Bob
On Jun 22, 2013, at 8:20 PM, Magnus Danielson magnus@rubidium.dyndns.org wrote:
Hi Bob,
On 06/23/2013 02:06 AM, Bob Camp wrote:
Hi
Well if the chip rate is at or above 1 MHz, a wavelength is 300 meters or less. A 1 KM error is probably a bit to large.
A tube-channel to keep tracking within a chip does not seem too hard. Utilizing that precision for the rest of the calculation is a challenge.
Each channel would naturally have their own 1.023 MHz crystal oscillator, tweaked by the feedback loop control. That part would be pretty straight-forward. There also needs to be a carrier oscillator for final carrier removal.
Doing this beast in transistors would be enough challenge and a good exercise in itself.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi
How stable a 1.023 oscillator? How much pull range on that oscillator? Hmmmm…..
Bob
On Jun 22, 2013, at 8:20 PM, Magnus Danielson <magnus@rubidium.dyndns.org> wrote:
> Hi Bob,
>
> On 06/23/2013 02:06 AM, Bob Camp wrote:
>> Hi
>>
>> Well if the chip rate is at or above 1 MHz, a wavelength is 300 meters or less. A 1 KM error is probably a bit to large.
>
> A tube-channel to keep tracking within a chip does not seem too hard. Utilizing that precision for the rest of the calculation is a challenge.
>
> Each channel would naturally have their own 1.023 MHz crystal oscillator, tweaked by the feedback loop control. That part would be pretty straight-forward. There also needs to be a carrier oscillator for final carrier removal.
>
> Doing this beast in transistors would be enough challenge and a good exercise in itself.
>
> Cheers,
> Magnus
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
