Re: [time-nuts] 4046 experiment for gpsdo

2015-09-25 Thread Will
Hi,

I'm new and trying to get to grips with things.

If I understand correctly, please forgive if I have it wrong,  This
locks a 10MHz signal  to a 1Hz (1pps) signal.  What makes it lock to 10
000 000Hz instead of 999 999Hz or 10 000 001Hz?  Just the hope that the
10MHz is exactly that?

Cheers,
Will

On 26/09/15 08:32, Jim Harman wrote:
> To further demonstrate the Diode - R- C- approach, here  (hopefully) is a
> screenshot of the raw DAC output vs time on my Arduino Micro (32u4) based
> system. For this test the oscillator is free running with an error of about
> 1 usec per 460 sec or 2.17x10^-9. The horizontal scale is 125 sec/div (1000
> sec total) and the vertical is 1024  DAC counts (0-2.56 V) which
> corresponds to 1 usec of offset between the oscillator and the reference.
>
> You can see that there is some curvature because the capacitor is being
> charged through a resistor and not a true current source, but as I
> mentioned earlier this does not affect the system's ability to lock the
> oscillator to the pps reference. When locked with a time constant of 1000
> sec, the phase detector output is almost always less than +/- 100 counts
> from the setpoint of 500.
>
> The noise is due mostly to jitter in my PPS reference, which is generated
> by an Adafruit GPS module. Presumably it would be less if I had a real
> timing receiver.
>
>
> ​.
> If the inserted image does not come through, I will re-send as an
> attachment.
>
>> --
> --Jim Harman
>
>
>
> ___
> 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-5680B Rubidium and DDS

2015-09-25 Thread Bryan _
There is information on this thread on how you can tap into the unit at various 
points to get 20 and 60Mhz. Other owners have used a divider to bring it to the 
10Mhz frequency desired. I have one of these units and haven't gone around to 
dividing it down. I purchased mine from Ebay and the seller notes that this 
particular version will output 10Mhz for a second or two and then disappear. I 
suspect you have the same version, maybe even the same seller, so the operation 
of these particular units appears to be normal. Mine will lock so I know it's 
working.
http://www.eevblog.com/forum/testgear/fe-5680b-1pps-to-10mhz/msg556800/#msg556800
I as well wish there was a quick way of converting it back to 10Mhz. I am sure 
it can be done, just not sure how or where to look 

-=Bryan=-

> From: kb...@n1k.org
> Date: Fri, 25 Sep 2015 17:45:08 -0400
> To: time-nuts@febo.com
> Subject: Re: [time-nuts] FE-5680B Rubidium and DDS
> 
> Hi
> 
> There is no dump of the firmware. The problem you are most likely 
> having is not firmware related.
> 
> If the VCXO i the unit drifts to far it needs to be re-tuned. Until this is 
> done
> the device simply sits in a “search for lock” loop forever and ever.
> 
> Simple way to do it:
> 
> Monitor the VCXO and bump the trimmer until the frequency goes above the 
> intended
> target (10 x N MHz depending on your monitor point) by at least 0.15 ppm. The 
> sweep is
> slow enough that a counter running at a 0.1 second gate will easily show you 
> what’s going on.
> 
> Of course it can be other things. All of them are a bit more involved to fix. 
>  
> 
> Bob
> 
> > On Sep 25, 2015, at 11:34 AM, Clint Jay  wrote:
> > 
> > I've recently purchased one of the PPS Only FE Rubidium standards from eBay
> > and, like many others I suspect, haven't been able to get a stable output
> > frequency that lasts longer than a few seconds from the module.
> > 
> > It appears that the 10MHz source vanishes after a few seconds but this is
> > controlled by firmware.
> > 
> > Which leads to my question, there is a dump of the firmware from the
> > FE-5680, has anyone tried to reprogram one?
> > -- 
> > Clint.
> > 
> > *No trees were harmed in the sending of this mail. However, a large number
> > of electrons were greatly inconvenienced.*
> > ___
> > 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 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] wwvb gps d-psk-r details

2015-09-25 Thread Bob Camp
Hi

