Univac Keyboard (Micro Switch) - Now USB converted via custom TMK scan module!

[snacksthecat]

Time for more of Dave's stupid questions.

Stupid Question #1:

I guess these are spec'd for 6.8k resistors. Is it okay to instead use the internal pull-up resistors from a teensy? Seems to work fine but I don't understand electricity.

Stupid Question #2:

Does pin 1 have to connect to pin 1, pin 2 to pin 2 (left example)? Or does it not matter? I ask because my keyboard doesn't always do this.



Stupid Question #3

My keyboard doesn't have a resistor on all of the rows / columns. Only most of them. What could be the reason for this?

Stupid Question #4

Why's it called a Micro Switch? It's not that small and it's not really a switch (IMO).

Stupid Question #5

What am I doing wrong?

First, I tried the simple 2x2 matrix -- expertly crafted inside a cardboard box



But it did not work. I tried changing a couple of variables but every time there was one non-functioning switch.

So then I wanted to remove all the variables that I could goof on. So next I tried on the actual PCB. First I removed all the ICs and tried a simple 1x2 matrix.



Again, one switch appears dead. Next I removed all the other components save for resistors and capacitors. Retested and so on...

Clearly I'm missing a few pieces of the puzzle. I'm sure someone's done this before and knows the answer. Hope he reads this thread!

[listofoptions]

ok so if i recall correctly microswitch hall effect switches are open collector output on pins 2 and 3, pins 1 and 4 are power and ground. the reason you need resistors on pins 2 and 3 is because current flows when there is a potential difference (waters moves from areas of high pressure to low pressure) and the resistor acts as a way of generating that potential. its 6.8k because 5v/6.8kOhms = 0.7mA and that apparently is the current needed to flow through the transitor that outputs.

what do i mean by open collector? so instead of outputting a current open collector switches sink, or try and pull current down to ground. what does this imply for your sensing? it means that you need to invert the signals you're getting from your matrix! when you sink current to ground there is no longer a lower resistance path to ground through the microcontroller, instead its through the transistor in the switch, so it drops the output voltage to 0 when the transistor in the switch is turned on! this basically means that the signal is inverted!

[Anakey]

In answer to the other questions:

In original pcb

Pins 2 and 3 are generating an output however one pin would be connected to a row and the other would be connected to a column and both row and column would be read to determine the position of the switch however it is not always a set pin for row a set one for column this is why it is only 1kro as pressing more then one would end up with a ghosting effect.

For NKRO

For NKRO think of both output pins as a single pin as in this case the power pin instead would be strobed.

Micoswitch made many many types of switch including microswitches similar to mouse button switches considering that they started up in the 1940s at the time such a small switch would have been micro indeed.

[snacksthecat]

Thank you @listofoptions and @Anakey for answering my questions.

But no one answered the question about why some lines have no pull up resistor on them.

Then, this morning on my commute to work I was digging for more information. That's when I got hit in the face with this brain buster....


http://bitsavers.org/components/microsw ... odules.pdf

My assumption up to this point is that the two inner pins are separate but identical outputs.

The Micro Switch SD information packet on bitsavers tells a whoooooole different story. This would totally explain why I always am encountering "dead" switches when they're hooked together.

I'm going to

1. more closely study the PCB
2. try another small matrix proof of concept with different wiring

Now, slom, I know you are already aware of this fact cause I found you're TI Silent thread. Is there anything else I should know?

[snacksthecat]

I think what makes this particular board so tricky is that they handled a lot of the typing logic in hardware. For example, the modifiers, return key, and top keys are all hooked up in a totally different way. So I can't figure out why sometimes they have one switch's output going to another switches input. I can't get my head around what that enables.

[Anakey]

i think that the modifiers and other keys you mentioned used different sensors the wiki article mentions several types so that would expplain the different layout for those keys

[snacksthecat]

i think that the modifiers and other keys you mentioned used different sensors the wiki article mentions several types so that would expplain the different layout for those keys

Yes, definitely. On my board, the alphas are the "pulse" variety and the modifiers are the "hold" variety. From what other people said in this thread, I guess this is fairly common for micro switch boards of this time.

