[DSP-10] U7 not locking up

Luis Cupido [email protected]
Fri, 1 Aug 2003 16:22:33 +0100


Cosmetics maybe, but whatever I did to solve the problem
that did not straighten up the signal to 'digital-looking' signals
I did not like too much... hence the inverters !
That was the 'emotional' motivation to do it clean.
Hope you all can understand this cosmetic concern about my beloved DSP-10

:)))

Luis Cupido.
CT1DMK.



----- Original Message ----- 
From: "kd7ts" <[email protected]>
To: <[email protected]>
Sent: Friday, August 01, 2003 4:03 PM
Subject: Re: [DSP-10] U7 not locking up


> Hi Doug, et al
> 
> This sounds very likely. The original QST product
> had a problem with the timing of the clock leading
> edge due to the delay through the register chips
> (595's). This was causing one PLL to be looking
> for data too ( soon ?? late ??). Whatever, it
> caused problems. 
> 
> The 19.68 KHz oscillator register is only loaded
> once when the program (UHF3.EXE) is loaded. It is
> never looked at again. 
> 
> All the diagnostics seem to do well with the LMX
> chip and the registers, but don't give a lot of
> help with the 145170, except to monitor the lock
> signal. 
> 
> The first "cure" was to bypass the box wall
> feedthroughs on the DSP enclosure. This allowed
> operation, but loading was still flakey. The
> change that made it all work correctly was
> changing R108. 
> 
> following is lifted from E-MAIL from Bob, W7PUA,
> which explains the situation.
> 
> Subject:         Got it
>    Date:         Tue, 30 Nov 1999 00:35:54 -0800
>    From:         Bob Larkin <[email protected]>
>      To:         [email protected]
>     CC:          [email protected]
> 
> 
> 
> 
> OK, it really wasn't as dumb as all that! Here is
> what is happening:
> When there are cascaded shift registers, like
> U108, U107 and U104, the data coming out of the
> end of one of them, like U107-9, does not line up
> with the data going in, shifted 16 clock pulses. 
> Instead it just barely comes after the rise in the
> clock pulse---only by perhaps 30 nanosec. This
> works great as long as all the devices agree about
> where on the clock pulse to trigger.
> 
> Unfortunately, some of the U104's must have been
> tending to trigger higher on the clock pulse than
> was U107. And they must not all be quite the same
> (or the U107's quite the same). If U104's clock
> input was to trigger
> below the point where U107 does (like my original
> one), you can delay the clock pulse or increase
> it's rise time almost without limit. But if U104
> triggers at a higher point than U107 (like
> Ernie's,) you can't tolerate any rise time at all.
> 
> The enable pulse is not involved in this at all,
> as it comes much later than the last clock pulse.
> 
> The solution: Delay the data going to U104 by a
> few hundred nanoseconds to be sure the new data is
> not seen at clock time (It is the data to be used
> by the NEXT clock pulse). This is pretty
> easy---Change R108 from 470 to
> 4700 Ohms, while leaving R107 at 470. After I did
> that my second board became as easy to get along
> with as the first one. Try it and see if it
> doesn't work. Then you should be able to have the
> FT's in the EZ-Kit box.  Or at least I sure hope
> so!!!
> 
> Also no software change is needed on any of the
> programs.
> 
> 73, Bob
> 
> -------------------------------
> 
> Rise time and pulse shape  are all part of TIMING.
> 
> It might be that changing R108 to an even higher
> value would move the timing enough. I'm guessing
> here, so don't take this as coming from any great
> authority. 
> 
> The buffer seems to do the job, but maybe it is
> worth trying a resistor change.
> 
> Mike KD7TS
> _______________________________________________
> DSP-10 mailing list
> [email protected]
> http://mailman.qth.net/mailman/listinfo/dsp-10