Look at the falling edge of your square wave - I'd guess there is some
undershoot and it's triggering the extra counts. With the back to back
limiting diodes in that circuit, I don't think the ringing shown in your
scope trace will matter, however, ringing around the 0V level will matter.
I've seen similar with HP 5335A and 5370A counters with inputs set to DC
and the level pots set to preset. Change it to AC, or tweak the level pots
and the problem goes away.
You can probably see the effect on the scope by setting the trigger level
somewhere around 0V - sometimes it will trigger on the rising edge and
sometimes on the undershoot on the falling edge.
On Sun, Nov 19, 2017 at 8:40 AM, Vlad time@patoka.org wrote:
Hello,
I am doing another fun project. It is data logger at this time. The
"heart" is MV89A OCXO and the "brain" is STM32.
"The box" has 1PPS input to control DAC which will control OCXO. BTW, this
M89A is pretty hot to touch. My other OCXO's not that much warmed. Is it
normal for this Morion model ?
I woul ask an advise regarding following issue. I have signal generator
which produce the square wave. The freq. is 192Hz.
http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104659813.jpg
However, the logger measure it TWICE ! I think its because of that signal
form. Here is the output (in microseconds):
http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104838190.jpg
In average delta is .0026041 s, which is almost equal to 384 Hz (192x2)
For the input I am using the schema similar as HP was using in one of
their counters:
http://www.patoka.org/OCXO/LOGGER/IMG_20171110_123201987.jpg
I tried another source (DDS sine generator, referenced from GPSDO) and
that beast produce exact number of events:
26.5404621
26.5473008
26.5525067
26.5577297
26.5629260
26.5681280
26.5733305
26.5785262
26.5837255
26.23559295
26.5941842
26.5993546
26.6045699
26.6097716
26.6149911
26.6202076
26.6254149
26.6306244
26.6358103
26.6410386
26.6462491
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.
The "delta" is .0052 s, which is almost equal to 192 Hz. But data flow is
not that "smooth" though.
In square wave mode, "school grade" Wavetek generator produced exact 192
events with no issues. (Except its output frequency is not that stable)
21.0578286
21.0630547
21.0682807
21.0735070
21.0787330
21.0839591
21.0891852
21.0944112
21.0996372
21.1048632
21.1100892
However, if I switch Wavetek to sine, my logger detected twice number of
event (384)
97.0185559
97.0214570
97.0237852
97.0266822
97.0290048
97.0319054
97.0342336
97.0371408
97.0394552
97.0423578
97.0446802
97.0475836
97.0499131
97.0527969
97.0551313
97.0580259
97.0603560
97.0632648
97.0655869
I would assume, some improvement needs to be done for the data logger
input. I am using 2N5485 and 74AC04 elements there. Any advises will be
appreciated ! Thanks !
--
WBW,
V.P.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/m
ailman/listinfo/time-nuts
and follow the instructions there.
On Sun, 19 Nov 2017 11:40:27 -0500
Vlad time@patoka.org wrote:
I am doing another fun project. It is data logger at this time. The
"heart" is MV89A OCXO and the "brain" is STM32.
"The box" has 1PPS input to control DAC which will control OCXO. BTW,
this M89A is pretty hot to touch. My other OCXO's not that much warmed.
Is it normal for this Morion model ?
The MV89 is a beast of an OCXO and uses more power at warm-up than any other
I know of. But it is spec'ed ~1W for steady state. Which means the
outside of the OCXO should be about hand-warm. If it's too hot, then
the heater circuit is probably broken and running at full-throttle.
I woul ask an advise regarding following issue. I have signal generator
which produce the square wave. The freq. is 192Hz.
http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104659813.jpg
However, the logger measure it TWICE ! I think its because of that
signal form. Here is the output (in microseconds):
http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104838190.jpg
In average delta is .0026041 s, which is almost equal to 384 Hz (192x2)
For the input I am using the schema similar as HP was using in one of
their counters:
http://www.patoka.org/OCXO/LOGGER/IMG_20171110_123201987.jpg
Can you show us what your circuit looks like instead of some bad
(literal) screenshot?
But guessing from what you showed, I would say that your amplifier
circuit isn't stable and has some gain peaking at around 10MHz.
There are two ways to proceed: Either optimize your circuit or
simplify it using modern components to the input signal you expect.
I personally, would go for simplification, unless you want something
special.
If you only want to time-stamp input pulses and you can ensure
that those pulses are between 0 and 5V, then I'd use a 74LVC1G34
or 74LVC1G04, depending on whether you want inversion or not
(do not use the 74LVC1G14 as the hysteresis will increase the noise level)
If you want to measure sine input as well, then you have to AC
couple and add some bias voltage when using an LVC gate.
--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson
Hi
Based on what I’ve seen off of eBay, a properly working surplus MV89A is a rare beast. The
ones that are “ouch” to the touch do indeed have malfunctioning oven circuits. Out of a few
dozen purchased I don’t think I found one that fully met the specs that it did when shipped.
That easily could have been a function of only buying from the cheapest sellers …..
Bob
On Nov 19, 2017, at 11:40 AM, Vlad time@patoka.org wrote:
Hello,
I am doing another fun project. It is data logger at this time. The "heart" is MV89A OCXO and the "brain" is STM32.
"The box" has 1PPS input to control DAC which will control OCXO. BTW, this M89A is pretty hot to touch. My other OCXO's not that much warmed. Is it normal for this Morion model ?
I woul ask an advise regarding following issue. I have signal generator which produce the square wave. The freq. is 192Hz.
http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104659813.jpg
However, the logger measure it TWICE ! I think its because of that signal form. Here is the output (in microseconds):
http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104838190.jpg
In average delta is .0026041 s, which is almost equal to 384 Hz (192x2)
For the input I am using the schema similar as HP was using in one of their counters:
http://www.patoka.org/OCXO/LOGGER/IMG_20171110_123201987.jpg
I tried another source (DDS sine generator, referenced from GPSDO) and that beast produce exact number of events:
26.5404621
26.5473008
26.5525067
26.5577297
26.5629260
26.5681280
26.5733305
26.5785262
26.5837255
26.23559295
26.5941842
26.5993546
26.6045699
26.6097716
26.6149911
26.6202076
26.6254149
26.6306244
26.6358103
26.6410386
26.6462491
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.
The "delta" is .0052 s, which is almost equal to 192 Hz. But data flow is not that "smooth" though.
In square wave mode, "school grade" Wavetek generator produced exact 192 events with no issues. (Except its output frequency is not that stable)
21.0578286
21.0630547
21.0682807
21.0735070
21.0787330
21.0839591
21.0891852
21.0944112
21.0996372
21.1048632
21.1100892
However, if I switch Wavetek to sine, my logger detected twice number of event (384)
97.0185559
97.0214570
97.0237852
97.0266822
97.0290048
97.0319054
97.0342336
97.0371408
97.0394552
97.0423578
97.0446802
97.0475836
97.0499131
97.0527969
97.0551313
97.0580259
97.0603560
97.0632648
97.0655869
I would assume, some improvement needs to be done for the data logger input. I am using 2N5485 and 74AC04 elements there. Any advises will be appreciated ! Thanks !
--
WBW,
V.P.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
The MV89 is a beast of an OCXO and uses more power at warm-up than any
other
I know of. But it is spec'ed ~1W for steady state. Which means the
outside of the OCXO should be about hand-warm. If it's too hot, then
the heater circuit is probably broken and running at full-throttle.
If so, I think something is not OK with my MV89. It is probably 110
degrees or so.
Can you show us what your circuit looks like instead of some bad
(literal) screenshot?
Here is my schematic:
http://www.patoka.ca/OCXO/LOGGER/IMG_20171119_155907272.jpg
I did some simple tests for this. In it seems it was OK up to 10Mhz.
But guessing from what you showed, I would say that your amplifier
circuit isn't stable and has some gain peaking at around 10MHz.
There are two ways to proceed: Either optimize your circuit or
simplify it using modern components to the input signal you expect.
The main purpose for this circuit is to protect the MCU input and make
some sine to square conversion.
If you only want to time-stamp input pulses and you can ensure
that those pulses are between 0 and 5V, then I'd use a 74LVC1G34
or 74LVC1G04, depending on whether you want inversion or not
(do not use the 74LVC1G14 as the hysteresis will increase the noise
level)
I was using 74AC04 just because it was readily available in my junk box.
;-)
--
WBW,
V.P.
On Sun, 19 Nov 2017 16:10:54 -0500
Vlad time@patoka.org wrote:
Ok.. I am surprised, this doesn't oscillate.
You have a two stage amplifier, where the second stage
has a negative feedback path into the first stage.
When a pulse comes in, the jfet will turn on and conduct
current through its drain and source resistors. When the
current reaches something around 6-8mA the pnp will start
conducting. But the collector current of the pnp goes into
the source resistor of the jfet. This will increase the
voltage on the source, thus decreasing the gate-source
voltage, thus turn the jfet off, which in turn will turn
the pnp off, which in then will stop conducting, thus
no current into the source resistor, thus the jfet will
start conducting again... I guess you get it.
I did some simple tests for this. In it seems it was OK up to 10Mhz.
But guessing from what you showed, I would say that your amplifier
circuit isn't stable and has some gain peaking at around 10MHz.
There are two ways to proceed: Either optimize your circuit or
simplify it using modern components to the input signal you expect.
The main purpose for this circuit is to protect the MCU input and make
some sine to square conversion.
Use a biased 74AC04. That's the easiest. And you will have very
little noise degradation.
I would think that the MCU can probably take more abuse than the
74AC. Modern ASICs have quite a bit of protection circuits on
their inputs. I am not sure whether the 74-families have seen
upgrades on their protection circuits in the last 30-40 years.
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
Hoi Attila
That's a fairly standard JFET BJT negative feedback amp that's not usually unstable.
The unity gain version has been employed as the input stage of various high impedance oscilloscope preamps.
Bruce
On 20 November 2017 at 11:21 Attila Kinali <attila@kinali.ch> wrote:
On Sun, 19 Nov 2017 16:10:54 -0500
Vlad <time@patoka.org> wrote:
Here is my schematic:
http://www.patoka.ca/OCXO/LOGGER/IMG_20171119_155907272.jpg
Ok.. I am surprised, this doesn't oscillate.
You have a two stage amplifier, where the second stage
has a negative feedback path into the first stage.
When a pulse comes in, the jfet will turn on and conduct
current through its drain and source resistors. When the
current reaches something around 6-8mA the pnp will start
conducting. But the collector current of the pnp goes into
the source resistor of the jfet. This will increase the
voltage on the source, thus decreasing the gate-source
voltage, thus turn the jfet off, which in turn will turn
the pnp off, which in then will stop conducting, thus
no current into the source resistor, thus the jfet will
start conducting again... I guess you get it.
I did some simple tests for this. In it seems it was OK up to 10Mhz.
But guessing from what you showed, I would say that your amplifier
circuit isn't stable and has some gain peaking at around 10MHz.
There are two ways to proceed: Either optimize your circuit or
simplify it using modern components to the input signal you expect.
The main purpose for this circuit is to protect the MCU input and make
some sine to square conversion.
Use a biased 74AC04. That's the easiest. And you will have very
little noise degradation.
I would think that the MCU can probably take more abuse than the
74AC. Modern ASICs have quite a bit of protection circuits on
their inputs. I am not sure whether the 74-families have seen
upgrades on their protection circuits in the last 30-40 years.
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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Oops I meat to say:
Thats a MOSFET variant of a fairly standard JFET-BJT feedback amplifier.
Bruce
On 20 November 2017 at 11:47 Bruce Griffiths bruce.griffiths@xtra.co.nz wrote:
Hoi Attila
That's a fairly standard JFET BJT negative feedback amp that's not usually unstable.
The unity gain version has been employed as the input stage of various high impedance oscilloscope preamps.
Bruce
On 20 November 2017 at 11:21 Attila Kinali <attila@kinali.ch> wrote:
On Sun, 19 Nov 2017 16:10:54 -0500
Vlad <time@patoka.org> wrote:
Here is my schematic:
http://www.patoka.ca/OCXO/LOGGER/IMG_20171119_155907272.jpg
Ok.. I am surprised, this doesn't oscillate.
You have a two stage amplifier, where the second stage
has a negative feedback path into the first stage.
When a pulse comes in, the jfet will turn on and conduct
current through its drain and source resistors. When the
current reaches something around 6-8mA the pnp will start
conducting. But the collector current of the pnp goes into
the source resistor of the jfet. This will increase the
voltage on the source, thus decreasing the gate-source
voltage, thus turn the jfet off, which in turn will turn
the pnp off, which in then will stop conducting, thus
no current into the source resistor, thus the jfet will
start conducting again... I guess you get it.
I did some simple tests for this. In it seems it was OK up to 10Mhz.
But guessing from what you showed, I would say that your amplifier
circuit isn't stable and has some gain peaking at around 10MHz.
There are two ways to proceed: Either optimize your circuit or
simplify it using modern components to the input signal you expect.
The main purpose for this circuit is to protect the MCU input and make
some sine to square conversion.
Use a biased 74AC04. That's the easiest. And you will have very
little noise degradation.
I would think that the MCU can probably take more abuse than the
74AC. Modern ASICs have quite a bit of protection circuits on
their inputs. I am not sure whether the 74-families have seen
upgrades on their protection circuits in the last 30-40 years.
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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi Vlad,
However, the logger measure it TWICE ! I think its because of that
signal form. Here is the output (in microseconds):
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.
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?
I would assume, some improvement needs to be done for the data logger
input. I am using 2N5485 and 74AC04 elements there. Any advises will be
appreciated ! Thanks !
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.
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.).
Note the picPET outputs a h/w event counter along with the timestamp. This can be ignored but the counter helps identify noisy inputs, allows one to distinguish between fast and too-fast inputs, and was very useful during development to validate the accuracy of the device.
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.
/tvb
On Sun, 19 Nov 2017 16:10:54 -0500, you wrote:
The MV89 is a beast of an OCXO and uses more power at warm-up than any
other
I know of. But it is spec'ed ~1W for steady state. Which means the
outside of the OCXO should be about hand-warm. If it's too hot, then
the heater circuit is probably broken and running at full-throttle.
If so, I think something is not OK with my MV89. It is probably 110
degrees or so.
They do run hot, so if that's 110 DegF and not DegC it's OK (depending
on ambient...) The data sheet says 4.2W at 25 DegC.
BTW if anyone is thinking of visiting www.morion.com.ru this might not
be a good day - when I tried earlier the AV claimed it was infected
and the script blocker went nuts, so they did seem to have got
infected by something.
Angus.
I have four MV89As. Two are excellent and run at a case temp around
43C/110F. One tends to jump frequency when you move it, it also sits
around 43C/110F though. The final one has a broken temp controller.
Mounted inside a large block of expanded polstyrene insulation, it
reached 92C/198F before I realised something was not right.
The best MV89A has been running continuously for 18 months and has
drifted LF by 1.2ppb in that time, compared with two GPSDOs and the
GB3MHZ GPS-locked beacon on 1296.830MHz
The two bad ones were cheap and were still soldered to bits of hacksawed
PCB.
Neil
On 19/11/2017 22:56, Angus wrote:
On Sun, 19 Nov 2017 16:10:54 -0500, you wrote:
The MV89 is a beast of an OCXO and uses more power at warm-up than any
other
I know of. But it is spec'ed ~1W for steady state. Which means the
outside of the OCXO should be about hand-warm. If it's too hot, then
the heater circuit is probably broken and running at full-throttle.
If so, I think something is not OK with my MV89. It is probably 110
degrees or so.
They do run hot, so if that's 110 DegF and not DegC it's OK (depending
on ambient...) The data sheet says 4.2W at 25 DegC.
BTW if anyone is thinking of visiting www.morion.com.ru this might not
be a good day - when I tried earlier the AV claimed it was infected
and the script blocker went nuts, so they did seem to have got
infected by something.