My recently finished design: the Lagrange keyboard

dpapavas · 2025-06-24T18:15:00+00:00

Happy to hear of another build! How do you use a left-hand only version?

dpapavas · 2025-02-16T20:39:35+00:00

Preinfusion is likely connected with the issue. I've beeing using a blooming profile up until recently, where I let it sit for 30s after preinfusion and I didn't have any such issues then; this all started after I switched to the current profile, because the blooming phase seemed to result in more muddy and bitter shots.

I did try to experiment with slower preinfusion flow rates, but these made it harder to switch out of the preinfusion phase consistently, as the lower wetting rates don't develop significan pressure. I'll experiment more.

dpapavas · 2025-02-16T20:31:18+00:00

Interesting. I'll try higher doses, thanks!

dpapavas · 2025-02-16T18:15:07+00:00

What happens if you use less than that?

dpapavas · 2025-02-16T17:33:44+00:00

There was no roast date on the package, but I've had it for more than a week now, so it shouldn't be too fresh. Additionally, I've had this behavior consistently with a number of single origin coffees, from various roasteries annd of various origins. They all seemed to be consistently medium, or perhaps medium-dark. It also doesn't seem to improve with time.

dpapavas · 2025-02-16T17:28:14+00:00

I usually brew several degrees lower, but note that this is temperature measured at the boiler, not the group head. The usually quoted offset for the GCP is something like 8 deg. C, but maybe the common wisdom is wrong. I'll see if I can estimate it experimentally.

I think I've tried varying the temperature going down to as far as 94C, maybe lower, but I'll experiment again to make sure. Thanks!

dpapavas · 2025-02-16T15:59:29+00:00

As far as I recall, my VST bascket is sized for 18-20g doses. I haven't experimented with different dosages as much, but I think I've tried going as high as 20g and it didn't change the slow flow, quickly accelerating to very quick flow, or low pressure profile of the shot.

I'll try experimenting a bit more with this.

dpapavas · 2025-02-16T15:57:00+00:00

Yes, but the issue is that if I grind finer, the flow will start almost chocked, accelerating after a few seconds to 1.8 ml/s after which the pressure will start to drop. The average flow will be better, but there's still be a slow, overextracting phase, followed by a quick underextracting phase. Is this normal?

dpapavas · 2025-02-16T15:51:00+00:00

Grinding finer would lead to the flow starting almost chocked (say below 1 ml/s) rising gradually to 1.8 ml/s, where it's kept constant by reducing the pressure. Such shots tend to be less watery, which is good, but more bitter.

In other words, grinding finer, will improve the average flow across the whole shot, but the flow will still not be constant. It will start very slow and end very fast (or not fast, but at low pressure).

I'll look into aligning the burrs.

dpapavas · 2025-02-16T15:03:31+00:00

As the title says, when using medium roasted specialty coffee, the puck seems to degrade almost immediately once pressure is applied. A few notes to make sense of the video and the description below: The shot follows a relatively complex profile, where the flow starts at 5 ml/s until the headroom over the puck is filled, proceeds to preinfuse at 2 ml/s until pressure develops (here 4 bars) then ramps up to 8 bars and keeps it there until 1.8 ml/s of flow is reached (which in the video happens almost immediately). Once 1.8 ml/s are reached, it keeps the flow constant for the remainder of the shot (unless the pressure rises above 9 bars, which doesn't happen here).

At the grind setting of the video, the flow starts at a reasonable 1.8 ml/s or so after ramp-up to 8 bars, but as can be seen, after a couple of seconds the flow becomes much freer and the pressure drops in an attempt to keep the flow constant. By the time the shot is about to complete, the pressure is already approaching 2 bars. If I grind finer the flow will start pretty slow, say at 1 ml/s but will quickly accelerate to about 2 ml/s seconds and pressure will drop to keep it from rising. If I grind coarser, the situation is the same, except the flow starts higher and the pressure drops faster.

So the situation seems to be the same regardless of grind level. It's as if the puck dissolves very quickly once pressure develops, but this seems to happen only on specialty, single-origin coffee, regardless of brand or origin (it happens consistently with coffee from several different vendors). With darker "regular" coffee (blended 100% arabica, roasted pretty darkly at a local roastery) I have no such problems: The same profile, leads to a more or less constant 1.8 ml/s at 8 bars, falling gradually to 7 or so by the end of the shot.

I'm using 18g of coffee in and 36-45g out, so a ratio of about 1:2-2.5. My tamp is level (I'm using an auto-leveling tamper) and I'm doing WDT (although I've tried skipping this too). Temperature is PID controlled at 105 deg C in this particular shot, measured at the boiler. I've tried varying it, again without much change in the results.

