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 <[email protected]> wrote: > On 6/24/13 3:01 PM, Bob Camp wrote: >> 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. >> > 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. > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
