51–60 of 61 posts
Nice project! > 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 digitalRe…
Nice project! > 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 digitalRe…
I'm curious, why the first sleep? Why not go into the while loop right away?
Earlier quoted context omitted.
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, /…
If there are nested rings of keys, how would the keyboard know which key you "pressed"? Maybe I need to RTFM.
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.
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.
Earlier quoted context omitted.
If there are nested rings of keys, how would the keyboard know which key you "pressed"? Maybe I need to RTFM.
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 positio…
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…
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.
The most interesting for is the USB 3.0 connection, on the hub. Didn't know the lanes are totally independent.
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.
Part of me had hoped that this was some sort of insane mechanical keyboard, where every single key was on the rotary.
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.