[time-nuts] Input filter for data logger
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
I'll need to experiment with this. I think the drawback cold be for the
signal with long pulse width (more than one second).
>> 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