[41] Odd display problem

[emece67]

Hi all,

I recently fixed (almost) a broken posts 41C (fullnut) I own since the 90s. But, after the repair, it shows an odd display problem I'm not being able to fix.

Problem is: the display is always blank, except when a program is running or a key is pressed. In other words, the display only shows info in RUN mode, but it remains blank in SLEEP mode (as expected) and also in STANDBY mode (this is not the expected behaviour). As a side effect, the auto turn-off after 10 minutes in STANDBY does not work, the machine does not auto turn-off.

I've found some info on this problem in this forum ( see message 5 here ), but this was a 13 years old thread.

In order to diagnose and fix this problem I've done, by now:

• tested the machine with 2 different CPU boards (a 2-transistor C and a last gen. CV), both showing the same behaviour.
• desoldered the display board to check all tracks in the keyboard PCB. I'm sure there are neither shorts nor open circuits on such PCB.
• soldered again the display PCB checking that the metallic strips really connect both PCBs. I've checked continuity from the zebra strips between the CPU & keyboard PCBs to the tracks in the display PCB.
• cleaned keyboard and CPU PCBs with isopropyl alcohol.
• inspected the display PCB under a loupe trying to see any short/open. I cannot see any problem.
  

I'm suspecting that the oscillator in the LCD driver is not starting when the machine enters STANDBY mode. This explains both the dead LCD in such mode and also the non working auto turn off, as its timeout is controlled by the display oscillator.

Has anybody see this problem previously? Any clue about how to solve it?

Thanks & regards.

edit: I've forgotten to mention that the current consumption of the machine is, more or less, normal. About 5 mA in RUN mode, 500 uA in STANDBY and 35 uA when SLEEP. Batteries are new.

edit 2: lines PWO and SYNC work as expected. PWO high, pulses in SYNC when in RUN mode. PWO low and SYNC high in STANDBY (SYNC does not go low after 10 min). Both PWO and SYNC low in SLEEP.

[emece67]

A pity nobody can give a clue.

In any case, I keep looking for it. I've found that, in a a working 41, the display OS1 signal stays at 0.9 V in RUN and SLEEP modes, whereas it shows a triangular waveform, between 0 and 0.9 V (at a frequency of 7 kHz) in STANDBY mode. The 7 kHz frequency is consistent with the 11 minutes timeout, as the LCD driver chips wait for the timeout 9·2^19 ~ 4M7 cycles. At 7 kHz such number of cycles means ~11 minutes.

My faulty 41 does not show such triangular waveform, it remains fixed at 0.9 V anytime. I do not know yet if the oscillator is faulty or there is another reason for this behavior (although I am missing the hope on such).

Regards.

[Frido Bohn]

(04-21-2015 01:45 PM)emece67 Wrote:  A pity nobody can give a clue.

Sorry that nobody seems to have an appropriate solution to your problem.
My first guess on the broken post issue was that the contacts of the so called "zebra strip connector" or of the flexible bat PCB to the main PCB could be the matter of concern. As these contacts are only warranted by perfect fitting and firm pressure they are the Achilles' heels of the HP41.
These are only some general hints on this matter and may be not of real value to you as you already did such sophisticated measurements on the electronics.

Cheers,
Frido

[jebem]

I would recommend the Service Guide, in case you haven't got copy yet.
It is available from here (MoHPC).
I really recommend it, as it contains very detailed instructions for diagnosing and troubleshooting the 41.

From what I understand, when the CPU is running, the signal PWO is at high level and then the lcd driver uses the SYNC signal as a timing reference. When PWO goes off and the stby mode is active the cpu DPWO signal is high to allow the internal driver clock to run for a period of 10 minutes.

Besides that, the CPU controls the source voltage to be applied to the circuits and LCD.
When the LCD is in active state (in run mode or in stby mode), the power supply should feed a stabilized 6V supply to +Vcc.
However, when it goes off (sleep mode) the supply voltage goes below the battery level.

I would start by checking for the proper +Vcc voltage, probably the power supply IC is damaged, or the battery supply is insufficient.
You may also check capacitors C9 and transistor Q1 and Q2, as it are related to the cpu stby mode switching.

[Geoff Quickfall]

If, IF: no other issues such as memory lost or freezing ocur, then probably not the posts. Inspect them anyway.

Now to the display drivers; have you swapped the LCD with a known working board. What happens, if not, you can trouble shoot the board but the LCD panel contains the display drivers. They are found under the epoxy blobs and are inaccessible.

A spare working panel from an elswise dead machine is your best bet.

I have repaired four weird and wacky displays after checking all other connections and solder joints on the LCD panel; with spare panels from donors.

The latest being a 1979 tall keys needing a new LCD panel with working drivers for a CL conversion.

Cheers, Geoff

[emece67]

Thanks Frido, jeben & Geoff.

In fact I'd read the service manual (and the LCD driver chip manual) prior to starting the repair, so I have some knowledge of the expected behaviour of signals and voltages. After being sure that the pressure strips work, such signals were the next thing I diagnosed.

