Convert&Restoration project of IBM 3742 beamspring keyboard

Heikkonen

06 Oct 2019, 23:29

I just recently picked up this beamer from being recycled, sadly the other parts of the system it was built for were long gone according the contact i got it from :(
unknown.jpg
unknown.jpg (67.27 KiB) Viewed 1727 times
The case itself was in pretty good shape but aluminium parts had some minor damage as seen below
Image

Image

I was surprised how good of a shape it was and it was been clearly kept well considering its age. I proceeded to open it and check the condition inside to figure out what kind of restoration it needed. I saw there was spots of rust but evaporust will take care of them soon.

Image

Image

Old documentation found inside:
Image

Image

First look after removing barrel:
Image

Image

Its time to remove the keycaps and see hows the springs, the old dirtshield(?) was crispy and overall in a horrible condition and couldnt be saved. Dont worry about that small document found on the dirtshield,it was saved ;)
Image

Image

Closeup of the keycap:
Image

Image

First look at the springs:
Image

Image

I proceed to open the backplate to see hows the pcb and rubber mat doing after all these years. Turns out backplate has some minor dmg to it and will be dealt with evaporust,rubber mat was in pristine condition. And the PCB,what a beauty.
Image

Image

Image

Image
PCB stored temporarily :lol:

Now when the backplate and the pcb was removed i got my first look at the modules and the infamous sticky foam(will be replaced after):
Image

Image

I then removed each module and tryed to get rid of sticky foam. After many tedious hours removing the foam,double sided tape and the glue i was finally able to evaporust the barrel,it got rid of the small spots of red rust and small corrosion i founded early:


Image

After this i went to evaporust the backplate and spacebar that had rust spots aswell:

Image

Image

Aluminium parts were cleaned but couldnt get rid of all the damage they have taken, the frontside was fully restored tho:

Image

Cleaned the case and the keycaps with warm water and soap:

Image

Modules ready to be cleaned:
Image

I will keep uploading more pics as more restoration takes part(upcoming foam replace and possible evaporusting the springs of the modules)

If anyone of you guys have ideas how to convert that thing into modern pc´s,im happy to take all your suggestions and have a talk about this project overall,hit me with private message or send a msg on discord Heikkonen#3771

Ps. Thanks to you who already are helping me with the converting!

- Heikkonen

kmnov2017

06 Oct 2019, 23:34

Now that's a find! Where's the rest of the table?

Heikkonen

06 Oct 2019, 23:37

The lady who i got from said that the rest of the system were recycled years and years ago,what a shame.

User avatar
SneakyRobb
THINK

07 Oct 2019, 01:40

Honestly the mechanism for the switches is like 8/10.

You will easily be able to repair this beamspring mechanically...

I am unsure about converting the pcb.

DMA

07 Oct 2019, 03:35

As your attorney, I advise you to remake the PCB, it shows signs of copper corrosion.

Heikkonen

07 Oct 2019, 21:54

Im now ordering replacement pcb and controller for it. Thanks for the tip DMA! Is there any proper way to remove the corrosion without damaging the old pcb?

SneakyRobb: I had a talk with few members of DT that were kind enough to give me exact details of what kind of pcb and controller i need to proceed.

One of the members contacted me about the foam and will be getting replacement for it.

Ill keep updating the post when the packages arrive.

Atlantic

07 Oct 2019, 23:24

Very nice find!

DMA

09 Oct 2019, 06:29

Usually weak acid is used to remove oxides - but it doesn't worth it nowadays, PCBs are very cheap.

Heikkonen

17 Oct 2019, 19:11

PCB has arrived along with controller.
Image
Image

Thanks to manisteinn for providing replacement foam for this project!
Image

I managed to build firmware and bootloader well but when im trying to port acquire,ill get this
Image
Image

I checked PSoc Programmer side and it tells me this:

Image

I followed forum member snackcats guide other than i didnt solder everything up until i went for firmware side as shown below(Could this cause it?)

