#98 Telephone Dialler ☎️ and Hardware Debounce Solution (retro) 

Very kind of you, sir! I'm glad the video was of help.

Ah yes, Aidas, software debouncing. I've read Ganssle's paper on this a couple of times but have yet to try anything of his out. But keep tuned as we all need a definitive solution.

Indeed, Pekka, that PDF is an absolute MUST READ if you have any interest in debouncing. I've yet to read the software side of things but I certainly plan to do so. Thanks for posting.

Glad it was helpful!

Who would have thought that public phone boxes would get abused by vandals, hey, Brian? But I like the rotary dials from public phone boxes, because they were all shiny metal and probably had metal gearing too. They were really smooth in operation (before they got vandalised anyway). No chance of getting one of those I'm afraid, not unless you buy the phone box to go with it for a few thousand. Ah, memories.

Nostalgia ain't what it used to be.

You're too kind, William, and glad you liked the video. I enjoyed sorting out the switch bounce for *any* device using Jack Ganssle's brilliantly simple, yet highly effective, circuit. I hope to test this using a Rotary Encoder soon. On the subject of the DSO I checked my s/w version a couple of weeks ago and I thought it was the latest? Not so? I even took it apart to flash it and discovered (or so I thought) that I didn't need to. I'll check again, but as you say, it is working rather well for the simple stuff we usually do with Arduinos. Glad yours is now behaving properly too. Thanks for posting.

Muchas gracias, Rafael, en espanol me llamo tambien Rafael! I too love the old (retro) engineering like this dialler. I'm not sure I could actually live with a telephone like this though, no redial, no phone book, no SMS, no WhatsApp!!! But for an Arduino project it certainly is interesting. Gracias por su publication (post).

If you have really old one (or one in poor condition) then the contact could easily have got dirty or corroded over time. As you say, switch cleaner and a *really* thin and fine emery board (like the ones ladies use for their nails) may sort it out. Interesting what you say about turning one of these diallers into a USB keyboard - I'm guessing you're just using it as a number pad, or how are you getting letters out of it? Sounds interesting though (you see, there goes the inspiration moment again).

The plan is just to use it as a number pad possibly with a button connected to another pin as an "enter" key. The whole thing will then be hooked up to a raspberry pi and be a way of selecting options, entering passcodes etc.

Sounds cool. Even if you are using a Pi not an Arduino :) When you get it going don't forget to make a short video on RU-vid and share it here, it would be great to see what folks are using these things for. Thanks for the update!

In that case, Javier, you should watch video #92 JYE Oscilloscope Kit Build where I show you how easy it is to put together. And it's around the £16 - £18 mark ($20 maybe). Cheap but useful. Just ensure you get a *genuine* JYE one not some fake. Watch the video to see where I bought mine from.

Wow, if you knew how much that would cost to replace, Tubical, you would insure it separately!!! I'm amazed that someone is still using the old rotary dialler. Don't you miss the redial button? The phonebook (I suppose you have a hand written one of those)? Amazing. Very, very retro indeed. Yes the circuit from Jack Ganssle is excellent and clever too. Certainly it deserves a place in every Arduinites (digital) bookshelf. Thanks for letting us know that rotary dial telephones are still in use!

There was a time when these old and black only phones where considered just plain garbage, i have about another four of them i think, and they all had been given to me, for free....as in: there is a guy who "collects" old garbage, let him have this....back in end of the 80th i thing... Now it´s "Retro" style and i´m aware that some people paying some two eventually a three digit pricetag to own one of these. I hardly use my POTs but it´s fun to have it and when it rings you´ll never miss a call due to a fail of hearing ;)