Given the (relative) low precision required of the “dummy” timing data, other 
sources than GPS can be used. NTP 
level precision may be adequate if you have a good NTP source. Of course if GPS 
catastrophes are the concern, 
accurate NTP probably isn’t going to be a viable thing. 

The more interesting timing source would be a good WWVB clock, possibly 
upstream of the DPSK removal device.
Once you got things bootstrapped with GPS, switch over to WWVB. 

There are other alternatives. Now that we have a working demodulator, 
experiments can begin to figure out which
one(s) works. 

Indeed the question of “what’s the target application?” is relevant. In many 
ways simply having a second reference 
is the desired outcome. That’s what interests me and this gizmo does that quite 
well. There are always things that
one wonders about in any system. An independent reference chain is sometimes 
just the thing you need to work
some of them out.

Bob

> On Sep 24, 2015, at 5:11 PM, Charles Steinmetz  wrote:
> 
> Paul wrote:
> 
>> Here is the detailed document on the wwvb d-psk-r.
> 
> Interesting solution, and a good study in persistence.  Congratulations!  But 
> I thought the main point of having a working WWVB receiver was as a backup if 
> GPS fails (or for use in circumstances where WWVB reception is possible but 
> not GPS reception).  If GPS is working, and you have a GPS rx/GPSDO, what is 
> the point of having a time and/or frequency source that relies on GPS but 
> only has the precision of WWVB?  And what good is the predictive de-psk-r 
> when GPS is not working?
> 
> [Yes, I get that if one runs a museum it's nice to have working exhibits even 
> if they are simulated, and it's no big deal if the exhibits don't work from 
> time to time.  But the curator's solution doesn't seem to solve the 
> time-nuts' real problem.]
> 
> I hasten to add that I don't really care one way or the other about GPS 
> alternatives, particularly alternatives with the relative imprecision of WWVB 
> over time scales shorter than geological.  Personally, I presume that if 
> there is ever a persistent, system-wide GPS failure it will be due to a 
> natural or man-made catastrophe of earthshaking proportions (literally) and 
> there will be many, more urgent concerns than time-nuts' experiments.  But 
> others have expressed concern over having just one time and frequency 
> standard available.  For them, isn't a fully independent solution that does 
> not rely on GPS required?
> 
> Again, congratulations on bringing this idea to fruition.
> 
> 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.

___
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] wwvb gps d-psk-r details

2015-09-25 Thread paul swed
Charles like you I have quite a few gpsdo's that are far superior to wwvb
at least on the east coast in reality. But all of that said I actually used
wwvb more for propagation studies to watch the ionosphere. Its always been
interesting.
Not that any of it matters if all of GPS is gone my real interest will be
water, food, and heat.
I certainly spent the time building doublers, costas loops, and a large box
full answers that do not depend on GPS and yes they work till they skip a
cycle and you get a 180 degree phase shift in the chart. Those have been
shared with Time-nuts over the years. There are other approaches I may also
explore now that I have the codes figured out. But after 3 years a break
would be good and after all it was a 90 day project. Ooops that wasn't the
case.

I am looking forward to someone releasing a SDR version completely
independent of GPS. But at that point there is no longer a need for the old
receivers either as it can all be done very nicely in software complete
with phase measurements in about 2 Lbs and 5 watts.

I am scratching my head a bit here. It seems as though the 500 KB document
may have come through. But I never received a copy.
Regards
Paul.
WB8TSL

On Thu, Sep 24, 2015 at 5:11 PM, Charles Steinmetz 
wrote:

