> Due to debouncing troubles, it seems to be double-reading each pulse. At some point I should throw a scope on it to confirm what the problem is, but it works quite adequately as-is. (My first try only had a 10ms delay, which empirically resulted in septuple-reading each pulse…)
Needless to say, this is not the canonical way to count pulses. A more typical and accurate loop would look like
if digitalRead(pin):
count +=1 # register the pulse
sleep(0.01) # debouncing delay
while digitalRead(pin): # wait for end of pulse
pass
sleep(0.01) # debouncing delay
I’m more used to “while pin hot in the last devounceDelay consider held” approach. This double sleep method has a larger minimum for a given debounce delay and triggers multiple presses if you get any contact drops at all during a long hold. Not sure if there are other upsides I’m missing though.
Let's see, for 104 keys 3/4" wide, the fully-rotary keyboard would have a circumference of 78" and a diameter of ~25". At that size, it should probably be oriented like a steering wheel.
The holes on my rotary phone are about 1 cm. One can make them nested, since it would have to be custom anyway: starting with the diameter of, say, 3 cm, adding a bit more than 1 cm on each side (3 cm, 4.5 cm, etc), and assuming that at least floor (pi * (1.5 + 2.5 * n - 2) / 1.5) keys fit in the nth such nested ring (1.5 + 2.5 * n is the outer diameter, - 2 is there since the holes won't be on the outer diameter, / 1.5 cm is to leave some space around them; that's not meant to be optimal, just a quick estimate), that'd yield 101 holes/keys with 6 rings, with the outer diameter of 1.5 + 2.5 * 6 = 16.5 cm for the last one. That's a rather small keyboard.
Edit: nested rings would also work for modifier keys.
I think the most straightforward way is to have a separate usual mechanism for each ring, stacked vertically, passing the rotation from each ring through the inner ones without rotating them. But likely something nicer (more optimal) can be designed: either purely mechanical (to end up with just a single combined rotation on the output) or relying on more modern technologies (plenty of options on reading dial positions then).
Or the holes can just be staggered (so that each hole is at an unique angle): then the rings won't have to rotate separately, though the reading would have to be more precise/higher-frequency then, and it may be tricky to rotate the dial with a finger as precisely (with 6 rings and 15 mm per hole, that would be a 15 / 6 = 2.5 mm margin, roughly).
It doesn’t make sense for the modifier keys to be on the rotary dial, but the rest you code encode by a pair of dials (for 10x10 keys). Labeling would be a challenge.
I wonder which of Emacs and Vim would have the advantage here.
One thing this design demonstrates about the standard keyboard design:
- In order to disallow using the number row, a giant 10U keycap is placed over the number keys. This deliberately restricts usage. It's funny because it's unexpected.
- 3 rows down, you've got a giant 6U keycap. But, most keyboards just look like this, even though it's as impractical as this joke keycap above.
I recently noticed on my local canal the mile markers show how many miles you are from the place youre traveling from.
This is the Leeds Liverpool canal. So as you travel to Leeds it says Liverpool with increasing miles.
From the pov of the Liverpool side of the sign being the Liverpool side this makes sense, and on a barge it's easy to look back to see how many miles to Leeds. But to modern eyes it's completely backwards.
The slowness of the rotary dial might be actually a strength in certain use cases, like when its critical to get the number right the first time around. Consider attaching it to a Bloomberg terminal to eliminate the "fat finger" problem.
I was going to comment that I remember it being the opposite: it was _so_ slow that I would find myself losing my place in the number I was trying to dial and having to hang up and start over.
But then again, maybe that does mean I was less likely to end up dialing the wrong number.
That said, the phenomenon of dialing the wrong number was already well known when everyone was still using rotary dials, so maybe it’s not such a strength after all.
Rotary phones where used with https://en.wikipedia.org/wiki/Strowger_switch - so they have very simple interface - just generate the number of pulses that is either N or 10-N (I don't remember exactly which one is right). There is also a nice back-story about how it was invented.
This is a nice DIY project, but its practicality is questionable. Choosing a number on rotary phones is very slow, as you need to wait til the wheel returns to its start position.
You could redesign the rotary dial to return to zero much, much faster with shorter pulses and smaller intervals between them given advances in high frequency signal counting.
I remember adjusting my phone when I was a kid to spin back as fast as possible, if set too fast and the number wouldn't dial. There was a little speed governor inside which could be adjusted for more or less resistance, i think it had weighted arms that could be adjusted outwards to slow it down.
Tangent, does anyone know where can I buy a small mechanical ringer module like that? I'm probably feeding the wrong terms into ebay but the best it can do vintage doorbells.
> What would be really cool is to see some version of “Minority Report” actually work in my lifetime.
I suspect that that will come swiftly once VR headsets get good[1] enough to be used as a replacement for a laptop/monitor setup. I don't personally have a device, but people who do have told me that the resolution and weight just aren't there yet.
> While one could use a pin-change interrupt, the timescale is so large that busy-waiting is acceptable.
You should never use interrupts for this sort of input with lots of inherent switching noise. At best you could wait for one interrupt then disable it while polling in a debounce routine. Interrupts are a red flag that someone hasn't investigated what the switching is doing to their micro.
That's awesome. Given the effort that went into it, it's kind of a shame to use a cheap $10 board as a base. I think it'd be worthwhile to spend a bit more and get a keyboard running QMK, which also saves the headache of jerry-rigging an Arduino to control the thing and the complications that come with it (USB, custom logic in the firmware, etc).
Yep - same for usb-c spec, there's always a usb-2 bus available.
This makes some cheap hubs actually quite good for office work, they use all four lanes for the display and can also do usb-2 and power delivery for around 20 bucks.
> Due to debouncing troubles, it seems to be double-reading each pulse. At some point I should throw a scope on it to confirm what the problem is, but it works quite adequately as-is. (My first try only had a 10ms delay, which empirically resulted in septuple-reading each pulse…)
Needless to say, this is not the canonical way to count pulses. A more typical and accurate loop would look like