I was just watching an eevblog episode about VIA’s (research for my project), and I saw Dave using Saturn PCB Toolkit for various calculations.
Interestingly (and not surprisingly) the tool is only available for Windows, but I wanted it anyway, so I decided to give it a try under WINE.
It wouldn’t install, throwing a few errors, but then I did manage to install it on my Windows and copy the .exe file over to my mac,
and – voila, the thing works, it should also work on Linux…
First part here
3 days later, my mouser order arrived to Japan (this is super fast), I got the relays, desoldered the bad one (proper desoldering tool is very useful here).
(Right is new replaced, left is the old one for comparison, didn’t take it apart though).
Soldered the replacement and couple of screws later, I had the multimeter repaired, reassembled and ready to test.
(Don’t forget to note colors of the internal cables connected to the rear panel posts)
First I realised that once or twice another test had failed (500.2), and also 600.1 and 601.2 (which was definitely a change from original 600.1,600.2,601.1).
When the test process asks for 4-wire short I literally used a 4-wire kelvin clips shorted, and this seems to be the reason why error 500.1 came up, and likely the 600.x ones now were because I shorted HI to LOW instead of AMPS.
Now, for 4-wire short I used pomona banana leads (I think 12-ich ones) to get as close to a “real” Keithley 4-wire short brace (it’s literally a brace with 4 banana plugs that snaps right into the posts).
After the change of leads – all of the tests succeed. Voila, I repaired the multimeter (but I think I will someday make a a 4-wire short brace for reliable testing).
I got a Keithley 2000 multimeter, and as usual the first thing I did was to test it.
Builtin self-test ran through most of cases without issues but failed with 600.1, 600.2 and 601.1.
With a little research I found out that those errors are related to amps/ohm tests, and a little later I found out that one of the common causes is broken relay (K103) – NEC EA2-5NJ.
I took the device apart and probed the relay, comparing the result with other two relays.
It should have pins 2,3 and 8,9 shorted when off and 3,4 with 7,8 when on.
My relay has all the pins 2,3,4,7,8,9 shorted together – that is definitely not desired.
I ordered a new relay from Mouser and when it arrives I will replace it and see if that solves the problem.
I ended up buying TMK’s (hasu) alternative controller board via Geekhack, and, to my surprise, it didn’t work.
The issue manifested itself in a rather weird way – keypresses would send random keys, sometimes even two at a time (but I knew that since it registered as a USB device and that atmega would properly enter DFU mode the micro itself was most likely just fine).
I’ve exchanged a few messages with hasu, we tried some software solutions including reverting a commit that might have been the culprit, meanwhile I’ve consulted the schematic and verified the cable and traces.
I knew that all the signals from the keyboard go directly to inputs of the atmega, and with a few pokes using my multimeter I found that pin 7 of the Hirose connector did not have connection to pin 25 of the Atmega. There war literally no path between them as if the PCB trace was bad.
So I decided to make the connection temporarily with a probe and a wire – and the keyboard started to work, turns out that the solder somehow didn’t have good contact – which I couldn’t see even after inspecting the board visually several times.
Since it was just the solder – I’ve touched it up with my iron and voila – it was all fixed.
Hasu apologized for this, apparently this was the first time a board had such manufacturing issue.
Signed, Happy User of Happily Hacked Happy Hacking Keyboard ;)