Re: [time-nuts] FE-5680A not responding to serial commands

2017-11-19 Thread Jonas Jalling
Hi Bryan,

I don't know, so probably not. I'll try to make a dump of the firmware, and
see if that gets me anywhare. But thank you for your input - now I know
that units exist with the serial port disabled.

BR Jonas

On Mon, Nov 20, 2017 at 8:27 AM Bryan _  wrote:

> Did the serial communication ever work?. There is so many variations of
> the FE's that it's hard to know if it was even supported for that
> particular model or option. I have one and it has a serial port, but does
> not respond to any commands.
>
>
> -=Bryan=-
>
>
> 
> From: time-nuts  on behalf of Jonas Jalling <
> jo...@jalling.dk>
> Sent: November 19, 2017 12:20 AM
> To: time-nuts@febo.com
> Subject: [time-nuts] FE-5680A not responding to serial commands
>
> Hello all,
> I have an old FE-5680a I bought years ago, that surfaced from my storage
> boxes the other day. I thought I would experiment with disciplining it to
> my M12+t GPS. I have some problems adjusting the frequency though.
> If I put a scope on pins 5 and 7 of the DS80C323 processor, I can see the
> serial input (ie. 0x2D 0x04 0x00 0x29), but the processor never responds.
> Has anyone seen this problem before, and is there a way to fix it? Could
> the serial adjust be disabled? And if so, is there any way to enable it?
>
> Thanks in advance,
> BR Jonas
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> time-nuts
>  Info
> Page - American Febo Enterprises<
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts>
> www.febo.com
> time-nuts is a low volume, high SNR list for the discussion of precise
> time and frequency measurement and related topics. To see the collection of
> prior postings to ...
>
>
>
> and follow the instructions there.
> ___
> 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.
>
___
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.


Re: [time-nuts] FE-5680A not responding to serial commands

2017-11-19 Thread Bryan _
Did the serial communication ever work?. There is so many variations of the 
FE's that it's hard to know if it was even supported for that particular model 
or option. I have one and it has a serial port, but does not respond to any 
commands.


-=Bryan=-



From: time-nuts  on behalf of Jonas Jalling 

Sent: November 19, 2017 12:20 AM
To: time-nuts@febo.com
Subject: [time-nuts] FE-5680A not responding to serial commands

Hello all,
I have an old FE-5680a I bought years ago, that surfaced from my storage
boxes the other day. I thought I would experiment with disciplining it to
my M12+t GPS. I have some problems adjusting the frequency though.
If I put a scope on pins 5 and 7 of the DS80C323 processor, I can see the
serial input (ie. 0x2D 0x04 0x00 0x29), but the processor never responds.
Has anyone seen this problem before, and is there a way to fix it? Could
the serial adjust be disabled? And if so, is there any way to enable it?

Thanks in advance,
BR Jonas
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
time-nuts Info Page - American Febo 
Enterprises
www.febo.com
time-nuts is a low volume, high SNR list for the discussion of precise time and 
frequency measurement and related topics. To see the collection of prior 
postings to ...



and follow the instructions there.
___
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.


Re: [time-nuts] Symmetricom X72 rubidium oscillator breakout board now available

2017-11-19 Thread Jerry Hancock
Mark, do you have an inexpensive sour for the X72?
Regards,

Jerry


> On Nov 19, 2017, at 4:43 PM, Mark Sims  wrote:
> 
> I have finished my breakout boards for the X72 oscillator.   It consists of 
> two boards connected by a ribbon cable (or you can remove a header and 
> replace with a female and directly connect them or solder the boards 
> together).   Power input is through a 2.1mm barrel connector.  Input caps are 
> rated at 25V, so a max 15V input is suggested.  You can  power it via either 
> board... the connections are in parallel. 
> 
> The first board is a small interface board board that plugs into the X72 and 
> breaks out all 26 connections to a 2x13 pin 0.1" pin header.  It also has 
> connections for the SERVICE, LOCK, and 1PPS signals  driven through 1K 
> resistors... can be used to drive LEDs, etc.  Note the 1PPS signal would need 
> to be stretched to drive an LED and the LOCK polarity is such that LOCK is 
> indicated by the LED being off.
> 
> The second board is a breakout board that has an RS-232 interface (with 
> selectable 1PPS polarity signal and optional raw/5V regulated power signal 
> available).  It also has BNC connectors for the 1PPS IN, 1PPS out,  EFC IN,  
> 10 MHz output, and selectable user programable ACMOS frequency output / FXO 
> 60 MHz oscillator output.  The breakout board also has 
> 
> The boards are assembled and include a 200 mm long ribbon cable (photo shows 
> a shorter cable.  The price is $25 per set shipped in the US.  Overseas 
> shipping is an additional $10 for any quantity.  Contact me off list if 
> interested.___
> 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.

___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Charles Steinmetz

Bruce wrote:


Oops I meat to say:

Thats a MOSFET variant of a fairly standard JFET-BJT feedback amplifier.


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


___
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.

Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Tom Van Baak
> I'll need to experiment with this. I think the drawback cold be for the 
> signal with long pulse width (more than one second). 
> __|~~~

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'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.

That sounds fine.


> My other timer generate interrupt each second. This is used to start 
> count the microseconds over again. So, its pretty simple.

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.


> 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"

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.


> 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 

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.


> 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 (4000 % 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.

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

___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Vlad



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 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.
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Vlad

On 2017-11-19 20:20, Mark Sims wrote:

Here are Wenzel's input circuits:
http://www.wenzel.com/documents/waveform.html

The TAPR TICC uses a slightly modified version of the two transistor 
circuit.


Also check out the LPRO-101 manual for their versions of the single
CMOS gate squarer.  One thing they do is add an RC filter to the CMOS
gate power supply.


Thanks for the link. Actually I am using Wenzel two transistors in my 
other project. Works great. This time I tried to use LPRO-101. But that 
one is to "square" outputs from MV89 OCXO. MCU like it.
I am wandering, if it can it be an issue, if I am using the same 74AC04 
for all three purposes:


1. 1PPS to control the DAC
2. OCXO to feed the MCU
3. Input from DUT

--
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Vlad




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 (4000 % 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 -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Attila Kinali
On Sun, 19 Nov 2017 22:56:41 +
Angus  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.

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
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Attila Kinali
On Mon, 20 Nov 2017 11:47:09 +1300 (NZDT)
Bruce Griffiths  wrote:

> That's a fairly standard JFET BJT negative feedback amp that's not usually 
> unstable.

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
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Bruce Griffiths
The performance of virtually all CMOS gate sine to CMOS converters degrades 
significantly once the signal at the gate input exceeds the supplies 
sufficiently to cause the input protection circuitry to conduct. This effect is 
very easy to measure with HCMOS.

Bruce 

> 
> On 20 November 2017 at 14:20 Mark Sims  wrote:
> 
> Here are Wenzel's input circuits:
> http://www.wenzel.com/documents/waveform.html
> 
> The TAPR TICC uses a slightly modified version of the two transistor 
> circuit.
> 
> Also check out the LPRO-101 manual for their versions of the single CMOS 
> gate squarer. One thing they do is add an RC filter to the CMOS gate power 
> supply.
> 
> I use this version (with a 74HC86 as the input gate) on my HP-531xx time 
> interval calibrator circuit. Wenzel says an HC gate works better than AC 
> logic if you don't need to handle higher freqs. It provides surprisingly good 
> performance for such a simple circuit.
> 
> ___
> 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.
> 
___
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.


[time-nuts] Input filter for data logger

2017-11-19 Thread Mark Sims
Here are Wenzel's input circuits:
http://www.wenzel.com/documents/waveform.html

The TAPR TICC uses a slightly modified version of the two transistor circuit.

Also check out the LPRO-101 manual for their versions of the single CMOS gate 
squarer.  One thing they do is add an RC filter to the CMOS gate power supply.  

I use this version (with a 74HC86 as the input gate) on my HP-531xx time 
interval calibrator circuit.  Wenzel says an HC gate works  better than AC 
logic if you don't need to handle higher freqs.  It provides surprisingly good 
performance for such a simple circuit.
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Neil
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.



___
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.


[time-nuts] FE-5680A not responding to serial commands

2017-11-19 Thread Jonas Jalling
Hello all,
I have an old FE-5680a I bought years ago, that surfaced from my storage
boxes the other day. I thought I would experiment with disciplining it to
my M12+t GPS. I have some problems adjusting the frequency though.
If I put a scope on pins 5 and 7 of the DS80C323 processor, I can see the
serial input (ie. 0x2D 0x04 0x00 0x29), but the processor never responds.
Has anyone seen this problem before, and is there a way to fix it? Could
the serial adjust be disabled? And if so, is there any way to enable it?

Thanks in advance,
BR Jonas
___
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.


[time-nuts] Symmetricom X72 rubidium oscillator breakout board now available

2017-11-19 Thread Mark Sims
I have finished my breakout boards for the X72 oscillator.   It consists of two 
boards connected by a ribbon cable (or you can remove a header and replace with 
a female and directly connect them or solder the boards together).   Power 
input is through a 2.1mm barrel connector.  Input caps are rated at 25V, so a 
max 15V input is suggested.  You can  power it via either board... the 
connections are in parallel. 

The first board is a small interface board board that plugs into the X72 and 
breaks out all 26 connections to a 2x13 pin 0.1" pin header.  It also has 
connections for the SERVICE, LOCK, and 1PPS signals  driven through 1K 
resistors... can be used to drive LEDs, etc.  Note the 1PPS signal would need 
to be stretched to drive an LED and the LOCK polarity is such that LOCK is 
indicated by the LED being off.

The second board is a breakout board that has an RS-232 interface (with 
selectable 1PPS polarity signal and optional raw/5V regulated power signal 
available).  It also has BNC connectors for the 1PPS IN, 1PPS out,  EFC IN,  10 
MHz output, and selectable user programable ACMOS frequency output / FXO 60 MHz 
oscillator output.  The breakout board also has 

The boards are assembled and include a 200 mm long ribbon cable (photo shows a 
shorter cable.  The price is $25 per set shipped in the US.  Overseas shipping 
is an additional $10 for any quantity.  Contact me off list if interested.___
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.

Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Hal Murray

t...@leapsecond.com said:
> 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. 

The event counter also lets you catch lost events in the downstream gear that 
is capturing/logging data from the picPET.



-- 
These are my opinions.  I hate spam.



___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Angus
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.
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Tom Van Baak
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

___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Bruce Griffiths
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  
> 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  wrote:
> > 
> > On Sun, 19 Nov 2017 16:10:54 -0500
> > Vlad  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.
> > 
> > > 
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Bruce Griffiths
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  wrote:
> 
> On Sun, 19 Nov 2017 16:10:54 -0500
> Vlad  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.
> 
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Attila Kinali
On Sun, 19 Nov 2017 16:10:54 -0500
Vlad  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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Vlad




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.
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Bob kb8tq
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  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.

___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Attila Kinali
On Sun, 19 Nov 2017 11:40:27 -0500
Vlad  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
___
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.


Re: [time-nuts] Input filter for data logger

2017-11-19 Thread Orin Eman
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  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.
>
___
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.


[time-nuts] HP5065A C-field mods and optical unit mods

2017-11-19 Thread cdelect
Attached is the schematic of the C-field supply.

Cheers,

Corby___
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.

[time-nuts] Read blocks from 5371a

2017-11-19 Thread Jerry Hancock
I’ve been playing around comparing my REF0/REF1 with my 5371a.  I wrote some 
code that sets the interval time of 1 second and I can read the first block of 
data of up to 1000 samples (1000 seconds).  All is great.  I can’t figure out 
though, how to read the next block assuming I told it to read for instance 10 
blocks.  I can loop the code but thought what the heck, have the 5371a do it, 
put the code to sleep until it is about time for it to finish.  

This is over GPIB.  I’ve stared at the docs, etc. You would think there should 
be a command like “read next block’.

Thanks

Jerry


___
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.


[time-nuts] Input filter for data logger

2017-11-19 Thread Vlad


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.


[time-nuts] Keysight Caesium Standard lab in Australia

2017-11-19 Thread Bryan _
May be of interest.


https://youtu.be/2J9Y1-gxxhE

[https://i.ytimg.com/vi/2J9Y1-gxxhE/maxresdefault.jpg]

EEVblog #1040 - Caesium Beam Frequency Standards
youtu.be
A look at the Caesium beam time and frequency standards at the Keysight 
standards lab in Melbourne Australia, with Peter Daly. Forum: 
http://www.eevblog.com/...





-=Bryan=-
___
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.