Interesting HP-65 card reader failure mode

[John Garza (3665)]

First time I've seen this one...

HP65 #1333A09948 exhibited some squeal at the end of a card read, but the read was successful.

So, I replaced the coupler and cleaned/lubed the worm gear and thrust bearing. Along the way, a couple of head wires became detached - so I re-soldered them. And I double checked they were soldered in the right places.

Now... the machine reads cards in error without a flashing zero. What I get is the wrong program. Not random data, its always the same (but wrong) program steps for a given program card recorded on a good 65. It looks like some bits were dropped/misinterpreted with regularity.

I re-soldered all the head wires and replaced the 22uF caps from the head. No change. I'm suspecting the sense/amp chip, and I have some spares for that. But I wanted to get a second opinion from the group before I start.

Opinions?

-J

[AndiGer]

That‘s or not the standard codes that are loaded when you switch the 65 on?

[John Garza (3665)]

(09-20-2024 06:58 PM)AndiGer Wrote:  That‘s or not the standard codes that are loaded when you switch the 65 on?

No. They change depending on which card is read. And I've see some RCL 3, RCL 8, etc. instructions in there which I do not believe are in the pre-programmed 'convenience' keys.

And... I've also tried swapping the CPU card. No change.

I've seen bad heads before, but I just never got a signal at all in that case. Here, there is a signal, just garbled. So, I'm thinking it's the sense/amp chip. I guess I must have fried it when re-soldering the loose head wires. Lab RH was 55% though. Never seen anything get zapped at that level. If it's not the sense/amp chip, then it must be a head failure but not a complete failure. Would head magnetization cause it?

-J

[teenix]

Have you checked the card speed and head pressure which may have changed if the drive wheel cam axle is not in its original position?

Did the new coupler introduce some spindle vibration?

Have you cleaned up any soldering residue around the repair? It has been reported in the past that dirt and grime around the sense chip can upset the reading of a card. HP reported that some sense chips are working at their limits of operation and thus any upset might cause them to play up.

Are the sense board to CPU board connections still tight and clean?

The head might just need a simple cleaning.

To help verify some of the sense chip operation, are you able to check a card write that reads ok in another 65.


The sense chip is a bipolar device, so it may? be less susceptible to static damage. Not moving around too much during a repair would probably minimize any bodily static build up and each time you place solder on an earthed solder iron tip you automatically discharge yourself.

The default program code for the A - E keys is transferred from the ROMs into program memory at start up. Reading a card overwrites this as it would for any residing program.

cheers

Tony

[John Garza (3665)]

(09-21-2024 06:38 AM)teenix Wrote:  Have you checked the card speed and head pressure which may have changed if the drive wheel cam axle is not in its original position?


Axle/wheel was not removed in this instance. So it is in the same position as when it was working.


Did the new coupler introduce some spindle vibration?


This, I think is the likeliest candidate. Running the motor outside of the mount, there is zero wobble on the tip of the worm gear under rotation. However the aluminum cylinder coupler was off maybe 15 degrees from parallel. That could have made the gear out of balance. I'll rework the coupler assembly and let you know.


Have you cleaned up any soldering residue around the repair? It has been reported in the past that dirt and grime around the sense chip can upset the reading of a card. HP reported that some sense chips are working at their limits of operation and thus any upset might cause them to play up.


Yes, I cleaned up everything and inspected with a magnifier both sides of the board and even under the pins of the sense chip.


Are the sense board to CPU board connections still tight and clean?


Yes, all good.


The head might just need a simple cleaning.


This machine has been in storage. I doubt a dozen cards have been read since the head was last cleaned back when I did the gummy wheel repair.


To help verify some of the sense chip operation, are you able to check a card write that reads ok in another 65.


A card written by this machine can NOT be read by another 65. I get blinking zeroes in the display.


The sense chip is a bipolar device, so it may? be less susceptible to static damage. Not moving around too much during a repair would probably minimize any bodily static build up and each time you place solder on an earthed solder iron tip you automatically discharge yourself.


Very true. Maybe I'm just overly cautious about damaging a chip that is no longer in production.


The default program code for the A - E keys is transferred from the ROMs into program memory at start up. Reading a card overwrites this as it would for any residing program.


Yep. The incorrect program codes seen do NOT correspond to the default code for the A - E keys.


cheers

Tony

[John Garza (3665)]

Well...

