Close
0%
0%

lalboard - Ergonomic Keyboard

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.

The best place to chat about this project now is the "Datahand/lalboard/svalboard enthusiasts" discord server.

  • Steel sheets and static bases

    Ben Gruver06/08/2021 at 08:34 0 comments

    I've developed the designs for 2 different bases to attach the handrests and clusters to. One is based around a steel sheet, with the clusters attached magnetically, for maximum adjustability, and the other is a static design, with the clusters set at a specific location and orientation, for maximum stability.


    Adjustable Design

    (online viewer)



    Static Design

    (online viewer)


    The idea is that you start out with the one that uses a steel sheet, and live with it for a while, adjusting the positions of the clusters until you're satisfied with how it feels. And then you take some measurements (exact method TBD) and use the position and orientation of all the clusters to make a static base.

    When I was originally setting up my v1 lalboard, it took a while before I got everything positioned just right, with lots of small gradual tweaks as I tried to figure out the best positioning. It's surprising how much difference even moving a cluster less than 1mm can make in how everything feels under your hand.

    The steel sheet is great for adjustability, providing six degrees of freedom/adjustability for each cluster. But it's not a great permanent solution, due to how difficult is it to get everything set up *just right*. So if you accidentally bump it and move things around, it's rather annoying trying to get everything back exactly where it was.

    The static base solves this by providing a stable, immobile mount for the clusters. It's also smaller (no margin around the edges past the clusters), and provides somewhat better cable management (although I still have some ideas to improve this).

  • Central PCBs in, first full prototype up and working

    Ben Gruver05/16/2021 at 23:10 1 comment

    The central PCBs came in last week, and I got my first experience soldering fairly fine pitch SMD parts. I had just bought a stereo microscope recently, so I was able to put that to good use when soldering these.

    The soldering wasn't actually nearly as hard as I was fearing. I think the USB-c connectors were probably the most difficult, but really not *too* bad. The ESP32-S2 module in particular was much easier than I was expecting.

    After I got the first board soldered up, I ran into a couple of snags. At first, it wasn't enumerating as a USB device when booting into DFU mode. I used a little usb-power meter I had and confirmed that it was drawing more power when booted normally than when booted in DFU mode, so I was fairly sure the ESP module was booting and running.

    After a fair bit of poking around, and desoldering various parts, I finally realized I had soldered the little TVS diode for the USB-C port backwards. I fixed that and was finally able to get it enumerating as a USB device and then flash it.

    The next snag was that the clusters just weren't working. I wasn't getting any signal at all from the phototransistors. And again, after a fair bit of poking around, I finally realized I had wired the connectors backwards in the schematic and layout. At least, based on the way I had my existing JST-ZH cables wired. I had pin 1 on both sides as VCC, and pin 7 and ground. But of course, if the cable is wired normally, as mine are, the left pin (pin 1) on one side actually corresponds to the right pin (pin 7) on the other side.

    Fortunately, this was an easy fix, since there was plenty of room on the board for the connectors to be placed the other way around. So I got those desoldered and flipped around, and was finally able to get the first keystrokes registered. Woo!

    After that, there was a fair bit of futzing around with the firmware to get both sides working correctly and talking to one another. But I now have a working prototype, which I'm typing this log with :)

    Now that I have a keyboard I can actually use, I've discovered a couple of minor problems that I'll need to address.

    The first is that the central down keys have too much side-to-side wobble. You can feel them wobble as you place your fingers on them, and its a bit annoying. I did some quick tests, just placing some thin UHMW tape on either side of the post, and confirmed that that extra bit of thickness was enough to significantly reduce the amount of wobble. So I think I just need to tweak the size of the post and reprint them.

    Another thing is that I noticed that I was commonly accidentally shifting the key after a shifted key press. I suspect the problem here might be that the thumb down key (the shift key) is registering as a press a bit too soon (and correspondingly, unpressing a bit too late). I want to see if I can figure out a way to measure the distance to when a press is registered, and compare the new design with the old design. I may need to tweak either the physical design of the thumb cluster a bit to compensate, or maybe just increase the drive current of the LED, so it requires the key be a bit further down before the phototransistor stops "seeing" enough light.


    The other big thing that I'm working on is a better base. I'm thinking a plastic base (3d printed) with a void for a smaller steel sheet. The steel sheet will only be used for the clusters, but the handrest will be attached more firmly to the plastic base. I think this should have a few advantages over the current, somewhat ad-hoc, steel sheet solution.

    • The handrest will be firmly attached and kept in position relative to the base plate. This allows the keyboard to be slid around by the handrest. With the handrests just attached magnetically to the steel sheet, if you try to slide the whole keyboard half by the handrest, the handrest just slides on the sheet, and becomes misaligned with the clusters.
    • The steel sheet will...
    Read more »

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

    Ben Gruver04/27/2021 at 05:59 2 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.


    Using...

    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.

