Scanning encoder debounce on new scope

SOLVED: Had probes set on AC coupling instead of DC coupling. D'OH!


I am scanning an EC11 rotary encoder wired according to Bourns debounce design using a Owon SDS1104 scope:

R1 = 10K
R2 = 10K
C = 0.1uF (Bourns uses 0.01uF)

https://www.bourns.com/docs/technica...rsn=348415eb_4


This is what the scan looks like:

https://i.imgur.com/09H7TXe.png


The peak voltage slowly drifts up as I turn the encoder, and then settles back down. That is not the problem.

I'm concerned with the low voltage, it's also drifting up, well above the 0.8V threshold that is often referred to in Microchip documentation as the LOW level. The 10 or so encoder signals on the right would not get picked up.

Is this normal with RC circuits?

Or is the graph on this $250 DSO drifting north because it's low quality?

I'd be more worried by the fact that signal swings negative and not positive :-)
Don't worry though, it looks like you have the input coupling set to AC on the scope. Set it to DC and try again.

Quote:

---

Originally Posted by HenrikOlsson

... Set it to DC and try again.

---

Thanks! I thought of rechecking my stuff a Nth time yesterday and noticed the coupling too.

All is well in the world.
:biggrin:

Attachment 9674

Got this from AllAboutCircuits. First time I hear about a MC14490, Hex Contact Bounce Eliminator:

https://www.youtube.com/watch?v=BeFYsx6M3BM


Too bad it's in multiples of 6 pins. It would be perfect if it was 8; that way I could have 2 ICs running alongside MCP23017 I/O Expanders with no waste.

Wow, I designed those into counting circuits about 45 years ago.....

Nice chip! I did not knew that one although I am of the CMOS era!

Anyway, since you master the art of software, I think is waste of money to add hardware when you can debounce in software.

Plenty of ways to do that and as you said, going into production, will save you a lot of money and complexity.

One example. Read all buttons in an array. After a period of say 10ms, read again and compare all the buttons. One pass, reading and debouncing all buttons.

Ioannis

Quote:

---

Originally Posted by Ioannis

Nice chip! I did not knew that one although I am of the CMOS era! ...

---

I also found the MAX6818 debouncer, but it's $4.37 for 8-bit at JLCPCB.

Quote:

---

Originally Posted by Ioannis

... since you master the art of software, I think is waste of money to add hardware when you can debounce in software. ...

---

More like master of none. :wink:

Quote:

---

Originally Posted by Ioannis

... One example. Read all buttons in an array. After a period of say 10ms, read again and compare all the buttons. One pass, reading and debouncing all buttons.

Ioannis

---

I might still go for that. But I'd really like to avoid any debounce on the PICs so they are free to USART with the main USB PIC.

Quote:

---

Originally Posted by Demon

I might still go for that. But I'd really like to avoid any debounce on the PICs so they are free to USART with the main USB PIC.

---

This can work just fine:

1. Set up a timer interrupt at 10ms. Or even at 1ms and after ten int's do step 2.

2. Every interrupt read the buttons into the arrays. You can use a low priority interrupt if the PIC supports it.

3. Either with or without interrupt use the hardware USART to communicate. If you choose interrupt driven USART, use it as high priority, or Disable as long as you do serial, the timer interrupt.

Problem solved.

Ioannis

I wanted to see just how sharp a Schmitt trigger could clean up a signal.

This is using a MR0102 with rocker actuator, followed by the Bourns RC debounce circuit, and then inverted with a TCC74HC14 Schmitt trigger, followed by LED/330R resistor:

Attachment 9678

(text on image has been corrected)


Datasheet says negative threshold is 1.6V at 4.5V. This is USB 5V, so 1.8-1.9V seems ok to me.

What a magic tool Oscilloscope is, right?

Ioannis

Darn tootin' right.

It's nice to finally use it as a diagnostic/testing tool. The scope has always been a mystery to me. I've always wanted to use one, but never had any electronics training. So it's slow; getting old and a worsening memory doesn't help, but help from you folk make it fun.

One thing is for sure, I wouldn't hire me to do this stuff. :D

Your waveforms seem to indicate that you might benefit from adjusting the trimmer capacitor on your probe(s).

Quote:

---

Originally Posted by HenrikOlsson

