Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 11 of 11

Thread: Teensy missing Encoder Ticks?

  1. #1

    Teensy missing Encoder Ticks?

    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

  2. #2
    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 by jacko91; 07-17-2019 at 06:48 PM.

  3. #3
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    461
    I usually prefer a sampling scheme instead of using interrupts for high speed encoders. Here a thread with more info showing how to do that for 6 encoders. https://forum.pjrc.com/threads/38736...l=1#post142462. Maybe that helps?

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

  5. #5
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    461
    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 by luni; 07-18-2019 at 01:29 PM.

  6. #6
    Thanks,
    I still have some spikes in the encoder signal messing up my counting.
    Click image for larger version. 

Name:	encsignal.jpg 
Views:	12 
Size:	36.3 KB 
ID:	17023
    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

  7. #7
    Ah sorry, I just saw that the algorithm for decoding is from https://www.mikrocontroller.net/articles/Drehgeber

  8. #8
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    461
    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

  9. #9
    Undestood, thanks.
    One more question to your lib: In the source of the algorithm https://www.mikrocontroller.net/arti...spielcode_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

  10. #10
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    It's a 32Bit CPU. Memory Access is 32Bit, too.

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •