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.
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.
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.
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.
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.