Image

(Metallic pins wont touch eachother)

Any help will be appreciated! You can reply to this post,send me a dm on discord Heikkonen#3771 or send a private msg.

I will be assembling beamer back to original form with new pcb and foam soon,pics inc

DMA

19 Oct 2019, 12:30

I had this error recently. Thought I fried the chip, desoldered everything from it and then tried again. It worked.

So, try to remove wires from P0_0 and P0_1 and flash again.

Heikkonen

01 Nov 2019, 22:07

Its been awhile since last post. Things have gotten further.

I applied the foam sended by manisteinn and made "side foam" replacement
Image

I then made small slices of foam to match the double sided tape seen in the picture. Putted it all together
Image

After this my new cypress board arrived and i managed to flash commonsense firmware into it without errors. Then i proceed to get this thing soldered.

Rows/Columns connected:
Image

Controller GND connected to chasis:
Image

Overall view:
Image

Image

I then went to configure Flightcontroller and noticed it wasnt fully working
Image

Adjusting these values in "Hardware" tab solved a problem.

ADC 12
Charge delay 80
Discharge 7800
denouncing 16

After:
Image

Then i went to adjust Threshold values on with keymonitor and after few? tedious hours i finded values wich didnt give any of the errors: below:
- Keypress registers key next to it
- Some keys turning on permanently
- Some keys not registering at all after a press
- Some keys staying on even after release

Threshold values that i came up with:
Image

Going to create a layout and improve keyfeel abit by adjusting foam. Nitpicking tho.

Im probably gonna end updating this thread here and create a next one if i end up proceeding with creating a table for this thing or anything similiar!

Thanks for everyone that helped me with this project!

- Heikkonen

DMA

02 Nov 2019, 03:40