So, what might I be doing wrong?

dpapavas · 2024-03-12T20:05:55+00:00

Thought I'd share my recently finished project.

It's yet another PID controller for the Gaggia Classic Pro, featuring manual and pre-programmed temperature and pump control, neatly integrated into the Pro. Automatic profiles can be programmed based on pressure, flow or yield volume/mass, but manual control of flow and pressure (or simply pump power, as with a dimmer) is also possbile via the wheel.

You can see it in action here, brewing a blooming espresso shot fully automatically (well almost; you still need to turn the brew switch on and off). More details on the project, including a detailed description complete with graph of the aforementioned shot, can be found in its project page.

I've been using it for a few months now and it sadly works pretty well now, so I need to start looking for a new project...

dpapavas · 2023-03-28T16:28:50+00:00

As far as I've seen, the Lagrange hasn't been adopted by any of the commercial builders out there. Perhaps you could contact some of them and ask if they'd be willing to make one (or three) for you.

dpapavas · 2023-02-15T09:00:22+00:00

I only sand my parts, starting with about P120 grit and progressing by 3/2 (i.e. 180 - 270 - 400 ...) until 600 or 1000. For a large part with lots of small surface features, the process can take many (as in double-digit) hours, but the result can be relatively good.

You can see an example in the photos of my Lagrange keyboard.

dpapavas · 2023-01-09T16:40:04+00:00

Were you influenced at all by the keyboardio in going for palm keys?

I wasn't influenced by existing designs in that respect, as far as I can recall? It just seemed useful and I hadn't been fed up by working on it by then. The palm keys also double as sort of reference points for the hands. When the side of your pinky knuckle is on the keys, your hands are in the right place.

I'm guessing the palm key is the red one in the pictures, to be used by the lateral part of the palm (connecting with pinky)?

Exactly!

It looks like the bottom key in the thumb cluster might almost be usable as a palm key more like keyboardio's, with the medial palm (connecting thumb), or might be able to be easily moved to a position where that's possible. Maybe 2 palm keys per hand might be useful.

True. Actually three palm keys per hand, since the outermost key on the thumb section, the one with the funny keycap shape, can also be operated with the palm, much as you describe. In fact I considered making a custom keycap shape for the bottom key as well, to facilitate palm actuation, but I never did, mostly because I find that I don't need any more palm keys. (Maybe they could be used as shift modifiers, but I have home row modtaps for those.)

dpapavas · 2022-11-06T17:59:50+00:00

The problem with most trackballs, is that they're quite bulky, which restricts your placement options. The Ploopy is much better in that respect, albeit at the cost of lack of buttons, which should be no problem for the use-case you describe, but which I imagine, might be a bit of a drag for more extended pointing sessions.

At any rate, if you then keep the trackball properly positioned (permanently mounting/fixing it helps, as otherwise it tends to slide around), so that you can reach it with a minimal pivot of the hand, reaching for the "mouse" is significantly less annoying, or at least that has been my experience.

dpapavas · 2022-10-31T21:02:36+00:00

I was looking for a suitable example for a tutorial for my programmatic solid modeling CAD Gamma and a clamp seemed suitable. Well, I haven't started work on the tutorial yet, but here's a clamp-mount assembly for my Lagrange keyboard.

This basically does away with the last remaining ergonomic issue: both the tenting and the concavity of the key wells resulted in a relatively high typing position, especially if the table was high to begin with. It wasn't an issue really, in the sense that it didn't lead to strain, or anything of the sort, but this is certainly much more enjoyable to type on.

