HP Forums

I was on my way to London, currently at 35,000' in the cockpit over Greenland. I was looking forward to the HPCC meeting at Imperial College which I try to make every second Saturday of the month. I was demonstrating the capabilities of the HP41CX I had:

The current configuration is a double X memory followed by a Clonix and then an IR module for printing. I also carry an infared printer and card reader with a 'wall' of cards.

The double x memory contains 423 registers of program and data files while the program registers contain the programs associated with the key overlay you see in the picture above.

While I was demonstrating the calculator I placed it on the communications panel separating the two pilots seats. This panel, pictured here:

is backlit with incandescant bulbs and generates heat. I refer to the position just forward of the thrust levers where the paper can be seen. Placing the calculator on the panel will cause the calculator to warm but only slightly.

Now that the background has been set let me tell you what happened!

I had turned it on and was explaining the functions and modules etc. to a fellow pilot when the calculator started to warm up and the battery enunciator came on. I thought it odd that the batteries would be low as they were new. At the time, the heat I thought was transfer from the panel described. As I continued to demonstrate, all functions and modules working correctly the calc got warmer still.

At this point I got alarmed, turned it off and it continued to get even hotter. I removed the battery pack and then each module which included the CLONIX, Double X memory, and IR. I then cooled the whole package down with an air vent. I left the calc for an hour as other duties occurred.

On my break period I reinserted the battery pack with out the modules into the calc. All functions were perfect. I then introduced the double x memory and to my surprise it had maintained the data and program files without any loss! After installing and removing each module sequentially and testing the calculator, I then inserted all the modules and started the calculator. It functioned perfectly with no loss of any memory or damage to the virtual memory. I could not duplicate the failure.

The CLONIX module however, received physical, but not internal damage in the form of a heat distorted module case.

Also a faint smell of burnt marshmallows emanated from the opening of the module.

As I stated, the calculator works perfectly and the only result was the to the Clonix module case. The internal volatile memory of the Calculator, Double x memory, Ir module nor the CLONIX were disturbed in any way.

It was postulated at the HPCC meeting in London this Saturday that it may have been a stray cosmic ray interacting with a thyristor (spelling?) in the calculator creating an 'on' loop or short.

I guess I was just lucky that I did not leave it on the console running without checking!

Interesting story, I think, and to see physical heat damage to the CLONIX module with no disruption of the internal components is quite remarkable.

If Diego is reading this, it is a testament to his CLONIX that although it recieved enough heat to damage the module case, the circuitry in the module survived intact! It uploads and downloads through the pic programmer to the PC and functions perfectly in the calc. Still fits too!

Any other explanations are welcome.....

Cheers all

no offense [ but as a former military pilot] My first thought is isnt anybody in the cockpit looking these days, you know; 1] aviate 2] navigate 3] communicate

Yes Geoff, I'm reading this... and despite the fact that the Clonix survived the heating experinece, I'm certainly not happy to see the module so badly damaged.

The main question is that this also happened with one of the early Clonix-41, few years ago. The heat comes "from" the PIC inside Clonix.

I replaced the unit, (and of course I will replace your unit too) and was trying to reproduce the failure with the "damaged" unit, but after several hundreds of insertions/extrancions; power cycling; even extracting and inserting with the calc ON... I was unable to reproduce the over-heating.