> Paul wrote:
>
> Here is the detailed document on the wwvb d-psk-r.
>>
>
> Interesting solution, and a good study in persistence.  Congratulations!
> But I thought the main point of having a working WWVB receiver was as a
> backup if GPS fails (or for use in circumstances where WWVB reception is
> possible but not GPS reception).  If GPS is working, and you have a GPS
> rx/GPSDO, what is the point of having a time and/or frequency source that
> relies on GPS but only has the precision of WWVB?  And what good is the
> predictive de-psk-r when GPS is not working?
>
> [Yes, I get that if one runs a museum it's nice to have working exhibits
> even if they are simulated, and it's no big deal if the exhibits don't work
> from time to time.  But the curator's solution doesn't seem to solve the
> time-nuts' real problem.]
>
> I hasten to add that I don't really care one way or the other about GPS
> alternatives, particularly alternatives with the relative imprecision of
> WWVB over time scales shorter than geological.  Personally, I presume that
> if there is ever a persistent, system-wide GPS failure it will be due to a
> natural or man-made catastrophe of earthshaking proportions (literally) and
> there will be many, more urgent concerns than time-nuts' experiments.  But
> others have expressed concern over having just one time and frequency
> standard available.  For them, isn't a fully independent solution that does
> not rely on GPS required?
>
> Again, congratulations on bringing this idea to fruition.
>
> 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.
>
___
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] Z380XA The saga of the aging 10811

2015-09-25 Thread James Flynn
Bob Benward  writes:

> 
> Continuing this discussion, I have included a PDF showing the past 
30days of
> EFC.  Amazingly, the drift has reversed direction!  Anyone have any 
insights
> into this behavior?  Each data point represents 10 seconds.
> 

I have found that three things can cause this behavior over a short term 
(days) which do not involve failure of the standard itself ( in no 
particular order ):

1) Power supply. Most standards are immune to this but, if your EFC 
circuit or phase detector involves active circuits, it can show up.

2) Grounds. Bad grounds or ground loops, especially those that share 
current with the oven heater can cause unexplained drift. However, these 
usually have a diurnal temperature signature unless your set up is very 
climate controlled. Screw terminal grounds or connections can "age" and 
change things. Best to ahve everything soldered.

3) Cheap components, especially resistors. I recently had this driving 
me nuts. Carbon comp. and the 2 cent metal film resistors have large 
temperature coefficients and are even sensitive to humidity. Go for the 
<10ppm / deg C metal film or SMD resistors. Some caps also can be tricky 
if the circuit involves large caps.  Leakage is a problem in high 
impedance circuits and can be unpredictable and non-constant.

Finally, there is literature that supports resonators can reverse their 
ageing slope. However, this is rare.

I hope this helps.  I have been there, scratching my head while the 
system seems to have a mind of its own.

___
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] Z3801A expert?

2015-09-25 Thread Ben Hall

Hi Hal and list,

On 9/24/2015 2:29 AM, Hal Murray wrote:

It runs all the tests again and didn't find any errors, but it remembers that
it has seen an error sometime recently that hasn't been cleared.


That makes sense - I was able to find a log entry in the diagnostic log 
saying "self-test failed."  If I power-cycle the unit, it will boot up 
and fail the self-test again.


Interestingly, the error queue reads +0, "No error".


There may be a clear-errors command.  If you can't find that, there is
probably a restart command that goes through the whole boot sequence all over
again.


I dug *deep* into the manual last night.  Couldn't find a command that 
would do that, but I'm convinced now that I've got a real error that's 
recurring versus one that set once and cleared.


The hardware status register when polled says "1" which per the manual 
translates into "self test failed."


Interestingly, the unit seems to be performing fine.  After all the 
reboots and me fiddling with it last night, it settled down to a PU of 
5.0 us/initial 24 hours and TFOM = 3, FFOM = 0.


I'm going to run the unit until it fails.  With a power-on-time of 13.5 
years, it probably doesn't owe me a thing.  :)


thanks much and 73,
ben, kd5byb

___
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-5680B Rubidium and DDS

2015-09-25 Thread Bob Camp
Hi

There is no dump of the firmware. The problem you are most likely 
having is not firmware related.

If the VCXO i the unit drifts to far it needs to be re-tuned. Until this is done
the device simply sits in a “search for lock” loop forever and ever.

Simple way to do it:

Monitor the VCXO and bump the trimmer until the frequency goes above the 
intended
target (10 x N MHz depending on your monitor point) by at least 0.15 ppm. The 
sweep is
slow enough that a counter running at a 0.1 second gate will easily show you 
what’s going on.

Of course it can be other things. All of them are a bit more involved to fix.  

Bob

