A Smaller Xwhatsit

[wcass]

OK, i'm ready to give volunteers a shot at debugging this.

I have two assembled but not working and one unassembled. PM me if you would like to try getting one to work.

Thanks

[hypoxia]

I just started following this project today and read the project is currently developing this redesigned custom board.

Here's a stupid question since I am a software dev and not an engineer: If the only necessary interface is 30pin -> logic -> usb, why not use a RPi zero instead of a custom board: http://www.microcenter.com/product/4577 ... ment_Board.

These cost 5 USD and are quite small. This would give you power, USB and 40 3.3V pins and easily flashable firmware. There are also bluetooth and battery packs available on the more expensive models if you wanted to try a wireless keyboard later.

There is no software presently but it should straightforward given the existing tested firmware and configuration tool. I do not have a model F but I'd be happy to try and contribute on the software end if this is a viable solution.

[wcass]

Thanks hypoxia. I am a terrible programmer myself, so I like to hear from folks that can.

The controller needs to be able to detect a few pF change per switch at a reasonably fast scan rate. I believe that it dose this using two 4 channel comparators. the documentation:
http://downloads.cornall.co/ibm-capsens ... e-usb.html

If you build a better controller, the (keyboard) world will beat a path to your door.

[0100010]

Yeah, an RPi has more than enough horsepower and expansion ability, but you would still need to build the cap-sense portion of the controller.

wcass - I'd sign up to help with this controller, but I don't have ready access to a scope in TX or VA (where I am most of the time). Maybe the next time I am in CA (in Santa Clara) it may be an option (but that may not work timeline wise for the F62 / F77).

[hypoxia]

Thanks! The linked pdf explains it pretty well.

[idollar]

I have found this (x25 for $2)

http://www.ebay.de/itm/361426485831?_tr ... EBIDX%3AIT

LM339AD.JPG (21.16 KiB) Viewed 9265 times

Also, if done, I would try to ensure different thresholds for each key ...

[idollar]

This would be a full linux inside the keyboard.

How long it would take to boot ?
There would be a need to ensure syncing the file system on power down

It would be cool project, but it has some drawbacks.

[Halvar]

People have programmed the Raspi natively without the need to boot a Linux Kernel, but it's hard to do.

Since the comparator chips would still need their own PCB, I don't see too much of a price advantage in using the Raspi though.

I don't know if you can use its USB port as a HID device. What I know is that it normally uses more power than the 500mA a USB 2.0 port supports. Many times more than a AVG microcontroller or even the oldest keyboards in any case.

[cookie]

I am a Software Developer and even though I just understand a fraction of what you are talking about, I am totally mesmerized

Really nice work

[hypoxia]