Replacing the coupler assembly did not help.
Neither did replacing the 3.3uF cap on the motor leads.
Neither did replacing both 22uF caps on the sense board.

The only parts remaining are:

Motor
Head
15 uF cap on sense board (incoming part)
Sense chip


Interesting to note a fixed program recorded onto a card from a known good 65 and read into this machine can take one of two forms:

Code as recorded by good 65:

Code:


LBL
A
5
X
RTN

Possible result 1:

Code:


DSP
EEX
g Rv
g x=y
2
3

Possible result 2:

Code:


RCL 5
STO 8
C
9
RCL 7
STO 6

-J

[teenix]

(09-24-2024 11:02 PM)John Garza (3665) Wrote:  

Code:


DSP
EEX
g Rv
g x=y
2
3

I was going to look at a bit pattern shift for the data sets, but I'm not sure what g Ru is meant to be, I guess 2 key presses [g] [9], and g x=y is [g] [LBL]. Either way, I could not see a pattern.

I think the only way would be to use a scope and check the data coming from the sense chip. You could also get an idea of the card speed through the reader as well. (1mS per bit)

The other components worth replacing are the power supply filter capacitors (60uF and 15uF) and maybe the Vss (6V) rail filter capacitor (22uF) - marked on the attached image. These caps, if faulty, have been known to affect the card reader.

If the card detect switches are not in proper alignment, this can also affect the reader.

It is just odd that it seemed to work prior to the repair.

cheers

Tony

[John Garza (3665)]

Thanks Tony,

That g Rv is 'roll down'. The lowercase V for the downward pointing arrow.

And I did try swapping out the CPU card with one from a known good 65. No change.

Since everything was working before I touched it for the coupler work, I'm thinking it is likely something I've touched. Perhaps even handling the motor by pushing the new coupler on the shaft may have been too much for a worn motor. I'll try a spare motor first, then the 15 uF cap on the sense board. If neither of those help, maybe the head or leaf switches. Although I didn't tear down the machine to the level of the leaf switches when I replaced the coupler - I just removed the motor from it's mount. I also have a spare frame with leaf switches and head. And a few spare sense amp boards. It's fun troubleshooting all this!

-J

[Geoff Quickfall]

Just repaired a 65 for one of the HHC2024 committee members. It had me wondering why it was not reading cards from other machines.

I would insert the diagnostic card from one of my pristine restored 65’s , I have about 4 of these restored.

Insert the card, it would run through on the new silicon tubing and new couple made from insulating wire, but the motor would keep turning even after the card was removed from the other side.

I tried all the machines and this HHC version would exhibit the same symptoms. Then I noticed that it did read the card even though it produced the error.

So I inserted a new blank card and wrote the diagnostic to the card using the newly fixed HHC machine. Perfect read and write.

So why will it 100% read and write to its own cards but not read with an end command, another card.

Well there are two “end” commands to a card. One is the “gold plated spring steel finger (one of five) and the second is the card reader signal placed on the card with the last line of the program.

So what was failing? To compound this, this new card reader would occasionally read correctly another machines card.

Only a hypothesis:

When we pull the eccentric to address the pinch roller we change a few things. The pinch roller material is of a different OD. Therefore the eccentric pins old position is no longer the correct position.

To correctly set the eccentric you are to measure the current draw while the card is being pulled through. OR you can set the eccentric and manual change it while you are trying the read write until you hit the sweet spot.

Also, the speed at which it goes through the reader will trigger a problem. Now some of the 65s have a variable capacitor which regulates the speed of the motor while other 65s have a fixed capacitor in place.

The trick now is not only to get the eccentric in the correct position, one must also match the card read speed and be consistent among all the 65’s one is using in order for them to be cross compatible.

So I set the newly restored machine to read the standard pac, and other manufacturers original cards at 100%. Once read I wrote to NOS blank cards and tested it again and it reads writes at 100%

Now to apply that standard to the others.

I think what happens is the factory standard with the factory pinch roller and factory set trimming capacitor all vary. The roller as we are not using the specific OD and have to fuss with the eccentric and the trimming capacitor aging. We are not replacing like with exactly like as they did at the factory.

Combine all that with fixers, restorers, all using differing methods and trials to fix their machine which may be just that bit ‘off’ the standard. Then you meet someone with a 65 that is off from the standard in the other direction to yours (opposite sides of the bell curve to the median as yours is) and there is no read write.

