READY - $10 - DIY Through Hole Universal Model F and Beamspring Controller

kmnov2017

07 Feb 2020, 19:17

A few weeks ago I discussed this concept with user listofoptions and he is in the process of designing a through hole universal beamspring/model F controller.
IMG_20201102_224117_711.png
IMG_20201102_224117_711.png (618.81 KiB) Viewed 9288 times
Features:

1. Full compatibility with Beamspring Keyboards and Model F keyboards
2. Easy to hand solder components - all components require through hole soldering
3. Promicro as the "brain"
4. Fairly small form factor
5. Use of QMK firmware
6. Support for expansion header to wire up lock lights or solenoid
7. Optional plugboards for model F, Beamspring and Displaywriters (Purely optional, you can instead use jump cables to wire up the
controller


Link to GitHub https://github.com/listofoptions/TH-XWhatsIt

And the best of all, it will cost around 10 euros in components (including PCB and Promicro)
gerbers (1).zip
(952.13 KiB) Downloaded 153 times
Last edited by kmnov2017 on 02 Nov 2020, 22:51, edited 17 times in total.

listofoptions

07 Feb 2020, 19:21

contributions, and suggestions welcome! board is likely to go through *multiple* revisions, but thankfully its fairly modular. https://github.com/listofoptions/TH-XWhatsIt

User avatar
ZedTheMan

07 Feb 2020, 19:27

Ooh, this does look promising! Though admittedly CommonSense still has the advantage of off the shelf parts, even if it is a bit of a pain to configure.

User avatar
SneakyRobb
THINK

07 Feb 2020, 19:36

Wow this looks great!

I personally have always had a very hard time trying to solder together the xwhatsit by hand. I would have really appreciated a through hole hand soldering easy method. So I am happy to see that and look forward to building one!

User avatar
OldIsNew

07 Feb 2020, 20:13

I really like this idea. While commonsense is very cool, I have found it tricky to get rebuilt F&F boards working well with it. The xwhatsit has always worked smoothly for me and a through the hole version would be great!

listofoptions

07 Feb 2020, 20:35

ZedTheMan wrote:
07 Feb 2020, 19:27
Ooh, this does look promising! Though admittedly CommonSense still has the advantage of off the shelf parts, even if it is a bit of a pain to configure.
Id like to make the argument that the CommonSense controller does not use an "off the shelf" part. its a specific part that isnt made to by any other manufacturer, where as with the XWhatsIt design you can swap most of the parts around for other components, no particular reliance on a specific manufacturer with any of them! All the parts used, save the micro and the dac are industry standard (and the controller isn't because the only industrial standard controller is arm or 8051ish like parts; i simply didn't bother finding a more standardized dac), and not proprietary, or reliant on custom compilers with spotty-at-best support. I commend DMA on his work! id have given up a LONG time ago if i couldnt use GCC!

listofoptions

07 Feb 2020, 20:40

I will work on getting BOM CSV's spun up for digikey, mouser, arrow, and farnell later this week too

orihalcon

08 Feb 2020, 02:35

Very interesting indeed! How many rows and how many columns are supported? Would be pretty cool if you could go beyond the 24x4 and 16x8 of the existing beamsprings/model F's so they could be adapted to other custom projects potentially? Wondering if there could be optional components to install for expanded number of rows/columns so that not everyone needs to install if the project doesn't require expansion.

kmnov2017

08 Feb 2020, 10:26

There are 24 pins for columns and 8 sense positions for rows on the PCB. So it's truly universal for all Beamsprings and Model Fs out there. Support for additional rows/columns will need a change to the PCB, but can be done.

gravesdesk

09 Feb 2020, 21:37

Adding a solenoid driver (adjustable for different solenoid voltages and currents), not only an expansion header, would be extremely good.

kmnov2017

09 Feb 2020, 22:53

gravesdesk wrote:
09 Feb 2020, 21:37
Adding a solenoid driver (adjustable for different solenoid voltages and currents), not only an expansion header, would be extremely good.
A relay costs less than 1 eur and a DC DC Boost converter also costs about the same. So for just 2 euros in additional components you can drive a solenoid. If you buy a 5v solenoid, then you dont even need a boost converter - all you need is a 1 euro relay.

User avatar
OldIsNew

09 Feb 2020, 23:57

kmnov2017 wrote:
09 Feb 2020, 22:53
A relay costs less than 1 eur and a DC DC Boost converter also costs about the same. So for just 2 euros in additional components you can drive a solenoid. If you buy a 5v solenoid, then you dont even need a boost converter - all you need is a 1 euro relay.
Yes it's pretty straight forward with a 5v solenoid - it just takes a simple circuit with one transistor, a diode and a resistor. Here's a pic of quick and dirty one i used for my Fluke 1720A board:
solenoid.jpg
solenoid.jpg (172.54 KiB) Viewed 14849 times

gravesdesk

10 Feb 2020, 13:58

Nice, would you provide a guide for building a solenoid driver and installing it to Model F XT, running by a pro micro soarer's converter and a New Model F77 (by Ellipse) running by an xwhatsit controller?

(I am not an electronics guru (a medical doctor actually) and I am having some help for soldering from the guys in medical device repair dept.)

Thanks.

zzxx53

12 Feb 2020, 00:25

gravesdesk wrote:
10 Feb 2020, 13:58
Nice, would you provide a guide for building a solenoid driver and installing it to Model F XT, running by a pro micro soarer's converter and a New Model F77 (by Ellipse) running by an xwhatsit controller?

(I am not an electronics guru (a medical doctor actually) and I am having some help for soldering from the guys in medical device repair dept.)

Thanks.
Check out viewtopic.php?p=455535#p455535

User avatar
DMA

15 Feb 2020, 18:59

listofoptions wrote:
07 Feb 2020, 20:35
Id like to make the argument that the CommonSense controller does not use an "off the shelf" part. its a specific part that isnt made to by any other manufacturer, where as with the XWhatsIt design you can swap most of the parts around for other components, no particular reliance on a specific manufacturer with any of them!
You say that as if there is a wide choice of vendors for atmegas. Surprise - atmel is a single supplier. And it's bought by microchip, so that supply can dry up anytime.
listofoptions wrote:
07 Feb 2020, 20:35
id have given up a LONG time ago if i couldnt use GCC!
Are you kidding? The only ARM official toolchain is GCC.

listofoptions

23 Feb 2020, 21:04

DMA wrote:
15 Feb 2020, 18:59
listofoptions wrote:
07 Feb 2020, 20:35
Id like to make the argument that the CommonSense controller does not use an "off the shelf" part. its a specific part that isnt made to by any other manufacturer, where as with the XWhatsIt design you can swap most of the parts around for other components, no particular reliance on a specific manufacturer with any of them!
You say that as if there is a wide choice of vendors for atmegas. Surprise - atmel is a single supplier. And it's bought by microchip, so that supply can dry up anytime.
listofoptions wrote:
07 Feb 2020, 20:35
id have given up a LONG time ago if i couldnt use GCC!
Are you kidding? The only ARM official toolchain is GCC.
on the note of atmega being single sourced: duh, but my point was that its possible to swap out the microcontroller for another, only making some modifications to the firmware.
and on the note of ARM, I wouldnt mind using ARM devices either, granted the core in your design is ARM, but last i checked its not compilable on linux correct? and requires custom vendor specific libraries? im too much of a FOSS / OSH person to go that route!

User avatar
DMA

24 Feb 2020, 00:40

listofoptions wrote:
23 Feb 2020, 21:04
on the note of atmega being single sourced: duh, but my point was that its possible to swap out the microcontroller for another, only making some modifications to the firmware.
Oh, _that_. No difference there either. All the FPGA stuff can be pulled out and implemented using discrete logic and driven by effing i8051 - but you won't like the resulting BOM's cost.
You don't even need to install virtualbox to capture schematics - 2 screenshots is all you need and both of them are in that other topic :D

But have you ever tried to port things between MCUs tho? Like, bare metal, no OS?
I did and I can tell you that you'll be better porting the idea, not actual code.

Gory details:
Spoiler:
One example - USB. It will be COMPLETELY different. You can reuse descriptors, but descriptors are The Easy Part. Suspend/resume is where you'll spend your months of debugging. I mean after you'll figure out how to async-send data and not crash firmware. :)
And that's if you don't go the clowny way of having a separate "NKRO USB descriptor". That decision alone will make your life a compatibility nightmare, which you'll need to solve for every new firmware platform, separately.

