Electronics > Repair

Series defect on agilent 167xx boards?

<< < (17/50) > >>

DogP:
Thanks a TON for that info.  I'll dig into this more tonight... hopefully I can track this down.


--- Quote from: MarkL on February 06, 2022, 10:55:18 pm ---I've had more than one 16533A/16534A with way out of spec voltages because of resistors in the regulator's feedback network that had gone bad.  In a couple of cases it caused erratic behavior (like would pass calibration only some of the time).

--- End quote ---
I decided to take another look at the scope card... today, it seems to be consistently passing the FISO test, but failing everything else.  What kind of tolerance on these voltages is OK?  I pulled the bottom off the chassis and checked the voltages... at the regulator outputs I'm getting:
+6V = +6.11V
-6V = -6.19V
+7.3V = +7.31V
-2V = -2.12V
+2V = +1.84V

So... not TOO far off, but not dead-on, if that matters.

I did find several vias that looked pretty bad.  The two in the first picture look like they go to GND, and I still get continuity from the top to GND, so I'm not too worried about those.  I'm not sure about the other two... the one goes from the outer layer to an inner layer, and the other goes from an inner layer to another inner layer.  So I don't know where they're supposed to go, nor whether they're actually getting there.

Is there a way to get better debugging info from the oscilloscope self-test?  Even with d=9 r=9, I only get verbose output from testTrigger.  I assume the third number is the return code... are those meanings defined anywhere?:

--- Code: ---pv> x modtests
Mod   C: TEST passed       # "testFISO" (1, 0, 1)
Mod   C: TEST NOT EXECUTED # "testADC" (0, 0, 0)
Mod   C: TEST FAILED       # "testDAC" (1, 1, -3)
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Holdoff
Fail Holdoff
Mod   C: TEST FAILED       # "testTrigger" (1, 1, -2047)
Mod   C: TEST FAILED       # "testTimebase" (1, 1, -3)
Mod   C: TEST FAILED       # "testIMB" (1, 1, -1)
pv> x testADC

1.  Disconnect all stimulus from Channels 1 and 2.
2.  Press OK to continue. [OK]

Mod   C: TEST FAILED       # "testADC" (1, 1, -1)

--- End code ---

I saw your post about the DebugScope file, but that didn't seem to give any additional troubleshooting info.


BTW, did you ever make your right angle adapter board concept from this thread: https://www.eevblog.com/forum/testgear/agilent-16717a-comparator-and-zoomchipseltest-failures/msg3094078/#msg3094078 ?

Thanks,
DogP

