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
occurred.
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 =
DWT->CYCCNT"
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.
--
WBW,
V.P.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
