Thanks. I may take you up on that.
I haven't looked at the 2019 properly yet, just powered it up, looked at the output with a scope and frequency counter, and noted a few of the problems. One of the rear feet was missing, which was surprisingly annoying, so I replaced both with a pair of generic feet from something else. At least it doesn't wobble about now.
It's about sixth on the list of major items to tackle.
Hewlett-Packard 3314A function generator
Forum rules
Use tags for the type of equipment your topic is about. Include the "repairs" tag, too, when appropriate. If a new tag is needed, request one in the TEAdministration forum.
Use tags for the type of equipment your topic is about. Include the "repairs" tag, too, when appropriate. If a new tag is needed, request one in the TEAdministration forum.
Re: Hewlett-Packard 3314A function generator
I've poked and prodded the 3314A for a while and after replacing a 74LS245 it has resumed some sort of operation. I removed the NVRAM and have a horrific setup with a 28 pin SRAM hovering above the board with lots of wires soldered onto two IC sockets that are placed where the µPD444Cs were previously. The RAM may have been innocent, I've a feeling the '245 may have been a root cause of one of the symptoms, or perhaps all of them, as it is connected to the CPU's data bus and its job is to talk and listen to other circuit blocks. Unfortunately I don't have a functioning auto-calibration system now and this seems to be down to the awful, awful PCB interconnects that HP somehow got even more wrong than the terrible ones fitted to the 3325B. It could even be that the cables are to blame for every fault.
By examining the different PCBs I've discovered that my 3314A's external serial number date in 1981 is completely unconnected to the boards within, the newest of which seems to be from 1995. This thing has had numerous board swaps and those interconnects should've been replaced ages ago. I changed the pin headers on the computer board A3 because they were looking very rough but I didn't look closely enough at the interconnects themselves at the time. These wiring hell devices are 0.1" spaced ribbon cable with solid and very breaky cores. The result of this is that I had a bit missing from the interconnect that sends the data bus to the A2 board and a different bit missing on the data bus on the A1 board. Continuity tests require contortionist skills and a steady hand, as one end is always blind and difficult to clip anything to (my replacement A3 pins are longer and you can get a hook on them below the connector, though). Trying to autocalibrate when two bits are missing produces a lot of errors, as you might expect, but even turning off calibration and using the emergency centre-of-range DIP switch override doesn't help diagnosis much because that same incomplete data bus does control as well as calibration. Control uses a 12-bit DAC, which was missing a bit, this was more obvious as it's a mulitplexed DAC which meant that DC offset, amplitude and other stuff all went in a strange set of steps instead of a nice ramp.
I think I need to replace those cables…
By examining the different PCBs I've discovered that my 3314A's external serial number date in 1981 is completely unconnected to the boards within, the newest of which seems to be from 1995. This thing has had numerous board swaps and those interconnects should've been replaced ages ago. I changed the pin headers on the computer board A3 because they were looking very rough but I didn't look closely enough at the interconnects themselves at the time. These wiring hell devices are 0.1" spaced ribbon cable with solid and very breaky cores. The result of this is that I had a bit missing from the interconnect that sends the data bus to the A2 board and a different bit missing on the data bus on the A1 board. Continuity tests require contortionist skills and a steady hand, as one end is always blind and difficult to clip anything to (my replacement A3 pins are longer and you can get a hook on them below the connector, though). Trying to autocalibrate when two bits are missing produces a lot of errors, as you might expect, but even turning off calibration and using the emergency centre-of-range DIP switch override doesn't help diagnosis much because that same incomplete data bus does control as well as calibration. Control uses a 12-bit DAC, which was missing a bit, this was more obvious as it's a mulitplexed DAC which meant that DC offset, amplitude and other stuff all went in a strange set of steps instead of a nice ramp.
I think I need to replace those cables…
Re: Hewlett-Packard 3314A function generator
Now rid of the calibration errors, so back to a fully working unit, perhaps. Will it randomly restart? Find out another time, as I'm sick of the sight of it for the moment.
Re: Hewlett-Packard 3314A function generator
The last time I tried testing a sig gen that way, the test showed there was a problem. The audio started out reasonably, but over the course of maybe 500ms it faded and disappeared. Turn it off, and it repeated.
Later I realised the sig gen was fine, but my deafaid was deleting the signal. It was interpretating the signal as howlback, and suppressing it.
Later I realised the sig gen was fine, but my deafaid was deleting the signal. It was interpretating the signal as howlback, and suppressing it.
Re: Hewlett-Packard 3314A function generator
From that it sounds as if this thing was a pile of trouble from when it was new.synx508 wrote: ↑Mon Jan 19, 2026 1:49 pm By examining the different PCBs I've discovered that my 3314A's external serial number date in 1981 is completely unconnected to the boards within, the newest of which seems to be from 1995. This thing has had numerous board swaps and those interconnects should've been replaced ages ago..............
Re: Hewlett-Packard 3314A function generator
Well, a bit over an hour into testing and it rebooted itself! Whatever the root cause is, I still haven't found it but I have made an ugly NV SRAM modification and I suppose ruled that out as a cause. When it crashes and reboots it always returns with E09, which indicates that the battery backed memory has been corrupted and is starting with default values. This is what encouraged me to change the 1kx4 chips for a single 8kx8 chip with a similar standby current. I've a feeling the problem could be PCB related, maybe a via or a plated through hole that goes open at a certain temperature, I know that there's still a way to force it to reboot by pushing the PCB in a certain place. Perhaps, now I've got it back to where I started, I should check to see if reboots by pushing the PCB in that place also cause the NV RAM to become corrupt.
Re: Hewlett-Packard 3314A function generator
The previous owner of this function generator had replaced an octal flip-flop and the MC6800P CPU. I have re-flowed the soldering there but maybe I'll remove all the solder and replace it. The PCB seems particularly finicky about solder, which isn't usually the case with hp
Re: Hewlett-Packard 3314A function generator
Sounds like you are going to have to look at noise on the power lines, and signal integrity on the control/data/address bus.
The signal voltages should be easy to test with a long persistence scope setting.
IIRC the with 6800 you need to be careful with its non-overlapping non-TTL clock signals and of one of the hold times; after 50 years[1] I can't remember which one, but isn't there an E and a R/W signal? A good high speed logic analyser might help there, otherwise it is back to a scope and eye diagrams.
[1] come to think about it, it would have been exactly 50 years ago that I was getting microprocessor databooks and choosing which one to base my computer on. I looked at a hell of a lot of weird and limited devices (Fairchild F8 anybody, or MC14500 1 bit processor?). I whittled it down to the 8080, 6800 and 1802. The 8080 hardware was a pain, the 1802 simple but the instruction set was regular but bloody difficult for things like subroutine calls, while the 6800 struck a happy medium (with the exception of the clock inputs).
The signal voltages should be easy to test with a long persistence scope setting.
IIRC the with 6800 you need to be careful with its non-overlapping non-TTL clock signals and of one of the hold times; after 50 years[1] I can't remember which one, but isn't there an E and a R/W signal? A good high speed logic analyser might help there, otherwise it is back to a scope and eye diagrams.
[1] come to think about it, it would have been exactly 50 years ago that I was getting microprocessor databooks and choosing which one to base my computer on. I looked at a hell of a lot of weird and limited devices (Fairchild F8 anybody, or MC14500 1 bit processor?). I whittled it down to the 8080, 6800 and 1802. The 8080 hardware was a pain, the 1802 simple but the instruction set was regular but bloody difficult for things like subroutine calls, while the 6800 struck a happy medium (with the exception of the clock inputs).
Re: Hewlett-Packard 3314A function generator
I haven't looked very closely at the two-phase non-overlapping CPU clock so perhaps I'll do that. I can't get a feel for why it would generally take a fairly long time for the problem to appear, then rather than appearing regularly, there's a similar interval before it appears again.
I did signature analysis on most of the computer board but it's not much use with a problem at appears roughly once every 8 billion cycles.
I've checked ESR of the power line capacitors, they seem very good indeed. I don't completely trust the power supply, other 3314A owners have claimed to fix this problem by soldering the pass transistors in rather than using the rather silly Molex type sockets that they use - they're like those white 0.1" connectors for the ±15V and semi-transparent 0.2" for 5.1V, of the type that looses its grip after four decades. It's not impossible that there's a small glitch as the common heatsink plate warms through a certain temperature, but that doesn't completely fit with the problem recurring at similar intervals thereafter.
If this turns out to be a software release that's got a flaw like the Boeing 787 that you have to reboot every 51 days…
Except it can't be that, because the interval varies quite significantly.
One person with the problem split the power supply's supervisory LM339 output with diodes so they could see which of the protective measures was stopping the 555 that drives the 5.1V buck regulator. I don't really want to do that but it's beginning to look like it might be necessary. I think it might be easier to piggyback a second LM339 over the top and use that to identify the problem - hoping that it wouldn't load anything too heavily.
I did signature analysis on most of the computer board but it's not much use with a problem at appears roughly once every 8 billion cycles.
I've checked ESR of the power line capacitors, they seem very good indeed. I don't completely trust the power supply, other 3314A owners have claimed to fix this problem by soldering the pass transistors in rather than using the rather silly Molex type sockets that they use - they're like those white 0.1" connectors for the ±15V and semi-transparent 0.2" for 5.1V, of the type that looses its grip after four decades. It's not impossible that there's a small glitch as the common heatsink plate warms through a certain temperature, but that doesn't completely fit with the problem recurring at similar intervals thereafter.
If this turns out to be a software release that's got a flaw like the Boeing 787 that you have to reboot every 51 days…
Except it can't be that, because the interval varies quite significantly.
One person with the problem split the power supply's supervisory LM339 output with diodes so they could see which of the protective measures was stopping the 555 that drives the 5.1V buck regulator. I don't really want to do that but it's beginning to look like it might be necessary. I think it might be easier to piggyback a second LM339 over the top and use that to identify the problem - hoping that it wouldn't load anything too heavily.
Re: Hewlett-Packard 3314A function generator
I've never bothered with signature analysis, even when it was new. All it can do is indicate a subsystem/board that is grossly faulty, and gives no indication why.
Marginal signal integrity can be very sensitive to many things, e.g. temperature, PSU voltage. The trick is to spot what is close to the limit and likely to change.
After it croaks, do you turn it off or just leave it to recover and have another go? If so, there might be time for the temperature to fall and the timing to get back into the normal area?
Are there any electrolytics associated with generating signals? I once had an electrolytic which meant I could only do one test every 12 hours. Bit of a long shot.
If it is working and you play a hot air gun or hairdryer over the circuit, does the problem occur sooner? Ditto freezer spray? That might help isolate which sub circuit is problematic.
If worries about socket contacts, I'd put a tiny drop of contact cleaner in the socket,.and wiggle the component. Soldering contacts is for emergencies only!
Put scope on PSU, various clocks/enables look at voltages and setup/hold times for data and address lines.
Marginal signal integrity can be very sensitive to many things, e.g. temperature, PSU voltage. The trick is to spot what is close to the limit and likely to change.
After it croaks, do you turn it off or just leave it to recover and have another go? If so, there might be time for the temperature to fall and the timing to get back into the normal area?
Are there any electrolytics associated with generating signals? I once had an electrolytic which meant I could only do one test every 12 hours. Bit of a long shot.
If it is working and you play a hot air gun or hairdryer over the circuit, does the problem occur sooner? Ditto freezer spray? That might help isolate which sub circuit is problematic.
If worries about socket contacts, I'd put a tiny drop of contact cleaner in the socket,.and wiggle the component. Soldering contacts is for emergencies only!
Put scope on PSU, various clocks/enables look at voltages and setup/hold times for data and address lines.
Re: Hewlett-Packard 3314A function generator
I've generally left it running because I was hoping it would reveal more about the problem. If it happened repeatedly after reaching operating temperature I'd know it was something about being at operating temperature. If it did it once as it got to operating temperature I could assume some sort of continuity issue related to thermal expansion, maybe a cracked via or plated-through hole. But what it actually does is crash at reasonably similar intervals which are about the same as the time it takes to get to operating temperature and this makes me wonder if the thermal aspect is a distraction.
I don't have any freezer spray currently but I did get it quite warm with the hairdryer yesterday and I couldn't trigger the reboot. Worse than this, in a way, is that I did trigger a reboot with some connector wiggling but the reboot did not destroy the contents of NVRAM, so it's not the reboot I'm looking for.tggzzz wrote: ↑Mon Jan 19, 2026 10:13 pm If it is working and you play a hot air gun or hairdryer over the circuit, does the problem occur sooner? Ditto freezer spray? That might help isolate which sub circuit is problematic.
If worries about socket contacts, I'd put a tiny drop of contact cleaner in the socket,.and wiggle the component. Soldering contacts is for emergencies only!
I've done so much watching lines with my scope now but only once have I seen anything, which is what prompted the CMOS hex inverter to be replaced. Maybe I should look at the /CS and /WR lines on the NVRAM along with the data bus, using the logic analyser, since the bad reboot corrupts this. This is also where the 3314A's software causes an additional diagnostic roadblock by being helpful, it detects corruption on startup and restores defaults to all the NVRAM configuration memories. I know that it stores the working configuration in configuration slot 0, as the 3314A won't even start without working NVRAM. The slot 0 feature is quite nice, because it stores the settings-at-powerdown there which can be recalled with RCL 0, they don't automatically restore because, as the manual points out, this might be very bad in certain applications. It actually does more than store configuration there, it stores the full UI state, it even remembers which context the display was left in. It may do this with a "dying gasp" write, triggered by the PSU detecting that the AC power has gone away and perhaps this is a clue. The power supply does seem fine and is another clue to the mysteriously mixed vintage of this instrument as it has radial capacitors and strangely even much later revisions of the board where the NVRAM and RAM is a single chip and the 6 PROMs are just a single chip, has axial capacitors. Most pictures of the board online are completely different revisions but the manual talks about the early revisions having 6 EPROMs rather than PROMs.
Re: Hewlett-Packard 3314A function generator
Tricky, but more fulfilling than soduku/crosswords.
If it is a cut-and-shut with boards of a different vintage, that increases the chances of inter-board timing violations.
"Last gasp save" operations are likely to be based on noticing the mains or unregulated power lines are failing shortly before the computer's power lines are out of limits. That wouldn't work if the problem is between the main PSU and the computer.
The nice thing about a "proper" LA (i.e. not the 24MS/s USB things) is that you can set it up so it captures nothing until the fault occurs. That requires
I have an HP1682 800MS/s analyser for such purposes
If it is a cut-and-shut with boards of a different vintage, that increases the chances of inter-board timing violations.
"Last gasp save" operations are likely to be based on noticing the mains or unregulated power lines are failing shortly before the computer's power lines are out of limits. That wouldn't work if the problem is between the main PSU and the computer.
The nice thing about a "proper" LA (i.e. not the 24MS/s USB things) is that you can set it up so it captures nothing until the fault occurs. That requires
- amplitude: variable threshold levels
- timing: a decent set of FSM-based filter and arm and trigger options. Looking for marginal timing violations requires high sample rates; gross timing violations might not.
I have an HP1682 800MS/s analyser for such purposes
Re: Hewlett-Packard 3314A function generator
This seems a bit like teaching grandmother to suck eggs.
Have you cleaned all contacts and checked interconnects? They can be the cause of odd intermittent faults.
What about dry joints?
Without knowing anything about this model, I'd put a DSO on the power lines to at least rule out PSU glitches. Of course glitches may not be caused by PSU faults.
The number of board replacements sort of suggests they had problems, such as timing problems, which were never properly sorted out in R&D or by later upgrades.
Have you cleaned all contacts and checked interconnects? They can be the cause of odd intermittent faults.
What about dry joints?
Without knowing anything about this model, I'd put a DSO on the power lines to at least rule out PSU glitches. Of course glitches may not be caused by PSU faults.
The number of board replacements sort of suggests they had problems, such as timing problems, which were never properly sorted out in R&D or by later upgrades.