In fact, if you have a decent 200+ksps onboard ADC, can program 24-input analog mux on-chip and can reasonably quickly switch GPIOs from hi-Z to analog in to digital out - you'll only need bunch of 5k6 resistors worst case.

You can even transpose the board if you're short on analog pins - drive columns, sense rows. That would make for slower scans, but in reality NOBODY cares about latency.
xwhatsit only can into ~10k cycles/second (that's 435 scans per second for 23 columns, 625 for 16 columns) - and nobody cares even at debounce 11 (which essentially brings scan rate of the model F to ~55Hz - which is ~18 milliseconds of latency).

In fact I suspect teensy 3.6 can do all that - but it costs 200% more, what's the point? (And yes, I tried 3.2, and it just can't. Kinetis' ADC is IN CRE DI BLY shitty.)

Reproducing {DAC+comparator with per-row thresholds} scanner for capacitive sensing in 2020 is cruel and unusual - look no further than Ellipse's main thread. "Make sure you warmed up your keyboard for 24 hours before you use it", "flash debounce 11 firmware" (wth, it's 2020, this should be controllable from host utility - but that's a different topic) etc etc.

I had to go that way for inductive sensing and even tho I have per-cell thresholds AND the field in, y'know, "non-replica" keyboards is pretty level - it's still pain to set up because you don't have any idea about thresholds and have to "manually scan", and then fine-tune one or two keys couple days later. Good scope helps - but one needs to have it AND know how to use it.

It was so bad I made firmware tell the utility which keys were stuck pressed on startup - "why the scanner had to be shot", in other words. It helps, but ADC-based setup is MUCH easier to tune, even after this upgrade.
listofoptions wrote:
23 Feb 2020, 21:04
and on the note of ARM, I wouldnt mind using ARM devices either, granted the core in your design is ARM, but last i checked its not compilable on linux correct? and requires custom vendor specific libraries? im too much of a FOSS / OSH person to go that route!
GUI(PSoC Creator) is written in highly-abused .net, so that's windows-only. Once code generation is complete - it's just C code, compiled with standard ARM toolchain. GUI can even create a makefile for that.

But that doesn't matter in reality. "IE testing" windows images are free, virtualbox is free. Once you start getting commercial you'll pretty soon find out that lots of things are NOT free even if "open source", or encumbered by licenses nullifying your sales a month after you initially ship - but commercial stuff is a different world.

Don't get me started on OSH. It's not open. Schematic and PCB (in a godawful kicad, usually) is FAR from enough.

listofoptions

24 Feb 2020, 06:50

DMA wrote:
24 Feb 2020, 00:40
listofoptions wrote:
23 Feb 2020, 21:04
on the note of atmega being single sourced: duh, but my point was that its possible to swap out the microcontroller for another, only making some modifications to the firmware.
Oh, _that_. No difference there either. All the FPGA stuff can be pulled out and implemented using discrete logic and driven by effing i8051 - but you won't like the resulting BOM's cost.
You don't even need to install virtualbox to capture schematics - 2 screenshots is all you need and both of them are in that other topic :D
BOM cost is definitely not an issue here :D
DMA wrote:
24 Feb 2020, 00:40
But have you ever tried to port things between MCUs tho? Like, bare metal, no OS?
I did and I can tell you that you'll be better porting the idea, not actual code.
yes, porting between 6502 and z80 is gory (exempli gratia), but thats what decently written code in C is for :lol: (granted C in either of those is not fun :D) but yes *directly* porting code between micros generally means BAD TIME (tm) porting a serial comm protocol? over a well documented bus? I dont think it's that hard, but then again I'm a glutton for punishment (the first port is always the hardest)
DMA wrote:
24 Feb 2020, 00:40
Gory details:
Spoiler:
One example - USB. It will be COMPLETELY different. You can reuse descriptors, but descriptors are The Easy Part. Suspend/resume is where you'll spend your months of debugging. I mean after you'll figure out how to async-send data and not crash firmware. :)
And that's if you don't go the clowny way of having a separate "NKRO USB descriptor". That decision alone will make your life a compatibility nightmare, which you'll need to solve for every new firmware platform, separately.

In fact, if you have a decent 200+ksps onboard ADC, can program 24-input analog mux on-chip and can reasonably quickly switch GPIOs from hi-Z to analog in to digital out - you'll only need bunch of 5k6 resistors worst case.

You can even transpose the board if you're short on analog pins - drive columns, sense rows. That would make for slower scans, but in reality NOBODY cares about latency.
xwhatsit only can into ~10k cycles/second (that's 435 scans per second for 23 columns, 625 for 16 columns) - and nobody cares even at debounce 11 (which essentially brings scan rate of the model F to ~55Hz - which is ~18 milliseconds of latency).

In fact I suspect teensy 3.6 can do all that - but it costs 200% more, what's the point? (And yes, I tried 3.2, and it just can't. Kinetis' ADC is IN CRE DI BLY shitty.)

Reproducing {DAC+comparator with per-row thresholds} scanner for capacitive sensing in 2020 is cruel and unusual - look no further than Ellipse's main thread. "Make sure you warmed up your keyboard for 24 hours before you use it", "flash debounce 11 firmware" (wth, it's 2020, this should be controllable from host utility - but that's a different topic) etc etc.

I had to go that way for inductive sensing and even tho I have per-cell thresholds AND the field in, y'know, "non-replica" keyboards is pretty level - it's still pain to set up because you don't have any idea about thresholds and have to "manually scan", and then fine-tune one or two keys couple days later. Good scope helps - but one needs to have it AND know how to use it.

It was so bad I made firmware tell the utility which keys were stuck pressed on startup - "why the scanner had to be shot", in other words. It helps, but ADC-based setup is MUCH easier to tune, even after this upgrade.
there's a thousand and one ways to do capacitive/inductive sense. you've already made a well documented example of one method. I've been poking about IBMs own design which uses (afaict) a current sense (or at least an inherently high CMRR) amp, a 3bit latched dac, and a comparator (making an ADC), and a latched MUX (See http://halicery.com/Hardware/Intel%2080 ... blies.html and particularly http://halicery.com/Hardware/Intel%2080 ... NTERN.TEXT). myself ive had no issues with the xwhatsit, seems to be reliable enough. adding some per cell sensitivity shouldn't be that hard, and would definitely aid in reliability, as you have proven already. the fact that the original IBM hardware is pretty simple and reliable is telling enough for me.
DMA wrote:
24 Feb 2020, 00:40
listofoptions wrote:
23 Feb 2020, 21:04
and on the note of ARM, I wouldnt mind using ARM devices either, granted the core in your design is ARM, but last i checked its not compilable on linux correct? and requires custom vendor specific libraries? im too much of a FOSS / OSH person to go that route!
GUI(PSoC Creator) is written in highly-abused .net, so that's windows-only. Once code generation is complete - it's just C code, compiled with standard ARM toolchain. GUI can even create a makefile for that.
:D when is dotNet never highly abused ?
DMA wrote:
24 Feb 2020, 00:40
But that doesn't matter in reality. "IE testing" windows images are free, virtualbox is free. Once you start getting commercial you'll pretty soon find out that lots of things are NOT free even if "open source", or encumbered by licenses nullifying your sales a month after you initially ship - but commercial stuff is a different world.
no problem here, this is a community project. I dont care about making money; if I did it wouldn't be a hobby. so theres no reason to go towards commercialization. that being said I'm not really sure what you're trying to say about things not being "free" even if "open source", yes there are dual licensed software (free for community, but $$$ for commercial), but those are rather obvious to avoid. are you talking about code being forcibly opened under GPL?
DMA wrote:
24 Feb 2020, 00:40
Don't get me started on OSH. It's not open. Schematic and PCB (in a godawful kicad, usually) is FAR from enough.
kicad is still better than diptrace or FRAGGIN eagle. altium? well no mr moneybags its not, but at that price point literally nothing is good enough :D

I understand there is a point where its impossible to be truly "open". that mostly stops at or around silicon synth (gdsii/oasis gen and IC layout). id still prefer to use a format that the rest of the community can consume without needing virtualization. I'm not trying to imply the commercial format is worse, its just not what i would use; as its not something that the community can consume without vendor support at every turn.

that said, I'm not sure what you mean by "its not open" though; most of the time it just has to be "open enough". yeah you don't know the *actual* transistors placed to make an LM339A, but you know the equivalent circuit, which is enough to make a decently accurate model of operation with SPICE to verify against hardware.

User avatar
shine

25 Feb 2020, 10:56

I'm In! For a 3276 beamspring

pandrew

31 Mar 2020, 13:16

I'm working on porting QMK to xwhatsit boards. If there's a keyboard assembled with this board, and you'd like to help me by running some test code on it, please PM me. Also, is there anyone around here who would like to help me by testing my code on a Beamspring rev.3 or rev.4 original xwhatsit board?

kmnov2017

18 May 2020, 15:07

pandrew wrote:
31 Mar 2020, 13:16
I'm working on porting QMK to xwhatsit boards. If there's a keyboard assembled with this board, and you'd like to help me by running some test code on it, please PM me. Also, is there anyone around here who would like to help me by testing my code on a Beamspring rev.3 or rev.4 original xwhatsit board?
I've PMed you....

kmnov2017

18 May 2020, 23:55

Just a quick heads up, this is definitely not dead and WILL be coming back at some point in time, hopefully very soon....

User avatar
tentator

03 Jun 2020, 22:33

kmnov2017 wrote:
07 Feb 2020, 19:17
Pending Activities
1. Physical hardware testing
2. Firmware - needs modification to run on promicro
3. Firmware testing
listofoptions wrote:
07 Feb 2020, 19:21
contributions, and suggestions welcome! board is likely to go through *multiple* revisions, but thankfully its fairly modular. https://github.com/listofoptions/TH-XWhatsIt
Hi All!
wanted to contribute here to this project since I think it's a great idea especially in conjunction with the porting of QMK to xwhatsit by pandrei.
Actually I would consider it the best and easiest candidate for everyone to approach the idea: TTH PCB and QMK firmware.

Here you can see the PCBs that I ordered from JLCPCB (arrived lightning fast):
photo5958304273592857133.jpg
photo5958304273592857133.jpg (296.77 KiB) Viewed 13295 times
photo5958304273592857134.jpg
photo5958304273592857134.jpg (271.45 KiB) Viewed 13295 times
So far my comments about the "1. Physical hardware testing" are:
- The place for resistors is too narrow, it's barely good for SMD resistors IMHO, even when using small sized resistors and putting them "upright"; this will cause most probably that the components will touch the riser plugboard. I'd plan more space for the resistors, this will be also easier for newbie solderers.. :)
- The "ROWS" pins are moved above the 100K resistors, I would have kept them like in the PCB picture in the first post.
- Also the 10uF capacitor is most likely too tall to be compatible with the plugboard, I would program space for it to be installable as "lied down".
- The 100nF capacitor located between the two LM339 is too squeezed, needs a few mm more clearance.

