For the micrometal encoders, do I really need signal process

Hi!

I was hoping to make use of some of the $8.95 optical encoders. pololu.com/product/2591/blog

I am trying to figure out the simplest way to process the signal for my board.

I am using a teensy 3.1, which is a fairly capable 3v3 32-bit 96mhz arduino-ide-compatible board.

My plan is to simply attach the signals to interrupt pins. Although the signal from the board is analog and sine-y, it still ultimately only crosses once per signal moment. So I assume for general usage of the encoder, this may be sufficient.

Are there any problems I might be missing? For some of pololu products there are more “application note” sort of documents to clarify the situation. For example, there are some great notes on the DC motor about noise suppression. In this case I can’t tell how essential signal processing is.

Thanks,
-Tomek

I should add that I don’t really need directional information on my signal. So it doesn’t have to be perfect in that regard.

[quote]it still ultimately only crosses once per signal moment[/quote]Not true if there is electrical noise on the line.

[quote]In this case I can’t tell how essential signal processing is.[/quote]No one else will know, either. You will just have to experiment.

Hi, Tomek.

I connected those encoders directly to a Teensy 3.1 on a dead reckoning robot, making use of the Teensyduino Encoder library, and it seemed to work fine. I didn’t check particularly carefully whether/how often I was getting spurious or missed counts, but in the end, my robot essentially worked as I expected it to. I think it’s likely you’ll be able to use them without any intermediate signal conditioning.

- Kevin

Hi Jim, that’s a decent point. Do you advise any particular minimal ways to process the signal? I could add a tiny amount of capacitance if that would help remove high freq noise, if that’s a problem. I could have a weak pull-down, if that would help make the signal more explicit.

I found this stackexchange: electronics.stackexchange.com/qu … r-readings but it describes mostly suggestions for software fixes, and the problem is more about vibrations triggering increment signals when not moving (which is not an issue, I can make my response deal with that.) If I’m running an interrupt routine I want to avoid complicated software algorithms, and I would worry my implementation would be liable to not work well.

[quote=“kevin”]Hi, Tomek.

I connected those encoders directly to a Teensy 3.1 on a dead reckoning robot, making use of the Teensyduino Encoder library, and it seemed to work fine. I didn’t check particularly carefully whether/how often I was getting spurious or missed counts, but in the end, my robot essentially worked as I expected it to. I think it’s likely you’ll be able to use them without any intermediate signal conditioning.

  • Kevin[/quote]

Hi Kevin! Thanks. It is encouraging that you have had some success using them on a similar platform. My application has some importance to not missing more than 0.01% of the counts over a large number of counts, but I guess that’s a pretty big number. What’s even more, I realized that I’m using a stepper motor and so in reality I can somewhat rely on the step-count, with the encoder verifying I don’t have catastrophic failure. W/ the steppers and my application it’s pretty much that I either don’t skip any step, or skip and then fail all future steps. Except w/driver overheating [which can occur,skip steps, then recover], but I’m connecting to the FAULT pin on the DRV8825, so I should be able to monitor that.

[quote]Do you advise any particular minimal ways to process the signal? [/quote]That would depend entirely on the noise to be removed, if required. If you have access to an oscilloscope, simply look at the signal lines when the device is operating normally.