Universal Model M Controller

[scottc]

Mini USB? Quit being awkward! (Actually, I was the same way when I found the NovaTouch was Micro, but once I got a nice cable I wasn't bothered. Mini's supposed to be dead, superseded when Micro was released; but its zombie is doing a good job terrorising the land of the living after all these years.

Note the "minor nitpicky" part! As a non-Apple person, I've had nice Micro USB cables for years. They're usually firmly attached to my phones, tablets or other devices, though; no keyboards yet apart from my unused Pro Micro converter.

[phosphorglow]

Thanks for the encouragement everyone! I was getting a little bummed out about the Micro B. The only issue I was having with using USB-B on bluetooth applications was the power switch... but then I stepped away and got to thinking about some clever mounting techniques I've seen in vintage electronics. Solder the switch case to the USB connector! Plenty of space and it's a perfect fit.

Ideally it should be moved out about 2mm, but at the moment it's pretty easy to actuate.

2015-04-04 10.53.36.jpg (17.58 KiB) Viewed 5589 times

General layout, everything fits perfectly with clearance between steel plate and the EZKey:

2015-04-04 10.56.24.jpg (41.02 KiB) Viewed 5589 times

A happy coincidence is the wire routing. I was worried about it looking sloppy, but they fit just right between the mounting feet. Rockin'.

So, after some pointers/examples/help with TMK with bluetooth I can actually test it out.

A few key points that I'd like to have:
- Using the UVcc/Vbus to take care of the switching between bluetooth/USB. If that doesn't work or it's buggy, using Halvar's idea of a high impedance resistor connected between USB 5V and a spare input.
- Key combination for bluetooth pairing. (Pairing button went away in the USB-B scenario.*)
- Optional key combination to jump to bootloader.

In the meanwhile I have about 10 M's sent to me for repairs to take up the rest of my weekend. This week had so much going on I've barely gotten any keyboard related work done! Time to attempt to catch up!

(*Expanding on the lack of pairing button with other thoughts: If it becomes a matter of preference to have a dedicated pairing switch and you want to get creative, coming up with a clever board utilizing the speaker grill is an idea. You could have battery level lights, pairing button, etc.)

[phosphorglow]

Well, here's an annoying issue, but it might just be something that falls under my strict no-tolerance annoyance list.

General typing and various online typing tests have proven things to be working quite satisfactory. I suppose I'm an average typist amongst the keyboard enthusiast community, hovering slightly above 100WPM in Qwerty. But today I noticed the quirk when I type "you" really fast that "u" sometimes gets left out because of blocking in firmware. Yay for membrane matrix.

Currently I'm using Soarer's Controller with blocking and standard debounce of 5. The agenda for the night is to get the pin configs for TMK updated for this controller and see what happens.

This got me thinking that other languages and layouts could potentially be even quirkier at fast typing speeds. It also got me thinking about how awesome IBM engineers are since they were able to sidestep these limitations. So, glancing back at stock controllers I see some capacitor and resistor packs in line with the FPC connectors and I wonder if someone could shed some insight into their role.

[elecplus]

Kind of sounds like you are having the same sort of issues as the original typewriters.
We have the QWERTY layout because on the original layout, the women learned to type too quickly, and the "arms" that held each character to be typed got tangled up frequently. So they moved the letters around, trying to put the least used combinations closer to each other, and the most used farther apart.

As typists still got faster, IBM developed the Selectrics and the wheelwriter, so there were no arms to get tangled up.

If you ever see a Selectric with a serial port on it, don't kill it for the caps. It can be worth up to $3000, if in good working order.

[phosphorglow]

Ahhh Qwerty... I love/hate your inherently difficult design. It's too engrained in my brain to switch to Dvorak on a real keyboard so I learned to use it on my phone instead. Amusingly I have a difficult time typing Qwerty on a touchscreen now.

[Redmaus]

I have thought about learning dvorak or colemak, but then I remember that every other computer I use besides mine will have qwerty. Has anyone put bluetooth in a kishie yet? If I ever got one that would be one of the first things I would do.

[phosphorglow]

Learning multiple layouts reminds me of relatives who speak two languages and occasionally start mixing them up while talking. I kept doing that when I was trying to learn Dvorak on a real keyboard. Bluetooth kishsaver... The sheer size/weight ratio screams the necessity for bluetooth. I love the idea.

So, further playing around made me notice there's a very small time frame of blocking that takes place between key presses. Looking back on the thread for Soarer's Controller he had a nice description of the logic going into the blocking, but I don't know if there's some sort of interval adjustment. Or something.

[phosphorglow]

Stock Model M controller smartly handles being able to hold down Y and either O or U, despite the limitations. That part I'm not concerned with, it's the name of the game with this matrix, it's the timing interval between letting off Y and still getting a block on U.

I should be smart and relevant by posting this question in the proper thread, 'eh?

controller10.jpeg (89.4 KiB) Viewed 5746 times

[phosphorglow]

So it seems that TMK has significantly less of a delay when it comes to blocking. It's such a tiny quirk though, and it made me realize I often use my left index finger to hit Y. Go figure.

Next matter of importance:
Hooked up the 3.3V voltage regulator.
Cut trace to UVcc/VBus.
Reset button to get into DFU mode doesn't work.
Jumper wire between USB 5V and the UVcc/Vbus pad.
Reset to DFU mode works again.
Flashing a hex file throws error.
Bypass voltage regulator to run everything at 5V again and it succeeds in flashing.

So, umm... I'm guessing flashing at 3.3V doesn't work? Or am I missing something?

[phosphorglow]

(double post!)

[phosphorglow]

(double post!)

[phosphorglow]

Yep. Officially confused. You can flash a hex file to a Teensy or Arduino running on 3.3V, right? I'm stuck.

[hasu]

Yep, it works with 3.3V but 16MHz is a bit out of spec. I think 3.3V Arduino uses 8MHz Xtal instead of 16MHz.
I confirmed ATMega32U4 with 16MHz Xtal works at 3.3V but it is out of spec and it might have problem. I don't know about AT90USB1286 though.

Try 8MHz Xtal.

And can you post schematic so that we can check easily? The pic of PCB traces is low resolution and not easy to read

Great job so far!

[phosphorglow]

Ah! I was starting to suspect the crystal, but I seem to remember reading that the DFU bootloader kicks the CPU speed down to 1MHz with factory settings, and then the prescaler sets the speed when the program in firmware runs. (Did I get that right?)

But, I suppose there's a certain voltage it takes to get the crystal oscillating in the first place. I'll take a look at the datasheet and try to find another crystal.

I'll work on putting up a higher resolution image.

Thanks!

[hasu]

Hmm, I looked into this image again. Not sure but it looks like UCap(pin7) is given 3.3V line.
As far as I understand you cannot give UCap and UVcc power at a time.

[XMIT]

IIRC the ATmega32U4 runs at 16MHz at 5V and 8MHz at 3.3V. One of the datasheets I read suggested something like this. So what hasu posted seems correct.

[phosphorglow]

Bah. Can't upload it to my site at the moment so I have to be a bandwidth hog. I'll move it later. Here's the updated layout. I actually don't have Ucap connected like it was previously.

Spoiler:

controller13.jpg (644.56 KiB) Viewed 5655 times

[phosphorglow]

So, try an 8MHz crystal?

Which leads me to wonder how the Teensy can use a 16MHz crystal and run it at 8MHz... Oh! I just remembered earlier!:

I compiled TMK with 8MHz frequency, which didn't work, and re-compiled with 16MHz and it did. 22pf caps too high, or does this crystal really just not like 3.3V? (EDIT: At the time I was still running on 5V and trying 8MHz).

http://www.mouser.com/Search/ProductDet ... M1600-20-X

[phosphorglow]

Or if I had properly read the Input Clock Frequency section I would have realized it reflected the frequency set externally... Anyways, I set it back to F_CPU = 16000000, recompiled, and flashed the chip using 5V from USB. Works just as before.

Then I put the voltage regulator back into action, and now I'm typing on a board running on 3.3V.

...but I can't flash it on 3.3V.

[hasu]

So keyboard works but bootloader doesn't with 16MHz crystal and 3.3V, right?

How do you cut trace(or jumper) in fact when you install the voltage regulator?

Next matter of importance:
Hooked up the 3.3V voltage regulator.
Cut trace to UVcc/VBus.
Reset button to get into DFU mode doesn't work.
Jumper wire between USB 5V and the UVcc/Vbus pad.
Reset to DFU mode works again.
Flashing a hex file throws error.
Bypass voltage regulator to run everything at 5V again and it succeeds in flashing.

[phosphorglow]

Correct. Actually, bootloader enumerates and I can erase but not flash on 3.3V.

Cut the two traces near the regulator, remove fuse, jumper between UVcc/Vbus and USB 5V.

controller14.jpeg (28.83 KiB) Viewed 5630 times

[phosphorglow]

...oh, and 3.7V going into the regulator input from battery. Heh.

[hasu]

I see...
Just wild guess, no capacitor on output of regulator may cause kind of power problem. I imagine that flashing needs more current, output voltage comes down and MCU is brown out reset finally...

What if you add output capacitor on regulator?

[phosphorglow]

Sounds like a reasonable theory - I'll give it a shot. I just watched the voltage while attempting to flash and it stayed steady at 3.29 the whole time. I'll see what the current draw looks like and try a capacitor.

[phosphorglow]

Nope. :/

Tried a 1uF 50V electrolytic. Same thing.

[phosphorglow]

I suspect using the stock fuse settings is my issue. I'm going to attempt changing it to 8-16 MHz xtal. I'm nervous after my previous learning experiences... ;P

This informative thread sheds some insight.

[phosphorglow]

Nevermind! Comes stock with that fuse setting. I'm still stumped.

[Muirium]

Is there any particular harm in only being able to reflash when powered from USB voltage? As far as I know, fiddling with firmwares over Bluetooth is crazy town!

I actually really like having a USB fallback. The socket could even be physically switched between charging only and full control, also turning the Bluetooth on and off. That'd be just as elegant as the commercial Bluetooth hardware I already have.

[phosphorglow]

That's actually the setup. Flashing over bluetooth is probably impossible since you have to kick it into the bootloader. The problem right now is the voltage is dropped down to 3.3V regardless of USB or battery power and the general consensus is that the 16MHz crystal isn't liking it one bit. I'll order in some 8MHz crystals and see what happens.

"Converting to 3.3 volts saves a lot of power. But the CPU is not rated to run at 16 MHz when powered by 3.3 volts. It usually works, at least at room temperature, but technically 16 MHz at 3.3 volts is overclocking." (From PJRC).

...wonder what would happen if I stuck it in the refrigerator and tried flashing it... ;P

Anyways, as it stands, the power switch kills power to the board in general. Halvar mentioned that switching between bluetooth and USB with a key combo is doable in addition to using a spare pin to sense voltage. There's probably going to be a bunch of different angles to stab at it.

[Muirium]

Ah, good to see you're a step or two ahead of me. I'll only get good at electronics when it becomes smart enough that all you have to do is explain what you'd like it to accomplish.