So currently I'm considering to install the plugboard on the backside instead for the above reasons.

But I also have a couple of questions:
- What is the reason to chose the MCP4921 DAC instead of the original 101xxx DAC that is used in xwhatsit? I think this one is more expensive and would need to imlpement a new/different protocol in the xwhatsit FW to cope with the change, but maybe there's a good reason?
- Similar question about the usage of different pins on the pro-micro if compared to the xwhatsit, but this is less of an issue to change/adapt in the xwhatsit FW of course
- I was also thinking about the 10 and 100 K resistor networks in SIP-5 format: what is the advantage a part from space? I think just using normal resistors for this is maybe easier for people to source components. Yes I had rather difficulties to source SIP-5 networks as you can see here:
Spoiler:
photo5960556073406542173.jpg
photo5960556073406542173.jpg (162.6 KiB) Viewed 13295 times
- Is there a reason the traces are so thin?
- I still have to test the BS connector pad holes if they are compatible with the connector and see if diameter is ok and if the vias connect layer 1 to layer 2 for rows and cols

Other than this I updated the BOM and GERBERS on GIT for @listofoptions to check then others can also have a run in case.

That's all my comments and questions so far, for the rest I will proceed now with soldering and with working with pandrei to adapt QMK and start the FW testing then. Will report back when ready.