Currently there are about two hundred units in the field, and I myself "abuse" of several Clonix and NoVRAM modules in many different ways... (i.e. connecting an HP-41 to a Power Supply adjusted to 8.4 volts, with Clonix running continuously for 24hours... no that I want to burn anything, just trying to see if a couple of Li-Ion cells can be used to power an HP-41; but that's another story...)

The causes for this behaviour are completely unknown for me... some sort of specific situation: first I thought of a "defective" PIC... but I think that your PIC is from a different batch (I also want to check that point), so there must be another type of "trigger" for this failure: difference between V+ and BAT... ESD... rising slope of V+ from BAT... or a combination of all of them. I know how to avoid it though, with a small limiting resistor.

I can replace the modules but my main concern is the valuable Calculators... two cases out of two hundreds in five years is a 0.2% per year ratio... not "disastreous" but certainly it does not makes me happy at all.

Please mail me to arrange replacement. I want to examine your unit very closely, and compare with the other "Toaster/Clonix" I have(which BTW is also perfectly working). And of course I'll send you a burn proof modified Clonix.

Sorry for the inconveniences.

Cheers and good flight back home.

Diego

Such a failure would most likely be caused by CMOS latch-up, especially given that the module apparently worked correctly later. CMOS latch-up occurs due to the presence of parasitic SCRs in the chip. Usually latch-up only occurs when the electrical specifications for the device are exceeded. Various techniques are used in chip design to minimize the possibility of latch-up, but in general it cannot be completely prevented with normal CMOS processing.

Fairchild application note AN-600 "Understanding Latch-Up in Advanced CMOS Logic" gives a good explanation of the problem, though the specific preventative measures they describe may not be identical to those used in other parts such as PIC microcontrollers.

Some chip designs are more prone to latch-up than others. Years ago I was involved in the design of a product that used a 10-base-T ethernet transceiver chip designed by MicroLinear, and those had terrible latch-up problems. We had to switch to a part from a different vendor, which unfortunately was not even in the same package, let alone pin-compatible.

The current flight was 10 hours non stop duty with a three hour break broken into a 50 minute break and 120 minute rest period in a bunk. The flight left YVR at 6PM and arrived in London 10 hours later.

During that time, we plot, check, navigate, communicate and eat, go to the washroom, have chats, review emergency procedures, review aircraft systems.

It was between waypoints, as I stepping out of the cockpit for my 120 minute rest, with one pilot occupying the Capt seat and the second occupying the First Officers seat. The waypoints were 450nm apart, the plot had been made, the waypoints crosschecked for the 3rd time (SOP's), a scan had been completed and I, with HP41CX in hand had just done an independent check using a Great Circle program I had written to confirm our current True course and distance when the latchup occurred.

So rest assured that after 32 years of flying professionally that when conversation occurs in my cockpit all duties have allowed it. I am sure that in your cockpit, fighters? transport? that you to have shared a moment of relief from the tedium of a 10 hour flight. I only answer this to indicate to the people that have no idea what goes on that indeed at some points in time there actually is a lull where each individual is primed for emergencies and common duties but where conversation is permitted.

One thing over the last 30 years that I have noticed is the science of sleep and awareness that the aviation industry is subjected to. One of the conclusions is that NO ONE can concentrate for 10 hours straight without degradation in response time, awareness and etc.

In any case the latch up was interesting and did not interfere with the Cockpit Resource Management.

Cheers, and keep the shiny side up.

Geoff

Edited: 13 Oct 2008, 10:25 p.m.

Do you think it can occur again? If so I will remove the current module. It does appear to be functioning perfectly, but now since it may not be a 'ramdom' occurence I think I should remove it.

Since I have it I cannot do without it!

I will email you soon.

Cheer, Geoff

Hi,

Eric, I'm aware of latchup and am pretty ure that, as you've pointed out, this is the "effect" which produces the overcurrent (and therefore the heating) at the BAT line.

My question still is: What triggers this latchup?

According to Microchip's datasheet:

"Voltage spikes below VSS at the MCLR/VPP pin, inducing currents greater than 80 mA, may cause latchup.
Thus, a series resistor of 50-100Ohms should be used when applying a “low” level to the MCLR/VPP pin, rather
than pulling this pin directly to VSS."

This is the only mention to "latchup".

In a previous chapter:

"To take advantage of the POR circuitry,
just tie the MCLR pin directly (or through a resistor)
to VDD."

The Clonix circuit just connect MCLR "directly" to BAT. So it should not get under Vss (GND), ever!

But, despite of this, it is evident that under certain -not frequent- circumstances (and that's what's driving me crazy: I cannot determine "which" circumstances causes the undesired latchup effect) the fact is that the BAT line get's shortened thru the MCLR pin of the PIC.

The PIC chip can stand up to 150ºC while the plastic housing starts melting at about 80-90. With this temperatures nothing can really "burn into flames" (fortunatelly), but the damage can reach the calculator housing, and the I/O Block contacts.

I'm already building a new Clonix, with an extra (theoretically innecesary) limiting resistor to replace the damaged one.

Though I don't know the primary cause of the failure, it's clear that the effects are produced by direct BAT line conneciton to GDN thru PIC.

As the only point BAT is connected to PIC is at MCLR, I'll place a small limiting resistor this will cause current to drop to the (harmless) mA range in the event latchup will ever happens again.

Geoff, are you planning to attend Allschwil meeting?

Please keep in contact.

Best wishes.

Diego.

I have now sat through 3 power failures at our house in the last 5 hours!

So I have being trying to reply, I think our local Hydro company is having it's share of latchups!!!

Going to read the article now that you refer to.

Thanks again, Geoff

An interesting problem, can latch up be caused by cosmic ray interference?

In any case one would think the latch up would be a permanent not transient problem, but what do I know? Certainly as time passes listening to the likes of Eric et al in Corvallis, it would seem at lot less than I thought ;-)

Cheers, Geoff

Diego, I sent you an email about the module.

Hello Geoff!

Quote:

---

Any other explanations are welcome.....

---

Well, let's give it a try :-) I'm not really happy with this cosmic-ray-triggers-runaway-current-on-chip theory.



- First, at an altitude of 35.000ft, cosmic rays shouldn't be much of an issue yet.

- Second, how can it be that an obvious short-circuit inside a chip can generate enough heat to melt the plastic casing, but not enough to damage the chip itself?

- Third: Do the "old-fashioned" N-cell batteries really hold enough energy to melt the plastic housing of the calculator? Are the (horribly awful!) flexible-PCB-module-connectors of the HP-41 strong enough to carry such currents without melting? If so, we really should start worrying about high-energy-battery driven items on board of aeroplanes. Like iPhones/iPods/notebooks/cellphones/digicams with LiIon-batteries that are known to be able to burst into flames when shorted!



To be able to identify the cause, it would be useful to know the melting point of the plastic used for the module housing. Then one can start looking for heat sources with sufficient temperature. I know nothing about the systems of your Boeing (767?), but looking at aeoplanes I used to fly (e.g. C421 and Metroliner) and the ones I fly now (Citation) the following possible "culprits" come to mind:



- Gaps between the panels (or around the thrust levers) through which exits cooling air from the avionics. I see your aeroplane has CRT displays (including the FMSs) that produce a lot of hot air. The papers lying aoround could channel such hot air from a different place to where you put your calculator.

- Does your aeroplane have electroluminescent switch panels (I can't tell from the photos)? These get get quite warm in some places and they have inverters close to them that produce the high voltage required for their operation. On some aeroplanes (the Cessmna 421 comes to mind first) these inverters are so poorly shielded that you can hear them on the radios. Placing a calculator next to one could lead to induced currents in its PCB or components. If the molten plastic contains carbon particles (for the black colour), it could be directly heated by induction!

- The same induction could come from other HF-sources close by. Like an improperly shielded line-transformer inside one of the CRTs (there are quite a few of them around). Or the inverter of the "neon-tube" floodlighting of the instrument panel (if your aeroplane has that).

- Does your aeroplane have ducts with unconditioned bleed air that lead through the cockpit? Our Citations have them for window de-icing and de-fogging. A very minor leak could release a small jet of hot air capable of melting the plastic.

Of course, without knowing the melting point of the plastic all this remains pure speculation.



Greetings, Max


NB: Just hope that the same thing dosen't happen to your HP-01, otherwise it might be very painful ;-)

Edited: 14 Oct 2008, 6:13 a.m.

The housings are made of ABS, which has a melting point around 105C. (May vary depending on additives, etc.)

N cells certainly can provide enough energy to melt a small amount of ABS.

Quote:

---

I'm already building a new Clonix, with an extra (theoretically innecesary) limiting resistor to replace the damaged one.

---

diego,

i don't have a direct solution to the problem, however, a polyfuse 1210L005 instead or in series with the voltage bleeder resistor might be worth a try. yo can find the datasheet here:

http://www.littelfuse.com/data/en/Data_Sheets/Littelfuse_1210L.pdf

cheers,

hans

Hi Diego,

Based on the schematic from your site, I understand that the PIC is supplied by V+ (through a limiting resistor) and MCLR is connected to BAT. Does that mean that when the HP41 is off, the PIC is not supplied but there is a voltage on MCLR?

I didn't find the time yet to assemble my own Clonix due to other ongoing projects...

J-F

Hi Hans,

Certainly the aim of this resistor is limiting the current to prevent battery to become short-circuited thru the latchup.

Using a fuse, will render the module unusable if it ever happens a latchup situation. Anyhow, thanks a lot for the reference as it can be very useful in future projects.

A 62Ohms resistor will limit the max current to <100mA, which is basically harmless. Just removing the module will cease latchup while keeping module functionality intact.

Cheers from the Canaries.

Diego

Quote:

---

Using a fuse, will render the module unusable if it ever happens a latchup situation.

---

I expect the problem came from a static discharge. I've seen that before on my workbench, and cycling the power took care of it. The low humidity in the aircraft probably contributed to the static. Good shielding should prevent the problem.

Hi Jean-Francois,

Quote:

---

Does that mean that when the HP41 is off, the PIC is not supplied but there is a voltage on MCLR?

---

Not really, when HP-41 is in OFF (Deep Sleep) state the bipolar power supply IC stops generating V+ (6.4v) but V+ line is feeded with BAT voltage trhu a diode. Thus, both V+ and BAT stay at the same voltage.

Please in case you decide to build yor own Clonix mail me and I'll help with the details.

Anyhow, hope we can talk about it during the Allschwil meeting... :-)

See you there.

Diego.

Hi Garth,

I just oversight the big "Resettable" label and jumped directly to the small print under "Features" and then "sizes"; where, surprisingly, nothing is said about the ressetable feature (?)

Obviously this changes the concept in a very positive way... ;-)

