A 3D-printed keyboard inspired by the DataHand.

Public Chat
Similar projects worth following

For more information about the keyboard, see the github repo.

The initial version of the lalboard was completed and published in early 2019. But since then, I've been thinking about/planning/designing/working on a significant update to the design.

Up till now, I've mostly just posted about the status of the project occasionally on the geekhack thread. But that's a big thread, with a lot of other discussions happening, so I wanted to have somewhere a bit more focused. I plan on using this page as a central place to post project logs/status updates/etc.

  • Phototransistors, Transimpedance Amplifiers and Response Times, Oh My!

    Ben Gruver04/27/2021 at 05:59 0 comments

    The simplest way to use a phototransistor is to hook it up with the collector connected to a voltage supply, and the emitter connected to ground through a resistor. As more light hits the phototransistor, it conducts more current, and so the voltage across the resistor increases.

    You can adjust the sensitivity of the circuit by adjusting the value of the resistor. Higher values provide higher sensitivity, but at the cost of slower response times.

    For example, here is the key activation waveform for a problematic switch I was investigating, which was using a 1k resistor.

    Channel 2 (blue) is the selector for that that cluster, so a high value essentially enables/energizes the cluster, and a low value disables it. And channel 1 (yellow) shows the output voltage of the phototransistor when the key is in a pressed state, based on the above circuit.

    As you can see, this particular switch is only reaching about 1.5V at its highest value, which is not high enough to register as a logical 1 value. And the rise and fall times are already a bit sluggish, at around 30us.

    Swapping out the resistor for a lower value (470), we get the following:

    The rise and fall times are much improved, but the sensitivity is even lower, and the max voltage doesn't even reach 1V.

    Going the other direction, here is what we get with a 2k resistor:

    This is starting to look promising, with the max voltage reaching over 2V, which is the minimum required to register as a logical 1. However, the rise and fall times are now even worse, taking a full 50us before it starts leveling off.

    I had a bit of trouble with this particular key in the previous design as well. The problem is that the key travel is very short, and the key stem doesn't entirely get out of the way of the light path, so less light is reaching the phototransistor. I solved this in the previous design by boosting the current/brightness of the LED for that switch, but even that wasn't enough to get a fast/high enough signal from the phototransistors in the new design.

    The issue is likely the wider key stems in the new design. This increases the distance between the LED and phototransistor, and so even less light is reaching the phototransistor, and it's just not able to get enough light.

    And this is where the transimpedance amplifier (TIA) comes in. It's a fancy name for a particular arrangement of an opamp, such that it converts a current-based signal (like that from a phototransistor) to a voltage-based signal (like what is needed on a gpio pin). The main benefit in this application is that it has a very low input impedance. And similarly to when we swapped out the resistor in the first circuit for a lower one, a lower input impedance means that the phototransistor is able to respond more quickly. And, critically, the input impedance is independent of the sensitivity/amplification factor.

    In this circuit, the 2k resistor serves a similar purpose as the resistor in the first circuit. A higher resistor value increases the amplication and results in a higher output voltage. But without affecting the rise and fall times of the phototransistor, because the phototransistor still "sees" the opamp's low input impedance.

    And here's the key activation waveform after switching to a TIA.

    One thing to note is that the TIA inverts its output. So instead of a low-to-high transition when a key is pressed, it is now a high-to-low transition. And both the high and low voltage levels are at comfortable logic levels.

    As you can see, the response time is much quicker now, with the voltage leveling out after only ~10uS after the cluster is enabled.

    The above was with a 2k feedback resistor in the TIA circuit. Just for comparison, with a 470 ohm resistor instead, we get:

    The sensitivity is lower as expected, with the low voltage level only being about .5V below the high voltage level. But the response time is largely unaffected.


    Read more »

  • main board sent for fabbing

    Ben Gruver04/26/2021 at 20:13 0 comments

    I've been spending some time designing and prototyping the new main board. There are a number of improvements compared with the v1 board (in addition to just being an actual PCB, rather than the ad-hoc thing using the vinyl cut process).

    At first, I was thinking I would use an esp32s2 dev board, like the saola board, and just have a header socket for it on the main board. But I eventually came to the decision that it would be better to go a bit "lower level" and design a board around the raw esp32s2-wroom module.

    For one thing, the saola dev board is fairly large, and would be hard to fit along with everything else needed in the space under the handrest. But it also uses a serial<->usb converter chip, instead of exposing the actual usb interface. You can still wire up a separate usb port to the gpio 18 and 19 pins, but that's a lot of wasted board space on an unneeded usb connector and serial conversion chip.

    A few of the features/improvements:

    • USB C port (because USB C >>> USB micro)
    • It has a second USB C port for communication between the two halves. Although this isn't a real USB port. The actual communication will be a serial link over the D+ and D- pins. I didn't particularly like using a USB port for non-USB communication, but the best alternative I could come up with was a TRRS jack -- which isn't really hot-pluggable (e.g. shorting pins when you insert/remove a plug). So supporting hot-plugging won out over my concerns about confusion over the 2 different usb-c ports on each half.
    • It uses discrete transistors to select each individual cluster (row) when scanning the matrix. Previously, it used an LED driver chip, but it was a bit of an expensive, specialty chip. Using discrete NPN transistors is cheaper, and they're much more ubiquitous.

    One of the more significant changes is that it now uses transimpedance amplifiers to read the signals from the phototransitors, which you can read more about in my previous post.

    I honestly didn't want to go that route initially, because it adds yet more components and complexity, and required embiggening the board. But I just wasn't happy with the phototransistor response times.

    I do think it was the correct decision though, and it should help ensure more reliable operation of the optical switches, and enable even lower power usage due to lower LED currents and shorter duty cycles. Power usage isn't necessarily a huge concern atm, with a usb-powered device... But since it's using a bluetooth-capable chip, I won't rule out a battery powered bluetooth device in the future :)

  • First PCBs received, and first keypresses registered

    Ben Gruver04/08/2021 at 09:05 2 comments

    I got my order of PCBs for the finger and thumb clusters in from jlcpcb today. Exciting! My first time designing and having a PCB made. I'm super happy with the result. Surprisingly, everything seems fine with them so far.

    I got one soldered up and attached to a cluster, and was able to send my first key presses with it, with the current in-progress QMK firmware.

  • First QMK keypress on esp32s2

    Ben Gruver04/01/2021 at 06:58 0 comments

    I finally managed to hook everything up so that qmk, tinyusb and esp-idf all play nicely together, and managed to get that first glorious "a" key press, from the on-board button on the saola board.

    There's still a lot of functionality that doesn't work yet, but I'm super happy that all the USB stuff is working well enough that it's able to enumerate and actually send an HID report on a button press.

  • Initial testing of new cluster design

    Ben Gruver03/28/2021 at 10:38 0 comments

    I finally got in some parts I had been waiting for from digikey, and was able to throw together a little hand-wired prototype using the new cluster design. I was able to verify there's no light leakage problems between the different keys, and all keys were causing a high enough voltage swing on the phototransistor to trigger a high logic level.

    I also realized I had been carrying over the assumption from the previous design that everything would be driven at 5V. But the ESP32's input pins aren't 5V tolerant, so I'll need to switch everything to 3.3V. So I swapped out the LED resistors for a lower value to maintain the same current, and verified again that there's enough of a voltage swing at 3.3V for all the keys.

    Incidentally, all those 22g solid copper wires don't make a half-bad mount for the cluster. It's not quite stiff enough, but maybe if the wires were shorter or a bigger gauge. That might be an idea to explore in the future, for a different type of adjustable mount.

  • Investigating QMK on the esp32

    Ben Gruver03/24/2021 at 07:29 3 comments

    QMK seems to be a popular open source keyboard firmware. I've read through their docs a bit, and I think it should mostly support everything that is needed for the lalboard. Namely split keyboards and a robust key mapping mechanism that should be able to support the various mode keys/modes that the lalboard needs.

    The only problem is that it doesn't support esp32. I guess I *could* switch to a compatible board/MCU, but a brief search doesn't show anything readily available that is as featureful, available, and cheap as esp32. And there seems to be at least some demand out there for running qmk on an esp32, so I thought I would poke at it bit.

    After much gnashing of teeth (and keys), I managed to get a very very hacky proof of concept that compiles and links. This involves

    • adding a new esp32 platform to qmk (currently mostly just stubbed out)
    • tweaking qmk's build system to build a static library, instead of a full firmware image
    • creating a new esp-idf project, that calls into qmk to perform the various processing tasks needed in the main loop. (i.e. something similar to the main loop for the LUFA protocol)
    • manually copying that qmk static library to the esp-idf project, and ensuring it gets linked

    This is far from an actually functional proof-of-concept, but I think I'm convinced it's at least within the realm of possibility now. I think the next steps will be to more fully implement and integrate the new esp32 functionality in qmk, and ideally figure out some way to link the two builds, to avoid having to build in multiple places and copy stuff around between them.

    I doubt something like this would be accepted by the qmk maintainers, since it's essentially using bailing wire and duct tape to smoosh 2 different build systems together. But hopefully it can at least serve as a template for others who want to use qmk on an esp32.

  • Thumb clusters/pcbs mostly done

    Ben Gruver03/22/2021 at 19:58 0 comments

    I think I've pretty much finished updating the thumb clusters. I added an .stl and .f3d assembly export for both thumbs, along with an online viewer thingy (links: left, right). And the kicad designs for the PCBs have been updated.

    Right thumb cluster

    I'm currently waiting on a digikey order for the optical components, to be able to verify the optical performance of the finger and thumb clusters. That order also has some Saola ESP32-S2 boards that I want to play around with, and see if it might be feasible to port the QMK firmware to.

    I'm holding off on starting work on the central PCB for now, since that will depend a fair bit on what dev board I end up going with to drive it.

  • cluster assembly now viewable online

    Ben Gruver03/18/2021 at 05:37 0 comments

    I finally got around to creating a full assembly for a single finger cluster, with all

    the various parts in their correct places. The "stls" folder in the github repo should now contain an .stl and an .f3d (fusion archive) for the cluster_assembly part.

    I also threw it up on the fusion cloud, where I think it can be viewed by anyone, without logging in. You can check it out here.

  • Center key improvements

    Ben Gruver03/16/2021 at 20:48 0 comments

    I stumbled upon a minor, but nice improvement to the center key mechanism of the finger clusters. The current design is a square peg in a square hole, with a small amount of clearance all around. 

    This is fine-ish, but the key post always needed a little bit of clean-up after printing so it can slide in the corresponding hole without binding. There's usually a bit of unevenness around the corners, and especially where the seam is, which can cause the key to rub and bind.

    While working on switching over to an actual fabbed pcb, I had rounded the corners of the key post, so the corners wouldn't hit the radiused corners in the milled hole of the pcb.

    After I printed some test pieces, I realized that this had an unexpected side-benefit - there's extra clearance between the rounded corner of the post and the still-square corner of the hole. And if the slicer places the seam on the rounded corner, the little "bump" from the seam no longer causes any issues, since there's extra clearance there in the corner. So the center key was able to move nicely in the cluster in an "as-printed" state, without having to add extra clearance (which would also increase undesirable lateral key wobble)

  • clusters v2

    Ben Gruver03/14/2021 at 09:47 0 comments

    I think I'm close to being done tweaking the design of the main clusters. 

    There are some significant changes from the original version

    • The photodiodes and LEDs are inserted from the bottom now, so that the PCB can be inserted and removed without having to desolder everything
    • The cluster is printed upside down now, and the top surface of the cluster is flush with the top of the key wells, instead of having a thin, flat plate on the bottom of the cluster that the key wells rise up from.
    • The keys are wider, to hopefully make them less prone to breakage
    • It uses the IR908 LED instead of the IR928 LED, which is a bit thinner, and is the same shape as the PT908 photodiode that is used.
    • The adjustable mounting system is now based on using 1/8" x 1/8" x 1/16"  rectangular magnets on the bottom of the cluster, and having the adjustable screw mounts use a 5mm spherical magnet.
      • This gives a fairly firm attachment, while still allowing the angle between the cluster and vertical supports to vary, as the support heights are changed.
      • This also has the advantage that the cluster can be picked up and removed from the supports, while keeping the supports in place, so that the cluster can be placed back down at the same location.
    • The bases that the screw supports screw into are now multi-part, and have 2 pairs of 1/8" x 1/8" x 1/16" magnets for more holding power.
      • The magnets are on a separate part that slides down securely over the central "pillar", so that the central pillar can be swapped out (e.g. to adjust the height), while re-using the same magnets.
      • If more friction is needed, to avoid the bases from sliding around laterally, I found that you could rub a bit of beeswax on the bottom magnets. The beeswax provides some slight adhesiveness, while still allowing the supports to be repositioned.
    • The screw supports and the bases they screw into now have a very loose fit, that can be easily turned by hand, but with an additional nut that can be tightened down to keep the screw from wiggling or accidentally rotating and changing height.
    • The front attachment of the cluster is now a separate part. This allows the attachment point to be higher up, which allows the front of cluster itself to be closer to the base plate. 
      • This is useful especially for the pinky clusters, which are usually the lowest clusters, and typically don't have much room for the screw supports underneath, especially on the front.
      • This also allows that front support part to be removed when switching to a static base down the line, which should be able to hold the cluster with just the 2 back magnets.

    I also have a PCB design in the works in kicad, although it needs to be updated a bit with some recent design changes I've made to the cluster.

    I think the next steps for now are:   (sorry, another list :p)

    • Get some of the new IR908 LEDs, and breadboard up a proof-of-concept of the electronics, to verify that there are no light-leakage issues with the new design.
      • e.g. make sure that the IR light from one key doesn't trigger the photodiode of a different key.
      • There were some changes to the north key's optical component placement in particular that might be problematic. I don't think it will be, but I need to verify that
    • Get a saola board to play around with. It doesn't support USB HID out of the box (it still uses a USB<->TTY converter.. WHYYYYYY??), but from what I've read, I think you can just connect a usb micro/C connector up to pins 19 and 20 and get real usb connectivity.
    • Update the kicad design for the cluster PCB
      • I'd like to finish up and finalize the thumb and central PCBs before I send it off to be fabbed, so I can just have them all fabbed at once.
    • Apply some of the recent tweaks I've made to the finger cluster to the thumb clusters, and get those finalized

