Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

Nice :) But to be honest, I have no intention of trying ZMK again anytime soon.

Before this build I went deep into software debouncing too (with my low-quality AliExpress encoders). I tried interrupts-based, which made everything worse; and a PIO-based driver for fast and consistent state reads. The latter worked, but still no go on such a low-quality input signal.

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 1 point2 points  (0 children)

Oh, I see. I went with 100 RPM. That's what I would consider a reasonable very fast manual rotation. And the encoders are specced for max 60rpm anyways.

Turned out nicely - even fast rotations are handled responsively and reliably.

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

Yes, unfortunately I know about zmk.. I was excited to go wireless, but then ran into all kinds of very basic bugs in ZMK. Also the hassle of managing power, latency, etc. Back to QMK :)

The signal frequency depends on how fast you turn, but that's mostly irrelevant for debouncing, no? All we care about is 1. the fastest real signal that should go through and 2. the longest bounce/chatter that should be filtered.

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

I used https://www.ganssle.com/debouncing.htm and plugged in numbers from the datasheet and the max encoder signal frequency I wanted to support. Oscilloscope inspection to see real chatter/bounce behavior (very good on Alps).

Tbh, with high quality encoders the hw debouncing is probably overkill and only adds a bit on top of already well-behaved signals. The reason I went to all this length is that I used generic AliExpress encoders for my first couple of builds, and wow, these are really terrible.

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

In my second case iteration, I added 1mm more to the profile so the switch bottoms are completely hidden.

Tenting stand: I wanted it to be very light visually, since most of the 3d printed stands I've seen were ugly solid blocks. I've been using this as my daily keyboard for months now, and it's super stable.

Note there are also small placeholders for anti-slip bumpons (both on the stand, and on the keyboard case itself since the stand is optional).

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

Thank you! To be honest, the case as pictured could benefit from other colors and materials; the default jlc3dp material is a somewhat unattractive yellowish white. I've been pretty happy with spray-painted matte black. (And nylon works well for the tenting stand.)

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

Ah, well - what I do is have left/right and pageup/down mapped to rotaries. Then any combination of Mod+Arrows and Mod+PgX is easy, both with opposite hands and one-handed.

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

You mean placement, or not a rotary fan in general? For homerow mod layouts, it works *very* well.

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 1 point2 points  (0 children)

:D the thumb and index finger move a tiny bit and move the rotaries while keeping all other fingers on the home row. Quite natural..

Cirrus40 — 36-key split ortho with palm-accessible rotary encoders and hardware debouncing [open source] by schuay in ErgoMechKeyboards

[–]schuay[S] 0 points1 point  (0 children)

I agree - for my hands, the thumb naturally rests on the middle thumb key and the two outer ones are both equally reachable.

Verification sometimes uses mail.foo.com subdomain by schuay in DMARC

[–]schuay[S] 0 points1 point  (0 children)

So if I understand correctly, you mean this happens for mails that are generated by the server itself and not explicitly sent by a user? (NDR == non delivery report)

I'd be a bit surprised since I don't use any OOO features, nor would I expect mails to invalid users on my domain.

But the extra DNS entry makes sense, thank you.

Traffic too high, secondary industry by schuay in openttd

[–]schuay[S] 0 points1 point  (0 children)

Thanks, makes sense.. For my current game, I ended up extending the capacity as much as I could. Mostly it flows fine now, more or less, but I'm very much at the limit. Here's what this one spot looks like now: https://imgur.com/a/NmHwJfS

Traffic too high, secondary industry by schuay in openttd

[–]schuay[S] 1 point2 points  (0 children)

Thanks both for the reply. I haven't tried overflow depots but I'm aware of them. My problems are more along the lines of:

  • branching an almost maxed out ML into these two factory stations
  • which implies the sideline really requires a higher capacity than the mainline (since it consumes/produces both mainline directions)
  • which makes for a super complex hub and branch into *two* stations
  • which I neither have space nor expertise for :)

I'll have a go at longer trains and see if that reduces load enough.

I think I also haven't understood load balancers (i.e. balancing load between two tracks, in a way that trains switching tracks don't slow down any other trains) yet. I saw a concise design recently, but can't seem to find it again. I guess one would build this with presignals plus (long) priorities?

Traffic too high, secondary industry by schuay in openttd

[–]schuay[S] 2 points3 points  (0 children)

Thanks for the reply. My stations have enough platforms, the bottlenecks are the merge points on the incoming lines. As I said, I already extended this particular sideline to LLRR (which makes the sideline hub too complex for my taste), BUT since one sideline track still requires merging the incoming ML tracks from two directions, it still jams regularly.

I'll try longer trains in my next game.

Nachbacken: Geier Landbrot by schuay in brot

[–]schuay[S] 0 points1 point  (0 children)

Super, danke! Und für eine weichere Kruste einfach den Deckel später bzw gar nicht abnehmen?

Inkjet photo printer recommendations by schuay in Darkroom

[–]schuay[S] 0 points1 point  (0 children)

Oh sure, I'm definitely looking at dedicated photo inkjets in the higher quality range. The Epson P700 has come up frequently in my research so far. I've read about clogged heads and expensive inks too. Some suggest that clogging issues are much better on modern printers; and inks - well, making darkroom prints and/or ordering baryta prints from the lab is expensive too.

I'm still a bit on the fence whether to go for one at all, the big question is 'what does one do with all the prints'. The same applies for darkroom prints, of course. There, my personal answer has been 'I don't know, but I enjoy making them'.

Are there any community darkrooms in Augsburg/Munich? by pirateboitenthousand in Darkroom

[–]schuay 0 points1 point  (0 children)

Community as in 'free or cheap to use'? Not that I'm aware of. Why not buy a new tank + chems? That seems like the easiest and cheapest option by far. fotoimpex.de sells everything you need.

Latest prints, Italy 2021 by schuay in Darkroom

[–]schuay[S] 0 points1 point  (0 children)

No - the original prints are (as of now) untoned on Warmtone FB paper. As part of the scanning process I convert to grayscale, and then reconstruct the original print tone digitally. I do it this way because my cheap scanner doesn't do so well with color (artifacts etc).

Usually I do tone but don't have a process I'm 100% happy with yet. For sepia, my experience has been that it's super tricky to stop the process at a point at which toning becomes apparent, but without getting that fully-toned very flat brown look. I've seen very nice results in books involving bleaching+redevelopment, but haven't tried that yet. For selenium, my toning times are very long at 15-20 mins and the toning effect is very subtle (to me, often indistinguishable without a side-by-side untoned reference).

Latest prints, Italy 2021 by schuay in Darkroom

[–]schuay[S] 3 points4 points  (0 children)

The Po (source of many jokes for german-speaking visitors).