(In Pratchett's Death voice) PCB GROUNDS MUST BE CONNECTED TO THE CONTROLLER GROUND.
See a ground plane? Connect it to controller ground. See a floating piece of metal - connect it to controller ground, no options.
You can chain your ground wires, your ground wires may well be AWG 50 - but every large conductive piece must be connected to controller ground, NO exceptions.

PS: Congratulations on making it work at all without stable ground plane. I bow before your persistence.

PPS: Do I understand correctly that you didn't use Matrix Monitor mode figuring out the thresholds, and just bruteforced it?

Heikkonen

02 Nov 2019, 11:31

One of the PCB gnds is connected to controller gnd. I used keymonitor "min" values and tweaked them abit to get the board working properly.

kmnov2017

02 Nov 2019, 13:16

Great job. Your patience and hard work on this project is commendable...

DMA

03 Nov 2019, 05:04

Just noticed.
There is a defect in __red__'s PCB. Call it an oversight. We we were too excited by The Possibilities to think, plus I either didn't get to review the board before it was printed or just missed this outright. Not having a beamspring to test things out did definitely play a role.

The matrix is sparse - as in "has unpopulated cells".

This is a non-issue for model F (and practically everything else), as flipper is normally away from the PCB and signal gets stronger as you press the key.
But for beamspring - where signal goes fainter for a pressed key - it's a crippling defect, as unpopulated cels will appear permanently pressed, no matter what you do - and trip the scanner's sanity check (in other words, you got lucky your empty cells giving positive readouts most of the time).

Easily avoidable - just draw 3x3mm copper squares, positioned one over another, one side being a column and another a row, for any missing keypad in the matrix. Would solve all the problems.

I would advise to remake the PCB - your current setup spends 440 microseconds per row, 2.2 milliseconds for a single matrix scan. Then there's debouncing - so 15 scans (33 milliseconds) are needed to register a keypress in ideal environment. So, ~30Hz scanrate. And if you have a LED lamp nearby or other EMI source, single-digit seconds keypress response is well within the realm of possibility.

Adding capacitors (even as ghetto as "an inch of thin isolated wire wound around another such piece of wire) for the missing row/column combinations (doesn't have to be on the PCB either! Just between row and column) would also help, but simply pointless with current PCB prices. If you can't draw PCBs - ask wcass or Sneaky Robb (or even __red__ if you can find him) - they'll gladly help I guess.

Heikkonen

03 Nov 2019, 18:03

Thanks for pointing this out. Ill get back to this thread when i decide how im gonna proceed.

User avatar
JP!

03 Nov 2019, 18:10

DMA wrote:
03 Nov 2019, 05:04
Just noticed.
There is a defect in __red__'s PCB. Call it an oversight. We we were too excited by The Possibilities to think, plus I either didn't get to review the board before it was printed or just missed this outright. Not having a beamspring to test things out did definitely play a role.

The matrix is sparse - as in "has unpopulated cells".

This is a non-issue for model F (and practically everything else), as flipper is normally away from the PCB and signal gets stronger as you press the key.
But for beamspring - where signal goes fainter for a pressed key - it's a crippling defect, as unpopulated cels will appear permanently pressed, no matter what you do - and trip the scanner's sanity check (in other words, you got lucky your empty cells giving positive readouts most of the time).

Easily avoidable - just draw 3x3mm copper squares, positioned one over another, one side being a column and another a row, for any missing keypad in the matrix. Would solve all the problems.

I would advise to remake the PCB - your current setup spends 440 microseconds per row, 2.2 milliseconds for a single matrix scan. Then there's debouncing - so 15 scans (33 milliseconds) are needed to register a keypress in ideal environment. So, ~30Hz scanrate. And if you have a LED lamp nearby or other EMI source, single-digit seconds keypress response is well within the realm of possibility.

Adding capacitors (even as ghetto as "an inch of thin isolated wire wound around another such piece of wire) for the missing row/column combinations (doesn't have to be on the PCB either! Just between row and column) would also help, but simply pointless with current PCB prices. If you can't draw PCBs - ask wcass or Sneaky Robb (or even __red__ if you can find him) - they'll gladly help I guess.
Wow, thanks for these insights. I was considering making some revisions based on Emdude's open source PCBs such as the 66 key beamspring which is Xwhatit ready + could work with Commonsense using an extra edge connector. Additionally red's PCB is missing the middle screw holes at the top and bottom. I tried messing around with some PCB design software but had a difficult time using that particular software as I have no experience with drawing.

DMA

03 Nov 2019, 18:24

JP: Use diptrace. kicad is an abomination with ugly fonts, altium interface is made by aliens for predators (and requires all your edits to be public).
Me and wcass use diptrace.

User avatar
JP!

03 Nov 2019, 18:32

DMA wrote:
03 Nov 2019, 18:24
JP: Use diptrace. kicad is an abomination with ugly fonts, altium interface is made by aliens for predators (and requires all your edits to be public).
Me and wcass use diptrace.
Yeah I believe that what I started with Kicad and gave up ages ago but really should make this a personal priority project as I will need 2 PCB’s. Do you think Emdude’s PCB’s are designed properly to work well with CommonSense? Also pretty sure the 66 key shares the same dimensions as the 3741/3742 but of course the layout is totally different.

DMA

03 Nov 2019, 19:08

Yep, his matrix seems fully populated.
But I just thought about one thing. Zero doesn't make sense as a threshold. Threshold is something _between_ the resting state and pressed state.

So.

By the power vested in me by God and Man, I pronounce zero as an "ignore this key" threshold, and will publish the firmware abiding that law today.

Heikkonen

04 Nov 2019, 06:25

I can also confirm that my statement getting the beamer working properly was a false. Did some more testing with it and noticed issues you were referring.

DMA

04 Nov 2019, 07:21

https://github.com/dmaone/CommonSense/r ... ag/1.0.0.4
If you downloaded a zip instead of cloning the repo - replace dma_core/scan_capsense.c and all files in c2/ with new versions.
Then build firmware and update.

FlightController is updated to show zero thresholds grayed out, but it's not necessary to update it.

Heikkonen

04 Nov 2019, 22:30

I builded a new firmware,updated it and got much better results with thresholds,it might be working fully but i still have to test it properly throught(I dont dont know if thats a placebo or is it actually fixed) :lol: . As this goes on,few modules feel manually hard to press down as if something was stopping them from going down smoothly. I assume i could open the modules that aint working,clean it and reassemble to see if it helps out. Thanks for updating commonsense DMA! It truly helped me alot and saved alot of time/money

DMA

05 Nov 2019, 07:27

Heikkonen: reset delays back to 20/180 or whatever tooltip says.

__red__

18 Nov 2019, 22:38

Yay - I'm glad to see another one of these in the wild.

... and defect my ass DMA - it worked perfectly here :-)

(I set the min and max as opposites of each other so they were never true).

I can probably track down the original diptrace files if you give me a little while...

User avatar
ZedTheMan

18 Nov 2019, 22:50

He returns!

Also, excellent keyboard and restoration, Heikkonen.

Heikkonen

18 Nov 2019, 23:05

ZedTheMan wrote:
18 Nov 2019, 22:50
He returns!

Also, excellent keyboard and restoration, Heikkonen.


Thanks! Still havent opened to modules to restore my keyfeel tho. I have been slacking :roll:
__red__ wrote:
18 Nov 2019, 22:38

Yay - I'm glad to see another one of these in the wild.

... and defect my ass DMA - it worked perfectly here :-)

(I set the min and max as opposites of each other so they were never true).

I can probably track down the original diptrace files if you give me a little while...
Sure! Hit me up with DM if u manage to find those. Im really glad to see you here. Your pcb has been a great help towards getting this thing running

__red__

19 Nov 2019, 15:13

Try the beamspring.dip file here:

https://github.com/redvers/modelf

For some reason I can't get a working diptrace here so I can't verify it. Let me know if it's good / bad.



Red

Heikkonen

19 Nov 2019, 21:53

Hi red! Thanks for providing me with the link. Im currectly doing restoration of modules to get the minty keyfeel.

That being said i opened the modules,some of the parts were in good condition,some were a little bit dirty. Overall nothing that cannot be treated.

Half way:
Image

Housings:
Image

Fly plates:
Image

O-Rings:
Image

You can see some of the beamers history in o-rings(and springs). It was originally stored in calcium mine/factorys office(thank god not the actual mine)

Springs:
Image

Sliders:
Image

Stems:
Image

Stems seem so clean ill just get pieces of old dirt shield off,no need to evaporust those.

Springs are currectly being evaporusted,o-rings and plastic housings are washed with soap/water. Sliders seem quite clean but ill gently clean them with cotton stick. Ill leave flyplates untouched. Gonna assembly the switches back as they are being treated and im gonna see if the keyfeel gets any better. After that its time to dwell into software side again.

DMA

20 Nov 2019, 03:29

__red__ wrote:
18 Nov 2019, 22:38
... and defect my ass DMA - it worked perfectly here :-)
Like, the row 5 is mostly empty. How can it even work?

..oh, I guess I know. Firmware didn't have the sanity checker then. So if you map those empty matrix cells to [None] - you're fine, they're always pressed at matrix level but nobody cares at layout level. "All keys released" will never be generated, but that's fine unless you end up with layer mapping with a non-transparent key above layer mod key.

Then I grew tired of the damn thing killing my shopstation every time I need to experiment with scan module while having a non-empty layout or plug the controller into another PCB, and I added sanity check (which actually tolerates up to 2 keys always-pressed - it trips on 3 key-down transition in something like first 500ms after scan init) - and it started to matter.

So yes, a defect. If you solder the keyboard and one key stuck pressed - it's a defect. Bug parity property - if a program executed correctly, it has even number of bugs.

Post Reply

Return to “Workshop”