Well, eBay is your answer if you ever a need a bob or two (that's UK-speak for a dollar or two)! Yes, they were certainly good ringers and they even do what they were designed to do: make phone calls! Good to hear from you, TubiCal.

Good to know, Dane. I didn't cannibalise a phone to do this, though, I just bought the dialer. But I like your thinking and the information, appreciated.

That was exactly the thought process that I had, Maxx, and I'm still thinking of where I might use it but one day it will come to me, I'm sure. As well as getting suggestions via this channel too. They're great to play around with.

Could I ask a favour? Please would you post a photo of the front of the dial with a ruler for scale? I had the idea to see if it would be possible to make a 3D printed version, triggering a couple of microswitches to generate the pulses. The mechanics in the back will have to be engineered differently, but knowing the diameter of the dial and finger holes would make modelling the front a bit quicker. Don't worry if you are too busy, I can always see if I could get dimensions from a screen shot. I just though I'd ask. If I can get one to work, I'll share the design files, so your viewers could make one if ebay can't deliver. Thanks.

No problem, here's a link to a DropBox folder: www.dropbox.com/sh/nox1l1ht71p9asd/AACpup5yWMmxdgzcIxMPjIP0a?dl=0 Any issues let me know (or if you want specific photos of it or further measurements). From what I saw the main dial was a tad over 7cm and the inner dial (where the number goes) 4cm.

Awesome. Thanks.

The chip I eventually settled on was the industry standard SN74HC14 which contains 5 single input Schmitt triggers. But *beware* that you will need two triggers per switch unless you're prepared to deal with inversion of the logic in your software (when the switch goes high the trigger goes low, not ideal). So I connect two triggers in line, per switch, to bring the logic to the correct state. Which means I only get two triggers (plus half a trigger) per chip. There are numerous other Schmitt trigger chips out there (including octal - 8-way - which might not even be inverting so that would be worth investigating). See what you can find and let me know and I'll give it the once over, if you like? You need TTL level not CMOS level remember for the Arduino - some chips are available in the two variants.

I just found this one: 74HC7014 Hex non-inverting precision Schmitt-trigger so that gives you *five* Schmitts per chip, meaning you would only need two. Looks interesting. Not sure whether it's available as a DIL format, might be surface mount. More here: assets.nexperia.com/documents/data-sheet/74HC7014.pdf

Thank you, Looks like Avnet has them $1.60 which isn't bad. This should help me keep the size down.

I'll try dealing with the inversion in software, I don't imagine there would be any issues. Did I just say that? I'll buy a few extras. ;-)

Yes, some trial and error may be required. See how it goes. Within your software there's nothing to stop you defining "ON" as a low value and "OFF" as a high value, just to keep things straight in your mind. See how it goes... as you say, what could possibly go wrong?

Remember that for the SN74HC14 you will need two gates per switch, otherwise you will get an inverted signal; so your code would have to check for LOW when the switch is HIGH - all a bit confusing! I used two gates per switch in my demo CD4093 Schmitt trigger (not a great choice for Real World use but OK for demo) to get the non-inverted output. The MC14490 looks interesting (and, ignoring the price differential) I wonder if it works any better than, say, a SN74HC14 with the "100%" debounce circuit? Frankly I just like Jack Ganssle's circuit so I'll stick with my SN74HC14 for now!

Ralph S Bacon yes indeed. Thanks for pointing it out. In my case it doesn't matter that much as I look for a state change as it will be a toggle switch. But ofcourse that isn't valid for every situation. I think I stick with your method

Indeed! It works well but there are other ways (which I've covered in other videos).

Sounds very cool your project there Stewart, not to mention retro. Old (dialler) telephones are easy to come by but the price is sometimes eye-watering. And many of them have been converted to work with our modern telephone lines too. I shall have to think what I will use this dialler for. If you have any suggestions...

I was lucky and got a couple complete (unadulterated) telephones here in Budapest for approx 15 GBP. You could convert a cheap keypad safe to store chocolate or other stuff you shouldn't binge on! They are crap and easy to break into as standard so you can't really harm it using this dialler! Something like this: www.ebay.com/itm/STARK-Digital-Electronic-Safe-Box-Keypad-Lock-Home-Office-Hotel-Gun-Steel-Black-/401192822967

Excellent suggestion for a Real World project using a telephone dialler. Er, hang on, that safe looks just like mine. Oh bother! No wonder the chocolate keeps going missing.

I can just about remember trying that trick out, Andymouse123. I'm still wondering what I can use my dialler for, but I just like it. Very retro. Thanks for posting.

Thanks for sharing! 60mS is a loooooong time in µController land, usually a switch will not bounce for more than 5mS, so even 20mS would be extraordinarily bad! I guess the telephone dialers didn't care about that!

I'm afraid it's not possible to extend the RAM (run-time memory) although you can use external flash memory for storage of data (not programs). If you need more memory you could move to an Arduino MEGA 2560 which has 256Kb of flash memory (for programs, whereas the Uno or Nano only have 32Kb) and it has 8Kb SRAM (run-time memory) and the Uno/Nano only have 2Kb. Sounds good?

the problem i like the nano as it's size fits more with my project so idk

Yes, I did wonder if that was the reason you chose the nano. You can however get much smaller variants of the Mega 2560 - I'll be doing a video on one of them in a few weeks time. At the risk of prematurely telling you about a future video have a look at this product, it's a Mega but *very* small: www.aliexpress.com/item/Mega-2560-PRO-Embed-CH340G-ATmega2560-16AU-with-male-pinheaders-Compatible-for-Arduino-Mega-2560/32801785024.html - I think it may do what you want in all respects: plenty of memory, storage and a small size.

awesome, u are really my hero. i hope u can consider me from now on a special sub cuz i will always watch, like all ur upcoming vids as much as i can unless i have serious stuff going on in rl. :) still waiting the video to check it well before i buy it.

Glad I could help and thanks for subscribing and watching! We all help one another here.

Was this at the same time that you walked in front of a car waving a red flag? And helped the man light the gas lights in the evening, Ed? Before running water was invented, in fact. Heh heh, I wish I could get one of those "wind up" phones, probably worth a mint these days.

Cars we also still had to start by cranking a lever but I was too young to help light the gass lights in the evening. I did join my dad hunting woolly mammoths for dinner though. I used to have one of those old phones, but at the time didnt see the value. Also had a number of those old rotay phones (T65 model) but somehow lost those in the course of my life with moving house etc. By the way, I remember that in Norway, the ciphers on those rotary phones went the opposite way

Got one of the crank phones from a friend whose dad passed. They were going to use it as a decoration, but someone 'helping' them clean the garage threw the thing out! Luckily my friend was able to retrieve it, but the microphone holding arm (metal) broke, as well as the bakelite cone around the mic, plus the earpiece wire was ripped out. As my friend isn't technical, I got offered it as a restoration piece. I haven't had a chance to do much with it yet, but I'm hopeful I can make it look good again - though I'm sure its lost any value as an actual collectable - It still is pretty cool. It's amazing what the wiring standard was back in the day. The insides wiring looks crazy. Since it needs work done anyway, I'm thinking of covertly converting it to work as the enter buzzer for our home - just need to steal a few parts from a cheap modern phone and rewire. Actually, do you happen to know any good sources of old-timey looking fabric-covered 2C wire? As an aside, Thanks for all the great videos - I'm making a small project that will be incorporating many of the concepts you've covered.

Yes, the MAX6816 is a good chip for that except for one thing: the price. You could buy several standard Schmitt triggers (plus the two resistors, one capacitor and one diode) for the price of one MAX6816. But as you say, the advantage is that you don't need external components and, well, it "just works". Horses for courses, I guess David, and you have found yours. Thanks for sharing this information, others may well be interested in this too.

MC14490 now 5 for 1.90USD at ali

The POTS (plain old telephone service) would never react to the switch bounce of a few milliseconds - but our microcontrollers do!

@@RalphBacon Ah, slow moving inertial switch debouncing!

Thanks for your kind words, captxrox, most appreciated. I'm really happy that my followers enjoy my videos. And yes, you're right that millis() does not increment during an ISR, but that doesn't matter as far as the code here is concerned. As long as a certain number of milliseconds have elapsed (it increments again as soon as the ISR finishes) before accepting further pulses that's fine. Polling is just not the optimal way of intercepting pulses that happen now and again as your Arduino's code might be busy doing other things and miss a few. MIcros() does continue to run during an ISR as the underlying routine does not use a timer, but we don't need that here, anyway. It's can be a minefield using the Arduino specific functions (if you were using native C++ it becomes clear(er) what is going on). Thanks for posting, this is an interesting area to keep plugging away at.

I guess I was wrong about micros()--but right about millis() and delay(). I just read the notes on cdn.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/ including the comment titled "About Interrupt Service Routines". One thing it says, that I think is relavent here is: "Generally, an ISR should be as short and fast as possible." That would be defeated as soon as a delay routine would be used. Going back to polling, I have generally been successful with software debouncing a polled input. Somehow it appears that the software debounce within the ISR will not work--whatever the reason. While polling clearly won't work for a rotary encoder (there's a few RU-vid videos demonstrating that) it should work on a rotary dialer. The nominal period between pulses on the dialer is 100 ms. I would try it myself but I don't have a rotary dialer.

