Encoder precision, poor in atmega328

[DrStein99]

Between the two interrupts available to count the quadrature signals on Atemga328, it is really too much work for this device. I found by adding a quadrature decoder component between the encoder and arduino, i was able to get precision from the highest speed at 24 volts tested with flauhauber micro geared motors with 512 point encoders. These motors were pulled from factory pick and place machines from a wafer production lab.

A quadrature signal simply sends too much information for arduino to keep up with, and have enough time left over to be useful for anything else, and struggles for timing to drive pwm accel curve for the output. With the decoder, it divided the encoder rise and fall edges and produced a common step and direction signal that the 2 interupts had time to handle.

I can not remember which one of the books I have my notes in for the project, after I find it I can show you the part # and some more facts of the test results.

I appreciate your work on the s curve calculation. i was trying (and failing) so much with it myself.

[DrStein99]

Ok I found my book. I used hc7474 flip-flops. The quadrature decoder components were ls7183 ls7184. but I only found them in SMD and they were expensive. The hc7474 cost about nothing. I use them every time I had a hand-encoder wheel for menu on an LCD interface, since the code seemed to bug out and skip without using the flip flops. It wound up work out great on the encoder reader project I tested.

[misan]

Every time I have a choice I mention the very limited processing power of 8-bit Arduino chips, that will struggle if the interrupt rate goes beyond what they can handle. This can happen whenever the encoder resolution/motor speed combine to create more than around 64.000 interrupts/second. For example, if your encoder has 512 slots, it can create 2048 interrupts per second at 60 RPM and it will reach the above threshold at 1875 RPM. I am not sure how you use the flip-flops but I am guessing you divide the encoder pulse by two (that will get you more time for processing each edge). Please note that I am usually processing each edge of the encoder's signals for maximum spatial resolution. But that can be easily changed in the code: https://github.com/misan/dcservo/blob/master/dcservo.ino#L62 by switching the CHANGE (that fires interrupt in both up and down edges) to for example RISING, that action will reduce in half the interrupt rate of the encoder (and angular resolution) with no additional components. There is nothing wrong with adding more components, but I tend to favor the simplest and cheapest when possible. Still, if that were not enough, the code could be changed to only watch one edge of, for example, line A, that will reduce in half, again, the interrupt rate and the angular resolution with no extra components. On the other hand, the so-called blue-pull boards are now actually cheaper than Arduino nano while being powered by an STM32F103, running at 72MHz, which you can imagine will blow away most of the limitations of the 324.

…

On Sat, Feb 2, 2019 at 3:46 AM DrStein99 ***@***.***> wrote: Ok I found my book. I used hc7474 flip-flops. The quadrature decoder components were ls7183 ls7184. but I only found them in SMD and they were expensive. The hc7474 cost about nothing. I use them every time I had a hand-encoder wheel for menu on an LCD interface, since the code seemed to bug out and skip without using the flip flops. It wound up work out great on the encoder reader project I tested. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAccyEgPUrpTEdZAZZ--fv51H7VuUUOxks5vJPv0gaJpZM4ad3bJ> .