View all 11 project logs

Enjoy this project?



rafael wrote 04/20/2021 at 15:27 point

Thanks for all this work, Ben!

Do you think it's possible to get an analog (analogic?) reading from these sensors? So that the key could be used as a mouse and have sensitivity to moving the cursor slow (move the stick a bit) and fast ("bottom out").

  Are you sure? yes | no

Ben Gruver wrote 04/29/2021 at 06:30 point

Sorry for the delay! hackaday didn't notify me of your comment for some reason. (Or maybe I just missed the email..). In any case, technically yes, it is possible to get an analog value if you carefully move the key back from the at-rest position. But I don't think it's actually practical, at least with the current key design.

The keys are held in the unpressed position by magnets. And the force characteristics are such that the highest force is required right as you start to press the key, when the magnets are closest together. And then the force quickly drops off as the magnets move away from each other.

So in practice, once you've pressed the key hard enough to get the magnet to release, then it's downhill from there, and the key goes all the way back to the backstop.

  Are you sure? yes | no

Mike Szczys wrote 03/29/2021 at 15:34 point

The adjustable mounting system is really brilliant, especially since you can swap out the threaded posts for fixed height when dialed in. Nice!

  Are you sure? yes | no

Ben Gruver wrote 03/29/2021 at 18:31 point