I'm a tad worried we're talking at cross purposes here, captxrox. The ISR in my demo (the one that includes checking the millis to ensure we reject pulses that occur too close together) is the standard software method of dealing with bounces. There's no delay involved at all. We just exit the ISR if the current pulse has come "too soon" after the previous one (so we assume it's a bounce). So apart from my demo-purposes-only where I have a Serial.print statement (definitely a no-no for a real ISR) it's about as fast as it can be. Using polling to debounce anything (switch, rotary encoder, whatever) this obviously *can* be done at a technical level but should *not* be done, as presumably your Arduino is busy doing the real work of switching heaters on and off, or measuring the light levels or something. We wouldn't want to poll for any kind of switch closing (bounce or not), it's just not good programming practice. The issue I had with the telephone dialler is that it is so ancient that it flies in the face of normal switch behaviour. We can get a semblance of proper behaviour by rejecting pulses as far apart as 50ms but that is crazy. As Jack Ganssle mentioned in his paper, he never discovered any kind of standard switch that bounced for longer than 10ms - most were much short than this. So for the telephone dialler (and by extension, any switch) we can dispense with software debouncing entirely and do it all in hardware using that circuit - it's as though all our switches are suddenly 100% perfect! My previous video on a Rotary Encoder (video #19) behaved perfectly using software debouncing (just 5ms) as I demonstrated in that video, so we don't *always* have to use external hardware to debounce switches - just when the occasion requires it and reliability demands it. Are we singing off the same hymn sheet here, I don't want to confuse my viewers?

I think I was in more of a hurry to leave a comment than I was to be sure what I was saying was valid. The truth is that when it comes to debouncing, software debouncing is a dirty way of doing it-at least to me. What I like about it though is that it significantly reduces parts count. Regarding what you are saying about rotary dialers-you didn't say it but in their day automatic phone switching was electromechanical so debouncing wasn’t an issue. By the way, I guess I missed your videos on rotary encoders. I'll make it a point to watch them.

No problem, captxrox, it's a fascinating area with many opinions. It seems the electronics world is split 50/50 about whether it should be hardware or software that sorts out debouncing. My take on this is that if we can do it easily and reliably in software (see video #19) then the job is done. If not, as this video and also video #96 shows, then we need extra help. For the sake of a few pennies we have 100% reliability! And yes, back in the day of gas lamps it was all electromechanical so I guess they didn't know or care about switch bounce. I marvel at how reliable the old mechanical telephone system was!

Believe me, Mina, if I had the time I would do it but I'm currently working on my next two videos which takes all my free time! The best place to get general help in coding is the Arduino forum (forum.arduino.cc) but you must show that you have thought about the issue(s) you are facing and have tried things that did not work. They will not write your code for you, or do your homework (if that is what it is!) but they are very experienced at nudging people like you back on the right path thus overcoming their coding road blocks. Do go there, register and be nice! You will get lots of help, I'm sure.

I have no doubt, Ralph that you would have helped me if you had the time :) but fortunately, I found some work around that fix the issue :)

Glad you found a workaround, Mina, and remember that if you are dealing with String(s) this is an artificial class for Arduino use only (not a standard C++ object at all) and it is just an array of char[ ]. Just bear that in mind :)

I'm not on Patreon, BaselBantam, it's not something I've (yet) seriously considered. Perhaps it will be something to look into if I ever reach the 10,000 subscriber mark, which at the rate I'm going will be in about April 2022! But thanks for offering to support me, it's most appreciated.

Funny you should ask...

Well, Patrick, you must watch my other videos where I look at switch debounce in a myriad of ways, and how to solve the issue (it is a _real issue_ when dealing with a device as fast as a microcontroller). Whilst I solved this issue in software for my Rotary Encoder, I did find hardware solves the problem so much better - it makes the hardware behave in the way we always _assumed_ it was working in the first place! Still, this will be a topic that will run and run as users newly discover the problem and problem-solvers invent ever more imaginative ways to negate that problem!

@@RalphBacon Thank You for the follow up. Having a dug through your hundreds of videos now. Thanks for the resource Ralph!