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

Thread: FreqCount caution

  1. #1
    Member
    Join Date
    Aug 2019
    Location
    southwest USA
    Posts
    50

    FreqCount caution

    after running several hundred cold starts the 100% safe thing to do is on FreqMeas, delay for 40 microsec just after ...begin AND do two dummy cycles before real measurements,
    this only costs about 52 microseconds

    similarly on FreqCount, do one dummy meas cycle before real measurements (i knew the TLC usually needed this) in my typical application this really has no cost because i just start
    my FreqCount loop one time interval early, loop one more time than required, and when pulling results out of the array later just start w index one higher than i would have

    in my typical applications these work-arounds are simple and do not stop the show

    these cautions are applicable to the TeensyLC and Teensy4, and i have not tested Teensy 3.6, and cannot test any others
    i am not sure how to link threads so i will start a new one w this same content titled FreqCount caution.

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,958
    There is an open thread on this :: pjrc.com/threads/58026-Teensy-4-FreqMeas-problem

    There may hopefully be a way to fix this in the FreqMeas.begin() - pjrc.com/threads/58026-Teensy-4-FreqMeas-problem

    Links for any post can be had with 'right click' on the "post #" hyperlink for that post.

    Links can be included with Ctrl+L - or clicking the "Globe Icon with 'chain link'" shown on it - then fill in the link and hit Enter.

    Not sure starting this extra thread until above linked thread gets attention/resolution is the best?

    And AFAIK the easy way to discard the first erroneous readings is posted on that thread:
    Code:
    FreqMeasure.begin();
    delayMicroseconds(15);
    while (FreqMeasure.available()) FreqMeasure.read();

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,958
    Post #2 code does not work … now with second thread it requires editing in two places … Teensy-4-FreqMeas-problem

    … code like this actually resolves the issue:
    Code:
          FreqMeasure.end();
          FreqMeasure.begin();
          {
            while (!FreqMeasure.available());
            int yy = 0;
            while (FreqMeasure.available() || yy < 2 ) {
              if ( FreqMeasure.available()) {
                FreqMeasure.read();
                yy++;
              }
            }
            Serial.print("\t\t DISCARD INITIAL READS #=");
            Serial.println(yy);
          }

  4. #4
    Member
    Join Date
    Aug 2019
    Location
    southwest USA
    Posts
    50

    confused

    Quote Originally Posted by analog&RFmodels View Post
    after running several hundred cold starts the 100% safe thing to do is on FreqMeas, delay for 40 microsec just after ...begin AND do two dummy cycles before real measurements,
    this only costs about 52 microseconds

    similarly on FreqCount, do one dummy meas cycle before real measurements (i knew the TLC usually needed this) in my typical application this really has no cost because i just start
    my FreqCount loop one time interval early, loop one more time than required, and when pulling results out of the array later just start w index one higher than i would have

    in my typical applications these work-arounds are simple and do not stop the show

    these cautions are applicable to the TeensyLC and Teensy4, and i have not tested Teensy 3.6, and cannot test any others
    i am not sure how to link threads so i will start a new one w this same content titled FreqCount caution.
    i am confused by post 2 and 3 - the whole reason i created "FreqCount caution" was to call attention to the FreqCount funny
    whereas post 2 and 3 focus on FreqMmeas which maybe belong under "teensy4 FreqMeas problem?" ???

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,958
    Quote Originally Posted by analog&RFmodels View Post
    i am confused by post 2 and 3 - the whole reason i created "FreqCount caution" was to call attention to the FreqCount funny
    whereas post 2 and 3 focus on FreqMmeas which maybe belong under "teensy4 FreqMeas problem?" ???
    Opps :: More confusion here it seems - was rushing to do some things and conflated Freq Count and Measure.

    However - quite possible a similar problem and solution apply as they both rely on "count - count_prev" to return the desired value.
    And both do .begin() in effect with :: count_prev = 0;
    Code:
    uint32_t FreqCountClass::read(void)
    {
        count_output = count - count_prev;
        count_prev = count;
        //Serial.println(count - count_prev);
        count_prev = count;

  6. #6
    Member
    Join Date
    Aug 2019
    Location
    southwest USA
    Posts
    50
    i agree, however, i have glanced thru the library files and can only say - way above my pay grade.

    i think you or some other professional programmer will have to tackle that.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,958
    Not sure if there is a way at .begin() to get a true start value synchronization? I found something close - but it is uniformly off and stays that way once I hack it.

    I'm not up for reading the book to understand operation just now - just into my outdoor summer chores - and fall is about a month gone.

    Maybe just need to add a .flush() with a timeout to get the initial 2 reads after .begin():
    Code:
            {
            int yy = 0;
            while ( yy < 2 ) {
              if ( FreqMeasure.available()) {
                FreqMeasure.read();
                yy++;
              }
            while ( FreqMeasure.available()) FreqMeasure.read();
            }

Posting Permissions

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