Thanks! I actually just realized something - since the clusters can be removed from the supports in the new design without disturbing the supports, you should be able to directly measure the height of each of them, which will give you the height and angle of the cluster. This should hopefully help in the transition from adjustable to static mounts.

One of the difficulties I had when switching to a static mount was getting the exact positions of the static mounts to match the adjustable setup. I think I ended up printing 7-8 static bases before I was finally happy with it.

For the new design, I think some combination of direct height measurement, indirect measurements from photos and/or full on photogrammetry (possibly using fiducial markers) should make the process smoother.

  Are you sure? yes | no

Rutger van Anrooij wrote 03/16/2021 at 15:53 point

PCB looks good, I made some improvements and changes. Such as adding ground and +5V planes. I also changed the resistors to 0603, to get some more room with the thumb cluster.  You can view the changes at  my fork Do you also plan to place the resistors at the bottom of the PCB for the thumb clusters?

  Are you sure? yes | no

Ben Gruver wrote 03/16/2021 at 18:35 point

Just to be clear, only the finger cluster PCB is anything like being done. The thumb cluster itself still needs a good once-over, so the geometry may still change, and the PCB design needs to be redone (e.g. putting the resistors and connector on bottom, like you mentioned.)

Looking at your reversible thumb cluster design, I'm not sure the added complexity of the board justifies the "simplicity" of having a single thumb pcb. e.g. I imagine it would be significantly easier for someone to screw up while hand soldering, due to misunderstanding which components need to be placed for which side, or due to the much smaller resistors, etc.

  Are you sure? yes | no