Apart from this 41C, I only have another fullnut (a CX) I can use to interchange the displays and see what happens. But up to now I'm reluctant to remove the LCD from the working CX. If, for any reason, its LCD also gets faulty... not a nice situation.

But it is probable that, in a few days, I'll feel that this is the last and definitive test I can perform to be sure that the problem is in the LCD assembly, so perhaps this weekend I'll perform the surgery.

Geoff, I have checked with a multimeter continuity from the keyboard PCB tracks to the tracks entering the epoxy blobs in the LCD assembly, but not having dismantled the LCD I haven't checked all connections on it.

I'll keep reporting here.

Regards.

[emece67]

Well, I've made some definitive tests.

The suspect LCD display was removed from the board, dismantled, its board cleaned with isopropyl alcohol, reassembled and mounted on a working 41CX. It behaves the very same way, so its driver circuits are, definitively, faulty. It's amazing that being stored in a drawer for years affects not only the posts, but also the LCD electronics.

Hope I can find a replacement somewhere.

Regards.

[Frido Bohn]

(04-26-2015 07:29 PM)emece67 Wrote:  It's amazing that being stored in a drawer for years affects not only the posts, but also the LCD electronics.

This is indeed bad news for the long-term preservation of the HP41C series. Hopefully, this was an incidental occurrence only and won't become a wide-spread problem.

Do you have any ideas why this could have happened, e.g. moisture or discharges during manipulation?

Cheers
Frido

[emece67]

(04-27-2015 09:13 AM)Frido Bohn Wrote:  Do you have any ideas why this could have happened, e.g. moisture or discharges during manipulation?

When fixing the broken posts problem, I used a Dremel in some places to remove some plastic. Not wanting the plastic dust to enter inside the display or key domes, I covered both keyboard and display PCBs with an adhesive tape. I've made such thing many times before but, who knows, perhaps this time some electrostatic charge managed to built up in the tape.

In any case, the datasheet of the display drivers claims that the on chip oscillator is controlled by a flag, called IAF from "I Am First", whose state can be altered by high loads on the DATA line. Apparently, the first one of the 2 driver chips, that tasked to start the oscillator, is not really aware that it is the first in the chain.

I'm studying ways to overcome such behavior, perhaps with an external oscillator.

Regards.

p.s. I do not know why, but I'm having a bad time with electronic glitches. Two days ago I managed to get the (almost) impossible: I bricked a hp30b when upgrading it to a wp34s. My last attempt will be to use a JTAG probe to try to revive it.

[emece67]

I've found that applying a 7 kHz, 0-6 V square wave to the OS1 pin of the display board solves the problem, even the 10 minutes timeout works as expected.

Thus I'm planning to attach a oscillator to the machine. It must only work when the DPWO signal is high. Seems feasible... except for the low power requirement.

Regards.

[jebem]

(04-28-2015 07:55 PM)emece67 Wrote:  I've found that applying a 7 kHz, 0-6 V square wave to the OS1 pin of the display board solves the problem, even the 10 minutes timeout works as expected.

Thus I'm planning to attach a oscillator to the machine. It must only work when the DPWO signal is high. Seems feasible... except for the low power requirement.

Regards.

Excellent news.
I would say that an rc oscillator around a cmos NAND gate should do the trick.

[robert rozee]

a CMOS 555 timer (LMC555 is one such example) may be a good choice, with plenty of output drive and a reset pin that when tied low will inhibit oscillation. see:
www.ti.com/lit/ds/symlink/lmc555.pdf

cheers,
rob :-)

[emece67]

A 555 shows way high power consumption. Thanks anyway.

I'm now trying to find the internal structure of the OS1/OS2 circuitry in order to use its working parts, thus minimizing the external components to add.

[TASP]

I think to maintain the purity of the calculating experience of the HP41 with the display problem, the only feasible work around is this:

http://www.hp.com/hpinfo/abouthp/histnfa...ents/0002/

Just wire it up to the display, and there you are. It would be an attention getter at conferences too.

[emece67]

Workaround working. Of course the surface mount version of the chip (a simple 4093) is much smaller & will fit on the LCD board.

The overall current consumption is well within specs. In fact, when the calculator is off, the current in exactly the same with or w/o the workaround, so I expect the very same battery life.

In a few days I'll post the schematic of the workaround and also my findings about the OS1/OS2 logic.

Regards.

[Didier Lachieze]

Great ! And btw, how did you fixed the broken posts ?

[emece67]

(04-30-2015 10:38 PM)Didier Lachieze Wrote:  Great ! And btw, how did you fixed the broken posts ?

I've taken some photos of the process. Will also post them in a few days.

[emece67]

This is how, I think, is the logic concerning the OS1/OS2 signals of the LCD driver chips.



In STANDBY mode, signal DPWO is high and PWO (CPU driven) is low. The IAF signal of the 1st chip is always high. Thus, the output of gate U1 is high, enabling the astable multivibrator around U0. Pulses generated by this multivibrator reach the internal counters and also the internal counters of the 2nd chip (via OS2), as the three-state buffer U2 is also enabled by IAF. After 9·2^19 (aprox. 4M7) pulses, the driver chips disable, forcing DPWO low, thus disabling the multivibrator and forcing the CPU to drive SYNC low, the system enters SLEEP mode.

