deskthority

Also, it needs 5.5v to run, so USB might be hard to work with.

I need to take a closer look. But I think what is happening here perhaps is that the board is consuming a whole bunch of power which could be causing a voltage droop from your supply. Just a theory, haven't checked.

The 7400 series logic is all TTL logic and should operate okay at 5 volts.

Maybe you can run the experiment that I was hoping to run tomorrow: desolder a single switch, tie the top pin to power and the bottom pin to ground (as viewed from the typist's point of view), tie the middle two pins to a pull up resistor (6.8 k) and probe the outputs when you press a key. I think they should go low when you do.

On the keyboard itself I think the open collectors are also tied to ground using a capacitor but I don't have a good capacitance tester handy to figure out the capacitor value.

I do maintain that, even with modern logic, the Hall switches themselves may draw enough power to overwhelm USB. I want to be sure before connecting this keyboard to a desktop computer. I was all but resigned to using an auxiliary power supply. We may need one anyway for the solenoid.

Update: It is not working :\

Haven't tried your experiment yet however.

Update #2: Teensy was able to power the keyboard to ~4.8v. This however still does not work.

Photos!

https://goo.gl/photos/q56n8i6eCa3CWNBT8

Still working on reverse engineering, more photos, a good writeup, the works, this is what I've got so far.

OK I have no idea what I'm doing, or doing incorrectly. I have managed to get a discrete switch to output something, so that's something. I kind of have an idea of how this keyboard works, although it's not working the way that I want it to.

More details would be helpful. What did you do? What did you expect would happen? What actually happened?

Firebolt1914 wrote: ↑OK I have no idea what I'm doing, or doing incorrectly. I have managed to get a discrete switch to output something, so that's something. I kind of have an idea of how this keyboard works, although it's not working the way that I want it to.

Oops, I got frustrated.

Anyways, we found out that the 'row' outputs on the connector are pins 22, 19, and 18 (may need to be checked). After powering on the keyboard with 4.9V, I tested the switch's 5V and GND lines. I tested the row outputs for anything with the arduino logic analyzer (I have a 'proper' logic analyzer now) and nothing shows up.


The bulb doesn't seem to work off of 5v (or at all!) as I had managed to desolder it, but applying electricity to it did nothing.


EDIT:
Row 3 outputs directly to SN7408N's pin 3

Lots more photos posted to my Google Photos album of this keyboard:
https://goo.gl/photos/q56n8i6eCa3CWNBT8

Sorry, not enough time / too lazy to share them all here. This is what happens when I take on too many projects at a time.

The most instructive things are my lab notebook, pictures of the key press pulse for the switches, and some high resolution shots of the PCB for reverse engineering work. I think the solution for this keyboard will be to remove all the 7400 series logic entirely and connect a brand new pin mux and microcontroller to the matrix rows and columns directly to enable high speed polling of the entire matrix and thus NKRO. None of this silly "use these lines to select a row and column" convention through the existing logic that appears to result in 1KRO.

Anyway, here are some nice photos.

Lab notes and bench setup for switch testing: Oscilloscope plot of resulting pulse when a key is pressed. You only get a "press" event, not a "release" event. Yuck! Quality photos of the front and rear of the PCB with all switches removed: Switch plate, being sand blasted in preparation for powder coating ("coming soon") :

Ebay seems to be selling more Wang today

http://www.ebay.com/itm/262236133191

tl;dr: I recommend to implement a replacement controller to achieve NKRO. My plan is to remove the 74148 encoders, and strobe the matrix directly.

Today, I had a chance to have a good look at the high quality photos I took of the PCB. I mapped the matrix of the PCB to pins on the 74148 encoders on the top edge of the PCB. I edited the photos to make it easy to flip between the back and the front of the board. I also mirrored the back of the board to make it easier to trace. See photos below - high resolution!
In total, there are 25 "rows" that need to be strobed. This is few enough pins that a Teensy 2.0 could cover the matrix. A Pro Micro, however, does *not* have enough pins and would need a multiplexer of some sort.

Why not just use one of the 74148s as a multiplexer? Simple: they are priority encoders, meaning that switches can block other switches.

This is where I could use some help from a controller firmware writer like hasu, HaaTa, etc. Not that I can't figure this out myself but it would go a lot faster with help. Anyway: we're going to need a different kind of strobing here. Let me try to explain below.

With a normal keyboard matrix, we have rows and columns. We send a pulse out on a row, and try to sense it on a column. Switches, being conductive, allow the pulse to physically (electrically) pass through the switch.

This is not how the Hall sensor works.

The Hall sensor has two (identical) outputs which are typically held high. When a key is pressed, the output spikes low. It takes 50ms to drop to low, and 50ms to rise back to high. (Note that, at the hardware level, there is absolutely no way to see how long a key is held. A key press generates a press and release event.)

So, instead, the Hall matrix strobe loop needs to look something like this:
This is where I grumble about never having learned the Arduino API. The only microcontroller I've programmed was the 8051 and that was ages ago. It will take some time to get a strobe going.

The good news is that these switches are bounce free. The total time the switch is in the low state is about 100ms. We should be able to scan the matrix at about 100 Hz (10x faster than the switching time) to 1000 Hz (100x faster). Keys will always appear to be pressed for about 50ms regardless of how quickly we scan. There is no way to make this shorter; it is a limitation of the Hall sensor mechanism.

An interesting point: the Shift keys (R7 and R10 in my diagram) have their own dedicated wires on the keyboard's cable. They do not require external pull up resistors since there are some on the board.

So, who wants to help me write a simple sensor loop? I might wire up a 4x4 matrix using a Pro Micro just to test this idea.

Who got the other Wang board that Engicoder posted?

For some reason I find the fact that there is only a "press" event elegant... It's like a distillation of what a button or switch is. Ask any child what one does with a button:

"You press buttons!"

Only keyboard gurus think about the release.

It would be impossible to game with, and I suppose that's the only downside.

Wait... How does shift work if there is only a "press" state? Will it only activate for one letter, meaning you'll need to spam it for acronyms?

Hmm. Modifiers would need to be latching and would only apply to one key. Isn't that frustrating. There is a small chance that modifiers had special switches and sensors that were different from the others. I'll test all the sensors just in case. But I think this is something that the controller itself would need to handle. Ugh.

The only modifiers on the board are Shift and Lock. There is a lamp next to Lock which I think indicates the Lock state. So, unless I misunderstand, holding Shift only applies to one key and the terminal is responsible for this behavior. I need to think about this some more.

Looking back at my switch plan, it looks like the Lock and Shift keys used a different kind of switch: a "4B3A", whereas most of the rest of the alpha keys either use either "4T2B" (angled stems) or "4A2B" (straight stems).

I wonder if the 4B3A switches had different sensors in them to facilitate latching keys. If so: I'll need to test every single sensor before re-installation. I had removed all of the sensors from all of the switch housings in order to clean the switch housings in my ultrasonic cleaner.

Perhaps these 4B3A switches have sensors that implement what would be my strong preference for how sensing could work: switch goes low when key is pressed, and high when key is released. If you can't hold keys down this board is useless for gaming.

Further: it does look like the keys are arranged in a row-column arrangement. All of the lines coming into 74148 #1 and #2 (from left to right) are "columns" and all of the lines coming in to 74148 #3 are "rows". As labeled in the image above everything has a "R" prefix for "row". Specifically, using my labeling convention above, these are the rows, 0, 1, 2, 3, 6, 8, 18.

Also: note that a number of switch positions that were unpopulated earlier, are valid places to put switches. This is handy for say modding the keyboard to have an inverted-T arrow cluster.

I feel slightly guilty for bringing that to your attention... You would've dealt with it later anyways, but still. >.<

You should be able to see a difference in the 4B3A sensors if they implement a high state on the upstroke -- I think it would be electromechanically impossible to do that without a physical alteration from the other types.

I'd do a visual examination before suffering through a comprehensive test of each unit.

No, I'm glad you brought this to my attention.

The Hall sensors have all the electronics under an epoxy blob so they all look identical. It's a simple logic change within the portion under the epoxy blob: a continuous pull down instead of a latch. Recall that the actual Hall sensor is coupled to an op-amp and either a Schmitt trigger or a one-shot. They may even be all together as one IC.

I should test every switch anyway since I have no idea what the working state of this keyboard is, so, all is not lost there.

This isn't dead. Not yet.

Last time, I discovered that there must be some difference in the different kinds of switches that are used in the keyboard. Some must emit a low pulse, some must stay low to act as modifiers. Since I pulled all of the sensors out of the switches I now have a needle in a haystack problem to find what should correctly go where.

I sorted all of the sensors from the switches. I have:

26A - qty 1

29B - qty 38

26K - qty 1
27K - qty 3
29K - qty 4

27Q - qty 2

28T - qty 46

Total 95

I don't know the significance of these codes. These are the letters that are printed on the sensor boards themselves, not the switches.
I know for a fact that "28T" is a single low pulse sensor. Moreover, I finally managed to get some time to play with my Hantek 6022BE USB oscilloscope and get this lovely capture.
I had an idea, though. Instead of testing all of the switches - or even, just one of each of the seven types above - perhaps I should have a look at one of the other Hall boards I have handy.

From my notes on which switch was where at the time of disassembly: I believe "4B3A" must be a switch that stays low. I believe anything that ends in B - being 4A2B and 4T2B - must be a single pulse.

From the switch plan that I recorded:

4A2B - qty 39
4T2B - qty 47
4B3A - qty 3
4A2K - qty 4
4B2K - qty 1
4B3K - qty 1

Total 95

One of my other Hall boards has a 4B3A that I can look at. I need to desolder it and see what it does, and what sensor it has.

XMIT wrote: ↑This isn't dead. Not yet.

Last time, I discovered that there must be some difference in the different kinds of switches that are used in the keyboard. Some must emit a low pulse, some must stay low to act as modifiers. Since I pulled all of the sensors out of the switches I now have a needle in a haystack problem to find what should correctly go where.

Spoiler:

I sorted all of the sensors from the switches. I have:

26A - qty 1

29B - qty 38

26K - qty 1
27K - qty 3
29K - qty 4

27Q - qty 2

28T - qty 46

Total 95

I don't know the significance of these codes. These are the letters that are printed on the sensor boards themselves, not the switches.

600_5488.JPG

600_5481.JPG

I know for a fact that "28T" is a single low pulse sensor. Moreover, I finally managed to get some time to play with my Hantek 6022BE USB oscilloscope and get this lovely capture.

20160204_hall_effect_single_pulse_capture.png

600_5502.JPG

I had an idea, though. Instead of testing all of the switches - or even, just one of each of the seven types above - perhaps I should have a look at one of the other Hall boards I have handy.

From my notes on which switch was where at the time of disassembly: I believe "4B3A" must be a switch that stays low. I believe anything that ends in B - being 4A2B and 4T2B - must be a single pulse.

From the switch plan that I recorded:

4A2B - qty 39
4T2B - qty 47
4B3A - qty 3
4A2K - qty 4
4B2K - qty 1
4B3K - qty 1

Total 95

One of my other Hall boards has a 4B3A that I can look at. I need to desolder it and see what it does, and what sensor it has.

I've had plenty of those moments when I realize, in retrospect, that I should have documented things a bit better before tearing them apart.

Thanks for continuing to document your progress. This board is very interesting; for example, the different types of switches to deal with the pulse nature of the hall-effect and key release. Modern boards are, for the most part, all so similar on this level Back when this board was designed there was a lot more variety of design and experimentation.

Alright, I pulled a "4B3A" from a different board I have handy. But I need some more alligator clips in order to test these rapidly. I'll check back in after a trip to Fry's and/or after ordering some toys online.

has that hantek got a logic analyser too ?

I have been looking for a DSO , i have an old CRO dunno if i should go for something like that or a low end desktop scope.

The Hantek does not, your best bet is a Saleae ($$$) or a Chinese clone such as:

"New USB Logic Analyzer Device Set USB Cable 24MHz 8CH 24MHz for ARM FPGA"
http://www.ebay.com/itm/201450276552

My trip to Fry's was a success. They've become what Radio Shack used to be: a reasonable place to buy test equipment and discrete components. I should have more updates soon.

I'm getting better results out of my USB connected oscilloscope than the bench top one I was using earlier. I need to look into this.

The other option, which I don't know if you've considered, is a switch that causes two low pulses on press and release respectively (or one low and one high). The two pulses could be used to actuate the shift key without a "hold low" state.

Sure, I guess that's an option (both are forms of the derivative of pulling the line low for a while). Since at this point I've got all the tools I need to probe the outputs, and I've already nicely sorted the sensors, I'll simply test each family to see what I've got. There is a small chance that several other keys are "special" as well though the schematic does not suggest this.

Firebolt1914, if you're around: what three letter code is printed on the sensor under the "Lock" or either "Shift" key?

Looking at the layout again I just realized that the Enter key for the numpad is in an interesting spot: it is placed to be pressed with the right thumb! Interesting.

XMIT wrote: ↑The Hantek does not, your best bet is a Saleae ($$$) or a Chinese clone such as:

"New USB Logic Analyzer Device Set USB Cable 24MHz 8CH 24MHz for ARM FPGA"
http://www.ebay.com/itm/201450276552

i was thinking of this

http://www.ebay.co.uk/itm/Hantek-DSO507 ... SwZjJU2F1h

easy software hack to 200mhtz

I don't know, but, I'm not sure two channels is enough for your needs.

2 should be enough for most things , i can get a separate logic analyser later , or get a old HP one off ebay at some point

tl;dr: 26A and 27Q are the "special" sensors. 4B3A is a special switch for modifiers that stays low when pressed. I can put the board back together now.

I purchased some "IC Test Leads" (test clips) that made it much easier to test Hall switches in quick succession.

What I've found:

Sensor types 26A and 27Q (as well as 99A7) are the "pull low" variant: the pull down resistor is pulled low as long as the sensor is active. As long as the key is held down, these are low. These are the "Lock" and "Shift" switches.

All of the other sensor types I tested - 28T, 29B, 26K, 27K, 29K - are of the "low pulse" variant. The open collector output is typically pulled high by a pullup resistor and I usually see 5V here. When the key is pressed, or held down, the open collector output drops to about 0V. This happens for 60 *microseconds* as posted in the earlier oscilloscope screen shot.

My guess is that the extremely short pulse time is an attempt to prevent ghosting. The way the board is wired, when a switch pulls a row or column low, it will appear low regardless of anything else happening. This isn't like mechanical switches where current either flows or doesn't flow and can be impeded by diodes. By design, I think this only gets 1KRO. There is no way to tell if a key is being held or if it was pressed once.

I'll need a really fast scan rate to catch these pulses. 1/(60 microseconds) is about 16.6 kHz. I need to sample at least double this (Nyquist rate) to see the output. I'll probably scan at about 40 kHz for starters to see if this works.

I guess the next step is to wire up a little toy 2x2 or 3x3 matrix and see if I can adapt one of the existing keyboard firmwares out there to read these pulses, or write my own. For the whole board I'll need a total of 25 input pins again: 23 for the matrix and 2 for the modifier keys (ideally 3 for the mods). A Teensy 2.0 just barely has enough pins (and doesn't let me tell the Shift keys apart). A Teensy++ 2.0 has more breathing room in this regard.

Speaking of which: The keys themselves are laid out in a 6x17 matrix for 102 possible positions. The "rows" (pin 2 from the top of the sensors) in my above convention are: R0 R1 R2 R3 R6 R8. The "columns" (pin 3) are: R4 R5 R9 R11 R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24.

I may end up picking up a Teensy 3.2 to better run HaaTa's firmware. That is unless someone wants to donate one.

So there are different switches in the board that are scanned differently that strange.