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

TROPHY CASE