Convert&Restoration project of IBM 3742 beamspring keyboard

[Heikkonen]

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 (67.27 KiB) Viewed 18094 times

The case itself was in pretty good shape but aluminium parts had some minor damage as seen below




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.





Old documentation found inside:




First look after removing barrel:




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




Closeup of the keycap:




First look at the springs:




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.







PCB stored temporarily

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):




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:




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





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



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



Modules ready to be cleaned:


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]

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

[Heikkonen]

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

[SneakyRobb]

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]

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

[Heikkonen]

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]

Very nice find!

[DMA]

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

[Heikkonen]

PCB has arrived along with controller.



Thanks to manisteinn for providing replacement foam for this project!


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



I checked PSoc Programmer side and it tells me this:



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?)



(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]

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]

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

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


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


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:


Controller GND connected to chasis:


Overall view:




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


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

ADC 12
Charge delay 80
Discharge 7800
denouncing 16

After:


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:


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]

(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]

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]

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

[DMA]

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]

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

[JP!]

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]

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.

[JP!]

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]

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]

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]

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]

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) . 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]

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

[__red__]

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...

[ZedTheMan]

He returns!

Also, excellent keyboard and restoration, Heikkonen.

[Heikkonen]

He returns!

Also, excellent keyboard and restoration, Heikkonen.

Thanks! Still havent opened to modules to restore my keyfeel tho. I have been slacking

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__]

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]

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:


Housings:


Fly plates:


O-Rings:


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:


Sliders:


Stems:


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]

... 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.