View all 13 project logs

Enjoy this project?

Share

Discussions

Gareth Kirwan wrote 09/08/2022 at 08:08 point

Hi Ben! Great progress on this since we last spoke.
REALLY happy you switched to QMK, and the latest changes last year really improved it.

I've settled nicely in Thailand now, so I've resumed where I left off and I'll get the boards printed after some initial testing.

I was still using the more modular design for fingers from ironfox, which worked quite well, but I'll probably switch over to your design now since it'll be easier with more consistnecy.

The one thing I really liked from his was the central button design.

Let me know if there's any gotchas I need to be aware of.

  Are you sure? yes | no

Morgan Venable wrote 12/15/2022 at 22:55 point

Hey Gareth, I just finished a build a month or so ago and am using it as my daily driver, many thanks to Ben.  We've learned a bunch of useful little things along the way that would be useful updates to the build docs, happy to share my experience -- as an example, the concerns about transparency are not an issue anymore with the V2 design.

I'm just finalizing the initial assembly of my own fork, which includes an all-new cluster electromechanical design with a tidier key retention mechanism, a dramatically improved center key, all-SMT boards, and a few other little things to make it a bit more turnkey.  I'm still figuring out the palmrest configuration though.  I'd like to integrate pointing devices once I have a stable setup.

Happy to share how I went about it -- I'm not using the FSCAD-Fusion workflow as I prefer Onshape for development speed, but you should have no trouble reproducing the important aspects of the redesign in whatever workflow you use. 

I created a Discord to make it easier for people to congregate around this topic -- anyone should feel free to join via this invite link:

https://discord.gg/9nucfURB

I'd love to gather more understanding of how other DH users use their devices, what working hand postures and DH position settings they use, and any other interesting mods.  Some basic demographic understanding would really improve the general process of how to build and tune with less difficulty.

  Are you sure? yes | no

Ben Gruver wrote 12/16/2022 at 01:28 point

Hey Gareth, sorry for the late response. Hackaday's email notifications about project activity seem to be completely borked for me. But yeah, it's all still a work-in-progress. Although the current state of the github repo is basically the design I've been using for a year or two now. But I'll definitely be incorporating some of the tweaks that Morgan has been experimenting with. The center key stuff especially.

  Are you sure? yes | no

wjo.ethan wrote 09/18/2021 at 15:57 point

This is an incredible project. I was hit with some bad autoimmune stuff in my early 20's that damaged my hand joints quite a bit, and happening onto the datahand keyboard back then saved my career. But like the other poster mentioned, since they no longer manufacture them there is a great anxiety about what happens if the keyboard breaks. What you're doing is amazing, there isn't any other keyboard I've found within a lightyear of the datahand ergonomics wise, and it sounds like you're making some real improvements too with moveable key locations, as for some of my knuckle joints the keys are spaced just a little bit off what the joint wants to do and irritates it after awhile, so the possibility of being able to move the keys around to fit your particular hand's needs is really interesting. 

I am a web developer with only the smallest knowledge of C/C++, and no knowledge of firmware/hardware/soldering etc. But if there's a way I can help out let me know, as being able to create replacement data hands after all this time would truly be a great mental relief.

I recently ordered a soldering kit, and have been meaning to learn some C/C++ when I have time. 

  Are you sure? yes | no

hillelcoren wrote 09/13/2021 at 14:05 point

Hi everyone,

I'm a long time user of the DataHand (about 15 years) and wanted to share my experience. I'm a programmer who never learned to touch type. I was quite fast as a hunt/peck typist however after a few years of coding I developed tendonitis.

I tried all of the ergonomic keyboards out there and eventually gave the DataHand a try. I was lucky to work at a sympathetic company who gave me months to accomplish very little while I got used to the keyboard. 

I believe it gave me back my career. It enables each finger to move less, in more varied ways with less resistance. I'm over 40 now, my eyes wear out long before my hands :) 

The DataHand I'm using has a broken x key (I keep an x nearby to copy/paste when needed), really excited to be able to try one of these. Thank you for your work on it! The keyboard is hard to learn but can be worth it in the long run.

Cheers

  Are you sure? yes | no

Ben Gruver wrote 09/14/2021 at 04:20 point

