Advice needed - Repurposing Apple eMate 300 keyboard

[MacMarty15221]

Hi! I'm Marty, and I'm new in town. I have a project goal and need pointing in the right direction.

I'd like to "repurpose" the keyboard from the Apple eMate 300, with a hopeful goal of turning it into a BlueTooth board. Yes, I know that it's barely mechanical - undersized mechanical keys, over rubber dome, over membrane keyboard. I have seen the Model-M-to-BT mod done by Benjamin Gould and posted on Adafruit.

I am naieve enough to have poked around with a VOM continuity tester, and seen that I don't get a dead-short contact closure when I press on the eMate keyboard's membrane. Can anyone set me in the right direction - is there any existing approach for jacking up a membrane keyboard matrix and attaching a replacement controller? (Maybe some Teensy?)

Any starting advice would be profoundly appreciated by this noob - I am only an egg.

[Muirium]

Hmm, can you see the rows and columns? On a Model M (which is the only membrane keyboard I've worked with) they come out the top in two groups, like this:



Which you want to analyse, to find the matrix, like this:



http://deskthority.net/workshop-f7/blue ... uetoothing

[MacMarty15221]

Yes, the two active layers of the membrane come out to pressure-point connections as in the photo. 8 lines on one, 16 on the other. (Oh, please let this be a viable solution...)

...but I have this annoying desire to understand what's going on under the hood. Is the microcontroller above looking for an open/closed contact? Or is it looking for some (unknown) change in resistance at each level? (An analog input?) I'm trying to understand the scheme at the theoretical level so I can proceed in an informed fashion. (Something other than "plug it together in blind faith".)

I have a couple of Teensy 2.0's coming in the mail, thinking to try the ADB-to-wired-USB approach as a stepping stone. Then maybe this matrix-to-wired-USB solution, if I can call it that. Last hop looks like matrix-to-BT.

[Muirium]

If you get straight from matrix to Bluetooth, let us know how you did it, because that's something lots of us want to do too.

The way the matrix works is all digital. The controller strobes one axis while sensing the other. So what you get is a line of 1s and 0s at a time, which are then interpreted as the appropriate USB (or Bluetooth) codes. Bear in mind that mods (Shift, Alt, etc.) are a layer of logical complexity on top of the matrix, for the controller to deal with in software.

Soarer's Controller is a great firmware to use on a Teensy for this. (I have it in my custom keyboard.) But if you want to code things for yourself, keep asking questions. There's people here who know most anything. Especially Hasu, whose open source TMK firmware handles everything from custom controllers to ADB converters.

[MacMarty15221]

"Never build a square wheel where a round one already exists." Which means I will certainly be using firmware from Soarer or Hasu.

Piecing together what I -think- I now know, it seems like the simplest way would be to send serial scancode 3 from the Teensy into one of the BlueFruit modules, probably the BlueFruit EZ-Key. If that works I'll be a happy guy.

[MacMarty15221]

Restatement of my possible stepping-stones:
1) ADB-to-wired-USB with an Apple Extended II, because I have a few.
2) Matrix-to-wired-USB using the eMate 300 keyboard, building on step 1
3) Matrix-to-BT, so I can finish my eMate Mini project. (iPad Mini Gen2 housed in an eMate case.)

[Muirium]

Well, ADB conversion definitely works. But the terrible battery life of the Adafruit Model M project was caused by "bitbanging" the keyboard's original controller. The combination of old desktop hardware and the need to keep polling it, unable to take a rest, sucks power and chewed through even a big battery pack in hours instead of days. The way to make practical Bluetooth is straight in the controller itself.

Anyway, here's the cream of the crop for info on all of this:

http://deskthority.net/workshop-f7/work ... t7192.html

Hasu's and Soarer's firmwares are included of course.

[MacMarty15221]

OK, I'm on a roll here, gotta share the joy, and maybe get a sanity check for my planning.

I built a ADB-to-USB converter cable using the Teensy 2.0 and the ADB_USB converter provided in the tmk_keyboard firmware. Testing it with an Apple Keyboard 2 reminded me that I am grateful for the inverted-T arrow-key layout. An Apple Extended Kbd 2 is so much better, desk space be damned.

Now I'm ready to use another Teensy 2 to tackle the eMate 300 keyboard. This time I'm going to try Soarer's firmware, starting with the Kevex-blank example so I can use HID-listen to suss out the matrix. I'm choosing the Port B lines for strobe, since the ATMEGA32u4 spec document states that "Port B has better driving capabilities than the other ports". (I do see that Soarer chose Port B for the 8 sense lines, but what the heck.) I'm intending to use PE6, PE7, PF0, PF1, and PF4..PF7 for the additional eight strobe lines I need - the eMate keyboard FPCs are set up 8x16. I may shuffle some of these pin assignments may change on the final PCB, depending on what is simplest for trace routing.

The flex cable connectors are on a 1mm spacing. I've carefully robbed the two off of the eMate logic board for now.

Fun, fun, fun!

[Muirium]

Sweet.

I'm thinking of doing something like this to an AEK II at some point. Cindy has a few in so-so condition that I wouldn't feel too bad about chopping. An Apple Extended Space Saving Keyboard would be a fine old TKL indeed! Although I've no idea if it'll be easy…

