READY - $10 - DIY Through Hole Universal Model F and Beamspring Controller
-
- Location: Germany
- Main keyboard: Model F77
- Main mouse: Logitech MX Master 3S
- Favorite switch: Alpaca V2
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.
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)
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)
Last edited by kmnov2017 on 02 Nov 2020, 22:51, edited 17 times in total.
-
- Location: united states
- Main keyboard: anything in my collection
- Main mouse: none
- Favorite switch: capacitive buckling spring
- DT Pro Member: 0215
contributions, and suggestions welcome! board is likely to go through *multiple* revisions, but thankfully its fairly modular. https://github.com/listofoptions/TH-XWhatsIt
- ZedTheMan
- Location: Central US
- Main keyboard: IModel F77/IBM 3101/Omnikey 102/96Kee
- Main mouse: Logitech G430/Logitech M570/Kensington Expert
- Favorite switch: Beamsprings. Alps SKCM Blue, Capacitive Buckling S
- DT Pro Member: 0219
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.
- SneakyRobb
- THINK
- Location: Canada
- Main keyboard: KB-5161A, F122, Dc2014, Typeheaven, Beamspring FXT
- Main mouse: MX518 Legendary
- DT Pro Member: 0242
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!
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!
-
- Location: united states
- Main keyboard: anything in my collection
- Main mouse: none
- Favorite switch: capacitive buckling spring
- DT Pro Member: 0215
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!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.
-
- Location: united states
- Main keyboard: anything in my collection
- Main mouse: none
- Favorite switch: capacitive buckling spring
- DT Pro Member: 0215
I will work on getting BOM CSV's spun up for digikey, mouser, arrow, and farnell later this week too
-
- Location: Des Moines / Cedar Falls, IA, USA
- Main keyboard: IBM Model F107
- DT Pro Member: 0190
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.
-
- Location: Germany
- Main keyboard: Model F77
- Main mouse: Logitech MX Master 3S
- Favorite switch: Alpaca V2
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.
-
- Location: Turkey
- DT Pro Member: -
Adding a solenoid driver (adjustable for different solenoid voltages and currents), not only an expansion header, would be extremely good.
-
- Location: Germany
- Main keyboard: Model F77
- Main mouse: Logitech MX Master 3S
- Favorite switch: Alpaca V2
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.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.
- OldIsNew
- Location: US
- DT Pro Member: 0248
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: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.
-
- Location: Turkey
- DT Pro Member: -
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.
(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.
-
- Location: US
- Main keyboard: Model F AT
- Main mouse: Roller Mouse
- Favorite switch: Capacitive Buckling Spring
Check out viewtopic.php?p=455535#p455535gravesdesk 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.
- DMA
- Location: Seattle, US
- Main keyboard: T420
- Main mouse: Trackpoint
- Favorite switch: beamspring
- DT Pro Member: NaN
- Contact:
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 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!
Are you kidding? The only ARM official toolchain is GCC.
-
- Location: united states
- Main keyboard: anything in my collection
- Main mouse: none
- Favorite switch: capacitive buckling spring
- DT Pro Member: 0215
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.DMA wrote: 15 Feb 2020, 18:59You 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 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!
Are you kidding? The only ARM official toolchain is GCC.
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!
- DMA
- Location: Seattle, US
- Main keyboard: T420
- Main mouse: Trackpoint
- Favorite switch: beamspring
- DT Pro Member: NaN
- Contact:
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.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.
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
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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:
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.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!
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.
-
- Location: united states
- Main keyboard: anything in my collection
- Main mouse: none
- Favorite switch: capacitive buckling spring
- DT Pro Member: 0215
BOM cost is definitely not an issue hereDMA wrote: 24 Feb 2020, 00:40Oh, _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.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.
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![]()
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
yes, porting between 6502 and z80 is gory (exempli gratia), but thats what decently written code in C is forDMA 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.
![Laughing :lol:](./images/smilies/icon_lol.gif)
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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:40GUI(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.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!
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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 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.
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 enoughDMA 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.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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.
- shine
- Location: EU - Spain
- Main keyboard: F122
- Main mouse: Deathadder Elite
- Favorite switch: Beamspring
- Contact:
I'm In! For a 3276 beamspring
-
- Location: Romania
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?
-
- Location: Germany
- Main keyboard: Model F77
- Main mouse: Logitech MX Master 3S
- Favorite switch: Alpaca V2
I've PMed you....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?
- tentator
- Location: ZH, CH
- Main keyboard: MX blue tentboard
- Main mouse: Pointing Stick
- Favorite switch: Cherry MX Blue and Model F BS
- DT Pro Member: -
kmnov2017 wrote: 07 Feb 2020, 19:17 Pending Activities
1. Physical hardware testing
2. Firmware - needs modification to run on promicro
3. Firmware testing
Hi All!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
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): 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..
![Smile :)](./images/smilies/icon_e_smile.gif)
- 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:
- 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
-
- Location: Germany
- Main keyboard: Model F77
- Main mouse: Logitech MX Master 3S
- Favorite switch: Alpaca V2
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)
-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)
-
- Location: republic of ireland
- Main keyboard: ducky zero shine
- Main mouse: zowie fk1+
- Favorite switch: mx blue
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
https://github.com/ginjake/qmk_firmware ... s/ec_helix
- tentator
- Location: ZH, CH
- Main keyboard: MX blue tentboard
- Main mouse: Pointing Stick
- Favorite switch: Cherry MX Blue and Model F BS
- DT Pro Member: -
Ciao Gipetto,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
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..
![Smile :)](./images/smilies/icon_e_smile.gif)
tent:wq
-
- Location: republic of ireland
- Main keyboard: ducky zero shine
- Main mouse: zowie fk1+
- Favorite switch: mx blue
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/
-
- Location: Germany
- Main keyboard: Model F77
- Main mouse: Logitech MX Master 3S
- Favorite switch: Alpaca V2
There's nothing with capacitive sensing in there.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/
-
- Location: republic of ireland
- Main keyboard: ducky zero shine
- Main mouse: zowie fk1+
- Favorite switch: mx blue
varmillo converted the mx switch to capacitive by insulating one plate. internal pics here https://geekhack.org/index.php?topic=94239.0
- tentator
- Location: ZH, CH
- Main keyboard: MX blue tentboard
- Main mouse: Pointing Stick
- Favorite switch: Cherry MX Blue and Model F BS
- DT Pro Member: -
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
It would be interesting to ask @hasu if he knows what capacitance delta is measured on those tiny ec switches...
Tent:wq