Ben Gruver wrote 03/17/2021 at 05:25 point

Thanks for sharing your improvements for the finger cluster :) I was able to learn a thing or two, and updated the design. It's still using the larger resistors, but it has the copper fills and some thicker traces. And with the +5v pin on pin 1 of the connector, where God intended it! :D

  Are you sure? yes | no

Rutger van Anrooij wrote 03/15/2021 at 09:10 point

Very nice project, I am interested in creating one. For the microcontroller and firmware,  QMK ( firmware is easy to implement and hack on. It has all required features for making the keyboard. For the boards Pro micro(Atmel chips)  or Blue pill(STM32) boards are very cheap, run QMK very well and have HID support. I prefer bare STM32 chips on a PCB so I can have an on-board USB-C connector on the PCB, but this is less beginner friendly.  I think Teensy is also supported, but indeed a bit too expensive. Could you share a first version of the Kicad PCB design? 

  Are you sure? yes | no

Ben Gruver wrote 03/15/2021 at 09:40 point

Cool, I'll have to check it out. Although I suspect just about any existing firmware will need a decent amount of work to get it working for the lalboard. It has some special considerations in terms of the low level key scanning logic, and also some unique key mapping requirements, with the various modes, etc. But still, starting from a solid base may be better than starting from scratch. :)

Sure, I've been meaning to push what I had at some point anyway. I pushed it to a new v2 branch on the github repo ( I made some updates to the kicad design earlier this evening, but it's still not totally up to date with the cluster.

  Are you sure? yes | no

Ben Gruver wrote 03/16/2021 at 10:24 point

I've just uploaded the updated design for the finger cluster pcb, if you want to take a look. This is my first time designing a PCB, so go easy on me! :D.

  Are you sure? yes | no

Rutger van Anrooij wrote 03/16/2021 at 11:27 point

Sure,  I will have a look at the finger cluster sometime today. I started redesigning the thumb cluster so it can be flipped so only one version is needed for left and right. Also have some questions about the PCB. How much space is there for components? I have only added extra resistors, but maybe I will add a transistor to replace the led drivers.  Looking in the matrix readout it should be possible looking at, they columns could be to toggle the IR leds and the rows to read out the photodiode. What where the specific requirements for the key scanning? 

  Are you sure? yes | no

Ben Gruver wrote 03/17/2021 at 02:45 point

Yeah, swapping out to transistors probably makes sense. I mostly just used the LED driver in the current design for simplicity. But it is an expensive component (~$2 iirc), and obviously not nearly as ubiquitous a discrete transistor.

There's not much space on the boards for adding extra through-hole components. The front of the PCB (with the LEDs/PTs) sits flush against the bottom of the cluster, so there's not really any space for through-hole leads poking through on the front. It's not out of the question -- a hole could be added to the bottom of the cluster to accommodate the leads sticking through, but I would tend to prefer to stick with through-hole parts on the central pcb. Or maybe largish SMD parts on the back of the cluster PCBs (something that's still relatively easy to hand-solder, even for a novice).