> On Sep 25, 2015, at 11:34 AM, Clint Jay  wrote:
> 
> I've recently purchased one of the PPS Only FE Rubidium standards from eBay
> and, like many others I suspect, haven't been able to get a stable output
> frequency that lasts longer than a few seconds from the module.
> 
> It appears that the 10MHz source vanishes after a few seconds but this is
> controlled by firmware.
> 
> Which leads to my question, there is a dump of the firmware from the
> FE-5680, has anyone tried to reprogram one?
> -- 
> Clint.
> 
> *No trees were harmed in the sending of this mail. However, a large number
> of electrons were greatly inconvenienced.*
> ___
> 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] 4046 experiment for gpsdo

2015-09-25 Thread Jim Harman
To further demonstrate the Diode - R- C- approach, here  (hopefully) is a
screenshot of the raw DAC output vs time on my Arduino Micro (32u4) based
system. For this test the oscillator is free running with an error of about
1 usec per 460 sec or 2.17x10^-9. The horizontal scale is 125 sec/div (1000
sec total) and the vertical is 1024  DAC counts (0-2.56 V) which
corresponds to 1 usec of offset between the oscillator and the reference.

You can see that there is some curvature because the capacitor is being
charged through a resistor and not a true current source, but as I
mentioned earlier this does not affect the system's ability to lock the
oscillator to the pps reference. When locked with a time constant of 1000
sec, the phase detector output is almost always less than +/- 100 counts
from the setpoint of 500.

The noise is due mostly to jitter in my PPS reference, which is generated
by an Adafruit GPS module. Presumably it would be less if I had a real
timing receiver.


​.
If the inserted image does not come through, I will re-send as an
attachment.

>
> --

--Jim Harman
___
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] more teensies

2015-09-25 Thread Bill Dailey
It would be neat to drive one off a disciplined 16MHz synthesizer and compare.

Bill Dailey


> On Sep 25, 2015, at 1:40 PM, Jim Lux  wrote:
> 
> I ran 5 teensys in parallel, driven from the same Rb source for an hour..
> They track reasonably well.
> The differences are probably due to where they are relative to their 
> neighbors, and where the AC is blowing in my office.  They're all on a single 
> piece of perfboard side by side.  I'll find a cardboard box and some foam to 
> put them in.  (excuse me.. an isothermal atmospheric convection current 
> inhibition system)
> 
> There's a pretty noticeable "turn on" transient, so I should probably wait a 
> few minutes before taking data..
> 
> They're actually run off a 16 MHz crystal, which is presumably multiplied up 
> by 4 internally.
> <5teensyfreq.png>
> <5teensyquadfreqremoved.png>
> ___
> 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] 4046 experiment for gpsdo

2015-09-25 Thread Jim Harman
Hi Can,

I suppose your circuit will work as you describe, but the diode-R-C network
at the output of the HC4046 followed by an A/D converter works fine if your
application is to lock an oscillator to a reference and you don't care if
there is a constant time (phase) difference between the two when locked.

The key is that instead of trying to reduce the time difference to zero,
you define a setpoint near the middle of the range of the phase comparator.
You then adjust the frequency of the oscillator to keep the phase
comparator output near the setpoint.

Using PC3, 1 MHz for the oscillator, and 1 PPS for the reference, you will
get a pulse 0-1 usec wide. If you have a 10 bit A/D converter reading the
height of the integrated pulse, you get 1 nsec resolution, which is at
least 10x better than anything you will get from an all-digital solution
counting clock cycles. Defining the setpoint at 500 A/D counts in the
filter algorithm will control the oscillator so it is nominally 500 ns
ahead of the reference.

On Fri, Sep 25, 2015 at 2:18 AM, Can Altineller 
wrote:

> Hello All,
>
> I got a CD74HC4046 and started to experiment. It seems that this is a newer
> version, which has another phase comparator instead of the zener diode.
> There has been some changes in the chip basically. PC1out is a xor gate,
> and PC3out is an RS flip flop. It will give pulses if one source is behind,
> and it will give reverse pulses if one source is forward. PP pin gives the
> reverse of every phase differences corresponding to a rising edge, so it is
> half the xor pulses in frequency.
>
> I made the following circuit on breadboard:
>
>
> ​
> 1PPS pulses from both RTC and SYNC source gets inverted, (because we are
> interested in falling edges) - Signal and comparator pins of 4046 is fed
> with those pulses. The PC1 out is a XOR phase pulses, for both rising and
> falling edges, so we are only measuring it for display purposes on the
> following images.
>
> P3Out gives a pulse, if source is behind it will give a sharp pulse from 0
> to logic 1 voltage, and if source is forward it will be at logic 1 voltage,
> and give a sharp drop. (On the circuit above the 4046 has no zener, but PC3
> instead).
>
> The PP output from 4046 inverted gives as the phase pulse, no matter if it
> is lacking or forward it will give the same normal pulse. By using and
> gates and getting
> !PP & PC3Out gives us forward pulse, and !PP && !PC3Out gives us reverse
> pulse.
>
> Here is a logic analyzer capture of XOR, Forward pulse and reverse pulse,
> when the RTC is behind.
>
>
> And here Source is behind
>
>
>
> So in summary, we get pulses from one pin saying that the RTC is behind,
> and if RTC is forward it will pulse from the other pin. I will now proceed
> to feed these pulses into the RC network.
>
> I got this far tru experimentation with the 4046. The VCO can also be
> inhibited for low power consumption, (since we are only using the phase
> comparators)
> I tried a lot of logic circuits to cover a generalized case of the phase
> difference between clock pulses, but now I want to make a hybrid algorithm
> which will work with interrupts until within certain range steering the
> clock in to the zone, and then it might tune from the RC networks. (I would
> use two of them, for increasing and decreasing the oscillator)
>
> I would love to hear your comments for the above circuit because I might
> have overlooked something major, that will screw up the operation.
>
> Best Regards,
> Can
>
> ​
>
> ___
> 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.
>



-- 

--Jim Harman
___
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] teensy as time capture device

2015-09-25 Thread Jim Lux

On 9/24/15 11:02 AM, Hal Murray wrote:


xne...@luna.dyndns.dk said:

External Oscillator (the system clock clock) ,  or External Timer clock
(limited to system clock/4)


That sounds like they are running the external signal through a synchronizer
and then doing all the logic on the system clock.  That would add a lot of
high frequency jitter but work as expected at longer time scales.

It would be fun to see if you could pick up hanging-bridge type artifacts.




Almost certainly.

___
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] wwvb gps d-psk-r details

2015-09-25 Thread Charles Steinmetz

Paul wrote:


Here is the detailed document on the wwvb d-psk-r.


Interesting solution, and a good study in 
persistence.  Congratulations!  But I thought the main point of 
having a working WWVB receiver was as a backup if GPS fails (or for 
use in circumstances where WWVB reception is possible but not GPS 
reception).  If GPS is working, and you have a GPS rx/GPSDO, what is 
the point of having a time and/or frequency source that relies on GPS 
but only has the precision of WWVB?  And what good is the predictive 
de-psk-r when GPS is not working?


[Yes, I get that if one runs a museum it's nice to have working 
exhibits even if they are simulated, and it's no big deal if the 
exhibits don't work from time to time.  But the curator's solution 
doesn't seem to solve the time-nuts' real problem.]


I hasten to add that I don't really care one way or the other about 
GPS alternatives, particularly alternatives with the relative 
imprecision of WWVB over time scales shorter than 
geological.  Personally, I presume that if there is ever a 
persistent, system-wide GPS failure it will be due to a natural or 
man-made catastrophe of earthshaking proportions (literally) and 
there will be many, more urgent concerns than time-nuts' 
experiments.  But others have expressed concern over having just one 
time and frequency standard available.  For them, isn't a fully 
independent solution that does not rely on GPS required?


Again, congratulations on bringing this idea to fruition.

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.


[time-nuts] Symmetricom 8130A Software

2015-09-25 Thread GandalfG8--- via time-nuts
In a 2005 White Paper singing the praises of "their", actually ex Datum,  
8130A rubidium module, Symmetricom mentioned a small RS232 utility  they 
referred to as 8130Comm.
 