DogP:
I looked into the 16750B card some more... I confirmed continuity of the chip select pins you mentioned.  I inspected the traces more, checking continuity across all traces going across/through the runner sections, and looked for any signs of corroded vias (didn't see any).  I also checked the voltages at the two regulators... they're 3.31V and -1.74V (seems like they should be close enough).

I also noticed that I get this error in pv, but it only shows up the first time I run the tests (right before zoomAcqTest fails).

--- Code: ---Mod E: Unable to Detect WRAP Flag.  Possible Board Fault.

--- End code ---

Do you know anything about the WRAP flag?

Thanks,
DogP

MarkL:
Ok, we've got two things going here...  First the 16533A.

But pre-first, a few general comments:

- If you haven't done so already, I'd strongly recommend reading the Theory section in the Service Guide for the cards you're trying to fix.  I've found they're very accurate and must have been written by the hardware and software developers.  It's the only service info us mere mortals have, so every little detail can be (and usually is) important.

- And along with that, read the Self-Tests Description.  Like the Theory section, every word can be valuable when trying to decipher the debug output.

- When running pv, I've found that it's almost always the case that the first thing that fails is the thing that has to be fixed first.  pv doesn't understand failure dependencies, and it will try to use a failed sub-system to do further validation, which in all likelihood will cause those subsequent tests to also fail.  I'm not saying to ignore the subsequent failure output, but take it with a grain of salt and scan the output for further clues regarding the first failure.

Ok, now back to the 16533A.  I would focus first on the DAC.  Those regulator voltages look ok to me.

I agree that for the scope cards the pv output and the DebugScope output are fairly worthless.  There's some tantalizing strings to be found in the 16533A/16534A pv driver (different that the operational driver) that implies there's more debugging to be had.  I can't figure out how to access it.  (Anyone up for some assembly-level reverse engineering?  DDE is provided on the system.)

If the scope card will run enough to give you a trace or at least let you onto the configuration screen, you can start to experiment with the DAC.  Move the trigger up and down and the trace offset up and down (even if the trace is off the screen).  Watch the trigger and offset DAC outputs to see if it's responding.

The DAC is U200, HP part 1SJ2-0102, a 24-pin narrow DIP.  I have figured out this much:

     Pin        16533A/16534A Function
  ---------     ----------------------
   1 CH13       Ch2 Trigger Level
   2 CH14       Ch1 Trigger Level
   3 CH15
   4 DIN
   5 DCLK
   6 DGND
   7 DVDD       5V
   8 DAC_CLK    19.66080MHz
   9 DL_EN
  10 CH0        Ch1 Offset
  11 CH1        Ch2 Offset
  12 CH2

  13 CH3
  14 CH4
  15 CH5        "Startable Oscillator"?
  16 CH6
  17 CH7
  18 AVDD       +5.000V
  19 AGND
  20 CH8        DC Cal
  21 CH9        ? (is either 0V or 5V)
  22 CH10
  23 CH11
  24 CH12

It's a PWM DAC, so you won't see a nice analog voltage on the output pins unless you have a DMM with a good filter.  The 3478A is in that category.  If a DMM doesn't work for you, you can look with a scope, or you can reverse-engineer the PWM filter on the output and look at the voltage after the filter.

pv moves around the DAC output voltages to force triggers, so if the DAC is failing, this is a good example of why subsequent tests will also fail.

There's more than anyone will want to know about this DAC in the Feb 1992 HP Journal, page 48:

  http://hparchive.com/hp_journals

There's also a CLIP for the 546xxA digital scopes which use the DAC.  The schematic could be helpful.  This particular site looks a dubious, but you can search around for the file name for other locations:

  http://bee.mif.pg.gda.pl/ciasteczkowypotwor/HP/546XXA_CLIP_Package.zip

I've encountered bad resistors in the DAC area.  Alexandre Souza did a nice blog on one particular resistor that has been reported as bad 4 times:

  https://tabajara-labs.blogspot.com/2019/05/repair-of-hp16533a-and-for-that-matter.html

Did you try a calibration?  It will fail, but it goes through different steps and puts a lot more info in the DebugScope directory if you have it enabled.  Maybe there's some clues lurking there with what fails or what it puts in the debug files.

I never got around to making the angle adapter.  I kept finding ways to troubleshoot cards from the underside.  I thought I could find a 0.1" male angle header with long enough pins but I couldn't.  It's going to need a short PCB and I got lazy.

It looks like you still have copper on those vias.  They're probably ok but we can get back to them.  The first is in the timebase area and the other next to an ADC.  They shouldn't affect the operation of the DAC.

MarkL:

--- Quote from: DogP on February 07, 2022, 11:01:13 am ---I looked into the 16750B card some more... I confirmed continuity of the chip select pins you mentioned.  I inspected the traces more, checking continuity across all traces going across/through the runner sections, and looked for any signs of corroded vias (didn't see any).  I also checked the voltages at the two regulators... they're 3.31V and -1.74V (seems like they should be close enough).

I also noticed that I get this error in pv, but it only shows up the first time I run the tests (right before zoomAcqTest fails).

--- Code: ---Mod E: Unable to Detect WRAP Flag.  Possible Board Fault.

--- End code ---

Do you know anything about the WRAP flag?

Thanks,
DogP

--- End quote ---
I agree those voltages are fine.

I haven't heard of the WRAP flag before.

I suggest the next step on the 16750B is to start looking at the data pins and the chip select on the zoom chips with a loop test running in pv.  Make sure they look like good TTL levels.  I'm sure there's also a R/W pin there too, but I haven't looked for it.  It can probably be identified by looking on that side of the chip as a signal that's in sync with CS or the data lines and gets set up before CS goes true.

Other possibilities is that one of the zoom chips is misbehaving or some of the pins on the FPGA are not working.  I have seen both, and both times manifested themselves as bogus logic levels on the bus.  But I think we're far from concluding it's a dead chip at the moment.

DogP:
Once again, thanks for all that info!  I didn't have time to look at the DAC today, though I did try the calibration, which passed ADC, Gain, and Ext Trigger Skew, but failed everything else.

Not sure if it helps any... but it does seem that the scope is at least somewhat working.  When I press run, it sits at "Waiting for Prestore", but if I press stop, it does show the waveform.  And the waveform of both channels seems to be correct (I tested with a roughly 10kHz 2Vp-p sine wave, and it looks correct).

Attached is a zip of the debug output directory.  The one that jumps out at me is logictrig.file:

--- Code: ---freq = 0, startable osc DAC = f800
Max Delay: No Trigger found
Min Delay, Rising Edge: No Trigger found
Trouble! Speeding up the startable oscillator to 1.08108e+08 Hz.
freq = 0, startable osc DAC = 8000
Error! Could not speed up the startable oscillator. Setting it to its maximum.
Min Delay, Higher Frequency : No Trigger found

--- End code ---

Based on the frequency mentioned, I assume this is the 100 MHz oscillator referred to in the theory of operation?  I see your DAC notes say CH5 goes to the "Startable Oscillator", so I think you're right that I need to start by looking at the DAC.  It sounds like the sample clock comes from the 100 MHz oscillator, so I'd expect that the oscillator itself is working.

relay.file also had a couple error lines:

--- Code: ---  Relay Errors Channel[0] =    112

  Relay Errors Channel[1] =    113

--- End code ---

I had seen that post about the bad 100K resistor, and was one of the first things I checked.  I desoldered it, it measured 100K out of circuit, so I put it back.

So, I plan to look at the DAC next, but please let me know if you have any other thoughts.

Thanks,
DogP

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod