Help with HP 8116A

[George_Race]

Glad you found the pictures Mark, and a nice explanation of what was happening.

Well the Signature Analysis of the Microprocessor Board is done.
Here is the results:

Signatures for Address Drivers and Decoders:  All Correct
ROM Signatures:  All Correct
Keyboard Signatures:  All Correct

And for those looking in, my board has the set of 6 ROM's.
I used Table 10.7-5 ROM signatures 08116-1002X/310X Series
for the Signatures.
It is from BackDating Page B-49

I thought that Signature Analysis on an HP instrument would clearly show where the problem being experienced was, right down to the chip.  But in this case that is not the way it turned out.   It still took digging in and looking at the Data Buss to discover where the difficulty was.

Mark, how come there is no signature analysis for all the other chips on the board?  Must be some limitations depending on the type of chip and how it is used in the circuit.  Can you please fill us in?

As soon as I get the new chip installed I will get back with more information on how the repair is coming along.

George

[MarkL]

Sorry the signature analyzer wasn't more helpful for you.

No surprise, though, since that's what others have said about the signature analyzer - Sometimes you get lucky with it, but most of the time you have to dig in anyway.

But it did confirm that side of the data bus is ok since all the ROMs read out fine.  So, it can help by at least verifying what pieces are working.

Mark, how come there is no signature analysis for all the other chips on the board?  Must be some limitations depending on the type of chip and how it is used in the circuit.  Can you please fill us in?

Who knows for sure, but there's a very large number instrument setups and moving around of probes they would have to document to be able to get meaningful signatures on every pin of every chip.  And signatures depend on consistently repeating patterns of bits so it might not even be possible in every case.

They probably could have done more, but it looks like they chose to cover just the more insidious failures, for instance a bad byte in a ROM.

It's also why they spend a significant amount of time writing the theory of operation sections so you can understand how it's *supposed* to work and go from there.

[George_Race]

Today the new 20 pin Socket Adaptors arrived.  Removed the defective 74LS245N (U2), and replaced it with the Socket Adaptor.



Had hoped that the replacement 74LS245N would be here today too, but no such luck.  Hopefully it will be here Monday and I can plug it in and see what happens.

George

[George_Race]

The new IC arrived and has been installed:



when I hit the on switch, it went into self test and here is the result.


Just sitting there putting out a perfect 1 MHz Sine Wave!

I am very pleased, especially with MarkL for all the hand holding he did as I worked through learning how to properly use a Digital Scope.  It is interesting that very early on in the process he already knew that U2 was probably causing all the difficulty.  Hats off to MarkL!  I really do appreciate all you have done to help me with this repair.

Normally I buy, repair, and resell on eBay, but not this time.  This one is a keeper.  Have been wanting a nice Function Generator for some time, and this has turned out to be a really nice working and looking instrument for the work bench.  Next I am going to go through the Performance Testing section of the manual.  If needed I will continue with adjustment procedures, where necessary, just to make sure this "Old Girl" meets it's original specifications.

Everything seems to work, but I do need to sit down and go through the setup procedures for the various modes.   All the waveforms coming out really look great, frequency wise, it is very close all across the range up to over 50 MHz.

I can hardly wait to take a look at the output on the Spectrum Analyzer to see just how good it really is.  I am very pleased.

There is one last question that hopefully MarkL can answer for me.  I can't seem to find an answer in the users manual, but maybe I have not looked in the correct place as of yet.

When I press and hold the LCL button, the display shows A 16.  Just what does that mean?

Thanks for all the comments and I hope you all enjoyed being along on the journey, it has been fun.

Take care and 73,
George - WB8BGY

[dave_k]

Hi George,

Pressing the LCL button shows the GPIB address in decimal.
In your case the address is 16.
Glad to read your HP works again - great job!

[MarkL]

Hey, that's great George!  Glad it's working now!

There is one last question that hopefully MarkL can answer for me.  I can't seem to find an answer in the users manual, but maybe I have not looked in the correct place as of yet.

When I press and hold the LCL button, the display shows A 16.  Just what does that mean?

That's its GPIB address, as set by the DIP switches on the back.  16 is the default.

One word of warning on adjustments - I would recommend doing the performance check before trying to adjust *anything*.  If it passes the performance check let it go.  I went down the road of doing a calibration on my unit and it took me 2 days to get it back.  Some additional detail:

  https://www.eevblog.com/forum/testgear/hp8116a-manual-problem/msg388727

Glad to help - Enjoy your func gen!

[George_Race]

Thanks for all the comments, yes I am going to enjoy it a lot.  It will really come in handy.

MarkL, I totally agree, if it is even close to being where it belongs, I will not change anything.  I don't need 2 days of aggrevation over a few Hertz or MiliVolts!

And lastly, it seems that I always have one more thing that I need help with!

There was not a battery in the unit when I got it.  My question is which battery do I need, NiCAD or Lithium?

BD 61 on page B43 talks about serial numbers and a change that has to be made.  I don't know how that applies to my unit.

My serial number is:  2334G02413

My Microprocesor board is the 08116-66503, but the circuitry that  I have on the board is exactly like Figure B-15.08116-66513:  U28 schematic that is shown on Backdating page B-47 in the top diagram.

Can someone tell me which one I need, and if possible a replacement part number.   I am aware of the Panasonic BR 2/3 being used for some replacements, but don't know if that is the corrrect replacement battery for my unit..

Thanks,
George

[MarkL]

Serial #2334G02413 is old enough to have the NiCad.  See my previous post on the battery type here:

  https://www.eevblog.com/forum/testgear/hp8116a-manual-problem/msg423568/#msg423568

I didn't see anyone post an easier to get cross reference, or confirm any of the three part numbers mentioned were ok or available.

HP says the original is 2.5V, so it must be 2 NiCads in series.  One suggestion would be to get 2 of these with the PCB pins, solder them together end-to-end, and shrink wrap them:

  http://store.batteryspecialists.com/nicd-nimh-1-3aa.html

There might also be a battery assembly company that could make you one, but it's probably going to cost a bundle.

You could also get a generic 2 cell pack, or install a 2xAA holder and put some regular NiCads in it as other have mentioned.

[George_Race]

The project is finally finished.
Installed the batteries and everyting is working as it should.



There was not enough room to install a battery holder for the new NiCAD's so I simply soldered them in place and tied them down with a tiewrap.

I purchased the batteries for a total of $2.73 at my local Batteries Plus Bulbs store.  Part numbers are:  NUN1100-AAF  -  AA 1.2V NICD FLAT

Now when I do a setup, and turn off the instrument, it starts back up with all the same setting as before I turned it off.

MarkL, I spent a lot of time last evening going through the performance testing, page after page!  Did not have some of the equipment needed, but managed to do all the tests and am very pleased with the overall results.  Throughout the full range of Frequencies and Amplitueds, all are within +- 5% to 7% of indicated values.  The scans on my HP-8568 look very close to the pictures printed in the Testing and Performance section of the Manual.

This turns out to be one of the best $130 equipment investment that I have ever made.  I am most pleased with the overall outcome, and I learned a bunch about using a Digital Scope, thanks to your help.

Here is the finished project.


A big thanks to the group on EEV, and especially you Mark for seeing me through the project.

All that I need to make this almost like brand new is the front top plastic trim piece, that snaps into place, and two of the bottom snap in feet and the bail stand.  Boy, what would I do without eBay!  They are there!

George

[George_Race]

Got the bottom feet and the 2 bail pieces on the way from eBay.

I cannot find the plastic strip for the top front of the instrument anywhere.  Even searched by the HP part numbers, no luck.

Does someone on here, by chance, have one just laying around begging to be used?

If you do, please let me know.  I will be glad to pay a reasonable price and shipping cost to get it.

Thanks,
George

[pelule]

I need to repair one of my HP 8116A (option 001).
Fault is definitively on the CPU/A3 board, rev 66503 (2440), placeplan attached.
Checked all voltages and replaced A3 with another A3 from a 2nd 8116A - system works fine then.
Failure:
all displays/LEDs, controlled via the Latches Data Bus do not operate correct.
The ICM7218A controlled 7-segments and LEDs are dark, the LS374 controlled LEDs are random.
As long as a key is pushed (for example scanning down the frequency) the displays show, a bit dim, the correct displays, as soon no key is pushed, the display goes dark/random again.
Thus no problem on ROM, RAM, CPU. No akku issues for the RAM.
It must be a problem on the data bus / latched data bus path or the control signals for that.
Checked with HP 5005B signature analyser. All signatures are ok (not a big surprise as there are none given for the Latched Data Bus area).
Replaced/tested U25 (245), U2/U26 (244), U16/U23/U24 (374) and U22 (ICM7218A).
Control signals (LB, LATCH1, LATCH2, /WRITE, /READ, /MODE) seem to be fine also.

Any idea for the problem is welcome.
Really stuck, that 8116A drives me crazy.

[MarkL]

Very strange.  Does the unit output the right waveforms?

You are saying that ALL signature tests passed: tables 10.7-3, 10.7-5, and 10.7-6?

If you hold down a key, are all the LEDs then correct too?

If you hold down a key on boot, do you get the key stuck indication with normal display brightness?

Can you include a photo of the front panel so we can see the random LEDs that are on?  Are the same LEDs on each time?  Do you get the "all LEDs on" test at boot?

If you have a working second A3 board, do you have a fully working second 8116A to compare against?

For next steps: Do you have oscilloscope?  How about a logic analyzer?

[pelule]

I try to answer your question as detailed as possible. But it's not easy to explain dynamic processes.
Hope your are able to follow, what I did/tested already.

Very strange.  Does the unit output the right waveforms?

In deed, it's quite strange. All output (incl. sweep) are correct with both A3 board, just hard to control with the bad one.

First I checked the supply voltages. Next I conected the good A3 board and checked the functions.
Than I used the bad A3 board and (tried) to check the functions again. 
Thus my conlusion: problem is located on the CPU/A3 board on the display section.

You are saying that ALL signature tests passed: tables 10.7-3, 10.7-5, and 10.7-6?

