Noise Picked Up by Counters but not PASM
Duane Degn
Posts: 10,588
I've been experimenting with some optical encoders erco sent me.
I thought it would be interesting to use several different techniques to read the encoder pulses with the Propeller.
The attached code uses three different techniques to count pulses. One is a simple "ina" loop in Spin and another was a similar loop written in PASM. These two techniques report identical numbers of pulses from the encoders.
I also used the Prop's counters to count low to high and high to low transitions. I was surprised to see extreme differences between the number of pulses picked up by the counters when compared with the other two pulse counting techniques.
I found this difference completely went away if I used a clean power line on the encoder. This makes it pretty clear the counters where picking up noise which was interfering their ability to count legitimate pulses.
What I don't understand is what the counters were counting? If they were counting very short pulses, I'd think the PASM loop would pick up a some of these short pulses but it didn't.
The encoder output looked clean on my cheap oscilloscope set to 50us per division.
See the link at the beginning of this post for additional information.
Any ideas of what the counters were picking up?
Edit: I made a small change to the code.
I thought it would be interesting to use several different techniques to read the encoder pulses with the Propeller.
The attached code uses three different techniques to count pulses. One is a simple "ina" loop in Spin and another was a similar loop written in PASM. These two techniques report identical numbers of pulses from the encoders.
I also used the Prop's counters to count low to high and high to low transitions. I was surprised to see extreme differences between the number of pulses picked up by the counters when compared with the other two pulse counting techniques.
I found this difference completely went away if I used a clean power line on the encoder. This makes it pretty clear the counters where picking up noise which was interfering their ability to count legitimate pulses.
What I don't understand is what the counters were counting? If they were counting very short pulses, I'd think the PASM loop would pick up a some of these short pulses but it didn't.
The encoder output looked clean on my cheap oscilloscope set to 50us per division.
See the link at the beginning of this post for additional information.
Any ideas of what the counters were picking up?
Edit: I made a small change to the code.
Comments
The statement is revealing, about how "this difference completely went away if I used a clean power line on the encoder". How was that arranged?
Ground bounce is the small noise signal at the 80MHz clock frequency that is added onto the real signal from your encoder. It can sometimes be minimized by isolating the analog ground, or the whole analog power supply. To see it on a scope, you'd need to be looking at the rising and falling edges of the encoder signal sampled with a few ns resolution, and not only that, it is easy to be fooled by a noisy connection of the ground wire on the 'scope. Imagine the encoder edge as a rough splintered line instead of a nice straight line.
The QuickStart running the program was powered my the USB connection. The servo was powered from a bench power supply set to 5V. When the encoder shares the servo supply while the servo is running, I get the noise problem. When the servo is off or I power the encoder from "Vin" on the QuickStart (USB power) the noise problem goes away. The noise also goes away when the servo is running at (or near) full speed.
I consider this more of a curiosity than a problem since I know I can get a clean signal if the power supply to the encoder is clean.
The QuickStart's ground is connected via a 6" wire to breadboard where the bench supply's power is also connected.
What you said makes sense. If the noise is only occurring at the edges, the PASM loop wouldn't catch the noise spike as being separate from the regular pulse. I had thought the noise would be kind of random and that the PASM loop should at least catch some of the noise.
My logic analyzer can capture at 24MHz. Maybe it's fast enough to catch the noise?
I haven't added any filtering caps to the servo motor yet. I was hoping to understand the differences I was seeing in the counting techniques before adding the filters. I think your explanation satisfies my curiosity enough that I'll add the filter caps on the motor and see it clears up the noise the counters see.
other such artifacts, whereas the raw counters were just detecting separate counts for A and B without relating them to each other?
You can have any number of transistions on say just A, so long as B doesn't change the quadrature count is only going to hover
back and forth between neighbouring counts - if you just count pulses on A alone you'll see all these transitions.
I suspect the origin of the noise was the encoder outputs being rather slow, thus power rail noise would cause the inputs to
chatter between 0 and 1 for a while during the midrail part of the transition (why you often see schmitt triggers used for this
sort of thing).
Any code which reads A and B pins simultaneously won't be fooled unless its running less often than true encoder transitions.
This is why quadrature encoding is used in preference to step/direction, more robust (and easier to generate!).
I a picture of the encoder setup in the other thread (there's a link in post #1)(I just added the same photo to this post). I'm only using one encoder; it's not quadrature.
The transitions look clean on my cheap oscilloscope. The encoder has a built in schmitt trigger but I tried adding an additional schmitt trigger to see if it would help. It didn't.
I'd prefer to use these encoders in pairs in order to get a quadrature output but I'm a bit concerned a second hole in the servo casing could cause structural problems. I suppose I could probably fit a second encoder in the servo but I think I'd need to only use one large black stripe instead of the current two stripes in order to have the second encoder the require 90 degrees out of phase with the first one.
I think there's enough gear reduction from the other gears in the servo to give good resolution even with a single black area on the first gear. I doubt it will be practical to add quadrature encoders to many servos but having position feedback in a continuous rotation servo is something I've been wanting to try for a while.
The schmitt trigger would best be placed close to the Prop pin with short well filtered power supply leads. Anything out on cables or loose wiring can pick up that power supply noise. Sometimes a capacitor of 100pF or so to Vss or Vdd right at the Prop pin can smooth out the rough edge.
How many extra counts did you get, and how does it change if you lower the PLL rate ?
I can see that if the encoder bounces internally (which will be worse with slow rates, and poor decoupling) it could generate double pulses on the edges.
Encoders start out analog, so they need to slice the slowly moving optical signal somewhere, to give the digital one.
If the bounce exceeds the slew-margin, you can get double (or more) pulses.
Above some sampling rate, the Prop will see those double edges.
As you lower the PLL rate, the problem should go away.
You could also try a 40106 schmitt - we had a similar edge-fur issue a while back, where a slower schmitt cleaned up much better than a LVC schmitt. Of course a fast schmitt plus a RC will work, but we found this detail late in the design, and a part-change was much easier than a new board design.
I didn't try a cap that small but it try a 0.1uF cap between the input pin and Vss. It wasn't very close to the Prop though. I think I had a 6" wire between the cap and the input pin.
The counters were picking up about ten bad pulses for every good one at some motor speeds (particularly at slow speeds). When I set the servo to full speed the counter's count agreed with the two other counting techniques.
I didn't try any PLL rates but x16 (5MHz crystal on a QuickStart board).
I had a 0.1uF smt ceramic cap very close to the encoder's Vdd pin. Next time I wire up the encoder, I'll try a different PLL to see if it makes a difference.
Here's a link to the schmitt trigger I used. It looks like Digi-Key doesn't sell them anymore.
I'm pretty sure I'll add a second encoder to make it quadrature. I don't think there's a way to read quadrature encoders with counters (and retain direction information) so I doubt I'll end up using counters in my final application. I was just curious to try a few different ways of counting the pulses with a the Prop and was surprised to see such large differences between the number of pulses detected by the counters and the two other methods I used to count pulses.
I am curious if the extra pulses are on the leading or trailing edge of the pulse. Tracy's post leads me to think the extra pulses are on the back side of the pulse. In which case this next graph won't present a solution.
It looks like the rise time can be lengthened by using a weaker pull-up on the output pin. It doesn't look like much can be done to increase the fall time.
I want to make sure everyone contributing understands, this isn't really a problem for me. It was more of a curiosity. I appreciate your willingness to give me your opinions about what is causing the noise but this isn't a problem that needs solving. I wont be using counters in my final application. Still I do think it's an interesting issue and I would like to understand it (and thanks to the input received, I feel like I kind of do).
That is quite a bit of 'edge fur', certainly enough to be a problem on a Prop 2 running SW counting.
Yes, but it could bite anyone who feeds a slower detector straight into a timer, and has no easy way to check or see the edges.
A RC low pass + schmitt is the most bullet proof noise filter. (it also kills RFI )
The slew between the Hyst points, sets the bounce rate, anything above that cannot pass thru.
A web calc says 10k + 1nF, will have a ~10% hyst window cut off of ~ 1.05us