I'll check for a suitable provider.

Many thanks for the hint and the remark about resettability!

Cheers.

Diego.

the heat enviroment of the 767 cockpit is such that the extreme temperature bulbs are shielded and overhead. Granted the background lighting composed of minuture incandescent bulbs generate heat, but that is vented by the avionics cooling system.

The console above the main instruments and the centre consol are warm to the touch not 'hot' That is why I initially did not recognize the latch up at first. When I picked the calc up it was warm due I thought to direct heat transfer to the casing. As I held the calc and started executing programs the bat annuciator came on and the battery housing became warmer still. I realized at this point that the calc was generating it's own heat. Removing the batteries and then the modules allowed me to cool the calc down with the gasper vents.

The batteries did not cool down for some time as the chemical reaction in them continued to generate heat. These batteries have been discarded due to the 'short'.

ESD is probably the culprit and HP 41C are notorious for that going right back to the advent of the first HP41C and continuing to the last design. In fact, in conversation with Richard Nelson in Corvallis last month I brought up the fact that ESD causes many a "memory lost" condition on my HP 41c, HP41CX and second HP41CX. This is or was known by HP and was extensively tested for in Corvallis. The key here is it was tested in corvallis which at best runs around 85% humidity ;-) They could not reproduce the results of ESD that Richard was finding in the midwest of the USA.