Yes correct.
Table 10.7-3. Signatures for Address Drivers and Decoders - all correct
   Note: signature U10( = shows UUUU, printed is UUUH. This is A0 @ U10/RAM, it is the same signal as U3(18) A0 @ 74LS244N, thus UUUU must be correct (doc error?)
Table 10.7-5. ROM Signatures (for 08116-1000X Series) - all correct
Table 10.7-6. Keyboard signatures - all correct (now)
  Just as note: found an issue with [LCL] button, I have repaired already. An "i..t" had glued a brocken part of the button, that glued also the metal connectors.

If you hold down a key on boot, do you get the key stuck indication with normal display brightness?

I get the "stuck" display, but dim (see picture)

If you hold down a key, are all the LEDs then correct too?

Not at all keys (depends on function)
if I press [Auto], all seems to be ok, just a dim display (see picture).
At some buttons pressed, display is correct but only ~1s
If you scan frequency up or down, all seems to be ok, just dim.
So my conclsion:
- during key scanning the display data is frequently updated, thus you get a dim, but visible display.
- if no key scanning is processed, the display data is not continously updated, thus the display is deleted/cleared.

Can you include a photo of the front panel so we can see the random LEDs that are on?  Are the same LEDs on each time?  Do you get the "all LEDs on" test at boot?

I added some pictures for good & bad A3 board. Showing setup, Stuck-Key-State, All-On-State and Ready-State.
Note: as the accu is not present, the bad board shows first Err1-state befor going to "ready" state. Bad seems not to show All-On-State.
 

If you have a working second A3 board, do you have a fully working second 8116A to compare against?

Yes, I have a 2nd fully working tool, but does not have option 001 (sweep).
But as noted, the "defekt" tool works fine with the "working" A3 board.
As the good A3 boards has different revision (66513), I did not yet test the "defekt" A3 board in the working tool.
Does not give any further information beside an additional confirmation, the error is on the bad A3 board.

For next steps: Do you have oscilloscope?  How about a logic analyzer?

Yes, have all that equipment.
2ch 200 MHz digital scope (RIGOL) & 2ch 500 MHz analog storage scope (TEK)
16ch 150MHz analyser (LAP-C)

I did already many measures.
I check the signal in/out of the various bus driver, the latching of data, as well I recorded and analysed the data & control signals for the ICM.
The signal seem to be ok, the data flow is in line with my expectation of correct control/data of the ICM for required displays.
That let me first think the ICM is defekt and I replaced it with a NOS (in fact I tested now 3).
But that wasn't the cause of problem.
Thus my conclusion is: it is related to the data bus, the latched data bus or the related control signals.
As the display shows in certaint conditions the correct, but dim displays and taking into account, the running program does continously
update of display data (to change display, all data has to be re-written), the dim display may caused by the frequently change between correct display data and wrong/corrupted display data.
This results to a kind of on/off, thus reduced brightness.
So I would assume the display data is time to time presented with wrong timing and/or missing signals/levels.

I assumed a bus-down of one of the "driver" ICs. So I "strategic" replaced the different ICs connected to the Data Bus and the Latched Data Bus (244/245/374).
But the problem persist.
I have soldered sockets for each IC I replaced.
So my next planned step was, to concentrate on just problem after the other, starting with the most simple part of circuit.
First get one of the two 374 latched LEDs operating.
Thus remove all for that function not relevant ICs to make test condition more simple.
Seach for the problem and solve it.
Than do the same with the 2nd 374 latched LED.
Than work on the ICM problem, as is is the most complex part.
I would start with the select signals and timing (74LS138 ICs). As signatures where ok, it may be a timing issue caused by a week FAN-OUT of one of the 74LS138.

Notes on the pictures:
000 shows the used A3 board
001 shows the setup
002 shows keep LCL button pressed during power-on (force stuck key)
003 shows display after LCL release (all-on or Err1)
004 shows ready state
  on the bad board the sequence is
  first 004a, after ~1s 004b, if [auto] button keept pressed, shows 004c.
  this state keeps until [auto] is released, than it goes to state 004b again

Any tip or sugestions is highly welcome.
BR
PeLuLe

[pelule]

next pictures

[pelule]

and the next

[pelule]

and the last ones

[free_electron]

check the circuitry around the battery

the 'dim diplayt' is because the main cpu cannot complete its scan cycle. it keeps getting interrupted by something.

these machines run a timed cycle codebase. if something keeps bombarding the cpu with interrupts you will get this strange dimming effect.

could also be the GPIB controller that is wonky ...

[MarkL]

Thanks for the very detailed information.  I'm still looking at it all, but here's a couple of thoughts.

I agree it could be a weak driver.  Take a look with your scope at the data and control pins on latch bus components to make sure they are getting to the right levels.

Another way to tackle a problem like this is to set up your scope or logic analyzer to trigger when the problem occurs.  Once that's done, you might be able to work your way backwards to the cause.

In this case, the 8 button LEDs that are on from 90deg to DISABLE are all on the DIG0 line. The register that controls DIG0 is the first one written after the ICM7218A is given the DATA COMING command.  You could try to set up a trigger for all 1's getting written immediately after DATA COMING, or maybe it's sufficient to just look for all 1's getting written in conjunction with /WRITE=low and MODE=low.

Because the ICM7218A is loaded sequentially, it may also be getting too many or too few write pulses.  That's also something you could verify by counting groups of 8 pulses with /WRITE=low and MODE=low before MODE goes high again.

[MarkL]

the 'dim diplayt' is because the main cpu cannot complete its scan cycle. it keeps getting interrupted by something.

these machines run a timed cycle codebase. if something keeps bombarding the cpu with interrupts you will get this strange dimming effect.

could also be the GPIB controller that is wonky ...

The display controller autonomously does the display scan multiplexing without CPU intervention.  You load it with 8 bytes of data and off it goes.

I think he's on the right track that it's getting loaded with the right data when a key is held and then it gets clobbered.  It's probably all happening in the key poll loop.

[MarkL]

Attached is a trace of the MODE and /WRITE lines on the ICM7218A.  As expected, the mode byte is written, followed by 8 bytes of display data.

This sequence happens *once* when a button is pushed.  It does not happen upon release, nor does it happen continuously to keep the display updated (except if auto-vernier is active).

I would suggest looking at MODE and /WRITE to see if you get the above behavior.

From what you're describing, I'd bet the ICM7218A is being written after a button release.  If so, find out why the extra writes are happening.

I'm not ignoring the fact that the LS374 LEDs are random, but the above is something that is easy to test and repeatable.  The random LEDs likely have the same root problem.

I'm not sure it's significant, but when a button is pushed the CPU appears to go into a tight loop waiting for release.  It doesn't even respond to GPIB requests as long as the button is pushed.  It's possible on your 8116A, the ICM7218A being written continuously during a button push, which may explain the dimming.  A further guess is that the keyboard scan and ICM7218A writes are getting tangled up together.


One caveat is that the above test was done with EPROM firmware version 08116-10018.  If your working unit has the same version as the broken one, you can verify MODE and /WRITE behavior on it first.

Also, the RAM error would appear as "E01".  I'm not sure why a "1" would appear, except that it's likely related to the display problem at hand.

EDIT: Fix minor ambiguity in EPROM version.

[pelule]

Hi guys,
thanks a lot for digging into my problem and all the tips to check.

@  free_electron
Sorry, I did not mention, but I checked the circuitry around the (old rotten NiCd) battery and it seems to be ok.
I don't think this may the caused of the issues, as the program continues after RAM pwr test. This old board revision writes some test data to the RAM, switches of the 5V RAM supply for short time and than check, if RAM content has changed (if changed it generates the E01 bat pwr error and than continues).
But I will connect a 3.5V lab-supply for further tests to simulated the NiCd. For security via a silicon diode and active current limit.
When repair is done, I plan to connect a 3V Li-battery (for protection against unwanted charging current via a Germanium diode for the lowest possible drop voltage ~0.3V at the needed RAM standby current. silicon diode at sane condition drops ~0.5V). Or simply use same solution as George_Race (2 standard NiCd accus in series).

@ MarkL
Many great tips. Will need some time to check.

Keep updating here for the progress.

BR
PeLuLe

[MarkL]

A small update to the button push vs. display update test above...

It appears that not all button pushes result in a single update to the ICM7218A.  Examples (not an exhaustive list):

One update: AUTO, LIMIT, COMPL, DISABLE
One or two updates: 90deg, -90deg
NO updates: 1 CYCLE

This makes sense since those buttons which have an LED associated with them need to be updated.  90deg and -90deg are complementary, so it needs to turn one off and the other on (depending on what's already lit).  And "1 CYCLE" has no LED, so no update needed.

If the ERROR LED is on, the display gets updated about twice a second, continuously.

I wonder if the display comes on on the broken one if you hold in "1 CYCLE" ?  My guess is not, but it would be interesting to know.


I don't think any of this provides clues to the problem.  I'm just pointing out that you should use one of the "one update" buttons if you proceed with the MODE + /WRITE testing.  That way you know what *should* be happening.

[pelule]

I prefer to think first and than do the measurement. That I did based on your tips and tried to confirm the thoughts with measurements.

Here some intermediate results and my so far conclusions:
Buttons are not activate any interrupt thus CPU need to poll the buttons.
As system does react on pushed buttons as expected, CPU must operate ccontinously (no stuck or NMI from the HPIB-device).
Thus ROM, RAM and the CPU related busses (address bus, data bus, and bus transceiver) and decoding are ok (signature confirm this).
Conclusion: issue is at the Latched Data Bus area (as thought already).

MarkL correct explained, the 8116A display management.
ICM is setup with single 9 byte shot sequence (see also data sheet ICM7218AI).
The continously multiplexing of the segment LEDs is done by the ICM independant.
The other button LEDs are simple latches, no multiplexing.

A sequence is send only, if the display content has to be changed.

On the 8116A the ICM direct segment controlling is used, nodecoding.
7-segment LEDs are inverted (1 means the segment is off), the decimal point (DP) is non-inverted (1 means the DP is on)
For example the all off sequence is:
   9-Byte sequence = 1x Mode Byte (only upper 4 bits are valid) + 8x display data bytes (8 bit).

   Byte   M/D   Value (hex, binary, meaning of data)
   1   1   FFh = 1x11---- = Data Coming, (Don't Care), No Decoding, Normal Operation
   2   0   7Fh = 01111111 = digit 1 (all off)
   3   0   7Fh = 01111111 = digit 2 (all off)
   4   0   7Fh = 01111111 = digit 3 (all off)
   5   0   7Fh = 01111111 = digit 4 (all off)
   6   0   7Fh = 01111111 = digit 5 (all off)
   7   0   7Fh = 01111111 = digit 6 (all off)
   8   0   7Fh = 01111111 = digit 7 (all off)
   9   0   7Fh = 01111111 = digit 8 (all off)

That sequence I measured with the analyser already.

MODE and /WRITE signal levels are ok and have good shape.
Looks exactly as in MarkL's attached screen, thus I did not attach again.

If a button is pushed (depend on the button) one or more display sequences are generated, exactly as MarkL noted.
Conclusion: display (ICM, button LEDs) are working in principle. But the data is correpted time to time.
This gives the impression of no display or dim display.

So next steps are (as MarkL alreday recommend)
Ignore the 374 latches for the button LEDs and concentrate on the ICM data sequence first to find the error condition, corrupting the ICM data.
It must an incorrect write (may a wrong mode byte or wrong display data).
For example if the "standby" would wrongly activated (just one wrong mode bit) this may cause a "no display".
Thtas what I will measure first (does the ICM multiplex? means is display of by wrong segment data or by standby)
@ MarkL - excellent tips, the button/sequence list will help a lot.
So it's measurements time now.

Keep you informed on my findings/progress.

BR
PeLuLe

[pelule]

First potential cause found.
Ao measure with the analyser everything on the Latched Data Bus controlling the ICM everything seems fine, data and controle signal seem ok and match with setting of the expected display..
But a more detailed look showed at each new 9 byte sequence after the 1st /WRITE (5us) low pulse (the mode write) at around 74µs later a short just ~20ns low pulse exist. This may caused by the decoder area, but I have to check in detail.
First I will check at the "good" CPU board, if the pulse exist there also.
Secondly I will try to increase the capcitice load at the /WRITE pin (connect a 100nF cap) to get this short pulse removed to see, if it makes any difference.

BR
PeLuLe

[MarkL]

100nF?  That's a lot.  You're going to kill the /WRITE signal.

I would check the enable inputs to U17 (LS138) which is driving the /WRITE line.  Check that pin 6 is always high, pin 4 always low.  The only enable being used is pin 5, so it should be the only pin pulsing the output.

As far as timing goes, the select inputs (pins 1, 2, 3) should be set up before the enable pulse comes along.  The sequence should be to set up the select pins first, then pulse the enable low then high.  Changing the select inputs while the enable is active can cause unpredictable glitching on any of the output pins.  Could be your problem.  You can check for this by triggering on /WRITE and looking at the enable and select pins.

U21B drives U17 and is configured as a pass-through buffer.  It could also be at fault.  Check that each pair of input and outputs match (pins 13+7, 15+5, 17+3).  An easy way to do this on your scope is to subtract one channel from the other and probe the input on one channel and the output on the other channel.  If the gate is working, you'll always see 0V, except during switching where's there's a short 10 to 20ns of gate delay.