This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Most precise way to measure frequency of PWM signal

Hi,

I have to measure the frequency (~100kHz) of a PWM as precise as possible (want to capture positive edges with Timer0(B) in 16-bit mode, up-counting edge time mode).

I'm using a TM4C123GCL launchpad with 80MHz CPU clock settings.

The following code basically works but fails my precision expectations:


// Interrupt handler
void Timer0BISR(void) { TIMER0_ICR_R |= TIMER_ICR_CBECINT; // clear capture interrupt ticksBetweenEdges = TIMER0_TBR_R & 0x0000FFFF; // volatile uint32_t
ticksDelay = TIMER0_TBV_R - TIMER0_TBR_R; TIMER0_TBV_R = 0; // reset counter (only the lower 16-bits are reset when in 16-bit mode) }

// Configuration of Timer0B
void configureTimer0B_risingEdgeTime(void) { // Target: detect positive edges (edge time mode) // Configure TIMER0 (TimerB) capture to measure received PWM signal --> PB7 (TIMER0 T0CCP1) TIMER0_CTL_R = 0; // disable timer TIMER0_CFG_R = TIMER_CFG_16_BIT; // 16 Bit mode TIMER0_TBMR_R = TIMER_TBMR_TBCMR | TIMER_TBMR_TBCDIR | TIMER_TBMR_TBMR_CAP; // set edge time capture mode, count up TIMER0_CTL_R |= TIMER_CTL_TBEVENT_POS; // timer event on positive edges TIMER0_TBPR_R = 0; // disable prescaler extension TIMER0_TBILR_R = 0x0000FFFF; // upper bound for timeout event (for up-counting only) TIMER0_IMR_R |= TIMER_IMR_CBEIM; TIMER0_TBV_R = 0; // reset counter TIMER0_CTL_R |= TIMER_CTL_TBEN; // start timer IntEnable(INT_TIMER0B); // Enable timer interrupt in NVIC }

Can anybody give me some hints how to increase the precision. Actually I have an error of approx. 1,5%.

I also have no idea why I have to mask the TBR register in the interrupt handler with 0x0000FFFF to get the correct ticksBetweenEdges.... I always set the counting value (TBV register) to 0 and the frequency of 100kHz will never overflow at 16-bits.

Many thanks in advance!

BR

Andy

  • Hello Andy,

    The first item to perform is calibration. What is the source of the PWM signal. If you can perform a persistence capture of the PWM signal, do you see edge variation?

    In 16 bit mode the true value of the counter is what is received in the lower 16 bits of TBR register and 23-16 contains the prescalar.

    Regards
    Amit
  • Hi Amit/Andy,

    Amit - you (stole) "Perform a persistent capture of the PWM signal" (likely) right off my (bit slow) keyboard!  Ratz!

    Unstated is how/why poster has such confidence in the stability & accuracy of his input signal.   Should it vary - or be "inefficiently introduced" - what then?

    Our small tech firm supplies a BLDC Motor Controller employed w/in an MRI machine.   The frequency control elements w/in that MRI are w/in a small, shielded, temperature & voltage controlled "oven."  

    Expecting "precision" (w/out its clear definition) from a common/vanilla MCU (and board) may prove a challenging task...

  • Hello cb1,

    No sir, I did not (just bumped my kybd scan rate). Never rule out the source as the likely cause of the issue.

    Regards
    Amit
  • Hi Amit,

    Local constable - here right now - "dusting my keyboard" for prints.    (We're told that "confession" (never denial) reduces time, "in the pen.")

  • Hi Amit,

    Regarding calibration: Of course, this is an reasonable approach. I just wanted to find out, if there is something to improve in my interrupt handler in order e.g. not waste time unnecessarily.

    Regarding TBR register and prescaler: Acc. to the datasheet (TBPR register): 

    In a 16-bit mode, bits 15:0 contain the value of the counter and bits
    23:16 contain the value of the prescaler in Input Edge Count, Input Edge Time, and PWM modes,
    which is the upper 8 bits of the count. Bits 31:24 always read as 0

    --> I do not understand how 23:16 (upper 8 bits of the count) can be different from 0x00, when I never exceed the lower 16-bit capacity because setting TBV = 0 in every interrupt handler call.

    BR

    Andy

  • Hi cb1,

    The input signal comes from a signal generator (not a very expensive one...). I trust this signal because my DSO measures the 100kHz very precise (~0.1% error). But yes, I know this is a cheap board and MCU...

    Do you have experience with the TI C2000 series, regarding timing predictability, programming model, community/support compared to the TM4C family? Would they better fit to measurement & control tasks?

    BR
    Andy
  • Andy are you looking for precision or accuracy?

    Robert
  • Robert Adsett said:
    Andy are you looking for precision or accuracy?   

    Andy - before falling to Robert's bait:

    You are welcome...

    Should (either) accuracy or precision be your (real) goal - my small firm believes (any) Eval board (designed, most always, for low cost) to be NOT, "Good for Gov't Work!"   Instead - search for a "pro" board - see how those (serious) design & produce.   (recall the small oven w/in our MRI machine...that extra design/effort/size/cost is there via true need & intent!)

  • Hello Andy,

    Can you send the a few set of representative values that is being read out for successive edges?

    Regards
    Amit
  • Hi cb1, Robert,

    Well, accuracy is my real goal, precision is already OK.

    As I understand, accuracy is mainly influenced by the oszillator's (crystal) accuracy and the MCU internal delay from rising edge to resetting the counter in the interrupt handler. This MCU internal delay depends on the handler's code which I want to improve. The rest I can calibrate.

    What I really cannot believe: why is an EVAL board not suitable? All of the bare metal boards (launchpads) mainly includes the MCU and a crystal. These components will be the same on PRO boards? Or do you define a PRO board = board with a very precise crystal AND a special real-time MCU?

    BR

    Andy

  • Andreas Kroes said:
    why is an EVAL board not suitable?

    Perhaps the "value proposition" of such Eval Boards warrants examination?    Are these boards designed for "excellence" - for best possible performance - with highest grade & very well investigated (i.e. top) components?    Or...might "cost" be a dominating factor?    And would the "average" user note - or care?

    As a supplier to medical & defense firms - my small firm must "know, care - and jump thru multiple "hoops."    With very few exceptions - Eval Boards (from this vendor and others) could not meet strict "end user" requirements.   And - as stated - that was "never" their intent!

    Next time you "gut" the analog input circuit of a "fine/pricey" scope - note the "absence" of an MCU as, "Analog front-end."   (and not one "eval board" in sight...)

  • Andreas Kroes said:
    Well, accuracy is my real goal, precision is already OK.

    Good, that narrows the items to look at.

    Andreas Kroes said:
    As I understand, accuracy is mainly influenced by the oszillator's (crystal) accuracy and the MCU internal delay from rising edge to resetting the counter in the interrupt handler.

    The factors affecting accuracy will include

    • Crystal (usually 100ppm or so but check).
    • Oscillator, you can get oscillator variation even with a good crystal.  Check the Spec sheet to see if there are any details. Note that loading capacitors can affect the oscillator frequency. An external monolithic oscillator generally does not suffer from this but is more expensive. Note that it would be good to verify the actual rate, possibly via an output PWM.
    • Edge rate and input thresholds. The point you measure on the 'scope is likely not the point the micro transitions at. The slower the edge the less well defined that transition is going to be. Also positive and negative transitions are likely to be different thresholds. You are likely to get better defined transitions with an external clean up circuit before the micro,
    • PLL, generally the jitter from the PLL is just going to give you some noise but check the data sheet to see how large it is.
    • SW overhead. If you are not using a capture timer (I'm not sure if the micro actually has one) then you are limited by latency and processing time. The higher the frequency the worse this will get.

    Another option is rather than measure edge times, count transitions.

    Andreas Kroes said:
    What I really cannot believe: why is an EVAL board not suitable?

    Eval boards are built for, surprise, evaluating the micro. As such they usually emphasize the cheap and cheerful over painstaking high accuracy. I suspect your problem lies elsewhere but keep in mind those limitations.

    Robert

  • Speaking of jitter, do you know how much jitter your input has?

    Robert
  • Let the record show that (now) two have noted the inherent weakness of, "Eval Boards" when accuracy or precision is the goal.   (again this is not a "vendor knock" it is - instead - business reality)

    Kindly record "Vote #2" for capturing a number of signal cycles - and computing frequency from that collection.

    Your board's 3V3 regulator - and any/all common source inductance introduced via power trace routings - also limit.   Again - rarely have such fine details been "sweated" in the design/implementation of Eval Boards.

    Blind faith is sometimes good - but rarely when "accuracy/precision" stand as an objective...

  • Any recommendations for a board with good price-performance ratio similar to the TM4C familiy? There is no demand for medical/military accuracy/stability.

    Many thanks in advance!
  • Hi Robert,

    I started smiling when reading your last sentence (I suspect your problem lies elsewhere but keep in mind those limitations.)... This is also my opinion, because I do not see any jitter in my measured (from MCU timer module) values. So I do not expect to have a precision problem.

    Thank you!

    Andy
  • Hi Amit,

    For 100kHz PWM:

    Debug build: TBR=738 difference between TBV and TBR = 50
    Release build: TBR=752 difference between TBV and TBR = 41

    nearly no jitter in the values (sometimes 1 digit)

    BR
    Andy
  • May we note that you (remain) vague in what "real world values" constitute "accuracy/precision" - and now "good" price performance.

    Such sets you up to be "judge/jury" - not especially enticing.

    Several here have made effort in guiding/assisting you - perhaps (your) investigative skills can (now) be ignited - with results presented here...   (we note that never has your application been revealed - nor performance & cost/size/delivery targets...)

  • Hello Andreas,

    Thanks for the data. It seems that the variation is coming because of the reload. Note that the timer is still counting when a reload is being done. You would need to ascertain that value before reloading so that the it can be added to the overall timing when computing the frequency.

    Regards
    Amit