Kr,
tent:wq

kmnov2017

03 Jun 2020, 23:33

A few answers:

-the original xwhatsit DAC is an SMD package and we had to find a cheap through hole component
-pro micro uses a different chip than xwhatsit. The pins are different.
-when the initial components were drawn up we checked mouser, digikey and Farnell. They had all the components.
- regarding the spacing, we can fix that in the next design update. For now ignore the plug boards and use jump cables to connect to an edge connector (if you intend to use on a beamspring)

gipetto

04 Jun 2020, 18:19

I didn't see this project mentioned but since it uses capacitive switches and qmk i thought it would be relevant. I'm not sure what the chips are in the photo to use the project as a base.
https://github.com/ginjake/qmk_firmware ... s/ec_helix

User avatar
tentator

04 Jun 2020, 19:17

gipetto wrote:
04 Jun 2020, 18:19
I didn't see this project mentioned but since it uses capacitive switches and qmk i thought it would be relevant. I'm not sure what the chips are in the photo to use the project as a base.
https://github.com/ginjake/qmk_firmware ... s/ec_helix
Ciao Gipetto,
are you sure those switches are capacitive?? I mean from the picture I see normal hotswap sockets and rgb leds..
there is definitely no capacitive sensing in that pcb unless it's inside the single switch but that would be quite sick, right?
but I might get it wrong since my Japanese level is quite low.. :)