Is your key broken mechanically? Or some electrical problem? If the key itself is just mechanically broken, it probably wouldn't be too hard to mold and cast (or 3d print) a new one. If it's an electronic problem, the only thing I can think of that would affect only a single key would be if the IR LED or phototransistor for that key went out. Most any other electrical problem would affect at least 2 keys.

  Are you sure? yes | no

Martin Rudat wrote 09/12/2021 at 13:08 point

Some thoughts:

From other keyboard projects, there's a kind of plastic with a low melting temperature for making temporary braces; you boil it, then drape it over your hand, and once it cools down, it sets in that shape; you can then trim off the excess that you don't need; that might be a less complicated way to make a user-sized wrist-rest than scanning and 3d-printing something.

The other thought is you could make a casting of your hand and wrist (there's a number of different methods to do something like that) in a neutral position and use that for the initial finger/thumb layout?

Ideally would probably be to use a casting, 3D scan that, and then compute a custom model to be printed with mounting locations for the finger and thumb modules.

Hmm. Resting finger spacing (at least for me) doesn't look to leave enough room for the keys for sideways motion, though. Perhaps you'd need to wear some thimbles during the casting to get the right spacing?

  Are you sure? yes | no

Ben Gruver wrote 09/14/2021 at 04:16 point

Yeah, all good points. You might be able to generate an initial positioning of the clusters doing something like that, but I suspect it would still need tweaking. It's very "sensitive" - in the sense that even small changes in cluster position and angle can change the "feel" of it significantly. It may be possible, but I'm not sure I would be the person to do it :)

  Are you sure? yes | no

Mojitas wrote 08/21/2021 at 12:26 point

I've been following this project for over a year and I really want to build one. Though as I live in Sweden the magnets are really expensive to ship here and I don't really know anyone in the US who could help me.

Have you thought of selling bundles of magnets and will you change any of them in v2?

  Are you sure? yes | no

Ben Gruver wrote 09/14/2021 at 18:31 point

Yeah, I'd like to sell kits at some point. But no specific plans yet. The v2 uses mostly the same types of magnets, although probably in different quantities. It also needs some 5mm spheres (iirc), for the new adjustable height standoffs.

  Are you sure? yes | no

Carl Öst Wilkens wrote 05/25/2021 at 08:27 point

I want to build this. Is the BOM on github up-to-date? 

  Are you sure? yes | no

Ben Gruver wrote 05/28/2021 at 07:29 point

The BOM on github is for v1. v2 is still WIP, and I haven't written a BOM for it yet.

  Are you sure? yes | no

Jonathan Brodsky wrote 05/17/2021 at 21:40 point

this is amazing. Very excited that you are continuing on this project.

  Are you sure? yes | no

boogerlad wrote 05/13/2021 at 06:12 point

Have you considered integrating an optical mouse sensor like a PMW3389 to the bottom of the lalboard? If the lalboard isn't too heavy, it could definitely replace the mouse. This way, your hands would always be on a lalboard, never needing to switch to a mouse.

The traditional mouse buttons(left, right, middle click) can activate as soon as there's movement detected from the sensor, and go back to "keyboard mode" buttons(j, k, l) after a period of inactivity from the sensor or input from other "keyboard mode" only keys.

EDIT: looks like mouse sensors are already supported in qmk: https://github.com/qmk/qmk_firmware/tree/master/keyboards/ploopyco/mouse

Also, can you provide a force vs distance travelled graph of the switches? I'm very curious to know the maximum travelable distance and the actuation distance.

  Are you sure? yes | no

Ben Gruver wrote 05/14/2021 at 03:50 point

Yeah, it's definitely something I want to experiment with in the future. I have a sheet of acetal/pom (hard, fairly low friction plastic) that I use as my mousing surface. I had put one side of my lalboard on there, just to see how it might feel, and I was able to move it around like a mouse without any problem. 

Unfortunately, I don't have anything that can do the force vs displacement measurements. I had bought some load cells with the intention of trying to build something, but never got around to it.

But given that it's a magnetic force, I would expect it to be an inverse cube graph, with the point of highest force at zero displacement, and falling off quickly after that.

I did do a penny test on the first version, just for the central "down" keys, and was getting around 25g key activation force.

  Are you sure? yes | no

Ben Gruver wrote 05/16/2021 at 03:46 point

As far as the max travel distance goes, it's about 1.9mm for the central "down" keys, and about 1.5mm for the 4 directional keys. For actuation distance, do you mean the distance to the peak force? If so, that will be at or near 0 for the directional keys, and just guestimating about .5mm for the down key (it's a bit different, since the action is 2 magnets sliding against each other, instead of a magnet moving directly away from another)

  Are you sure? yes | no

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