> 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 delayI am glad you shared the video because it was exactly what I thought of when I read the parent comment.
Edit: nested rings would also work for modifier keys.
Edit 2: fixed the formula.
I wonder which of Emacs and Vim would have the advantage here.
Vim could have a mode dial. Which mode should be the default is possibly the thing that flame wars are made of though.
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.
Even traffic signs are 'intuitive'!
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.
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.
I'd like to see a video of a google voice or other call made using the rotary number pad :)
What would be really cool is to see some version of “Minority Report” actually work in my lifetime.
Sort of like people who lived during the invention of the airplane and got to see humans land on the moon
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.
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.
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.