[DSP-10] U7 not locking up

[Doug Bade]

I had also tried the resistor value correction too, and while I had the 
original dsp board it worked most of the time as long as I did not do long 
sustained freq ramping.... It would still flake out once in a while but was 
pretty stable.. THEN I changed to the new DSP board (KDSP-10) and it 
started all over again...... no lock no op 99% of the time...
         I then investigated  Luis CT1DMK's suggestions and it fixed it all 
right up. His code change would have worked with using the one spare 
inverter on the board, except I was using KDSP code, so it would need to be 
fixed too... My dead bug solution was, while not pretty, very effective in 
solving the problem, and I have not seen it since...


Doug KB8GVQ


At 08:03 AM 8/1/2003 -0700, you wrote:
>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 <boblark@proaxis.com>
>      To:         mreed4@uswest.net
>     CC:          beblark@aol.com
>
>
>
>
>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
>DSP-10@mailman.qth.net
>http://mailman.qth.net/mailman/listinfo/dsp-10