However, it isn't mentioned in the 8130A manual and I can't find anything  
else about it either online or within my own Symmetricom  archives, could 
anyone confirm please whether or not this  does actually exist, or better 
still have a copy they could  share?
 
Regards
 
Nigel
GM8PZR
___
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] teensy as time capture device

2015-09-25 Thread Chris Caudle
On Thu, September 24, 2015 7:30 am, Jim Lux wrote:
> What would be interesting is if there's a pin on the Arduino/Teensy that
> you could feed a high quality oscillator to, and then do counting with
> that.  The K20 microcontroller has a mindbendingly large number of
> features and alternate pin functions.

The Beaglebone Black has that feature.
I have been trying to figure out if having both the 10MHz to drive the
counter and the PPS latching the count fed from the same Thunderbolt might
cause some kind of systematic offset similar to a hanging bridge effect.
Any guess?

-- 
Chris Caudle



___
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] algorithms and hardware for comparing clock pulses

2015-09-25 Thread Bill Hawkins
The role of the diode is to break the current path to the cap
when S1 shorts the current to ground when PPS 2 occurs.

With the diode, S1 does not short the cap to ground.

Bill Hawkins

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Alex
Pummer
Sent: Thursday, September 24, 2015 3:58 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] algorithms and hardware for comparing clock
pulses

the role of the diode is just to have a voltage drop?
73
KJ6UHN
Alex

On 9/23/2015 11:31 PM, Bill Hawkins wrote:
> Perhaps I can do this in words, as I have no schematic software.
>
> Start with the input to your favorite microprocessor's A/D converter.
> Connect it to a suitable (more later) capacitor to analog ground.
> Connect a cmos switch across the cap and call it S2. When S2 is on, it

> discharges the cap.
>
> Now build or buy a constant current generator connected from a 
> suitable positive voltage to another cmos switch called S1.
> When S1 is on, all of the current generated flows to analog ground.
>
> To make it all work, connect the anode of a diode from the junction of

> the current source and S1 to the cap and analog input.
>
> When S1 is on, no current gets to the cap. When S1 is off, all of the 
> current gets to the cap, if S2 is off. This causes a linear buildup of

> voltage across the cap, for a suitable time.
>
> When 1 PPS pulses are compared, suitable means one second to charge to

> almost the maximum that the micro A/D supports.
> The value of I is chosen to overwhelm diode leakage and A/D input 
> current. The value of C follows.
>
> All that remains for a working system is a pair of flip-flops to 
> control
> S1 and S2.
> FF 1 is set by PPS 1 and cleared by PPS 2, and by power on reset. When
> FF1 is on, S1 is off.
> FF 2 is set by PPS 1 and cleared by an output from the micro when the 
> A/D conversion is done. When FF2 is on, S2 is off.
>
> And so C will charge from PPS 1 to PPS 2, hold the value while the A/D

> conversion occurs, and be reset to zero volts when the micro is done 
> processing the input.
>
> This gives the micro a linear conversion of pulse difference time 
> rather than an RC exponential value.
>
> Feedback controllers do better with linear error signals.
>
> But all of this is wasted if the PPS signals are not accurate due to 
> things that affect pulse rise and fall times.
>
> If the above was not adequately clear, please ask for clarification. 
> Or do a schematic and ask for corrections.
>
> Bill Hawkins
>
> P.S. This will not work well for small differences between PPS 1 and
2.
> It will work if the goal is 50% difference, or 90 degrees phase shift.
>
>
> -Original Message-
> From: Can Altineller
> Sent: Wednesday, September 23, 2015 2:56 AM
>
> %< --
>
> 4. I think an analog solution like Bill Hawkins described, would be 
> best suited for this task. But I have not understood it enough to
build it.
>
> Best Regards,
> C.A.
>
>

___
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] algorithms and hardware for comparing clock pulses

2015-09-25 Thread Bill Hawkins
Don't know why I was referenced on this. The simple approach is what I
was trying to improve.
But I was only looking at a way to covert pulse width time to voltage
for further processing.
Perhaps linearity is not required in this application.