Just my two cents, the moral is, if yours reads and writes at 100% and read the manufacturers issued pacs then you have nailed it. Try to read someone else’s card and you may have a problem.

Again, this opinion is worth the paper it is written on :-)

[teenix]

(09-25-2024 03:46 AM)Geoff Quickfall Wrote:  Again, this opinion is worth the paper it is written on :-)

In my opinion it would be correct. The specification for HP-65 card reader speed is +/- 2%, so outside this range there might be problems. The sense chip, speed control resistor and motor mechanicals are all old now and overall may be out of this spec.

The replacement drive wheel material may not be as temperature tolerant as the original polyurethane material, and as was mentioned may not be the same diameter when compressed against the card during transit.

The data speed flowing into and out of a card is important because of the relationship between that data and the 600 bit circulating buffer to which it is read from or written to. Perhaps too fast or too slow and the bit patterns of the data get skewed. The other card readers of this type, 67 97, 41 are controlled in software, not so much hardware. There are still some timing considerations, but some variations can be absorbed by the operating code.

Just like the other readers, there is a list of odd value resistors that could have been used to trim the motor speed for a particular calculator. This is required due to manufacturing tolerances of the circuitry, hardware and motor. I guess for a factory, it is a simple test to determine the motor current when a known load is placed on it. A trimmer resistor can then be fitted to suit.

These seem to be in the range 3 - 9K and it would be easy then to read the value of the manufacturers fitted resistor and build a small motor trim circuit.

You would need to disconnect the original resistor, then use two 1% resistors that in series are 5% or so less than the fitted resistor, then add a variable resistor in series with the 2 fixed value resistors such that the overall series resistance can be +5% (or so) of the original resistor.

For example, the original resistor was 4K64, so with standard values, use

Code:


Sense pin#1   ---------2K2--x--1K---2K2------- sense pin #2
                            |   ^
                            |---|

Use a multiturn trim pot for the 1K and you will get a fine adjustment of the motor speed. This is preferable because the motor adjustment is touchy, and it will stop you accidently connecting the sense inputs directly together when adjusting the trimmer.

Use the trimmer and ohmmeter to set the resistance closest to 4K64.

It may work properly now.

If not, using adjustment steps of (say) 100 ohms, wind the resistance down and see if the card reads ok.

If no joy, go back to 4K64 and wind the resistance up in steps and try again.

You could speed this up if you had an oscilloscope because you could check the data bit widths during adjustment and see that they are closest to 1mS wide.

Before trying this, I would wind the cam adjustment to put the least pressure on the card that will allow reliable drive. This will need some adjustment as the new drive material may not be exactly what was original whatever that was - consensus seems to be 1/4 inch, but I actually think it was a little less.

cheers

Tony

[John Garza (3665)]

Going back to HP65 #1333A09948

Replacing the entire motor/coupler/worm gear from a known good unit had no effect.

Replacing the CPU with a Teenix 65 CPU did show a difference: It correctly detected an error and gave a flashing zero display (good job Tony!). Unlike the original CPU that gave the user the impression it was a good read. However, switching to W/PRGM I saw it inserted a single STO 4 instruction at the top of memory with the rest of the locations NOP. This even though it was flagged as a read error.

I then tried the Teenix CPU in a known good 65, and it read the card fine, but still inserted the mysterious STO 4 instruction as the first step of the program, with the entire card contents inserted below it. Strange. Easy enough to delete the single extraneous step, but not sure why it's there. Maybe I need a firmware update.

On the timing resistor issue, I'll try that after my 15uF cap arrives. But I have my doubts as it was working long after I had fiddled with the eccentric / pinch roller / etc. Going back to my original post, this was a working unit with the gummy wheel fix done years ago. It read cards fine, but just started to give a little squeal at the end of the read. So I replaced the coupler between the motor axle and worm gear and re-lubed the thrust bearing. Then things started getting interesting.

-J

[John Garza (3665)]

You know...

I did add a little extra lubrication... so there is the possibility the worm gear spins a bit faster now.
Maybe enough to put it outside that +- 2% window ?
Time to start digging in the resistor bin...

-J

[teenix]

(09-26-2024 06:29 AM)John Garza (3665) Wrote:  However, switching to W/PRGM I saw it inserted a single STO 4 instruction at the top of memory with the rest of the locations NOP. This even though it was flagged as a read error.