I rotated all three through the cockpit to make sure it was not a specific unit. I carry a 'wall' of cards including sythetics to reboot the calc to it's programmed state.

My precautions include and antistatic bag which contains the calc in my flight bag. If I remove or install the card reader and modules I always breathe into the module port to temporarily increase the local humidity.

So the simplist (Ocams razor) solution is an ESD that cause a Latch up condition in the clonix41 chip grounding it to the VCC (if I read the explanation correctly).

Cheers, Geoff

Quote:

---

In fact, in conversation with Richard Nelson in Corvallis last month I brought up the fact that ESD causes many a "memory lost" condition on my HP 41c, HP41CX and second HP41CX.

---

My HP-71 got it a couple of times, and a friend said he had it several times, and he suspected it was just from keys getting pressed while it was in his attache case. Acting on that tip, I had a wood-worker friend make me a box out of 1/8" plywood that the 71 in its case would slide into, so the keys would not get pressed in the attache case. Problem solved. Not a single memory-lost condition in the last 15 or 20 years since then.

Hi Diego,

I acquired another Clonix module, apart from the one I got from you, when I purchased some HP41 accessories. The module's plastic casing is similarly damaged and the seller told me that it happened when he accidentally left the module in a window where there was direct sunlight. The module, however, can still be inserted into a HP41 and functions well. If you are interested to investigate I can send you this. This is just another case like the one currently being discussed except that it happened on the earth and not in the sky.

Best regards,

Prabhu