There are a lot of "plugin" capacitance sensors for prefab boards (the Teensy 3 even comes with 12 cap sensors built in). However, basically all of them look like they are using oscillators to measure which can take a longer than is desirable in this use case (the Teensy's take about 3ms to measure I think). I believe there are oscillator prefab ICs that would work in this case, e.g. this PCap02 which oscillates up to 500,000 Hz and can measure at 500kHz (http://www.acam.de/products/picocap/pcap02/features/) but they don't have the convenient plug in boards, at least not that I can see.

I think you're better off debugging the existing PCB, but if you were to start from scratch you could potentially eliminate the need for custom built cap sensors with either of these:

1. Atmel has its own well-tested capacitance measurement ICs with its own calibration software to tweak the filters and thresholds etc. The QT60486 (http://www.atmel.com/Images/qt60486_801.pdf) can supposedly measure a 32 key matrix in the femtofarad range at up to 500microsecond scan speeds which would allow for 2000Hz full keyboard measurements assuming you use 4 of them to continuously measure the entire keyboard. This seems like the easiest solution but you'd still have to build a PCB because there's no Arduino boards or anything for it.

The PDF also mentions including support for Beamwriters which have some voltages out of these chips range.

2. The only other point I notice is that the main issue of the difficult speed threshold mentioned in the PDF (which rules out oscillator sensors) assumes that there is 1x sensor and no parallelism whatsoever so the CPU has to scan all 128 keys and reset the sensor every time.

But ICs like the PCap have their own internal RISC chip which executes the measurement in parallel without any external driver, so if you took the 8x16 matrix and wired the 8 X-Axis wires to a single Pcap02, you only need to let the sensor measure 16 times instead of 128 (i.e. once per Y value), so, instead of needing 156microsecond maximum measure times you only need 1.25 maximum millisecond measure times. And obviously, you can add more sensors all the way up to a 20ms read time if you have enough chips to support 128 continuous sensor inputs.

And I agree, you really have an amazing product here.

[phosphorglow]

They're alive! I have two of them working and giving me block blips in the capsense utility!

THEY'RE SO CUTE AND TINY AND AWESOME!

(Seriously, they're super tiny. Takes up basically the same space as a cluster of 4 function keys. And they're actually pretty easy to hand solder! Love 'em!)

OK - so long story short, after a lot of desoldering, the culprit was bad reflow from the skillet.

30pf capacitors for the XTAL work just fine (so an assumption of 3pf in stray capacitance does seem correct for this PCB).

After resoldering everything by hand and mucking about with the USB connectors, all is well.

^_^

[idollar]

Nice !

[Techno Trousers]

Great work, phosphorglow! Ellipse must be drawing a big sigh of relief today.

[0100010]

Came down to solder huh?

[wcass]

Yep - I suck at it. My reflow looks pretty, but works poorly. My iron work looks awful and usually just doesn't work too. I really should stick with what I am good at, stop trying to solder things myself, and start relying more on this very cooperative community.

[Techno Trousers]

The important thing, though, is that your design was correct from the start! I may want to pick up a couple of these if a group buy is run eventually. My soldering skills are very suspect too, so a fully built and tested GB would be my preference.

[Ellipse]

Yes this is great news! I expect to make extra units as part of the F62/F77 project. Barring any issues with my thorough testing, it looks like this will not hold up the project.

[vivalarevolución]

They're alive! I have two of them working and giving me block blips in the capsense utility!

THEY'RE SO CUTE AND TINY AND AWESOME!

(Seriously, they're super tiny. Takes up basically the same space as a cluster of 4 function keys. And they're actually pretty easy to hand solder! Love 'em!)

OK - so long story short, after a lot of desoldering, the culprit was bad reflow from the skillet.

30pf capacitors for the XTAL work just fine (so an assumption of 3pf in stray capacitance does seem correct for this PCB).

After resoldering everything by hand and mucking about with the USB connectors, all is well.

^_^

Great news.

[0100010]

Yep - I suck at it. My reflow looks pretty, but works poorly. My iron work looks awful and usually just doesn't work too. I really should stick with what I am good at, stop trying to solder things myself, and start relying more on this very cooperative community.

Meh - all good // plenty of other stuff the community is grateful to you for! I will admit I am not the best solder-er myself. I do have an urge to build a reflow oven (though I don't really have any plans for stuff that I would want to reflow in it, it is just more of the next project to do kind of thing).

[alh84001]

Yes this is great news! I expect to make extra units as part of the F62/F77 project. Barring any issues with my thorough testing, it looks like this will not hold up the project.

Could additional ones be added to an existing F order?

[wcass]

Could additional ones be added to an existing F order?

Ask in your F order thread.

All of my files will be published, so anyone that wants to can make them (or have them made). I managed to get PCBs and components to build 3 of these for about $75. There is added value in getting someone to assemble and test it out for you, so take that into consideration.

Right now I am making a few minor tweaks to USB footprint holes, moving some vias, and trace routing. I'll publish the files shortly.

[idollar]

Could additional ones be added to an existing F order?

Ask in your F order thread.

All of my files will be published, so anyone that wants to can make them (or have them made). I managed to get PCBs and components to build 3 of these for about $75. There is added value in getting someone to assemble and test it out for you, so take that into consideration.

Right now I am making a few minor tweaks to USB footprint holes, moving some vias, and trace routing. I'll publish the files shortly.

wcass ... that's a very good idea.
I actually wanted to ask your for the source files to do some updates that I guess that could be interesting:

1) Additional pads, in parallel to the existing USB connector, that could be used to solder the USB cable directly. I have already broken 1 controller because of the week connector. I would prefer to cut the cable and solder it directly.

2) Pads to connect the Model M membrane directly to the controller. One could replace the model M controller with a xwhatsit.

3) (related to the previous) distribution of components and connecting pads such that the controller could replace the position of the Model M controller.

4) Additional Bluetooth daughter board. I am not interested on this, but lot of people has asked me about it.

1 to 3 should be simple to implement.

Thanks a lot for your nice work !!!!!

[wcass]

I plan on designing a controller based on this specifically for FSSK and FEXT. These will fit nicely into the vintage IBM cases. They will have 3 USB connector options - direct wire, classic USB-B, and micro-USB. I have had surface mount USB ports pop off too. The micro-USB receptacle that i used on this controller is surface mount, but has 4 through hole pins (for shield connectivity). The through hole pins make a very strong physical connection to the board.

I would not suggest using this controller for a model M. This controller has the columns on the right and rows on the left (matching the FSSK and FEXT PCB) where the M controller has the columns and rows the other way around. But a bigger deal is that xwhatsit's firmware presumes NKRO switch matrix. The original M controller and all of the other substitute M controllers block key combos that would lead to ghost character generation; there is nothing to do this in xwhatsit's code so ghost characters will be registered.

Bluetooth would be nice, but i don't have the skill-set to implement.

[alh84001]

I plan on designing a controller based on this specifically for FSSK and FEXT. These will fit nicely into the vintage IBM cases.

Wow. Good to know. Owing to my non-existent soldering skills, I might wait with my FSSK build so I avoid desoldering original xwhatsit. Do you have any rough timeline maybe?

[idollar]

