Too slow for Input Capture? 1Hz

[john doe]

Posted on July 19, 2017 at 14:17

Looking to measure duty cycle of a pin where I'm looking for a pulse anywhere between 200miliseconds and 800 miliseconds on a 1Hz period. I think I used the terminology correctly, sorry if I didn't. Much of the time, the pin could be ringing with a lot of noise, rather than a good solid pulse. It is a WWVB receiver/decoder.

It seems like the counters might be rolling over before my input period ends, so I would have to slow down the clocks. I think.

I could probably just use GPIO and external interrupts, and simply count ticks between them.

Your thoughts?

[andy b]

Posted on July 19, 2017 at 14:40

Hi John

I don't see any problem in using input capture but since it seems like your timer is timming out too early you should increase the timer's prescaler to make it count slower.I don't think using GPIO's is a good idea (especially if you are looking for a certain level of precision) since stm32's GPIO are pretty slow and depending on the activity of other peripherals their speed of response can change.If increasing the prescaler isn't enough to slow down your timer you can then reduce the APBX clock speed.(where X is the timer bundle in which your timer is, you can find that info in the datasheet)I encourage you to calculate your timer and prescaler values properly.Take the time to make sure they will work.Try and error is not really the way to go.Hope this helps-Andy

[S.Ma]

Posted on July 19, 2017 at 14:55

HW edge measurement in msec is non stressful for MCUs. If the granularity of the measurement is in 10-20us units, you can run a free running timer with at least 1+ second roll over period, and use EXTI or Input Capture to take more precise snapshots of the timer. Timer overflow is a non issue, if the rising edge is detected at timer 0xF000 and the falling edge is captured at 0x1000, the pulse high level will correctly be calculated with 0x1000-0xF000 (16 bit sub) will yield 0x2000

[waclawek.jan]

Posted on July 19, 2017 at 15:10

You also can set a filter on the timers inputs, see ICF field in TIMx_CCMRy register.

JW

[john doe]

Posted on July 19, 2017 at 14:53

Thanks. I havent written any code yet, I'm just looking at this flashing LED and pondering how to read it.  I've never used input capture so this will be a fun exercise. Thank you for confirming I'm on the right track.

[Tesla DeLorean]

Posted on July 19, 2017 at 23:51

I've done GPS 1PPS with STM32 parts, preferably you'd use a 32-bit TIM, but failing that a seriously prescaled 16-bit TIM.

Alternatively, have an EXTI interrupt reading the DWT_CYCCNT as a free-running 32-bit time stamp, with the granularity of the CPU clock. 

[john doe]

Posted on July 20, 2017 at 02:53

>Alternatively, have an EXTI interrupt reading the DWT_CYCCNT as a free-running 32-bit time stamp, with the granularity of the CPU clock. 

This seems to be the one I understand the most.

Set timer running

  get interrupt from rising edge - read timer count register to start counting

  get interrupt from falling edge - stop counting. start register - end register  == duration im trying to find

With input capture, am I understanding things correctly?

   Input pin goes either high or low depending on what polarity you wanted

   a timer/counter is triggered to start

   Input pin state changes

   timer/counter stops

[S.Ma]

Posted on July 22, 2017 at 05:13

The value will be in timer clock unit. It depends on the timer clock prescaler value. If not sure, send a known periodic pulse to make sure. Also as extra, increment a 16 bit variable on timer update interrupt. This way, you can manage longer time periods, or skip this small effort or add it after long debug time...

[john doe]

Posted on July 22, 2017 at 04:30

ok 32 bit timer free running

read the counter register on rising edge and falling edge, take the difference

do I divide that by APB1 speed to get milliseconds?

[Vangelis Fortounas]

Posted on July 22, 2017 at 19:59

Hello John

The key to take the advadage of using the atomic clocks transmitting the time over the air (WWVB), is to catch the exact edge  when

minute

is changing. So you can synchronize your rtc equipment (also for cryptographic use) or calculate your rtc calibration coeficients.etc

In case you want to decode the signal  and to take the full clock signal(date,time and not the crucial minute edge only)you need at least a timer with more than 1 minute rollup counter. (preferable 32 bit counter (no presc)  but no mandatory). Capture all edges and levels and after try to decode them according the protocol the station transmits.

Practicaly: use an apropriate receiver  , put hardware LPF filter(optional, this introduces delays)   pass the signal from a schmitt trigger gate(you can use internal filters carrefully adjusted) and feed it to input channels 1 and 2 (or others) of a hi res timer running.

In channel one just capture the rising edges, and in channel two capture the falling edges, save the captured  values.

(opt DMA)

Debias(or not) the captures and you will have all the information you need to work with.

After the last pulse falling must reset the counter to zero and wait for the first pulse again.(so you will lost the first pulse that has standard width)

This means that you must wait for a minute to take all the info about clock, date, etc)

If you dont want to wait  a minute to take the values you may make a state machine code and run a loop every pulse received(more complicated).

The pulse width generaly can be calculated by subtracting CCR2  from CCR1 on every CCR1 interrupt (remember we measure low state pulse width).