In the 2nd chip, the multivibrator is always disabled because its IAF signal is always low. Its multivibrator is also isolated from the internal counters as U2 is disabled. Thus, its internal counters are driven by the OS2 signal coming from the 1st chip and both chips keep synchronized.

In RUN mode the multivibrator is disabled (because PWO is high, thus the output of U1 is low, which disables U0). In this case, OS1 is high because the high level at the output of U0 reaches OS1 thru Rf. As U2 is enabled, OS2 is low.

The Schmitt trigger NAND gate U0, with C2 and Rf, forms an astable multivibrator. The thresholds of U0 are aprox. 2.0 & 4.3 V. Being Vcc aprox 6.3V, the frequency is aprox 0.653/(Rf*C2). In this case this is aprox. 7 kHz. 4M7 pulses of a 7 kHz signal means aprox. 670 seconds, aprox. 11 minutes, the STANDBY timeout.

Finally, in my machine, it seems that the lower input clamp diode of pin OS1 has been damaged by an electrostatic discharge, as there is a (relatively) low impedance when looking into OS1. Such impedance Rc forms a resistive divider with Rf that prevents the gate U0 to drive OS1 above aprox. 0.8V, thus not reaching the threshold levels of U0 and preventing oscillation. Thus, in my machine, the LCD driver chips remain stopped in STANDBY mode, thus blanking the display and preventing the system to enter SLEEP mode. When a key is pressed or the system is running a program, the CPU drives clocks PHI1 & PHI2 and maintains PWO high, in such situation the LCD driver chips use PHI1 & PHI2 to control their internal timings, so the display works.

In a while I'll describe the patch I've applied.

[emece67]

As U0 does not oscillate because of the damaged clamp diode, and it is not possible to remove it, the obvious workaround is to replace the oscillator by an external one.

An external oscillator (with an output impedance lower than than of the damaged diode) driving OS1 will do the trick. The low impedance of such oscillator will "overdrive" the damaged clamp diode. The pulses will reach U0 that, being enabled by U1 in STANDBY mode, will pass them to its output and thus to the internal counters and, thru OS2, to the 2nd chip.

In RUN mode, the external oscillator can be stopped, but it is not a must, as in RUN mode U0 is disabled (and thus the oscillations do not go beyond U0). If the current consumption of the external oscillator is much lower than the overall current consumption of the rest of the system, it is allowable to keep it working in RUN mode.

But in SLEEP mode it is mandatory to stop the external oscillator, otherwise the current consumption is such mode will be high, seriously reducing battery life. Evenmore, in SLEEP mode, OS1 must be maintained low, otherwise the DC current consumption on the damaged clamp diode will also affect battery life.

Signal DPWO can be used to switch the external oscillator on and off, as such signal is high in RUN and STANDBY modes and low in SLEEP mode.

Thus, a low impedance, low current consumption, switchable astable multivibrator is what is needed to solve this.

The power consumption of the system in SLEEP mode is very low, in my case it is around 38 uA. This prevents the use of TTL, HC, and many analog chips because of excesive power consumption. So, the external multivibrator must be built around discrete transistors or using 4000 series chips. The later seems way easier. Evenmore, the 4000 series chips date back to the late '60s, so they are appropriate for a vintage calculator, even TASP will find it right ;-)

So, the patch is this:



A single 4093 gives 4 Schmitt trigger NAND gates. One of them is used to build the switchable astable multivibrator with the same architecture to that inside the LCD driver chip. It is controlled by DPWO. A 2nd gate is used to invert the output of the multivibrator to ensure that OS1 is low when the system is in SLEEP mode. The other 2 remaining gates are unused.

The thresholds of the 4093 gates are not the same as those of the Schmitt trigger inside the LCD driver chips, thus, to maintain the same timeout period of 11 minutes, it is needed to modify the value of the resistor from 200k to 470k.

Capacitor C2 in the CPU board is no longer needed. Opening the connection between OS1 and such capacitor will lower the power consumption in STANDBY mode a bit.

I have also tested another version of the multivibrator (with another more resistor and a diode in the feedback net) that produces the same frequency but drives OS1 high a very little time and low a longer time. The expected goal was to minimize power consumption in the damaged clamp diode, but the measured power consumption was almost the same (only a 5% decrease in STANDBY mode). Perhaps other parts of the LCD driver chips "do not like" to be driven by an asymmetric clock. Thus I finally used the symmetric multivibrator.

Finally, the current consumption of the whole system in SLEEP mode is the very same with or without the patch (my multimeter sees down to 0.1 uA). In RUN and STANDBY modes it has risen about 150 uA, which is almost negligible in RUN mode (from 5 mA to 5.15 mA) and acceptable in STANDBY mode (from 550 uA to 700 uA). The battery life will be affected very slightly.

Hope this helps, regards.

[emece67]

Detail of the PCB in the display module. Some vias are labelled with the signal they carry. The bottom view is mirrored, so its traces look as seen through the PCB from the chips side.