I plan on designing a controller based on this specifically for FSSK and FEXT. These will fit nicely into the vintage IBM cases. They will have 3 USB connector options - direct wire, classic USB-B, and micro-USB. I have had surface mount USB ports pop off too. The micro-USB receptacle that i used on this controller is surface mount, but has 4 through hole pins (for shield connectivity). The through hole pins make a very strong physical connection to the board.

You are great wcass !!!

I would not suggest using this controller for a model M. This controller has the columns on the right and rows on the left (matching the FSSK and FEXT PCB) where the M controller has the columns and rows the other way around. But a bigger deal is that xwhatsit's firmware presumes NKRO switch matrix. The original M controller and all of the other substitute M controllers block key combos that would lead to ghost character generation; there is nothing to do this in xwhatsit's code so ghost characters will be registered.

I was mentioning this because orihalcon has done it before and reported to be working:

keyboards-f2/solenoid-in-model-m-t11683.html
https://www.youtube.com/watch?v=DYIDDoRS25Y

Bluetooth would be nice, but i don't have the skill-set to implement.

I do not know how to do it neither, but is should not be too complex.
I currently do not have the time to do it.

Great news, wcass. Thanks a lot.

[lot_lizard]

2) Pads to connect the Model M membrane directly to the controller. One could replace the model M controller with a xwhatsit.

I would not suggest using this controller for a model M. This controller has the columns on the right and rows on the left (matching the FSSK and FEXT PCB) where the M controller has the columns and rows the other way around.

I have started researching making a mini version of this FSSK project (if we decided to make our own cases, we have options for standard or compact layouts). For that, figuring out how to compress the PCB down is ideal. Using a flexible PCB, rigid/flex, or even flex with rigid inserts for the pads could be very interesting. With the flex, using a Zif (or whatever) to connect to this new controller would be AMAZING

If the top of the PCB magically "went away", we could compress the top of the physical inner assembly by ~12mm (thats A LOT) before we reach a barrel base

[idollar]

2)

If the top of the PCB magically "went away", we could compress the top of the physical inner assembly by ~12mm (thats A LOT) before we reach a barrel base

a) An idea would be to have two connectors: columns) on the long edge of the PCB rows) in the short edge of the PCB.
This will solve the routing problems and the need to have a GND separation between the PCB top and bottom layer.
In order to avoid the crossing of the wires to the controller, a version with rows and column separated in the right edge could be designed.

b) Another option is to integrate the controller in the sensing PCB, but this will require more surface and the conflicts between the routing of the top and bottom layers will not be resolved.

If you go for a new case and barrels plate, I offer to redesign the PCB. The idea a) is actually a simplification of the PCB that could be easily done. Also, if the FSSK holes are not required, the PCB will be simpler.

Let me know ...

[lot_lizard]

I PM'd i$ with some measurements for the bottom row of screws (the only spot where the top/bottom plate assembly would pass through the PCB to secure it along the bottom flange). What I would like to do for awareness of everyone here, is have a single top plate and barrels, with single version of the PCB using this new controller, and give people the option of changing out the backplate if they wanted to go from a SSK drop in, or compact case redesign. Once I know how much we can compress the PCB, I will start in on the compact case version of the assembly. Exciting stuff

[Ellipse]

As an update I have been testing the smaller xwhatsit controllers re-designed and assembled by red/wcass/phosphorglow and there are some issues with the prototypes.

I have tested two of the prototypes on 3 different computers (2 desktops and 1 notebook) running Win 7 (one) and Win 10 (two PC's) as well as two different 10 foot USB micro cables and there is an issue: the keyboard stops working after a few minutes and it requires disconnecting and reconnecting the USB cable for it to resume working. Sometimes the threshold in xwhatsit's GUI also resets to a random number, even though I have clicked the store override in EEPROM button and closed and re-opened the utility. I have set column skips where appropriate and that helps make the crashing every few minutes instead of every minute or so.

Also the pad for the "1 !" key shows up as pressed unless the threshold is set to 192 (too high a threshold for any other key to be recognized). Switching the jumper wire for rows 7 and 8 move the affected pad's position on the matrix in xwhatsit's software but it's always the same pad.

Also I saw when testing the columns for strobing that the voltage levels were about 1.7v instead of the 0.7v of the originals and the strobing time was about twice as long (the size of the "rectangles" actually changed depending on which two columns were being tested - possibly due to smaller or more variable trace lengths? This could be due to the smaller board size and total length of the traces and may or may not be an issue affecting operation.

Test with original xwhatsit (1st screenshot) and small xwhatsit (2nd screenshot):

original xwhatsit column strobing test.jpg (62.78 KiB) Viewed 8907 times

small xwhatsit column strobing test.jpg (64.57 KiB) Viewed 8907 times

[Muirium]

Yuck.

Has Xwhatsit been involved at all in this shrink of his design? From what I recall back when he was doing the original F controller, he was careful about routing the analog stuff. There's more than just a little touch of black majicks about it. Especially when it comes to grounding.