FreqMeasureMutli Teensy 4.1

[jonidohc16v]

Hello everyone,

I'm working on a project with the Teensy 4.1 and I'm using the FreqMeasureMulti library, to get the PWM value from a Servo. But I'm having a little problem, the values it prints in the Serial are not consistant. They are always "glithcing" at least 1 value and I don't even move the servo, like this:
663.45

657.40

661.48

657.40

657.40

655.36

661.48

661.48

653.31

669.65

651.31

The situation is, I used the same code with a Teensy 3.2 and 3.6 and it worked perfectly like I wanted, but with the 4.1 not. So, my question is, is there a bug with the 4.1 or am I doing something wrong.
Here's the code by the way:

#include <FreqMeasureMulti.h>

FreqMeasureMulti Servo1;

void setup() 
{
  Serial.begin(115200);
  while (!Serial); 

   Servo1.begin(22,FREQMEASUREMULTI_MARK_ONLY);

}

float sumServo1 = 0;
int countServo1 = 0;
elapsedMicros timeout;

void loop()
{
  if(Servo1.available())
  {
    sumServo1 = sumServo1 + Servo1.read();
    countServo1 = countServo1 + 1;
  }
  if(timeout > 100000)
  {
    if(countServo1 > 0)
    {
     Serial.print((Servo1.countToNanoseconds(sumServo1/countServo1))*0.001);
     //Serial.print ((((R5ER.countToNanoseconds(sumServo1 / countServo1))-752650)/ 2294.7))
    }
    else
    {
      Serial.print("(no pulse)");
    }

    Serial.println();
    sumServo1 = 0;
    countServo1 = 0;
    timeout = 0;
  }

}

Thank you and I hope that someone can help

[mlu]

Where do you get the input pulses on pin 22 from ? You write the you dont move the servo, something is sending out a pulsed signal ?

You should perhaps discard the first reading since you dont know where in the signal shape the measurements began .

[KD0RC]

Put a print statement in to show timeout as the first statement of 'if(timeout > 100000)'. I think you will find that the if statement is being hit with different values of timeout (all over 100000). Hitting exactly 100001 every time should give you a consistent value, but that is not likely using this scheme. If you set a timer so that count is displayed at exactly 100000, then I think you will be +- 1 microsecond which will translate to however many counts could happen in that time period.

[jonidohc16v]

So, I tried that and indeed the time is hitting 100001 every time and the count is working well, but the values keep not being consistent. I did the same with the 3.6 and it works.
I must be doing something wrong, but I don't know what...

[defragster]

Teensy 4.1 runs loop() many more times per second. It will pull .available() counts perhaps more times per second? Perhaps just one more and one less on alternate timing cycles

This code:

  if(Servo1.available())
  {
    sumServo1 = sumServo1 + Servo1.read();
    countServo1 = countServo1 + 1;
  }

Will be incrementing the value countServo1 each time it is read and that is used in the denominator under "sumServo1" to display the nanoseconds and it isn't clear that would not change the resulting value shown?

Serial.print((Servo1.countToNanoseconds(sumServo1/countServo1))*0.001);

Quick test would be to also print out on each loop : countServo1 on T_4.1 and T_3.6

Also show the raw value sumServo1 on both - maybe that countServo1 should not be in the printed result calc?

[jonidohc16v]

Teensy 4.1 runs loop() many more times per second. It will pull .available() counts perhaps more times per second? Perhaps just one more and one less on alternate timing cycles

This code:

  if(Servo1.available())
  {
    sumServo1 = sumServo1 + Servo1.read();
    countServo1 = countServo1 + 1;
  }

Will be incrementing the value countServo1 each time it is read and that is used in the denominator under "sumServo1" to display the nanoseconds and it isn't clear that would not change the resulting value shown?

Serial.print((Servo1.countToNanoseconds(sumServo1/countServo1))*0.001);

Quick test would be to also print out on each loop : countServo1 on T_4.1 and T_3.6

Also show the raw value sumServo1 on both - maybe that countServo1 should not be in the printed result calc?

Well, I tried what you suggested.
I printed the "sumServo1" and the "countServo1" in all the loops, and it prints this:

6356992 - sumServo1

106 - countServo1

6422528

107

100000 400.15 - timeout and the final value

6422528

107


6291456

106

6356992

107

100000 396.07

6356992

107

And as you may see the value is never constant. I don't know if its the count or the sum or if I'm doing the loop all wrong. Some idea?

[KD0RC]

Hmmm... What type does Servo1.read() return? I see that you have sumServo1 declared as a float. Can all of this be done with int or long instead of float? I am thinking of rounding errors...
Len

[defragster]

Well, I tried what you suggested.
I printed the "sumServo1" and the "countServo1" in all the loops, and it prints this:

6356992 - sumServo1
106 - countServo1
6422528
107

100000 400.15 - timeout and the final value

6422528
107
6291456
106
6356992
107

100000 396.07

6356992
107

And as you may see the value is never constant. I don't know if its the count or the sum or if I'm doing the loop all wrong. Some idea?

It was constant twice in that set: "6422528 107"

> What does the T_3.6 show running that same code?
> Why is the "6356992 - sumServo1 and 106 - countServo1" print twice per summary print?

Also not sure when and how often this returns true?: if(Servo1.available())

Maybe it would be better to sum for 100 counts of countServo1 than for a fixed time ?

[jonidohc16v]

Hi everyone.

So I decided to go with the T_3.6, I couldn't figure out why the T_4.1 wasn't working the same way the T_3.6, probably because that it's a faster processor, I don't know. But anyways, thank you for your advices.
I will try to keep finding a solution to this problem, but since I can't loose anymore time with this, I will go with the good and old T_3.6

Thanks again,
Jonathan Teixeira

[defragster]

Would still be interested to see how the numbers in p#6 look on the T_3.6 ?

it might explain the difference

[KD0RC]

One other thing you can try is setting the Teensy clock speed down to test your theory that it is the faster processor. Go to Tools, CPU Speed and set it down to 150 MHz which will be in the ballpark of the 3.6. I would also try doing all integer additions and only convert to float at the end when you do the division. Float rounding errors accumulate which might be the issue.
Len