On Mon, 20 Nov 2017 11:47:09 +1300 (NZDT)
Bruce Griffiths bruce.griffiths@xtra.co.nz wrote:

Uh.. uhmm.. sorry about that... I'm electronically challenged, it seems.

		Attila Kinali

--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor

On Sun, 19 Nov 2017 22:56:41 +0000
Angus not.again@btinternet.com wrote:

Oops.. I miscalculated the power consumption of the MV89..
Sorry about.

Today doesn't seem to be a good day for me to answer questions it seems.

		Attila Kinali

--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering.  -- The Doctor

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

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.

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.

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.

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.

I think I found the problem and the solution (partially).
Since I am using capture interrupt which change the value
"on-the-flight" - its appeared that some capture event could happen when
USART doing its work (printing).
So, I put the "lock" there. If USART is already printing, then the
interrupt routine will not change the value. It seems its helps to some
degree. At least I have normal data flow. No strange numbers any more.
However it make me think that I definitely loosing something, when USART
is busy to print.

--
WBW,

V.P.

I'm not sure I understand. If you're building some kind of time interval counter or timestamp counter the duration is only limited by how many digits or bits you allocate to your timestamp. Longer than one second should be very easy.

That sounds fine.

This could be trouble. You'll have to check for timing windows in your code. It's usually better to let counters free-run rather than to start / stop / reset them all the time.

Make sure this assignment is atomic (a single load/store pair, not multi-byte or multi-word instruction sequence); very timer and cpu dependent.

You don't want unresponsive. When you get an event, capture the timer, format your output, and do the serial transmit. Only when that's all finished then re-enable for the next event. This avoids lock-up. And it means your CPU saturates at the point where your output rate is a maximum. So it's self regulating. Note if you do all your event processing in the interrupt handler and cur_tick is not used at main level, you don't have to worry about atomic loads and stores either.

Another way around all of this is to use capture/compare registers. Most uC have this feature. This way your precise timing is not at all dependent on interrupt latency or what language you write in.

One solution is to use h/w timers for the low bits and s/w overflow counters for the high bits. For example a 64-bit counter could be made using a 16-bit timer and a 48-bit overflow count. This is an overflow every 1.6 ms, which is easy to deal with using either interrupts or polling.

Right, if this is just for a GPSDO then you can consider modulus tricks like this. If you're making a more general purpose time interval counter or time stamping counter then you can't rely on that trick. I'm not sure of the context for this thread. It sort of seemed like you were building a counter.

Then again, even if this is a GPSDO I would not want to rely on magic number tricks. What happens if the user decides to change antenna length in order to move the 1PPS by hundreds of us? The magic trick will now cause great trouble. You can avoid that with a FLL instead of PLL version of GPSDO and ignore what look like glitches. But this is now adding hack upon hack. My advise is just implement a 0 to 1.x second TIC. It can't be that hard to do that in a STM32.

/tvb

Bruce wrote:

I think you were right the first time.  Vlad said in his first post that
the input device is a 2N5485 (JFET).

I'm not sure why Vlad designed the input squarer that way.  If the
FET/BJT amp feeds a 74AC gate, which Vlad said it does, the gate is
doing all of the effective squaring.  The discrete components are just
adding noise.  The circuit will have lower noise and jitter if the FET,
BJT, and diodes are left out and the input signal is just cap-coupled
into the gate, with its input biased to half-supply by a voltage divider
from V+.  Note that with AC logic, the gate may oscillate with an open
input and/or no signal, if the termination resistor is too large.  HC
logic is much less prone to this.

A small improvement in the phase noise of this circuit can be made by
filtering the gate input bias divider (well, it could be a larger
improvement if you have noisy power rails...).  This can be easily
accomplished by using a string of four resistors for the divider rather
than two, and bypassing the added nodes to ground with low-leakage
electrolytic capacitors (see attached diagram).

Best regards,

Charles