I decided to put the alphas back in place and see if I can get a handle on them.



I traced all of the routes in the PCB and soldered wires to those lines (for all keys, not just alphas). It's hilarious how many wires there are.



But I guess this was a pretty stupid idea. I need to isolate the lines connected to the alphas anyways so I'll have to retrace them anways. Oh well, everything with this keyboard up until now has been extra work/confusion/surprises so I guess this is just par for the course.

Oh and I may regret it later but I decided to keep the "pulse" switches for the main typing block. My rationale is that the board is wired up differently for all these different parts so rather than trying to swim upstream I'm just going to go with the flow.

[snacksthecat]

I wrote a very simple arduino sketch that implements the "scan/scan" logic to read key presses and outputs the row and column numbers to console.

Code: Select all

const int rowPins[] = { 27, 0, 1 };
const int rowPinCount = (sizeof(rowPins) / sizeof(rowPins[0]));

const int colPins[] = { 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 };
const int colPinCount = (sizeof(colPins) / sizeof(colPins[0]));

void setup() {
  Serial.begin(115200);
  Serial.print(rowPinCount);
  Serial.print(" rows ");
  Serial.print(colPinCount);
  Serial.println(" cols");
  
  for (int i = 0; i < rowPinCount; i++) {
    pinMode(rowPins[i], INPUT_PULLUP);
  }
  for (int i = 0; i < colPinCount; i++) {
    pinMode(colPins[i], INPUT_PULLUP);
  }
}

void loop() {
  for (int i = 0; i < rowPinCount; i++) {
    if (digitalRead(rowPins[i]) == LOW) {
      for (int j = 0; j < colPinCount; j++) {
        if (digitalRead(colPins[j]) == LOW) {
          Serial.print("Row: ");
          Serial.print(i);
          Serial.print(" Col: ");
          Serial.println(j);
        }
      }
    }
  }
}

First things first, it works! So that's great. I'm taking this as evidence that this method of working with the switches will work with my PCB.

A couple other things, what I found was that none of these rows / columns had external pullup resistors attached to them. Actually the pullup resistors on the keyboard PCB were attached to IC slots that had nothing in them. So I really don't know what to make of that.

Also this little code snippet works, however 1 in ~10 keypresses don't register. I did a little bit of research and found out that digitalRead() is actually quite slow. Is it possible that the code can't keep up with the short little pulse that the switch puts out?

Oh and I also have a bunch of dead sensors Someone must have already put them through their 40 billion cycles already.

[Slom]

I love this thread

Now, slom, I know you are already aware of this fact cause I found you're TI Silent thread. Is there anything else I should know?

Scan, pulse and hold switches are different variants of these SD switches. You have hold and pulse switches (Or, in wiki terminology, you have sink level and sink pulse switches. Your part numbers for the switches do *not* match the wiki, it seems like for yours the first number is the switch weighting and the second place is the switch output description. The S in the end is just to annoy me, because now I can not tell people that S in the last place are the good ones. )

As for your latest post, are you sure about the matrix? I have a keyboard with hold low switches, and there are no columns and rows there, or rather each output can be a column and a row, depending on which switch it is connected to.

The gist is that each switch has a unique combination of 2 output pins. The controller then only has to check if exactly 2 pins are low, and in that case it can look up the matching key. If zero or more than 2 pins are low then no output is emitted.

If you want to show it as a matrix, then the all pins will be on both the columns and rows, but the switches will form part of a strict lower triangular matrix.

Halvar made a nice picture here:
viewtopic.php?p=290338#p290338

I suspect the "dead" switch are those where you classified both pins as row or both pins as column. That way your loop will not be able to read them.

[Slom]

Also this little code snippet works, however 1 in ~10 keypresses don't register. I did a little bit of research and found out that digitalRead() is actually quite slow. Is it possible that the code can't keep up with the short little pulse that the switch puts out?

That is certainly possible, note that the whole loop must be faster than the pulse time. That includes the serial output as well.

[snacksthecat]

I suspect the "dead" switch are those where you classified both pins as row or both pins as column. That way your loop will not be able to read them.