Your waveforms seem to indicate that you might benefit from adjusting the trimmer capacitor on your probe(s).

---

I noticed that "rhythmic pulse" too. I figured it might be the breadboard.

I wanted to enjoy my scope for a few days before tweaking it and messing it up.
😄

OK, if you just want to see squiggly lines on the screen :-)
But you're not going to mess it up. It's part of verifying that it actually works as it should.
Compensating the probe, or at least veryfying its compensation, should ideally be done whenever you move a probe from one channel to another - which is another great reason to use the color coded rings on the probes so that the same probe gets used on the same channel each time.

Without a properly compensated probe your scope will not display a "true" representation of the waveform and things like automatic risetime and peak-to-peak voltage measurements might be incorect.

I'm sure there's a section, close to the beginning, in the manual on how to perform the probe compensation.

So I finally got around to compensate each probe (in their colour-coded connector, just in case that matters). Also auto-calibrated the scope; very straight-forward.

Before/after compensating:

https://i.imgur.com/UNGj1Rv.jpg

https://i.imgur.com/LIxmUAA.jpg

Before compensating, the probes had a slight up-tick/down-tick when changing edge:

https://i.imgur.com/Db9URoS.jpg


That is now gone, so I must have done something right:

https://i.imgur.com/qShLrP2.jpg

Yellow, encoder A
Blue, encoder B
Beige encoder A after Schmitt trigger
Green encoder B after Schmitt trigger


But there is still some static that cycles through at a regular rhythm. Here it is at a slower rate so it's more apparent:

https://i.imgur.com/G2U5Jub.jpg


This could just be an artifact on the USB port (have that static on PC USB port and external hub). I'll have to test on another 5 VDC power source.

Quote:

---

But there is still some static that cycles through at a regular rhythm. Here it is at a slower rate so it's more apparent:

---

would your mains power be at 60Hz ?
hint 16.667mS

the A B debounce looks very uneven between rising and falling edges. the unequal phase shifts so introduced will make R.E data interpretation interesting, especially at varying rotational speeds

Do you have any Switch Mode Power Supplies, either 5Volts or other?

The noise might be because of that. If it is on a specific pattern and rate then something else cause this. Either clock, interrupt or as you said USB action.

Critical decoupling may come to rescue. Also earthing correctly also may help.

Ioannis

ARGH.... I finally found out what is that regular noise, the probes reset to AC coupling. I haven't looked in the manual yet if there's a way to save the current setting as Default.

https://i.imgur.com/yLH7sEn.jpeg


About the uneven edge spacing, it's mostly the A wiper (yellow) that varies a LOT. B wiper seems to remain stable on average (sometimes it gives a longer intermission, but nothing as radical as A wiper).

I don't know if it's me that damaged the rotary encoder, or if it's "cheap" that way. I turned it countless times both directions, and I don't find a pattern.

If I turn CW and get a long intermission, I turned 2 clicks CCW, then turned again CW, but didn't get the long intermissions again.

I moved the posts here from the SDS-1104 review thread.

Quote:

---

Originally Posted by HenrikOlsson

Your waveforms seem to indicate that you might benefit from adjusting the trimmer capacitor on your probe(s).

---

Yup, waveforms are cleaner now.
:cool:

Quote:

---

Originally Posted by Ioannis

... Anyway, since you master the art of software, I think is waste of money to add hardware when you can debounce in software.

Plenty of ways to do that and as you said, going into production, will save you a lot of money and complexity....

---

I know. But I haven't started coding yet and don't know exactly how burdened my processors will be. I prefer to start with hardware debounce, and then see as I advance. It's a lot easier to take stuff off a PCB, than to add it all later.


...insert drum roll and trumpets here...

I present to you, the Encoder Driver v1: 24 encoders, 1 switch, debounced according to Bourns, inverted via 74HC14 Schmitt triggers, in a 30mm x 160mm vertical package. I have 180° pins on the design, but it'll be 90° pins on the final product.

https://i.imgur.com/2xJ1IlG.png

Hmm, too many wires to connect switches and encoders. Have you thought about that? For a production this is very time consuming.

Ioannis

No more wires. It's unrealistic.

I changed to a single main board for all switches. The ADC, MCP (switches and LEDs) and encoder drivers will be placed around the perimeter with headers.

So now I'm down to just soldering the switches, pots and encoders.