It's been my experience that controllers with proportional terms such as
PID do a better job with a linear error signal, unless the thing being
controlled (crystal frequency) is so nonlinear that the integral term
does most of the work.

Wish I could do the experiment, but no longer have a lab.

Bill Hawkins


-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob
Camp
Sent: Thursday, September 24, 2015 6:37 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] algorithms and hardware for comparing clock
pulses

Hi

Simple approach:

Use a pair of tri-state buffers. 

Both have their outputs hooked to the cap through resistors.

One (call it A) has its signal input grounded. The other (call it B) has
its signal input tied high. Both of the tri-state controls normal sit in
the "off" (= output is tri-state) condition. 

When I turn A on, the cap discharges. If instead, I turn B on, the cap
charges. If neither is on, the cap changes voltage only due to leakage
current. 

Let's say I have a long R/C on A and simply use it to discharge the cap
to zero. It's there only to set a starting value on the cap. The R/C
could be just about anything. 

Let's also say that I feed a variable width pulse into B. While the
pulse has the gate control "on" the cap charges. The voltage on the cap
is proportional to the well known R/C time constant formula and the
width of the pulse. 

Once the pulse is gone, I fire up the A/D and read the voltage. After I
have the voltage I put the cap back to ground with A. 



So what can go wrong?

1) I have the cap in the "both gates off" state to long and all I'm
reading is the impact of leakage current.

2) My pulse is to wide and the R/C maxes out.

3) My pulse is long enough that my resolution goes below my desired
resolution target. 

4) The resistance is low enough that the gate output R gets into the
act.

5) The C is so small that trace stray C (and input C's) get into the
act. 

6) The current into the R is so high that the gate current limits at the
start of the charge cycle. 

7) The caps or resistors are not stable so the system is not repeatable.


8) Your ADC has some pathogenic thing it does when it converts that
shorts the cap to ground. ( = you have a really weird ADC). 

Except for leakage current, everything is controllable in the design.
Some of the stuff above can be modeled (or measured) to minimize it's
impact. There are more subtle issues like the fact that the gate has a
different propagation delay low to high than high to low. That will
stretch the pulse a bit. If you get really fast on the pulse, the output
of the gate gets into the act a couple of ways. 

Bob


> On Sep 24, 2015, at 2:31 AM, Bill Hawkins  wrote:
> 
> Perhaps I can do this in words, as I have no schematic software.
> 
> Start with the input to your favorite microprocessor's A/D converter.
> Connect it to a suitable (more later) capacitor to analog ground.
> Connect a cmos switch across the cap and call it S2. When S2 is on, it

> discharges the cap.
> 
> Now build or buy a constant current generator connected from a 
> suitable positive voltage to another cmos switch called S1.
> When S1 is on, all of the current generated flows to analog ground.
> 
> To make it all work, connect the anode of a diode from the junction of

> the current source and S1 to the cap and analog input.
> 
> When S1 is on, no current gets to the cap. When S1 is off, all of the 
> current gets to the cap, if S2 is off. This causes a linear buildup of

> voltage across the cap, for a suitable time.
> 
> When 1 PPS pulses are compared, suitable means one second to charge to

> almost the maximum that the micro A/D supports.
> The value of I is chosen to overwhelm diode leakage and A/D input 
> current. The value of C follows.
> 
> All that remains for a working system is a pair of flip-flops to 
> control
> S1 and S2.
> FF 1 is set by PPS 1 and cleared by PPS 2, and by power on reset. When
> FF1 is on, S1 is off.
> FF 2 is set by PPS 1 and cleared by an output from the micro when the 
> A/D conversion is done. When FF2 is on, S2 is off.
> 
> And so C will charge from PPS 1 to PPS 2, hold the value while the A/D

> conversion occurs, and be reset to zero volts when the micro is done 
> processing the input.
> 
> This gives the micro a linear conversion of pulse difference time 
> rather than an RC exponential value.
> 
> Feedback controllers do better with linear error signals.
> 
> But all of this is wasted if the PPS signals are not accurate due to 
> things that affect pulse rise and fall times.
> 
> If the above was not adequately clear, please ask for clarification. 
> Or do a schematic and