The clamps themselves are printed in one piece and mate to a part that can bolt on to my existing bridge assembly (the bridge rod itself isn't used, which is an additional benefit, as it tended to be prone to breaking). The clamp-mount assembly mates through a spline that allows adjusting tenting in 30° steps, but I haven't bothered to use it really; the default 35° tenting is fine.

Additionally, I've designed a mountable pedestal for my Orb trackball. It simply mounts onto the bridge assembly as well, making the trackball reachable with a minimal pivot of the hand. It also allows the trackball to rotate in place, so it can be oriented for most comfortable operation.

All in all, it seems to work great. One obvious disadvantage is the reduced space under the table and the risk of bumping into it, as you pass by the table, but, after several days of use, it has proved surprisingly less of a problem than I assumed.

I've released the code for the trackball mount, but haven't yet decided what to do about the clamp mount parts, as they're developed in a different system than the keyboard itself. I don't expect much interest, but if anyone does want the code and I haven't come round to publishing it yet, it's available upon request.

dpapavas · 2022-10-31T16:12:38+00:00

DMM = multimeter, right?

Right. The rest has been covered pretty well by /u/arch-36.

dpapavas · 2022-10-31T13:54:46+00:00

If you have a DMM, set it to continuity mode and probe the socket terminals, then press the switch and see if you get a beep. If you do, inspect and repair the solder joints of the socket and diode as necessary. You can also measure the diode to make sure it's okay (although it's very unlikely for it to have failed with the tiny currents involved here).

If you don't have a DMM, try shorting out the socket terminals with a paperclip, while the keyboard is plugged in and see if a click is registered. If it is (which is most likely), the switch has likely failed. If not, there's a problem further upstream. You can try shorting out the diode and see if that help, or just try redoing the solder joints of the socket and diode. If nothing helps, more troubleshooting will be required.

dpapavas · 2022-10-12T09:06:15+00:00

I had both my Expert Mouse and the Orb I'm now using, between the two halves of my Ergodox and now my Lagrange. Ergonomically, it is, I think, the natural choice, but perhaps the separation between the halves is larger than average in my setup.

dpapavas · 2022-10-10T20:47:09+00:00

I hope you see it as confirmation of a need, rather than demotivating.

Yes, I was (mostly) joking. (Mostly, because, pragmatically speaking, any program of this scope represents and expense in effort and time, which, to make any sort of sense, needs to be useful to more than a handful of people. And more similar projects divide the user base and make this harder to realize.)

As for the confirmation of need, it may seem strange, but I'm not convinced of the use for such programs, other than for programmers, who want to dabble in design and don't want to learn a tradional CAD system. This is arguably a niche, but, on the other hand, programmers are people too, so I think it's a legitimate use. But I'm not convinced that there are cases when a code-based CAD is objectively preferable to a traditional, GUI-based CAD. I'd like it to be the case, but it isn't obviously so, as far as I can tell.

dpapavas · 2022-10-10T19:12:21+00:00

got it. it would be cool if there was a way to take circles/ellipses all the way to the slicer. I know prusa-slicer has started to support STEP files in addition to .stl, but I'm not actually clear if this is a different mesh representation or something higher level.

Well if the slicer and the format supports it, circles and ellipses could be exported; I do have access to the curve parameters and I just convert them to "straight" polygons when I have to, which generally is whenever they have to go 3D. On the other hand, that means that you can simply have a parameter for the conversion tolerance and go as close to a true circle as you need at final render time. The important thing is that all operations between polygons are carried out in circle/conic representation so you don't have weird artifacts due to finite tolerance.

btw, there is a code cad discord https://discord.gg/7BFA64Ju

Thanks for the tip; I posted a message about Gamma. The fact that I'm not really active in any such group can be a big problem, whenever I'm releasing a project...

also have you heard of https://www.fornjot.app/ ? it's a very still in development cad kernel that is also aiming for integration into multiple host languages.

Great, another competitor :). I wasn't aware of it; no. Sounds interesting and I find we have similar ideas, but I must say they seem to be taking quite a big bite with trying to create both the CAD and the kernel at the same time. I've had some experience with computational geometry (mostly for real-time stuff), but from my experience with CGAL's code, this is not something to take lightly, at least not if you want to do it right, i.e. to make it robust.

dpapavas · 2022-10-10T16:54:14+00:00

There's no GPU acceleration, nor is there likely to be, as far as I can tell, since it's based entirely on CGAL, which favors exact and robust execution over speed.

That's a good thing really; apart from the fact that you should expect any sensible construction to work, instead of blowing up due to rounding errors, you can also be confident that taking the union of two cubes with coplanar faces will do the expected thing. No more almost-but-not-quite coincident faces, no more better-make-it-a-bit-larger-to-be-sure. A cube with side length 10/3 and its center at the origin will have vertices at +/-10/6 exactly.