I have no reports of this, but I will check it out. It'll may take a few days, I have to build a unit to test.

cheers

Tony

[teenix]

(09-26-2024 06:41 AM)John Garza (3665) Wrote:  Re: I saw it inserted a single STO 4 instruction at the top of memory

I was having some frustration with something I was working on, so I decided I would save my sanity (what's left of it) and make up a new 65 CPU board.

I keep my program cards inside a tin box, which under my current living circumstances I was lucky to find. I wrote a small test program and wrote it to the card, then it read back which was ok and the program ran ok. I'm not sure why the error happens as stated, but maybe it just needs a reflash to fix.

There is a function available from the CalCom program where you can dump the 65 program memory to the PC screen. This can be helpful in seeing what was actually read from a card.

cheers

Tony

[John Garza (3665)]

I remembered I had another Teenix CPU card, an older one (with the switch on the board). So I tried it, and it exhibited the same issue with the mysterious inserted instruction. The newer one was very new, I had just received it from you this week.

Maybe this is somehow a common fault to these two 65s. One has the known issue we are pursuing in this thread, the other works fine with the original CPU card. However, these are just two examples.
I'll get a few more HP-65s from storage and test those too.


-J

[teenix]

Ok, I'll keep fiddling :-)

Is the program you are using to test available? That might have some effect.

cheers

Tony

[John Garza (3665)]

It was the example posted earlier:

Code:


LBL
A
5
X
RTN

But, I have noticed it happens with any card. I had a Heat Index Equation card in one of the 65s, so I loaded it and the STO 4 came in as the first step, then the remaining program steps after that.

The extra instruction usually does not impair function as there is no user defined label before it. It becomes 'cargo code'. There are some 65 Pac programs that require a RTN R/S to initialize and that would execute the instruction. Still, the instruction should not cause problems unless you're loading all 100 steps and it bumps your last instruction off the end.

I tried four 65s with three tests each: the original CPU, the early Teenix (with switch), and the current one (no switch).
The results were the same:

HP65 #1333A09948 Original: (errors as described in this thread)
Both new: flashing zeros, inserts single STO 4, remaining steps NOP
HP65 #1333A02701 Original: OK Both new: insert STO 4, card program after
HP65 #1509S07379 Original: OK Both new: insert STO 4, card program after
HP65 #1333A06439 Original: OK Both new: insert STO 4, card program after

The first machine in the list is the one that was the original subject of this thread, so I expected some weirdness there.
Odd though the STO 4 still gets in memory even though there was a read error and the rest of the memory was NOP (35 01).

-J

[Geoff Quickfall]

Well time to get mine out and check.

[John Garza (3665)]

To summarize for those jumping in at this point:
2 issues at work.
1) HP65 #1333A09948 reads a card and mistranslates the program steps.
2) a couple of Teenix HP65 CPU cards insert a STO 4 in memory when reading a card.

Some more information on HP65 #1333A09948 running with the original CPU:

1) Replacing the 15uF capacitor on the sense/amp board did not work.
2) Head resistances are 50.5 ohms each (Red-Yellow and Orange-Blue wires)
3) Replacing the 5.6K speed control resistor on the sense/amp board with an external 10K multiturn pot produced some odd results. Settings near 5.6K reproduced the error. Slight deviations in the setting produced different codes, twice it produced the correct codes, but these could not be repeated on subsequent reads. Settings far beyond 5.6K on either side produced flashing zeros, or 'memory full' displays (negative signs) with either 35 01 or 41 codes in memory.

-J

[teenix]

Can the faulty 65 write a program to a card and read it back. That is the only option I have for testing, I don't have pre-recorded cards to test with.

With this limitation, I still cannot replicate the STO 4 error, but I'll keep trying.

It is hard to make sense of it, because the only way data can be entered into the buffer is via the HP-65 card command [memory insert] when a key is pressed in WPGM mode, otherwise this code is not executed.

STO 4 is program code [01]. This can't just be added to the buffer, it has to be inserted at the 1st program point and shift the buffer pointers as well. I am having trouble finding anywhere in code that might do this after the buffer is reset. I'll have to enable some traps to see if code is executing without permission.


Just a useless info tidbit...

The HP-65 uses 96 instructions to enter key [1] as a program step, the HP-67 uses 787 :-)

cheers

Tony