[DSP-10] U7 not locking up

[Doug Bade]

         I had a problem with bad loading and another user suggested (as he 
had found) that the wave forms from the dsp were being severely rounded off 
coming into the latch/registers. I too found this. His suggestion was to 
wire around the bypass caps temporarily and see if it got better... it did. 
( they are a large part of the problem) He then suggested using a buffer to 
buffer the clock line (as I recall) and clean it up and more especially 
square the wave form up.. I speculate the sloping curvature of the leading 
edge was causing the latch/registers to lock up inconsistently and without 
proper data being ready ( because of variations in trigger thresholds)... 
It fixed my problem, and it has been fantastic on loading since then. I 
used a dead bug mounted chip on the radio side of the feedthru caps, and 
inverted twice and all was well..
         In theory, as long as the data was ready first, it should not be 
an issue, but I beleive internal scrambling of the data was occurring 
because rise time was exceeded (inside the register chips) , and/or noise 
on the signal at threshold... again I am speculating, but I did observe it 
and it did correct it with the fix....

         A scope showed a very curved leading edge on the clock signal 
coming through the feed thru's..

         This may have nothing to do with your problem, but it indicates to 
me the pulse quality is borderline after filtering through (at least some) 
feedthru's and might be one of those too close situations where tolerances 
push one way or the other....go or no go...

Hope it helps some anyhow...

Doug KB8GVQ


At 06:56 PM 7/31/2003 -0700, you wrote:
>Hi Mike,
>
>I rechecked all the corrections thru rev 4.5 and everything looks OK. The
>voltage on U6-3 is 2.47V. I built my unit from a TAPR kit, no parts
>substitutions. When I load the PLL diagnostic program I see data moving on
>U7-5&7 and pin 6 goes low for awhile. It appears that the wrong data is
>being loaded. I just got another email from Chuck, WA6EXV, and he is still
>having the same problem. He tried changing the MC145170 but that did not
>help. Any more ideas?
>Thanks for the quick response.
>73's Larry  K6HLH