2024-01-25 10:21 PM
I am am trying to assess the accuracy of the input capture measurements by capturing a stable periodic pulse, setting the output compare on another channel of the same timer to the measurement, and then measuring the offset on a scope. It appears there is a pretty consistent 25ns lag in the input capture measurement.
What primarily drives the lag and should/can this be calibrated out?
Solved! Go to Solution.
2024-01-26 04:46 PM
There is a resynchronizer circuit on the input figure 2 - 3 flop-flops in a chain.
It's going to add delay, and behave like a nyquist sampler.
I think it's off the TIMCLK, 120 MHz ?
2024-01-25 11:24 PM - edited 2024-01-25 11:26 PM
You connect pwm output with a wire to capture input pin - right ?
Then the external signal is going to input filter and is synchronized to the internal timer clock.
This needs minimum 1 clk.
see rm , timer x :
2024-01-26 12:51 AM
Hello @Tkmn
As @AScha.3 already mentioned, this lag could be primarily driven by the filter value set in the CCMR1 register.
Incorrect filter values can cause a delay in the input capture measurement, you can manually modify the register to set the correct bit.
Please note that this might not be the only factor (configuration of the timer, the clock speed,.. )
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-01-26 03:40 AM
> and then measuring the offset on a scope
Offset of what against what?
JW
2024-01-26 06:35 AM
> setting the output compare on another channel of the same timer to the measurement
Details matter here. How are you doing this exactly?
I wouldn't expect a 25 ns lag on IC.
2024-01-26 09:22 AM
I was not expecting 25ns either....
Hardware wise, I am running everything off of a GPS disciplined oscillator. So HSE is on 10MHz and I am capturing 1PPS off of the same DO so the input capture value is extremely stable.
I have configured TIM2 with a 240MHz clock rate to update once a second. I input capture 1PPS (rising edge) on channel 1 and then I set the output compare value on channel 4 (polarity low to high) to be equal to the input capture value. When I compare the rising edge output of channel 4 to the rising edge of 1PPS input on channel 1, I always observe a 25ns delta.
I can play with the filter configuration as suggested but I suppose I was expecting this to be maybe 1/480MHz or 1/240MHz and I'm not sure what is driving the additional delta.
2024-01-26 10:10 AM - edited 2024-01-26 10:13 AM
When you look at the 25ns delta on the scope between the two edges, you're looking at the current TIM2_CH1 edge (from the GPS) vs the previous IC value that was captured and sent to TIM2_CH4 from the previous second. To me it seems like you have ~25ns drift over 1s.
I may be misinterpreting the details a little, but it does feel like you're comparing edges from different things.
This would be a good test to determine the same thing: Hook up TIM1_CH1 and TIM1_CH2 together, set CH1 to be IC and CH2 to be a PWM and see if the IC value exactly matches the programmed PWM value.
2024-01-26 10:17 AM
GPIO pin driving strength?
FYI, Timer's input capture pins as any general GPIO pins, have logic synchronization module, so they always jittery - depends on system clock derived to GPIO bus.
There is LPTIM that possible 'd be driven externaly, I have not tested yet it's functionallity
2024-01-26 04:06 PM
I am seeing the same issue when I loop back. For example when I set output compare of CH4 to 1000 and I feed it into my CH1 input capture, the input capture is 1008.
This is on the Nucleo... I'm not sure that there is any hardware that would cause a line delay in between but I can check filtering next. I never messed with the filter settings in the register. I assumed the default was none but not sure.
2024-01-26 04:34 PM
My CR1 value is 129 and my CCMR1 value so I think it should be sampling at 240MHz and not applying filtering. I can try to increase the rate to 480 MHz to see if it halves.