Teensy missing Encoder Ticks?

Status
Not open for further replies.

jacko91

Active member
Good day,
I have 8 motors, each with 2 channel encoders connected to the t3.5 using interrupts. Leading to a total of 68k ticks in a second. I am using the encoder lib from paul. Sometimes I have the slight feeling that the system could miss some ticks. Is 68kHz too much? On the encoder page it is state 100kHz with the t2.0. But since the 8 motors dont fire the pulses well ordered i suppose some could go missing? Inside the encoder library interrupts are not turned off, right? So interrupts should not go missing, right?

Any thoughts on this?
Thanks
 
Okay,
To figure out the problem I minimized the project to just one brushed dc motor. I have a logic analyser hocked up to the encoder lines to measure the true count.
After reading more about interrupts on ARM based chips, I changed the priority of the pins used with the encoder. I use pin 31 and 32. As far as I read the schematics, both pins are PORTB. I am using
NVIC_SET_PRIORITY(IRQ_PORTB, 0); in setup() to set highest priority to those pins.

With a good encoder (ME22 from pwb) I dont have any missing pulses.
When I use a rather cheap one (hall from china), I still miss a couple encoder pulses (around 100 missing pulses, total pulses 60k). On the logicanalyser it counts all the impulses The encoder signal looks good (on oszi as well as on the logicanalyser).
Anything else I can do to ensure every interrupt of the encoder is taken into account.

Another question regarding the priority settings of the PORTs. Will this just affect the GPIOs on the PORT or also the priorities of the peripherals like I2C?

Thanks
 
Last edited:
Thanks. I have tested it on one motor. Looking good so far.
One question: You use the IntervalTimer Library. As far as I understand, the lib uses not FTM Timer but the PIT modules. Are the PIT modules used by any other common library? Y I am asking is, that i have the feeling that the sampling period I set in your begin() function, doesn't seem right.

Thanks
 
Glad it works so far. I don't know all common libs of course but since there are 4 intervalTimers available it is not likely that all are used by other libraries.

i have the feeling that the sampling period I set in your begin() function, doesn't seem right.

The sampling period is directly passed into the intervalTimer so that should be quite precise. Can you show your sketch?

Anyway,
the linked library is just a shallow wrapper around the isrEncoderRead() function. You only need to make sure that you call that function often enough. -> You can use any timer you like or use TeensyDelay or even call it from loop if you want to reduce the dependency on existing resources.
 
Last edited:
Thanks,
I still have some spikes in the encoder signal messing up my counting.
encsignal.jpg
This is the signal in the logic analyzer.
I am wondering if I could filter those spikes with software, not with a low pass but with the logic of the counting algorithm.
As your counting algorithm is quite compact, it is not straight forward to follow. Did you come up with it by yourself or did you use existing ones and if so could you provide your source.
Thank you very much
 
Are you sure that you need to filter that spikes? The algorithm (and probably any other quadrature algorithm) should be immune to those and should just ignore it.
I used the algorithm from this page (german) https://www.mikrocontroller.net/articles/Drehgeber

I also have a Encoder Simulator on GitHub which is very useful for testing. It generates a settable number of quadrature pulses at up to 1MHz count rate including optional bouncing and adjustable signal phase. It does not generate spikes but this could easily be added. https://github.com/luni64/EncSim
 
Undestood, thanks.
One more question to your lib: In the source of the algorithm https://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C it is shown that when reading the counter variable all interrupts are disabled. I assume it is because the int is volatile and is change within an interrupt, and could therefore be changed while reading the counter value, depending how the memory access is handled. Not sure how the memory access is for the arm cortex m4 of the T3.5. Do you know if it is bytewise ?

Thanks
 
Awesome, thank you.
Also concerning the sampling periode I mentioned earlier works great. I checked it with writing a digital pin high every ISR and reading that pin with an digital analyser.
Thx
 
Status
Not open for further replies.
Back
Top