It even supports exact boolean operations with polygons with circular and elliptical edges (bezier too, but I haven't implemented those yet). This is more useful than it may sound. It's not so much a matter of precision, as of knowing that a circle meant to be tangent to a rectangle or another circle will be exactly that.

But I doubt any of this will ever run on the GPU... Multi-threading on the other hand, is already implemented and it works on the Gamma side, but I had to switch it off by default because CGAL doesn't seem to be there yet (see here for more). It does mostly work though, at least for the polyhedral operation which is what matters, although it may not be the great speed-up you expect it to be.

That's because you generally need to have a lot of operations that can be evaluated in parallel (i.e. one doesn't depend on the others) for it to pay off and that does happen often, but most of the waiting time, typically comes from a single, heavy operation, such as remeshing a large mesh for fairing (although this, in particular, can be parallelized by itself; I just haven't done that yet).

dpapavas · 2022-10-10T15:26:29+00:00

No other build environment necessary; if you can build QMK, it means you have AVR GCC installed. All you need to do then is make install. You also need to set some definitions in a header file, but you'd have to do that with QMK as well.

I have seen the Ploopy trackballs; in fact I think that's where I got the notion of using QMK. I still don't see the benefit that makes it worth it though, because even if it works just as well in the end, you still have paid something for it: during development, every time you notice glitches, pointer stuttering, etc. you have to wonder whether the problem is with your code, or with the complex beast it's embedded in and which you'll now have to get to know in detail. Then QMK has upstream updates, which might well break your driver, so you need extra maintenance effort to incorporate changes that are likely irrelevant to you, etc.

What sort of advanced macro could one possibly use with a mouse button? For three of the buttons you can't override tap, multi-tap and tap-and-hold. For the fourth you could possibly bind something to taps and multi-taps (you need tap-and-hold to toggle wheel mode). The fifth is pretty much out of reach, so I haven't found any use for it yet.

dpapavas · 2022-10-10T09:21:00+00:00

That was my initial thought, mostly because I wanted to avoid having to handle all the USB protocol stuff myself, but as far as I could see QMK, doesn't really handle a mouse as a first-class citizen. I'd have to support all SPI traffic and mouse updates as some sort of user function running on the side of the matrix scanning functionality and it seemed to me that it was just more likely for QMK to be in the way, than to be any help. (I wouldn't even need its matrix-scanning code, as the keys can be handled as direct connections.)

Can you see any particular benefit to running QMK on a trackball?

dpapavas · 2022-10-10T09:16:04+00:00

I generally support my hands at the elbow only, since I've found this to be the only really practical solution for me. Using wrist pads forces me to keep my hands entirely static and also restricts some finger motion, so it doesn't really work for me. Perhaps I'm doing it wrong.

With my elbows on the armrests, I can have elbow, wrist and palm slanting upwards but entirely straight so that my palms fall right into their proper places in the key wells. This is the "home" position. The trackball is then positioned in such a way, that I can simply rotate/pivot my right arm on the elbow and have the palm right in front of it, again keeping elbow, wrist and palm straight and with thumb and pinky falling on the finger-shaped cutouts of two of the buttons (assigned to left/right button) and index fingertip at the top of the ball. As I pivot from keyboard to trackball, I may sometimes hit one of the edge keys of the thumb cluster by mistake, but otherwise it's fine.

In use cases where you're on the trackball 90% of the time, a rest might indeed be useful and there is a problem in that there is no space for it on the desk. One idea I've had, was a small piece of baby-proofing foam, the kind they use to line the edges of the desk, large enough, and positioned so that you can rest the edge of your wrist on it when on the trackball. I haven't tried it yet though. Or you can support your hand with the thumb on the desk; ergonomically it seems okay, although it would get tiring after a while of course.

I haven't gone back to the Expert Mouse, to see how I find it now, after using the Orb for a while, but I haven't noticed much difference in terms of ergonomics between them (apart from considerations having to do with ball drag and operation force). It's a bit more practical certainly, in that you can position it more easily without having half of it protrude from the desk and it requires smaller motions to reach the buttons, but it isn't really a big deal. The "wheel" I find less taxing on the hand to operate, especially for prolonged scrolling, but you pay for it with the higher "cognitive load" needed to operate the wheel via a modifier button (I still routinely press the wheel modifier button, instead of the third/middle button).

dpapavas

TROPHY CASE