I think the main thing for scanning is around timing, it takes some amount of time for the phototransistor output to rise, so there has to be a delay between switching to a new column, and then reading the rows. And also just reducing the amount of time a column is selected, to lower the LED duty cycle and reduce power draw. The LEDs on both sides draw around 350mA when a column is selected.

So the read loop should be something like

- select next column

- wait long enough for phototransistor outputs to rise

- read rows

- deselect column

- wait as long as necessary to hit the target key responsiveness

I think the current firmware waits 10us after selecting the column, and 1000us total between each column read, so the duty cycle is fairly small (1-2%)

There's also the whole thing where each side has its own independent controller, and the secondary needs to send over its key events to the primary. But maybe something like that is already supported in qmk, for split key keyboards? I dunno how those are usually implemented.

  Are you sure? yes | no

Ben Gruver wrote 03/17/2021 at 06:10 point

From the QMK docs:  "Many keyboards in the QMK Firmware repo are split keyboards. They use two controllers—one plugging into USB, and the second connected by a serial or an I2C connection over a TRRS or similar cable." 

So yeah, it sounds like that part of it shouldn't be a problem at least. :)

  Are you sure? yes | no

Yang Hu wrote 04/19/2021 at 22:34 point

regarding scanning and delays, maybe you can modify this line to customize the delay between row selection and column reading:

regarding board space, SMD components are not that hard to solder as long as it doesn't have lots of tiny pins on the same side(mcu). Components with only 2 or 3 pins are pretty easy to solder by hand.

  Are you sure? yes | no

Ben Gruver wrote 03/22/2021 at 05:05 point

I was looking at qmk a bit more tonight, and I think its "layer" functionality might be sufficient to support the different modes for the lalboard. e.g. NAS (number and symbols) and "function" (f keys, arrow keys, home/end/insert/pgup/pgdown/etc.). As well the additional "nice to have" modes I've added to my firmware. Extra modes for gaming, for left-hand-only cut/copy/paste shortcuts, etc.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates