Weren't the original TRANSIT computer (AN/UYK-1) proofed out in vacuum tubes before they were able to build it with transistors?

--
Kenton A. Hoover
kenton@nemersonhoover.org
+1.415.830.5843

On Sunday 23 June 2013 at 14:50, Paul Berger wrote:

Hi

That's a bit past the register sized range, but still a bit small by today's standards.

Bob

On Jun 23, 2013, at 5:50 PM, Paul Berger phb.hfx@gmail.com wrote:

Hi

Switching diodes came along much earlier than transistors. A lot of "tube" logic was actually diode / resistor / tube logic. To fit my (likely bent) definition of "pure tube" you would have to not use solid state switching diodes.

Bob

On Jun 23, 2013, at 6:06 PM, Kenton A. Hoover kenton@nemersonhoover.org wrote:

On 6/23/13 10:47 AM, Chris Albertson wrote:

Lots of rotating drum memory and acoustic delay lines were used back then.

I don't know that the whole GPS thing is very memory intensive anyway.
You've only got a few dozen variables to work with, it's all in the
math, but presumably you'd that as a parallel or pipeline
implementation, rather than a ALU and memory.  It's not like you're
going to be changing the algorithm often (e.g. the programming language
is solder)

The almanac is a bit more of a challenge, but if you allow "externally
supplied" that might make it easier.  But even that isn't all that big,
11 or 12 numbers times 32 or so spacecraft.

Not necessarily.  That is, your redundancy doesn't have to be something
like triple modular redundancy.  You can do more efficient error
correcting codes, use clever arithmetic, or make use of the fact that
your computer can run faster than you need the computation to be done,
so you can get temporal redundancy.  Serial computation can also be
done.  Remember that the nav message is only coming in at 50 bits/second.

On 6/23/13 2:50 PM, Paul Berger wrote:

I was wondering about the Q7.. it was all vacuum tube, but I couldn't
remember whether it used core or not. I didn't ever see it running, but
when I worked at SDC in the late 70s as a relative software newbie, many
of my (older) coworkers had worked on it.

On 6/24/2013 01:44, Jim Lux wrote:

Interesting you should mention this.  One summer job had me working at a
company that made acoustic delay line memories.  Interesting beasties.
You stuck the data in at one end . The output was connected back to the
input to recirculate the data. One wound the magnetic wire in a flat
rectangular box.  A torsional mode was used rather than push/pull.  A
maximum of about 50 milliseconds of memory was possible.  A special near
zero temperature coefficient wire was used as the medium.  One used
either return to zero or non-return to zero data formats. NRZ logic
doubled the memory.  Part of the job involved laying out PCB's by hand
for the electronics.  IC's were just coming on the scene.  RTL logic was
the only thing available.  For military applications "flat packs" were
used.  Through hole IC's were used for everybody else. Interesting that
flat packs disappeared for about 20 years until SMT became the rage.

The company eventually died due to lack of suitable wire and other
memory advances.

Brian

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3199/5936 - Release Date: 06/24/13

Boy, are you bringing back memories and you made me look to see that my
collection of odd old stuff wasn't damaged by the recent flooding we've had.
I know that I have a "64" bit handwired memory board and I couldn't find
that but did stir up a Fabri-Tek board that I think was 64 K but that was an
entirely different generation.  I did get to tour the SAGE system computer
at Madison's Truax Field in 1958.  They had the loudspeaker on so you could
hear the computer work.  A monster pile of vaccuum tubes!

Lee  K9WRU
----- Original Message -----
From: "Jim Lux" jimlux@earthlink.net
To: time-nuts@febo.com
Sent: Sunday, June 23, 2013 7:44 PM
Subject: Re: [time-nuts] tube GPS receivers

Hi

I'm not so sure that "slow" would work. With all the sat's moving various directions all the time, I suspect you need to do a solution fairly quickly. If you don't the stale data messes up the solution. Also you need the correlators to work fast enough to lock on to an essentially unknown code before the sat is out of view.

Bob

On Jun 23, 2013, at 9:44 PM, Jim Lux jimlux@earthlink.net wrote:

On 6/24/13 3:01 PM, Bob Camp wrote:

The sliding correlator is pretty easy, and would lock up quite quickly.
Basically, you need to have a vacuum tube PN generator to generate the
correct Gold/Kasami code for the satellite in question (e.g. you need 32
of those generators). Each generator has a pair of 10 stage shift
registers in it.  I haven't looked in my copy of Millman and Taub, but I
think you could probably build the shift register with 2*N devices
(maybe N tubes, if you use dual triodes/pentodes, what have you).  There
might also be better choices for the tubes that have some form of
latching behavior (thyratrons maybe..)

You slide the correlator until it locks, and then it automatically also
tracks the doppler of that S/V.  I assume you'd use some sort of
early/late tracker rather than a tau dither. I don't know what you'd use
as the VCO, but there is probably some scheme (after all, FM
transmitters existed before the invention of the Varactor solid state
device)

You can track the raw observables (code phase and Doppler) without
needing to do a nav solution at all. And those observables don't change
all that quickly (after all, the Doppler only changes a few kHz during
many hours as the satellite goes from horizon to horizon).

The trick is in how do you get the code phase into your nav algorithm.
It's easy to get a pulse at 1 ms intervals when the code epoch comes by,
but you really want to get a range estimate, and that means figuring out
where you are in the bigger scheme of things. and, then getting that
ingested into whatever computation scheme you're using.

Hi

I believe that if you dig into it, the correlator is either running quite fast (in serial mode) or is pretty large (parallel processing).

Since you know neither the code nor the doppler (no almanac) you are sweeping both the frequency and the code.

The VCO is a bit of a challenge (as mentioned earlier). Prior art was basically a motor driven capacitor. Resolution / backlash / dead band are all obvious issues. Not quite so obvious are dead spots in the capacitor it's self and reversals in the tuning characteristic. It's the ratio of the tuning range to the running accuracy that is the driver.

Bob

On Jun 24, 2013, at 8:40 PM, Jim Lux jimlux@earthlink.net wrote: