[time-nuts] Input filter for data logger

Vlad time at patoka.org
Sun Nov 19 21:12:16 EST 2017

> Assuming the STM32 is set to trigger on the rising edge, a 2x output
> will occur if there is bounce from a falling edge. Normally this is
> not desirable, but there are cases where measuring both rising and
> falling edge improves resolution. For example I have a version of the
> picPET that timestamps both edges (this gives you pulse width and duty
> cycle information). The CNT-91 counter also does this in raw timestamp
> mode.

I'll need to experiment with this. I think the drawback cold be for the 
signal with long pulse width (more than one second). 

>> 26.5837255
>> 26.23559295
>> 26.5941842
>> However, it is some "spikes" in the data flow (see above the number
>> "26.23559295", which suppose to be something as "26.58..."). I can't
>> understand the reason for that.
> That's a software problem for sure. Do you use interrupts? Or some
> library code for formatting and output?

STM32 has an internal counter which counting MCU ticks (I clocked my 
stone by 40Mhz. So, it will be 40 mln. ticks per second). I am using 
this ticks number to get microseconds as signal capture event has 
My other timer generate interrupt each second. This is used to start 
count the microseconds over again. So, its pretty simple.
I'll need to dig this issue deeper, since its occurred only when I was 
using DDS generator as a signal source. I know DDS chips sometimes 
generates some spurs. But not sure if this is related.

> It sounds like you have two problems: 1) h/w signal conditioning
> before the STM32, and 2) a s/w timing issue in your code or in how you
> use the USART. To separate them, try a clean square wave directly into
> the STM32 over a range of frequencies from slow to fast to faster than
> the STM32 can keep up.

If I raise the input freq. to 1Mhz, the STM32 become unresponsive, since 
number "capture" interrupts is too high. The signal capture interrupt 
routine doing nothing more than one assignment : "cur_tick = 
Which means that I am getting current number of ticks.
USART will print the number as event will be detected. The speed is 
115200. And I am not using interrupt for this.

> BTW, the good news is that your time stamping output looks like the
> picPET -- http://leapsecond.com/pic -- which means that you can use
> TimeLab to directly capture and/or display all your data (phase,
> frequency, adev, etc.).

I think I'll need to order few picPETs to use them as a reference for my 
project. Let me know if you could ship to Canada.

> As an example, the old PIC I'm using is limited to 125 samples per
> second (mostly due to RS232 transmit time at 19,200 baud), but with an
> 8-bit event count you can directly measure frequencies up to 256 times
> greater (32 kHz). With a 16-bit event counter that number climbs to 8
> MHz. All this without a pre-scaler.

I was try to use DMA to keep counter value. And then I was counting 
number of overflows. However, I noticed this is more complex 
computations is necessary to get microseconds from this comb. STM32F103 
has no 32bit timers. Using 40Mhz clock, I can't go low than 610Hz 
without some tricks, like using pre-scaler or cascading the timers. I 
tried those methods but results was not impressive. Probably because of 
my software implementation. I am using DMA and other timer to capture 
1PPS events. It works OK for me. But in that case I just need one 
number. Which ideally should be 23040 in my case (40000000 % 65536 = 
23040). I don't care about number of overflows and anything else in this 
case. If I am getting something different from magic number - its time 
to tweak DAC to control OCXO.



More information about the time-nuts mailing list