[MacMarty15221]

OK, the good news this evening is that I have Soarer's firmware in the Teensy now, along with a .SCB file jammed full of UNASSIGNED. (No keys defined.) HID_Listen is happily showing me key presses and releases. What I can't quite figure out is the encoding (bit-packing?) of the hex numbers returned by HID_Listen.

If I stimulate row 1 left to right, (<Tab>,Q,W,E,R,T,Y...,) I get 01, 09, 11, 19, 21, 29, 79, [69 and 71], [69 and 71], 61, 59. I can sort-of see that the row number is packed into the 3 least significant bits, and then the column number is added into the next five bits. Except when things go hay-wire out there past /29. Maybe I literally have somem wires crossed, or my sense bits mapped incorrectly. *puzzled* Any thoughts?

[MacMarty15221]

I should also note that I -am- using PD6, which runs the LED. I've seen comments that imply that it should be avoided, but (electrically) why? Is it "haunted" by the LED in some way?

[Hak Foo]

The "diode" aspect of PD6 means that you can't sense an incoming signal on it.

[Muirium]

Yes, I had a lot of trouble with it on my v.1 OneHand PCB. The problem may well be polarity based, as it is a diode we're talking about!

Don't worry about the codes hid_listen is showing. If every key is doing something, assign them!

[MacMarty15221]

The "diode" aspect of PD6 means that you can't sense an incoming signal on it.

Ah, that's the ticket! Shifting pin assignments so that PD6 got rid of that double-key stuff, it seems.

Mu, I -can't- totally ignore the numbers HID listen provides! I need to know WHERE they belong in the matrix. My previous grubbing around with some disassembled flex layers showed me that there are keys on all 8 lines, and the line assignments are -not- orthoganal to the columns. Figuring out the first 80% (on paper) was relatively easy, I learned a lot that way. Now I need to back and tangle with that last 20%.

[MacMarty15221]

Got a usable keymap for my Soarer's Controller (eventually) by shoving arbitrary but unique HID_codes into unknown spots, using HID_listen to see what came out. Analyze, lather, rinse, repeat. Was puzzled about where to find all available keycode name strings, Quantalume turned me on to the fact that they are found in Soarer's CONVERTER codebase.

Lots of grubbing about the interwebz suggests that there's no adequately simple USB-to-Bluetooth device off-the-shelf. I actually circled around to Mu's [Brainstorming] post here on DT in September - how about that! It seems that tapping into serial data at a known baud rate would allow use of a number of Sparkfun or Adafruit devices. (And takes me back to the bad old days when we had to make modem cables by hand, and fuss with other such minutia. Three cheers for USB, Cat5 Ethernet, and other modern conveniences!)

Am continuing to scratch my head on this system integration conundrum. Always loved me a challenge. I wonder if we can beg a little bit of code support for serial output from Hasu or Soarer?

[MacMarty15221]

..And then there's this - Not a Teensy, but it is Atmega32u4. Hm...

"Blend Micro is our first integrated developement board, we have "blend"ed Arduino with Bluetooth 4.0 Low Energy (aka BLE or Bluetooth Smart) into a single board. It is targeted for makers to develop low power Internet-Of-Things (IoT) projects quickly and easily.

The micro-controller unit (MCU) is Atmel ATmega32U4 and the BLE chip is Nordic nRF8001. Blend Micro runs as BLE peripheral role only, it allows BLE central role devices to establish connection with.

http://redbearlab.com/blendmicro

[Muirium]

Yeah, I should have pointed out that Soarer's Controller is actually an extension of his legendary Converter, so they share the same docs (which he saved all of a few kilobytes by not duping in the controller's zip file). Most of us here encountered his Converter first, so this didn't seem quite as arbitrary!

That Blend Micro board is interesting, but I have a couple of qualms about it. First: not enough pins to run a controller. We need 20 at least for compact keyboards. Second: where's the antenna? Bluetooth chips usually have a little zig zag trace on board. And a bonus qualm: what's all this about apps? We just want to use Bluetooth HID (human input device, including mice, keyboards, joysticks etc.) rather than have to implement all that from the ground up.

I'm no programmer, though. So all of the above could be nonsense. You decide!

[MacMarty15221]

...We just want to use Bluetooth HID (human input device, including mice, keyboards, joysticks etc.) rather than have to implement all that from the ground up.

Totally understood and agreed. It's a new and sunny day here, and I've found a few positive items.

Adafruit has a BLE4.0 breakout card that uses only (!) six pins and SPI. The images show that the low-energy antenna is an L-shape, rather than the zig-zag for standard BT. https://learn.adafruit.com/getting-star ... rything-up

The Teensy 3.1 supports SPI and has -34- digital I/O pins, though we're going to lose a few for that SPI link. I bet we can end up with 20 or 24. (I need 24 for my eMate project.)

I used to be a programmer, back in the day. Enough so to understand that we're going to need some hints from our esteemed firmware gurus, to provide guidance on changes that would allow us to squirt data out the side with the SPI-capable pins, rather than through the USB connector. Maybe I can help by examining the PCB issue. Some of those I/O pins are just pads on the bottom side of the Teensy. Onward!