tent:wq

gipetto

04 Jun 2020, 19:25

I guess i should have linked the reddit thread. ginjake mentioned he was using varmillo capacitive switches. If you inspect the pcb you'll see there's no switch diodes anywhere. https://www.reddit.com/r/MechanicalKeyb ... _keyboard/

kmnov2017

04 Jun 2020, 20:04

gipetto wrote:
04 Jun 2020, 19:25
I guess i should have linked the reddit thread. ginjake mentioned he was using varmillo capacitive switches. If you inspect the pcb you'll see there's no switch diodes anywhere. https://www.reddit.com/r/MechanicalKeyb ... _keyboard/
There's nothing with capacitive sensing in there.

gipetto

04 Jun 2020, 20:43

varmillo converted the mx switch to capacitive by insulating one plate. internal pics here https://geekhack.org/index.php?topic=94239.0

User avatar
tentator

04 Jun 2020, 21:10

That's a funny switch then in there.. Not sure why they did this but theoretically I think it could work as well, as probably even topre could possibly work with pandrei 's capacitive algorithm.. Calibration seems the real tricky thing in this game and most likely the atmega32u2 or u4 have not enough ram and also the dac might be to slow to cope in case of big boards / big differences between capacitance of keys not to speak about interference.. But hey, that means we still have plenty of things to experiment with.. Also considering that nowadays there are nice and cheap SoC boards around with plenty of power and memory..

It would be interesting to ask @hasu if he knows what capacitance delta is measured on those tiny ec switches...

Tent:wq

Post Reply

Return to “Workshop”