That's definitely possible, maybe even likely. I unfortunately haven't gotten back around to see why those keys weren't registering.

I did however get this working in TMK last night. I only tested on a small matrix and with the "hold" type switches, but it appeared to function. I'd like to give this code a try with my Univac board next. I'm really excited to see if this works.

[snacksthecat]

TMK is actually handling this really well. I'm not really able to observe any issues at all which is really cool.

One thing I found interesting is that the keypresses weren't registering at all until I set debouce to 5. And I thought I'd read that these are "debounceless" switches. I'm not sure what to make of that but it works so I'm happy.

[snacksthecat]

I think I've figured out the cause of the dead switches. Unfortunately there's no way (at least I don't think) to bring them back. I wanted to share what I've learned in case it helps others avoid this mistake. Nothing I'm suggesting involves extra work so I don't see any reason not to implement these recommendations.

My theory is that the sensor are very vulnerable to excessive heat. Particularly heat generated during desoldering.

Suggestion #1: Don't desolder the switches if you don't have to

Seriously, these are a huge pain to desolder anyways. A full board has so many pins to desolder. And the pins really like to stick to the side of the holes making them very difficult to get out in one shot. If I'm correct about the heat theory, then this suggestion avoids the issue all together.

Suggestion #2: Use a proper desoldering gun

I unfortunately only own a cheap "bulb" type desoldering iron. This is the type I'm talking about:

Spoiler:

It does not have any temperature control and I feel it's probably too hot cool (thanks polecat!) for use on these switches. You would definitely want to use a tool that has a temperature control on it and you would want to keep the temperature down. Also only apply the heat for a short amount of time.

Suggestion #3: After doing a pin, allow the sensor to properly cool down

Most people's inclination would be to do all four pins of a switch in one go. I would suggest instead doing one pin, then moving on to a different switch. This prevents the sensor from heating up too much. This is what I'm talking about:



Suggestion #4: Be very careful when handling the sensors

The actual sensing part of the sensor is under a little dot of glue/epoxy. But this dot of goop is very very old. So even touching it or handing it less then gently might knock it loose. Don't handle the sensors while they're still cooling down. I had a couple of sensor where the little dot fell off from simply touch it (not even roughly). This is the part I'm talking about:

[Polecat]

It's counterintuitive, but a lower temperature on the (de)soldering tool can actually put more heat into the part. From decades of PC board work I've learned that it's better to get in and out quickly, which is easier with a higher temp iron. I use an old Weller station with an 800 degree (F) tip most of the time. With a lower temp setting the solder joint will take longer to heat up, and the whole time you're doing that you will have heat going up into the part. If you get in and out quickly (and keeping the tip clean and adding a bit of fresh solder/flux will help with that) you end up putting less heat into the part overall and doing less damage. Like most things it gets easier with practice. Your tips on moving from part to part and allowing cooling before handling are spot on.

[snacksthecat]

It's counterintuitive, but a lower temperature on the (de)soldering tool can actually put more heat into the part. From decades of PC board work I've learned that it's better to get in and out quickly, which is easier with a higher temp iron. I use an old Weller station with an 800 degree (F) tip most of the time. With a lower temp setting the solder joint will take longer to heat up, and the whole time you're doing that you will have heat going up into the part. If you get in and out quickly (and keeping the tip clean and adding a bit of fresh solder/flux will help with that) you end up putting less heat into the part overall and doing less damage. Like most things it gets easier with practice. Your tips on moving from part to part and allowing cooling before handling are spot on.

Wow, you weren't kidding. I finally caved over the weekend and bought a proper desodering gun with temperature control, vacuum, etc. It arrived today and I just tested it out. I set it to about where you said you set your station and got to work. The solder melts pretty much instantly and you suck it up in like quarter of a second, tops. The sensor doesn't even have a chance to get hot. Not to mention my hand doesn't hurt, it took 1/10th of the time to do the board, and zero rework with solder wick required. I just wish I'd purchased something like this sooner

[Polecat]

Wow, you weren't kidding. I finally caved over the weekend and bought a proper desodering gun with temperature control, vacuum, etc. It arrived today and I just tested it out. I set it to about where you said you set your station and got to work. The solder melts pretty much instantly and you suck it up in like quarter of a second, tops. The sensor doesn't even have a chance to get hot. Not to mention my hand doesn't hurt, it took 1/10th of the time to do the board, and zero rework with solder wick required. I just wish I'd purchased something like this sooner

Nice. I should have also mentioned that this will reduce PC board damage, and especially lifted pads. It's always painful to damage a nice piece of vintage gear, whatever it may be.

[snacksthecat]

I would smooth the housing and glue a new piece from the outside, something like that:



Sorry, I can't use Solidworks right now.

Huge thank you for this idea, Placa. I tried it out on one switch tonight and it worked perfectly.

Before doing anything... You can see the huge gap where the plastic was cracked off from pulling out the slider.



I tried to file it down to be as square as possible, so that it would accept a new piece.



I cut two pieces of thin plastic, just like in your drawing.



Test fit looked good.





Here's a clip that shows the fit a little bit better. There are a few factors going on: (1) I need to make sure it's flush with the inner wall of the switch and (2) I need to make sure the bottom piece of plastic in particular is the right thickness so that the switch doesn't sit too high/low.

I felt really good with how it was turning out so I set it in place with super glue. And much to my surprise it worked!

Regarding the height factor, I cannot tell the difference in height between this one and an intact one.



Thanks again man!

[PlacaFromHell]

I'm happy it worked I can't wait to see that keyboard working.

[snacksthecat]

Just a couple of updates. I've still been unable to get TMK working with the "pulse" type switches. I think the pulse it gives off is just too brief and is getting filtered out by the firmware or something. I've not ventured deep into the belly of TMK to see if this is actually correct. I've just been staying in the "end user" files where you define how the keyboard is scanned, keymap, etc.

But I think that is okay because I was never keen on the idea of using those sensors in this keyboard. I still will use them for something else, just not sure what quite yet.

I have, however, found a small supply of NOS "hold" type sensors which I've purchased. I'm hoping that those get delivered today so I can swap them in and give this a real test. And hopefully not ruin any of them in the process.

[PlacaFromHell]

Just a couple of updates. I've still been unable to get TMK working with the "pulse" type switches. I think the pulse it gives off is just too brief and is getting filtered out by the firmware or something. I've not ventured deep into the belly of TMK to see if this is actually correct. I've just been staying in the "end user" files where you define how the keyboard is scanned, keymap, etc.

But I think that is okay because I was never keen on the idea of using those sensors in this keyboard. I still will use them for something else, just not sure what quite yet.

I have, however, found a small supply of NOS "hold" type sensors which I've purchased. I'm hoping that those get delivered today so I can swap them in and give this a real test. And hopefully not ruin any of them in the process.

That's why I proposed my hardware solution. The entire code must run faster than the time of one pulse if you want to go only firmware.

[snacksthecat]

Wow, it's been a very long time since I undated this thread.

Basically I got to the point where I feel I have the fundamentals of the conversion down. I was able to put most of the keyboard back together. But I need a few more working sensors. I swear these things are cursed!

Here's what it looks like right now. A rat's nest of wires coming out the bottom and a few missing switches. It will be interesting when I need to figure out fitting the controller into the case.



I really want to get back to the fun stuff but these last few rebuilding hurdles are killing me.

[DMA]

This looks pretty close to cortron switches - including the driving electronics. Have you tried to reverse-engineer the driving electronics for it?
I'm trying to replace the central MCU in one of those, but couple of keys are not pressed reliably and I can't understand is it because of the keys being bad or me not driving the logic properly. Unfortunately, I don't have a DSO so limited to 4 channels and somewhat inconvenient viewing.

[listofoptions]

This looks pretty close to cortron switches - including the driving electronics. Have you tried to reverse-engineer the driving electronics for it?
I'm trying to replace the central MCU in one of those, but couple of keys are not pressed reliably and I can't understand is it because of the keys being bad or me not driving the logic properly. Unfortunately, I don't have a DSO so limited to 4 channels and somewhat inconvenient viewing.

probably the sensing method, cortron switches you're talking about are the mag-valve ones right? iirc those are basically just flux-gates on steroids. unless you're talking about cortron f&f

[jojolin]

Wow, That's fantastic work!

I just bought a Micro Switch keyboard and tried to fix it too.

Great Work!

[XMIT]

DMA for a DSO I think snacksthecat is using a Saleae logic analyzer or one of its many clones. I have one, it's a neat toy to have.

snacksthecat this is good progress. It's further than I got with my Wang board a few years ago.

That Honeywell switch guide is really helpful. Do you have any leads on this chart printed on the last page?

Code: Select all

Electrical, Mechanical & Temperature
Characteristics per Section "D" of
following CS

Sink Level   - CS 044 116
Source Level - CS 044 45
Sink Pulse   - CS 044 118
Logic Scan   - CS 044 117
Timed Repeat - CS 044 48

Electrical, Mechanical & Temperature Characteristics

Screen Shot 2019-08-20 at 5.17.38 .jpg (117.03 KiB) Viewed 10216 times

The text is tough to read, so, what might be a "11" may in fact be a "4" and vice versa.

[XMIT]

Steven Engineering in South San Francisco is a huge Honeywell vendor. http://stevenengineering.com/. I've contacted them for more information. Maybe they can point me to a data sheet.

[tentator]

Wow @snacksthecat this project you are undergoing and the documentation on this thread is really great!! +1

Tent:wq

[Muirium]

Indeed. There could be hope for my Honeywell (the Round 5 mother keyboard) yet. Thanks for playing guinea pig!

[snacksthecat]

Since this is nominated for a DTA, I thought I'd throw some icing on the cake and explain how I was able to get it working in TMK.

The matrix scanning is not so different from a normal conductive switch keyboard. The same row and column scanning principals apply; they're just shuffled around a bit.

I first prototyped using Arduino. Once I got a "rough draft" working there, I used that logic to write a matrix.c file for TMK.

So basically a custom scan module with all the TMK goodies.

Here's the matrix.c code:

Code: Select all

/*
 * scan matrix
 */
#include <stdint.h>
#include <stdbool.h>
#include <avr/io.h>
#include <util/delay.h>
#include "print.h"
#include "debug.h"
#include "util.h"
#include "matrix.h"


#ifndef DEBOUNCE
#   define DEBOUNCE	4
#endif
static uint8_t debouncing = DEBOUNCE;

/* matrix state(1:on, 0:off) */
static matrix_row_t matrix[MATRIX_ROWS];
static matrix_row_t matrix_debouncing[MATRIX_ROWS];

static matrix_row_t read_cols(void);
static void init_cols(void);
static void init_rows(void);
static uint8_t select_row(uint8_t row);

static uint8_t index;
static uint8_t row_to_select;

void matrix_init(void)
{
    // initialize row and col
    init_cols();
	init_rows();

    // initialize matrix state: all keys off
    for (uint8_t i=0; i < MATRIX_ROWS; i++) {
        matrix[i] = 0;
        matrix_debouncing[i] = 0;
    }
}

uint8_t matrix_scan(void)
{
    for (uint8_t i = 0; i < MATRIX_ROWS; i++) {
        uint8_t allow_select = select_row(i);
        //_delay_us(30);
		if (allow_select) {
			matrix_row_t cols = read_cols();
			if (matrix_debouncing[i] != cols) {
				matrix_debouncing[i] = cols;
				if (debouncing) {
					debug("bounce!: "); debug_hex(debouncing); debug("\n");
				}
				debouncing = DEBOUNCE;
			}
		}
    }
    
    if (debouncing) {
        if (--debouncing) {
            _delay_ms(1);
        } else {
            for (uint8_t i = 0; i < MATRIX_ROWS; i++) {
                matrix[i] = matrix_debouncing[i];
            }
        }
    }
    return 1;
}

inline
matrix_row_t matrix_get_row(uint8_t row)
{
    return matrix[row];
}

/* Column pin configuration
 * col: 0   1   2   3   4   5   6   7   8   9   10  11
 * pin: B7  D0  D1  D2  D3  D4  D5  D7  E0  E1  C0  C1
 */
static void init_cols(void)
{
    DDRB  &= ~(1<<0);
    PORTB |=  (1<<0);
    DDRD  &= ~(1<<0 | 1<<1 | 1<<2 | 1<<3 | 1<<4 | 1<<5| 1<<7);
    PORTD |=  (1<<0 | 1<<1 | 1<<2 | 1<<3 | 1<<4 | 1<<5| 1<<7);
    DDRE  &= ~(1<<0 | 1<<1);
    PORTE |=  (1<<0 | 1<<1);
    DDRC  &= ~(1<<0 | 1<<1);
    PORTC |=  (1<<0 | 1<<1);
}

static matrix_row_t read_cols(void)
{
    return (PINB&(1<<0) ? 0 : (1<<0)) |
           (PIND&(1<<0) ? 0 : (1<<1)) |
           (PIND&(1<<1) ? 0 : (1<<2)) |
           (PIND&(1<<2) ? 0 : (1<<3)) |
           (PIND&(1<<3) ? 0 : (1<<4)) |
           (PIND&(1<<4) ? 0 : (1<<5)) |
           (PIND&(1<<5) ? 0 : (1<<6)) |
           (PIND&(1<<7) ? 0 : (1<<7)) |
           (PINE&(1<<0) ? 0 : (1<<8)) |
           (PINE&(1<<1) ? 0 : (1<<9)) |
           (PINC&(1<<0) ? 0 : (1<<10)) |
           (PINC&(1<<1) ? 0 : (1<<11));
}

/* Row pin configuration
 * row: 0   1   2   3   4   5   6   7   8   9   10  11
 * pin: B6  B5  B4  B3  B2  B1  B0  E7  E6  F0  F1  F2
 */
static void  init_rows(void)
{
    DDRB  &= ~(1<<6 | 1<<5 | 1<<4 | 1<<3 | 1<<2 | 1<<1 | 1<<0);
    PORTB |=  (1<<6 | 1<<5 | 1<<4 | 1<<3 | 1<<2 | 1<<1 | 1<<0);
    DDRE  &= ~(1<<7 | 1<<6);
    PORTE |=  (1<<7 | 1<<6);
    DDRF  &= ~(1<<2 | 1<<1 | 1<<0);
    PORTF |=  (1<<2 | 1<<1 | 1<<0);
}

static uint8_t select_row(uint8_t row)
{
	uint8_t allow_select = 0;
	
    switch (row) {
        case 0:
		    allow_select = (PINB&(1<<3) ? 0 : 1);
            break;
		case 1:
		    allow_select = (PINB&(1<<5) ? 0 : 1);
            break;
		case 2:
		    allow_select = (PINB&(1<<4) ? 0 : 1);
            break;
		case 3:
		    allow_select = (PINB&(1<<3) ? 0 : 1);
            break;
		case 4:
		    allow_select = (PINB&(1<<2) ? 0 : 1);
            break;
		case 5:
		    allow_select = (PINB&(1<<1) ? 0 : 1);
            break;
		case 6:
		    allow_select = (PINB&(1<<0) ? 0 : 1);
            break;
		case 7:
		    allow_select = (PINE&(1<<7) ? 0 : 1);
            break;
		case 8:
		    allow_select = (PINE&(1<<6) ? 0 : 1);
            break;
		case 9:
		    allow_select = (PINF&(1<<0) ? 0 : 1);
            break;
		case 10:
		    allow_select = (PINF&(1<<1) ? 0 : 1);
            break;
		case 11:
		    allow_select = (PINF&(1<<2) ? 0 : 1);
            break;
    }
	return allow_select;
}

[DMA]

I guess you're not selecting the row, you're reading it. Took me some time to understand that this is a generating/active matrix, not a scanned/passive one.

Plus a subtle possible bug - if you don't have anything pressed in a row it's not updated. If you get an ideal reading (that is, a single key is pressed, detected, and then released while outside of the main scan loop) - you'll get a stuck key, because allow_select will always be false and matrix not updated anymore.

To fix - either zero out matrix_debouncing row if allow_select is false (pro tip - keep shorter if branch on top, so "if (!allow_select)" - or zero it out after you assign matrix row from matrix_debounced.