Close
0%
0%

lalboard

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.

  • First PCBs received, and first keypresses registered

    Ben Gruver04/08/2021 at 09:05 1 comment

    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 2 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

  • lalboard v2

    Ben Gruver03/14/2021 at 08:55 1 comment

    I've been thinking about a significant new version of the lalboard for a while now. My goals for the new version include:

    • Use actual fabbed PCBs
      • The DIY vinyl-cut "PCBs" were great during the early prototyping phases, but are not suitable for broader use. It's a very fiddly, time consuming process. Using actual PCBs will make the keyboard significantly easier to make, hopefully removing that as a barrier to entry.
    • Easier to print
      • Less fiddly custom printing settings needed. It should be mostly printable with stock .2mm layer height print settings.
      • Don't rely on friction for the screw mounts - this requires lots of tweaking of the exact size and printing parameters to get a reasonable amount of friction between the screw and the base.
    • More modular
      • Allow the pcb to be removed from the cluster without having to desolder every LED/PT, for ease of maintenance, upgrades, repairs, etc.
        • The LEDs/PTs will be soldered to the PCB first, and then the PCB with all components is inserted onto the bottom of the cluster, and held in place by a screw.
    • Add a supported "upgrade path" to a static base.
      • After using my original laboard with the adjustable screw mounts for a while, and getting everything exactly in the positions/angles that I want, I upgraded to a static, non-adjustable mount. However, The existing clusters/pcbs/etc. couldn't really be used with the new static mounts, so I basically had to build a new keyboard from scratch, with all new clusters, etc. So the new version will be designed such that all of the clusters/etc. can be used with either the adjustable screw mounts, or a static mount.
    • Parameterized static mount
      • It should be possible to take measurements of an existing screw-mount setup, enter that data and generate a matching static mount.
      • Also, I don't think I ever published the details of the static mount I made for the first version.
      • One option I'm considering is putting fiducial markers on the clusters, and using photogrammetry to determine the relative positions of each cluster. I know meshroom supports CCTag fiducial markers, so it may be possible to, e.g. have a set of special central down keys that can be swapped out in each cluster that have a CCTag printed(??)/applied on them.
    • Beefier keys
      • Some of the keys are a bit prone to breaking over time. The worst is the tall, thin mode key on the thumb. But I've broken some of the other thumb keys and even the short normal cluster keys.
      • The cutout for the magnet on the key stem is a particular weak point that is prone to failure, because there's not much material left at the widest point of the cutout.
      • It should be possible to make the keys wider, and maybe a tiny bit thicker, to help reduce failures.
    • Use the same form factor of LED as for the photodiode.
      • The LEDs and photodiodes that are used in the design come in 2 slightly different packages (PT908/PT928 and IR908/IR928), with different dimensions. I think there were some supply constraints with which types of which part I could get when I was originally working on the design, but digikey seems to stock both types of both components now.
      • Switching the LED from the thicker package to the thinner package frees up some space allowing the key stem to be wider (see "Beefier keys" point, above).
      • It also simplifies the design a bit, since you only need 1 type of "hole" for the optical components, and things are more symmetrical.
    • Use something better/cheaper than the teensy 2.*
      • I love the teensy 2, but it is... a bit long in the tooth. And possibly not long for this world. And the $20+ price point is a bit high by today's standards.
      • I mostly chose it because I had already used it years ago to replace the MCU in my datahand, and knew it would be significantly easier to modify that firmware to work with the lalboard, rather than writing a new firmware from scratch, or adapting another unfamiliar open source firmware to the lalboard.
      • Now that ESP32 has native USB support with the ESP32-S2 variants, I'm currently leaning towards using an ESP32-S2 dev board...
    Read more »

View all 9 project logs

Enjoy this project?

Share

Discussions

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 https://github.com/rutgervana/lalboard/tree/v2. 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 (https://qmk.fm) 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 (https://github.com/JesusFreke/lalboard/tree/v2). 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 https://docs.qmk.fm/#/how_a_matrix_works, 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 7 hours ago point

regarding scanning and delays, maybe you can modify this line to customize the delay between row selection and column reading: https://github.com/qmk/qmk_firmware/blob/dffa0891736ef8aeec54285f6ceb732eb7aaadf7/keyboards/ergodone/matrix.c#L125

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