[time-nuts] 1PPS to 32.768 khz

[Lee - N2LEE via time-nuts]

I have this (very smart) semi-retired design engineer friend named Craig who I 
first queried about this clock issue.
We always enjoy getting together in his lab or sitting outside enjoying the 
weather and good cigars. 

As usual I bug him with my crazy ideas as a way to educate myself or challenge 
him on how to solve a problem.
After I received some great suggestions from the Time-Nutz I sent a few of them 
to him for a second opinion.

Mark Sims suggestion (below) peaked Craig’s interest and got the juices flowing 
and into the junk box he went. :)

I thought you guys would enjoy hearing what he came up with and seeing a short 
video he sent me.

Lee


——
Lee,

I dug into my used junk box parts :-) and here is what I came up.

I used two 4060s, used the intermediate taps, in series to count 32,768 cycles 
greater than a 35kHz arbitrary oscillator. The final board will use a 555 but 
for now I used a Tek 500 series generator and 4060 tap wiring to allow power of 
two options plus/minus for testing.  The 4060 pair 2^15 or 2^16 (half cycle) 
output goes to a edge triggered D flip flop (74HC74 type) that resets the 4060s 
to stop the count and the 4060 Osc feed through output, pin 10, to the wall 
clock resonator input.  A Trimble Thunderbolt 1pps 50 Ohm loaded output is then 
used to clear the flip flop which releases the reset on the 4060s and the 
32,768 count starts over.  Verified the counts with the Tek counter in 
"totalize" mode.  Is fun to see the output count active vs idle duty cycle vary 
with the nnn kHz Osc input Freq change :-)  I will have to attenuate the 5V 
output to an appropriate level for your clock but it looks like this will work 
for your clock project.

Let me know when you can bring the “jumbo clock” by so we can test it.

Here is a video showing you the 32.768 burst.

https://youtu.be/yNciXTv8Y7c

Craig



 

Here's another way to do it for a wall clock display...   set up an 
oscillator/divider (or even a 555 timer) to generate a frequency close to, but 
faster than 65536 Hz.Setup a 16 bit counter clocked by that signal. When 
the 1PPS signal arrives, start the counter.  After 65536 pulses the counter 
will overflow... stop the counter (and set up for the next 1PPS trigger) when 
that happens.   The Q0 output (lowest bit) from the counter will be a burst of 
32768 pulses that repeats once a second.  Use that to drive your clock.   The 
slight pause between bursts of 32768 pulses will not be noticed on the clock 
display.

Mark







___
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] Anybody want a Thunderbolt power supply?

[Scott Stobbe]

Interesting, I would have thought that the +12V input would be extremely
well regulated since its shared with the oven heater, I*R drops are going
to show up every where, if your looking for uV levels of stability.
Just a connector has milliohms of contact resistance, let alone routing and
cables...

On Friday, 21 October 2016, Bob Camp  wrote:

> Hi
>
> > On Oct 21, 2016, at 7:44 PM, Scott Stobbe  > wrote:
> >
> > A little more data on the 7912.
> >
> > The first plot shows the tempCo of the 7912 measured with ambient
> > temperature swings "7912_TempCo.png". Which is -150 ppm/degC.
> >
> > The second plot is off a 7912 logged for an hour or so, "7912_1PLC.png",
> > nothing too interesting here. However the environmental temperature swing
> > of about 1 degC/hour is pretty conservative for a DUT sitting in free
> air.
> >
> > Finally, an allan devation plot looking at the normalized stability of a
> > 7912 regulator "7912_AllanDeviation.png". Interestingly here, is, how
> quick
> > a 15 mK/min temperature swing shoots above the 1/f floor, it's a matter
> of
> > seconds.
> >
> > Now if your PSRR is 1 ppb/V or better, then all of this is comfortably
> > below the intrinsic noise of a thunderbolt.
>
> The main point is that the internal tempco of the TBolt it’s self is much
> larger than
> the issues surrounding the power supply pins. The +12 is the only one that
> is
> sensitive enough to voltage (change in frequency vs voltage) to contribute
> to any
> significant way to the overall stability.
>
> Bob
>
> >
> > On Fri, Oct 21, 2016 at 12:20 AM, Scott Stobbe  >
> > wrote:
> >
> >> Nick had mention that the -12V rail on the thunderbolt has the poorest
> >> PSRR with respect to frequency output, so I first took a look at the
> >> venerable 7912.
> >>
> >> The first data-set was taken with a -13.5 VDC input. Attached is the 0.1
> >> Hz to 10 Hz noise of an essentially quiescently loaded 7912, only a 10k
> >> resistor was added as load for preliminary evaluation. With a 60 dB
> preamp
> >> the scale of the scope plot is 20 uV/div. The 0.1Hz to 10Hz band noise
> is
> >> 15 uVrms, which is about 1.3 ppm rms of the DC mean.
> >>
> >> In allan deviation terms, a quiescently loaded 7912 has a spot noise of
> 7
> >> uV/rtHz at 1 Hz (on the 1/f slope), normalized that's 580 ppb/rtHz.
> >> Equivalently speaking, the flicker noise floor of an allan deviation
> plot
> >> would be sqrt(2*ln(2)) that figure to be 6.8E-7.
> >>
> >> Assuming a thunderbolt should be achieving 1/f floor of around 1E-12, it
> >> would need a PSRR of at least 1 ppm/V. I'm sure someone has gone to the
> >> trouble of actually measuring it.
> >>
> >> So from a 0.1 Hz to 10 Hz noise standpoint, the 7912 isn't terrible
> >> with 1.3 ppm rms noise, considering an LM399 is about 0.1 ppm rms, only
> one
> >> order of magnitude off.
> >>
> >> The bad side of a 7912 is in long-term stability and tempCo, the sample
> I
> >> tested had at least a 150 ppm/degC tempCo, which is going to put a
> serious
> >> lump/bump in the 10s tau to gps crossover point on an allan deviation
> plot.
> >>
> >>
> >>
> >> On Tue, Oct 18, 2016 at 3:05 PM, Scott Stobbe  >
> >> wrote:
> >>
> >>> I'm sure I have some 7805s lying around, maybe a 7812/7912. I'm
> >>> interested to see the 1/f noise of a classic regulator, what load
> current
> >>> do you expect? I can bias a 7805 for the same load and measure the 0.1
> to
> >>> 10 Hz noise.
> >>>
> >>> Also if you have a digital scope without a very good builtin FFT,
> octave
> >>> would be one solution.
> >>>
> >>> On Tue, Oct 18, 2016 at 10:46 AM, Nick Sayer via time-nuts <
> >>> time-nuts@febo.com > wrote:
> >>>
>  Just an update. I’ve built the second prototype board (I skipped over
>  the first design), and it’s powering my tbolt right now.
> 
>  The design calls for 15v in (though it would also work with 13.8v).
> The
>  +12 output comes from a D2PAK 7812. For +5, there is an AP1509 buck
>  converter to make around 6.5 volts, then a DPAK 7805. For -12, there
> is an
>  MC34063 configured as an inverter to make around -13.75 volts and
> then a
>  DPAK 7912.
> 
>  Steady-state, the system appears to be working just fine. The AP1509’s
>  inductor and the D2PAK 7812 are just warm to the touch.
> 
>  I checked for noise and ripple on the outputs and it’s somewhere
> around
>  ±2 mV or so generally. From what I can see on the scope, there’s no
> ripple
>  - it’s all high frequency noise. I am not absolutely certain that the
> noise
>  measurement represents real noise or the limits of my measuring
> ability.
>  I’m just using the scope probes the scope came with, and 2 mV/div is
> its
>  lowest range.
> 
>  I haven’t compared the noise with the ex laptop supply that I was
> using
>  before, but I’d 

Re: [time-nuts] Linux PPS clues?

[Chris Albertson]

If you are detecting events at 100Khz I think the best way is not to try
and time stamp each event.  Even if only 32 bit time stamps are used you'd
have a 3.2 mega bit per second data rate for just the stamps.  And the
possible error in the stamp approaches the time between samples

I think a better way might be to generate some kind of time code.  It could
be just a sine wave or two or a hardware nanosecond counter.  Then sample
the time code.  It would be best to have a hardware device that latches the
time code, then interrupts the processor and the processor reads the latch.


100Khz is a little fast for software time stamping

On Fri, Oct 21, 2016 at 1:40 AM, Attila Kinali  wrote:

> On Thu, 20 Oct 2016 21:45:42 +
> Ilia Platone  wrote:
>
> > >> I will be interested to see what is recommended for a 100 kHz event
> rate.
> > > This is actually a very tough question. 100kHz means that for each
> event
> > > there is only 10µs available for detection, processing and output.
> Using
> > > a uC that would be something in the order of 1000-2000 CPU cycles. On
> an
> > > application processor (rpi and its cusins) that would be 2000 to
> 20'000 cycles.
> > > While 1000 cycles on a uC is quite a lot, you cannot do any fancy
> processing
> > > with so few cycles.
>
> > I can use one of my boards, which have (checked better) 6MHz sampling
> > frequency on the GPIO, but the sysclock runs at 180MHz, this should be
> > enough except logging support bandwidth. check the NXP3130 uC which is
> > powering these boards: it's old but its dirty job is done perfectly.
>
> [...]
>
> > These events are random photon arrivals (converted to 5vTTL pulses),
> > their rate was measured using the pulse width of the smaller detected,
> > which was 5~10 uS during an observation in low-light environment.
> > The photon arrival and pulse width were random with a minimum pulse
> > width of 10uS. What I want to do is measuring the photon arrival
> > precisely (low to high transition - interrupt I guess), consider that
> > the maximum rate would be 100Kcps because the photon events would
> > overlap if higher. If the 3130 controller can handle such rate it would
> > be great :)
>
> The LPC3130 is IMHO the wrong choice. It does neither have capture/compare
> timer units (ie units that can capture when an input event happend) nor
> does it have interrupts on GPIO. Hence you would need to poll the pins
> continuously while at the same time making sure that the USB port is
> properly handled. This will give you a high uncertainty when the event
> really happend.
>
> I would definitely use a different board than this.
>
> My advice would be to use one of the many high performance Cortex-M4 boards
> I recently had a look at the LPC4330, which should be plenty fast for
> this job. But really any other uC with an HS USB port and capture/compare
> should do. Then run a minimimal OS on it (Nuttx comes to mind) to give
> you the basic functionality you need without too much trouble. Upon each
> event, store the value of the capture register in a ring buffer(1k-2k
> large).
> Read that ring buffer in the main loop and push the data out of the USB
> port
> in chuncks of 512byte to get maximum throughput. Use a PC to record the
> data for later processing.
>
>
> Attila Kinali
> --
> Malek's Law:
> Any simple idea will be worded in the most complicated way.
> ___
> 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.
>



-- 

Chris Albertson
Redondo Beach, California
___
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] Anybody want a Thunderbolt power supply?

[Bob Camp]

Hi

> On Oct 21, 2016, at 7:44 PM, Scott Stobbe  wrote:
> 
> A little more data on the 7912.
> 
> The first plot shows the tempCo of the 7912 measured with ambient
> temperature swings "7912_TempCo.png". Which is -150 ppm/degC.
> 
> The second plot is off a 7912 logged for an hour or so, "7912_1PLC.png",
> nothing too interesting here. However the environmental temperature swing
> of about 1 degC/hour is pretty conservative for a DUT sitting in free air.
> 
> Finally, an allan devation plot looking at the normalized stability of a
> 7912 regulator "7912_AllanDeviation.png". Interestingly here, is, how quick
> a 15 mK/min temperature swing shoots above the 1/f floor, it's a matter of
> seconds.
> 
> Now if your PSRR is 1 ppb/V or better, then all of this is comfortably
> below the intrinsic noise of a thunderbolt.

The main point is that the internal tempco of the TBolt it’s self is much 
larger than
the issues surrounding the power supply pins. The +12 is the only one that is
sensitive enough to voltage (change in frequency vs voltage) to contribute to 
any
significant way to the overall stability. 

Bob

> 
> On Fri, Oct 21, 2016 at 12:20 AM, Scott Stobbe 
> wrote:
> 
>> Nick had mention that the -12V rail on the thunderbolt has the poorest
>> PSRR with respect to frequency output, so I first took a look at the
>> venerable 7912.
>> 
>> The first data-set was taken with a -13.5 VDC input. Attached is the 0.1
>> Hz to 10 Hz noise of an essentially quiescently loaded 7912, only a 10k
>> resistor was added as load for preliminary evaluation. With a 60 dB preamp
>> the scale of the scope plot is 20 uV/div. The 0.1Hz to 10Hz band noise is
>> 15 uVrms, which is about 1.3 ppm rms of the DC mean.
>> 
>> In allan deviation terms, a quiescently loaded 7912 has a spot noise of 7
>> uV/rtHz at 1 Hz (on the 1/f slope), normalized that's 580 ppb/rtHz.
>> Equivalently speaking, the flicker noise floor of an allan deviation plot
>> would be sqrt(2*ln(2)) that figure to be 6.8E-7.
>> 
>> Assuming a thunderbolt should be achieving 1/f floor of around 1E-12, it
>> would need a PSRR of at least 1 ppm/V. I'm sure someone has gone to the
>> trouble of actually measuring it.
>> 
>> So from a 0.1 Hz to 10 Hz noise standpoint, the 7912 isn't terrible
>> with 1.3 ppm rms noise, considering an LM399 is about 0.1 ppm rms, only one
>> order of magnitude off.
>> 
>> The bad side of a 7912 is in long-term stability and tempCo, the sample I
>> tested had at least a 150 ppm/degC tempCo, which is going to put a serious
>> lump/bump in the 10s tau to gps crossover point on an allan deviation plot.
>> 
>> 
>> 
>> On Tue, Oct 18, 2016 at 3:05 PM, Scott Stobbe 
>> wrote:
>> 
>>> I'm sure I have some 7805s lying around, maybe a 7812/7912. I'm
>>> interested to see the 1/f noise of a classic regulator, what load current
>>> do you expect? I can bias a 7805 for the same load and measure the 0.1 to
>>> 10 Hz noise.
>>> 
>>> Also if you have a digital scope without a very good builtin FFT, octave
>>> would be one solution.
>>> 
>>> On Tue, Oct 18, 2016 at 10:46 AM, Nick Sayer via time-nuts <
>>> time-nuts@febo.com> wrote:
>>> 
 Just an update. I’ve built the second prototype board (I skipped over
 the first design), and it’s powering my tbolt right now.
 
 The design calls for 15v in (though it would also work with 13.8v). The
 +12 output comes from a D2PAK 7812. For +5, there is an AP1509 buck
 converter to make around 6.5 volts, then a DPAK 7805. For -12, there is an
 MC34063 configured as an inverter to make around -13.75 volts and then a
 DPAK 7912.
 
 Steady-state, the system appears to be working just fine. The AP1509’s
 inductor and the D2PAK 7812 are just warm to the touch.
 
 I checked for noise and ripple on the outputs and it’s somewhere around
 ±2 mV or so generally. From what I can see on the scope, there’s no ripple
 - it’s all high frequency noise. I am not absolutely certain that the noise
 measurement represents real noise or the limits of my measuring ability.
 I’m just using the scope probes the scope came with, and 2 mV/div is its
 lowest range.
 
 I haven’t compared the noise with the ex laptop supply that I was using
 before, but I’d have to believe it’s cleaner. I don’t really have a way to
 check the oscillator’s before and after ADEV. My only other reference is an
 FE5680A, and I think the thunderbolt’s going to be far better at lower tau
 (where this all matters).
 
 I know also that ±2 mV is still one and perhaps two orders of magnitude
 higher than some have called for. But before I attempt to reduce the noise
 further, I’d like to know that there are real gains to be had. Would
 someone with a Thunderbolt and better output noise measuring wherewithal be
 willing to take a prototype and compare it with something that does 

Re: [time-nuts] 1PPS to 32.768 khz

[Scott Stobbe]

If the heart of your clock is a micro, you may be able to reset the
processor and set the time once a second fastest enough not to have any
visual artifacts. Even if you have a perfect 32.768 kHz clock you still
have to set the phase (time) manually and deal with DST, leap seconds,
and power failures if your total setup doesn't have battery backup.

On Wednesday, 19 October 2016, Lee - N2LEE via time-nuts 
wrote:

> Tom nailed the issue.
>
> First problem is I was native in thinking “Oh this will be easy to
> interface to the NTP or GPS”.  WRONG  :)
> But the good news I am learning a lot about accurate time from you guys.
>
> The second issue is Tom is right. This is a cheap jumbo clock that at the
> heart uses a Holtek HT48R30A
> 8 bit processor. Everything is contained in the chip except the 32khz
> crystal and led drivers.
>
> http://pdf1.alldatasheet.com/datasheet-pdf/view/82435/HOLTEK/HT48R30A.html
>
> This is certainly not the most sophisticated clock chip available.
>
> My original idea was to hijack the timing signal and replace it with
> something more accurate. But the more info
> you guys share the more I see there are a couple of ways to do this.
> Obviously the easiest might be to just replace the
> crystal with a TCXO and hope for the best. But my guess as soon as it is
> off by one second from my other sources I will
> be back into tearing it apart again. LOL
>
> A lot of my other clocks are 6 digit NTP POE clocks so they are not GPS
> accurate but I would at like them to all agree.
>
> Lee - N2LEE
>
>
>
> Right, but that trick only works with analog stepper motor clocks. OP has
> a "big digital clock" with 8-bit cpu and 32 kHz xtal. He didn't mention the
> make/model of digital clock but in my experience very few commodity clocks
> actually accept a 1PPS input. These clocks use 32 kHz:
>
> 1) to drive the MCU which computes day / date / hh:mm:ss, or manages alarms
> 2) to maintain timekeeping
> 3) to multiplex digits of the LED / LCD display (e.g., at 128 to 1024 Hz)
> 4) to create the short bipolar stepper motor pulse (e.g., 1/32 kHz * 512 =
> 1/64 s = 15.6 ms).
> 5) to create the sound for the alarm/buzzer (some PWM based on 32 kHz)
>
> The problem is that all these functions are usually integrated into one
> chip or even raw die/epoxy as in COB (Chip On Board). When hacking these
> sort of clocks it is often impossible to separate 32 kHz frequency features
> from the 1 Hz timing feature.
>
> So when your goal is to improve timekeeping accuracy in these
> self-contained digital clocks it's usually easier and less invasive to make
> the clock use your precise 32 kHz signal instead of its own cheap xtal. You
> almost always have access to the xtal, but rarely access inside the MCU.
>
> Note that you don't even need to unsolder the xtal -- you can "jam" the
> existing signal with an external 32 kHz sine or square wave applied to the
> XI pin (xtal in) of the MCU. Your external GPSDO/32kHz signal will "pull"
> the cheap xtal for free. Best yet, if your external signal goes away the
> clock keeps running using its own xtal without skipping a beat, like
> getting hold-over for free.
>
> For a "no solder" or "no wires" solution, I have also tried to
> acoustically discipline a tuning fork xtal with an GPS-based 32 kHz signal
> and ultrasonic transducer. Poor results. I think I needed better coupling
> between the transducer and the xtal tuning fork. But in theory it should
> work. Plus it would keep small mammals and insects away from your clock.
>
> /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.
>
___
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] Linux PPS clues?

[Gary E. Miller]

Yo Chris!

On Thu, 20 Oct 2016 23:37:23 -0700
Chris Albertson  wrote:

> I think your graph only shows 1/2 of the problem.  It is the easy part
> because all that code is written and likely already installed on the
> OP's computer.

Yup, of course.  But my actual results do not match people's
expectations as recently stated on this list.  To ground the data I am
merely providing an actual baseline for the quality of the system clock
on a RasPi 3 when GPS stabilized using the techniques documented in the
gpsd and ntpsec documentation.

> The other half of the problem is responding to events and getting
> them time stamped with very low latency and jitter.

Yup, of course.  I have not commented on the second part of the problem.
I am enjoying the many and varied solutions being presented here.  I look
forward to actual implementations and hard performance data on them.

> I think the best way is to copy the design of the Linux PPS
> system.

I'll reserve my judgement on 'best'.  Since my data says the Linux
kernel PPS system can reach about 1 µs standard deviation on a 
RasPi3 using the GPIO lines, I would expect a solution based on that
would behave similarly.

> Then assume the error in time stamp is a little larger
> than double your graph.

Ah, double which error?  I give error calculations of one standard
deviation, 90% percentile range, and 98% percentile range.  My guess
would be that any technique using the same method on the same hardware
would have a similar 98% range.

My 98% range on this RasPi3 is under 5 µs.  I'll leave it to the
OP to decide if that is good enough, easy enough, etc.

You can see the live numbers here: https://pi4.rellim.com/day/

> But if the event time stamp code is not so well designed the results
> might to 10X worse not just 2x worse.

Once can always do things badly.  :-)

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgp4TrD8A7tad.pgp
Description: OpenPGP digital signature
___
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] 1PPS to 32.768 khz

[Tom Van Baak]

Hi Jim,

I'm glad you mentioned the DS3231 aging trick. Many PIC's also have the ability 
to digitally tune their internal low power oscillator. Attached is a plot 
showing the 32 steps of the OSCTUNE register in a $1 8-pin PIC12F683.

Notice in the plot that the frequency adjustment range (and step size) of the 
PIC tuning is very large (+/- 10% fs) compared to the DS3231 (0.1ppm/lsb). This 
is both good and bad, depending on your application.

One trick that I've used is to apply PWM to the 7-bit OSCTUNE register. 
Although most people set the value once and forget it, there's no rule that 
says you can't update the register periodically, even rapidly. So for improved 
frequency resolution I update OSCTUNE every millisecond (!) as one would with 
PWM.

Using 1% PWM resolution, the 32 coarse OSCTUNE steps now turn into 3200 fine 
frequency tunings. With additional effort a GPS/1PPS pin capture directs the 
step size/direction and you can thus eliminate both the DS3231 and the Arduino. 
It's my $1 "best worst GPSDO" project. For you PIC assembly programmers the 
frequency microstep test code is at http://leapsecond.com/pic/src/pg41.asm

The key realization is that many microcontrollers now have internal 
oscillators, programmable oscillator tuning, and pulse capture capability. So 
they can function as a crude 1-chip GPSDO. Still, from a practical standpoint, 
the two chip DS3231 + PIC/AVR/Arduino is a more robust and stable solution, 
especially in the case where the goal is 32 kHz output.

/tvb

- Original Message - 
From: "Jim Harman" 
To: "Discussion of precise time and frequency measurement" 
Sent: Friday, October 21, 2016 10:42 AM
Subject: Re: [time-nuts] 1PPS to 32.768 khz


> On Thu, Oct 20, 2016 at 7:08 AM, Bob Camp  wrote:
> 
>> One problem with a PLL and a 1 Hz input are the values of components
>> you get in the loop.
>> The other issue is the cost of the VCXO that will get
>> you to 32,768 KHz.
>>
> 
> As I mentioned earlier, the DS3231 chip (about $6.50 qty 1 or $17.50 on a
> breakout board) might be a reasonable approach for this. It is a
> self-contained 32.768 KHz TCXO that lets you vary the frequency in steps of
> 0.1 ppm using its I2C interface. Left to its own devices, it measures the
> ambient temperature and switches its on-chip capacitors in and out to
> control its frequency.
> 
> It has both 1 PPS and 32,768 Hz outputs. Connected to an Arduino-class
> processor, you could measure the time delay between its PPS and the PPS
> from a GPS and tweak the oscillator accordingly, making a complete 32.768
> KHz GPSDO including the GPS with just 3 chips.
> 
> And you get RTC functionality and battery backup circuitry thrown in for
> free.
> 
> 
> -- 
> 
> --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] Linux PPS clues?

[Gary E. Miller]

Yo Chris!

On Thu, 20 Oct 2016 23:31:46 -0700
Chris Albertson  wrote:

> You should expect the system time to have error on the order of about
> 10 microseconds

Check out the graaphs I sent earlier.  On a RasPi I can get oue
standard deviation under 1 µs.

> The PPS signal error comping out of events low cost GPS receiver has
> error oon order of say a few tens of nano seconds, that is 100 to
> 1000 times less error

Depends on the vendor.  Many only specify one standard deviation of
1 µs.  And you should alway treat spec sheet numbers as besst case.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpQftaPz5GfK.pgp
Description: OpenPGP digital signature
___
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] leontp offset

[Gary E. Miller]

Yo David!

On Fri, 21 Oct 2016 09:00:33 +0100
"David J Taylor"  wrote:

> I set up and configured a brand new xenial box using ntp, and let it
> run for a day (approx 7 hours).

NTPsec, or NTp Classic?

>  remote   refid  st t when poll reach   delay   offset
> *172.17.21.11.GPS.1 u  164  512  3770.312   -1.531

That poll seems really long.  Your arp cache and L2 cache both time out
long before 512 seconds.  Have you tried getting the poll down to 32
seconds, or less?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgp9rt2cKIrDk.pgp
Description: OpenPGP digital signature
___
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] 1PPS to 32.768 khz

[ed breya]

I'm kind of late to the party on this one, but I think the simplest 
approach with the least disturbance to the operation of the original 
system would be to form a VCXO and PLL.


Good old 4000 series CMOS stuff should be plenty fast enough. Two pieces 
should be sufficient. For example, a CMOS 4060 counter/oscillator plus a 
32,768 Hz resonator, rigged as a VCXO could make the clock, and also 
divide it down to a convenient range for 1 PPS comparison. A 4046 PLL or 
some simple logic could then do the comparison and make the correction 
voltage to the oscillator.


Another option may be to use the clock chip's own system to get a 
comparison frequency, if there is a definite and fixed relationship to 
some output signal, say a digit scan line, or punctuation (colons 
between HMS) flash signal. It's conceivable to then use the chip's XO, 
modified to make it voltage-tuned, along with some form of phase 
detector logic.


This could be very simple to implement, but would take some figuring 
out, and risks hurting the clock chip if you screw up while 
experimenting - a definite disturbance. So, it's probably best to use an 
external circuit for all.


Ed
___
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] 1PPS to 32.768 khz

[Jim Harman]

On Thu, Oct 20, 2016 at 7:08 AM, Bob Camp  wrote:

> One problem with a PLL and a 1 Hz input are the values of components
> you get in the loop.
> The other issue is the cost of the VCXO that will get
> you to 32,768 KHz.
>

As I mentioned earlier, the DS3231 chip (about $6.50 qty 1 or $17.50 on a
breakout board) might be a reasonable approach for this. It is a
self-contained 32.768 KHz TCXO that lets you vary the frequency in steps of
0.1 ppm using its I2C interface. Left to its own devices, it measures the
ambient temperature and switches its on-chip capacitors in and out to
control its frequency.

It has both 1 PPS and 32,768 Hz outputs. Connected to an Arduino-class
processor, you could measure the time delay between its PPS and the PPS
from a GPS and tweak the oscillator accordingly, making a complete 32.768
KHz GPSDO including the GPS with just 3 chips.

And you get RTC functionality and battery backup circuitry thrown in for
free.


-- 

--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] Anybody want a Thunderbolt power supply?

[David]

On Fri, 21 Oct 2016 10:59:59 +0200, you wrote:

>On Fri, 21 Oct 2016 00:20:43 -0400
>Scott Stobbe  wrote:
>
>> The bad side of a 7912 is in long-term stability and tempCo, the sample I
>> tested had at least a 150 ppm/degC tempCo, which is going to put a serious
>> lump/bump in the 10s tau to gps crossover point on an allan deviation plot.
>
>If the Thunderbolt ist most sensitive to the -12V input, why not use
>something like the LT3090? Its temperature coefficient is quite low
>in the order of a few ppm/°C around room temperature. Using a metal
>film resistor that should keep the output variations low as well.
>As added bonus, you get a very low output noise.
>
>And while you are at it, use three LT3090 for the positive supplies :-)
>
>   Attila Kinali

Or if space is not an issue, use a discrete reference or zener,
operational amplifier, and pass transistor for better performance yet
at less cost.  If all of the supplies are to be regulated, then use a
common reference to further save cost.

Separating the reference, error amplifier, and feedback network from
the power pass transistor lowers the effects from thermal feedback.
___
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] Anybody want a Thunderbolt power supply?

[Attila Kinali]

On Fri, 21 Oct 2016 06:14:03 -0700
Nick Sayer via time-nuts  wrote:

> Well, because it's easily an order of magnitude more expensive than a 7912. 
> $5 instead of 50¢ (Q:1).
> 
> If it *matters*, then fine, but I am sensitive to cost efficiency in addition 
> to efficacy.

Sorry, I've been hunting ps level delay uncertainties in the last weeks
and kind of forgot that not everyone does things to that extreme.

If you want to go for cheap LDOs, I would recommend going for the
modern variants available from Ti and Linear. Those have much less
noise and drift than the 79xx and 78xx families and are also zero
load impedance stable (ie can be used with ceramic capacitors).
But these are already all in the 1-3USD range if you want to supply 800mA. 
Ie they are at least a factor 2 more expensive than an 78xx.

> If you put the board in a box in a stable temperature environment
> (which I'd kind of assume you'd do if you cared about temperature stability
> generally), then how far do you really have to go?

Let's put a few numbers here:
The stability of a cheap OCXO (SCOCXOHS by Microcrystal) is specced
as <5*10^-7/V. An 7812 (LM7812 by Fairchild) is specced to 0.8mV/°C @ 5mA.
Assuming that using 500mA output makes the Voltage drifft worse by a factor
of 10 (i hope this conservative enough) we are at 8mV/°C. Ie. we get a
total, temperature to supply voltage induced frequency dependence of 4*10^-9/°C.
This is quite noticable. Compare this to the 75ppb over 0°C to 60° of
the temperatur spec of the SXOCXOHS. I.e. we are suddenly adding as much
temperature dependence to the OCXO trough the power supply as it has itself.
Even if you discard the factor 10 for the 7812, that's still 4*10^-10/°C.

Using a more expensive OCXO (AOCJY4 by Abracon) gets you to 3*10^-11/°C
to 3*10^-12/°C, still quite noticable for a GPSDO and again in the order
of its intrinsic temperature coefficient.

And these calculations are only for the temperature of the LDO,
ie they assume an otherwise stable environment. If you start accounting
for drafts of air and changes in humidity, then things become even worse.

Also keep in mind, that unless you start putting cardboard boxes around
everything, then changes of 2-3°C within 10s is pretty normal when you
have people opening/closing doors/windows.


So.. does all this matter? Maybe, maybe not. :-) It depends on what you
actually do with the LDOs. If you put them in a metal box, maybe
with an cardboard box around it, then you dampen the temperature variations
quite a bit and give the GPSDO and its control loop  a chance to compensate.
If you leave them in the open, possibly with an heatsink attached, then
you definitely want to have a lower temperature coefficient.

Attila Kinali

-- 
Malek's Law:
Any simple idea will be worded in the most complicated way.
___
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] Anybody want a Thunderbolt power supply?

[Bob Camp]

Hi

At least in terms of voltage regulation (as opposed to noise), the -12V input 
on the TBolt is 
the *least* sensitive input on the TBolt. It’s issue is only in terms of PSRR. 
The internals of
the unit take care of any drift or really low frequency stuff on the -12 input.

Bob

> On Oct 21, 2016, at 9:14 AM, Nick Sayer via time-nuts  
> wrote:
> 
> Well, because it's easily an order of magnitude more expensive than a 7912. 
> $5 instead of 50¢ (Q:1).
> 
> If it *matters*, then fine, but I am sensitive to cost efficiency in addition 
> to efficacy.
> 
> If you put the board in a box in a stable temperature environment (which I'd 
> kind of assume you'd do if you cared about temperature stability generally), 
> then how far do you really have to go?
> 
> Sent from my iPhone
> 
>> On Oct 21, 2016, at 1:59 AM, Attila Kinali  wrote:
>> 
>> On Fri, 21 Oct 2016 00:20:43 -0400
>> Scott Stobbe  wrote:
>> 
>>> The bad side of a 7912 is in long-term stability and tempCo, the sample I
>>> tested had at least a 150 ppm/degC tempCo, which is going to put a serious
>>> lump/bump in the 10s tau to gps crossover point on an allan deviation plot.
>> 
>> If the Thunderbolt ist most sensitive to the -12V input, why not use
>> something like the LT3090? Its temperature coefficient is quite low
>> in the order of a few ppm/°C around room temperature. Using a metal
>> film resistor that should keep the output variations low as well.
>> As added bonus, you get a very low output noise.
>> 
>> And while you are at it, use three LT3090 for the positive supplies :-)
>> 
>>   Attila Kinali
>> -- 
>> Malek's Law:
>>   Any simple idea will be worded in the most complicated way.
>> ___
>> 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] Anybody want a Thunderbolt power supply?

[Nick Sayer via time-nuts]

Well, because it's easily an order of magnitude more expensive than a 7912. $5 
instead of 50¢ (Q:1).

If it *matters*, then fine, but I am sensitive to cost efficiency in addition 
to efficacy.

If you put the board in a box in a stable temperature environment (which I'd 
kind of assume you'd do if you cared about temperature stability generally), 
then how far do you really have to go?

Sent from my iPhone

> On Oct 21, 2016, at 1:59 AM, Attila Kinali  wrote:
> 
> On Fri, 21 Oct 2016 00:20:43 -0400
> Scott Stobbe  wrote:
> 
>> The bad side of a 7912 is in long-term stability and tempCo, the sample I
>> tested had at least a 150 ppm/degC tempCo, which is going to put a serious
>> lump/bump in the 10s tau to gps crossover point on an allan deviation plot.
> 
> If the Thunderbolt ist most sensitive to the -12V input, why not use
> something like the LT3090? Its temperature coefficient is quite low
> in the order of a few ppm/°C around room temperature. Using a metal
> film resistor that should keep the output variations low as well.
> As added bonus, you get a very low output noise.
> 
> And while you are at it, use three LT3090 for the positive supplies :-)
> 
>Attila Kinali
> -- 
> Malek's Law:
>Any simple idea will be worded in the most complicated way.
> ___
> 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] Anybody want a Thunderbolt power supply?

[Bob Camp]

Hi

> On Oct 21, 2016, at 12:20 AM, Scott Stobbe  wrote:
> 
> Nick had mention that the -12V rail on the thunderbolt has the poorest PSRR
> with respect to frequency output, so I first took a look at the venerable
> 7912.
> 
> The first data-set was taken with a -13.5 VDC input. Attached is the 0.1 Hz
> to 10 Hz noise of an essentially quiescently loaded 7912, only a 10k
> resistor was added as load for preliminary evaluation. With a 60 dB preamp
> the scale of the scope plot is 20 uV/div. The 0.1Hz to 10Hz band noise is
> 15 uVrms, which is about 1.3 ppm rms of the DC mean.
> 
> In allan deviation terms, a quiescently loaded 7912 has a spot noise of 7
> uV/rtHz at 1 Hz (on the 1/f slope), normalized that's 580 ppb/rtHz.
> Equivalently speaking, the flicker noise floor of an allan deviation plot
> would be sqrt(2*ln(2)) that figure to be 6.8E-7.
> 
> Assuming a thunderbolt should be achieving 1/f floor of around 1E-12, it
> would need a PSRR of at least 1 ppm/V. I'm sure someone has gone to the
> trouble of actually measuring it.

The EFC on the OCXO is less sensitive than 1 ppm / V. It is a slam dunk 
to say that the whole OCXO is less sensitive than the EFC by a good margin ….

Bob


> 
> So from a 0.1 Hz to 10 Hz noise standpoint, the 7912 isn't terrible
> with 1.3 ppm rms noise, considering an LM399 is about 0.1 ppm rms, only one
> order of magnitude off.
> 
> The bad side of a 7912 is in long-term stability and tempCo, the sample I
> tested had at least a 150 ppm/degC tempCo, which is going to put a serious
> lump/bump in the 10s tau to gps crossover point on an allan deviation plot.
> 
> 
> 
> On Tue, Oct 18, 2016 at 3:05 PM, Scott Stobbe 
> wrote:
> 
>> I'm sure I have some 7805s lying around, maybe a 7812/7912. I'm interested
>> to see the 1/f noise of a classic regulator, what load current do you
>> expect? I can bias a 7805 for the same load and measure the 0.1 to 10 Hz
>> noise.
>> 
>> Also if you have a digital scope without a very good builtin FFT, octave
>> would be one solution.
>> 
>> On Tue, Oct 18, 2016 at 10:46 AM, Nick Sayer via time-nuts <
>> time-nuts@febo.com> wrote:
>> 
>>> Just an update. I’ve built the second prototype board (I skipped over the
>>> first design), and it’s powering my tbolt right now.
>>> 
>>> The design calls for 15v in (though it would also work with 13.8v). The
>>> +12 output comes from a D2PAK 7812. For +5, there is an AP1509 buck
>>> converter to make around 6.5 volts, then a DPAK 7805. For -12, there is an
>>> MC34063 configured as an inverter to make around -13.75 volts and then a
>>> DPAK 7912.
>>> 
>>> Steady-state, the system appears to be working just fine. The AP1509’s
>>> inductor and the D2PAK 7812 are just warm to the touch.
>>> 
>>> I checked for noise and ripple on the outputs and it’s somewhere around
>>> ±2 mV or so generally. From what I can see on the scope, there’s no ripple
>>> - it’s all high frequency noise. I am not absolutely certain that the noise
>>> measurement represents real noise or the limits of my measuring ability.
>>> I’m just using the scope probes the scope came with, and 2 mV/div is its
>>> lowest range.
>>> 
>>> I haven’t compared the noise with the ex laptop supply that I was using
>>> before, but I’d have to believe it’s cleaner. I don’t really have a way to
>>> check the oscillator’s before and after ADEV. My only other reference is an
>>> FE5680A, and I think the thunderbolt’s going to be far better at lower tau
>>> (where this all matters).
>>> 
>>> I know also that ±2 mV is still one and perhaps two orders of magnitude
>>> higher than some have called for. But before I attempt to reduce the noise
>>> further, I’d like to know that there are real gains to be had. Would
>>> someone with a Thunderbolt and better output noise measuring wherewithal be
>>> willing to take a prototype and compare it with something that does have µV
>>> levels of noise and ripple so I can get an idea of what there is to gain?
>>> If you like, you can make such comparisons public - no secrets here.
>>> 
 On Aug 30, 2016, at 10:37 PM, Nick Sayer  wrote:
 
 
> On Aug 30, 2016, at 8:48 PM, Cube Central 
>>> wrote:
> 
> I would be interested, I think.  Planning ahead for if the one I have
>>> for my Thunderbolt fails, I guess.  Are there different models or would a
>>> photo of the input ports on mine be useful?
 
 Actually, what I had in mind is to just put a SIP4 header on the board
>>> for the output and people could wire the “last mile” themselves. The input
>>> is a 2.1mm barrel connector. You use whatever 15W 12VDC wall wart is handy
>>> and plug it right in.
 
 What it really amounts to is that you get +12 volts directly from the
>>> input, then there’s a buck converter to drop the +12 down to +5 and an
>>> inverter to generate -12 from the +12. Those 3 voltages, plus a ground go
>>> to the SIP4.
 
 So 

Re: [time-nuts] leontp offset

[Mike Cook]

> Le 20 oct. 2016 à 22:06, Hal Murray  a écrit :
> 
> 
>> full disclosure: there were a couple of outlier external clocks I threw out,
>> one with a 38 ms offset and the other with a 112 ms offset).
> 
> That's not uncommon.  It happens more often when the server is farther away 
> and there are more opportunities for strange network routing.
> 
> The NIST servers in Gaithersburg MD (near Washington DC) have been off by 30 
> ms for a while.  There was a discussion on some list several months back.  I 
> forget which one.

Yes though I couldn’t find that thread. time-a.nist.gov appears to me also as 
30+ms offset.
 129.6.15.28 .ACTS.   1 u5   16   77  151.600   33.212   0.161
I am also seeing systematic large offsets from another NIST server reported by 
NTP on clients with GPS PPS input.
 128.138.140.44  .NIST.   1 u6   16  377  126.938   -2.246   0.074
I had been monitoring the Nut1 UT1 time server in Boulder and was surprised 
when I detected a >2 ms difference between that reference and the NIST bulletin 
B UT1-UTC deltas.
Dr Judah Levine , who is providing the service, suggested that I monitor 
128.138.140.44 , a UTC server and which is in the same server room and on the 
same net as Nut1 ( 128.138.140.50 ) and I discovered this systematic and 
remarkably stable offset ( 5.28 x 10^-6 ) and which explains the difference. 
The unfortunate part is that the systematic offset that I see cannot be removed 
by any NTP « fudge » factor and is about  the same magnitude as a days UT1-UTC 
difference as reported by Bulletin B. A real PITA. 

I cannot think of any reason other than asymmetric path delay that could cause 
this, but the 33ms offset for the Gaithersburg server is huge. 

« The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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] Linux PPS clues?

[Ilia Platone]

it's a BC546, 10k collector resistor... I thought it was fast enough, 
but also think the signal is inverted, since there's passive quenching 
in this circuit, so the breakdown voltage of the APD is lowering too 
slowly before next photon, causing this kind of positive edge.. if you 
see well there's the same slope in all the signals. I'm currently 
searching for an active quenching circuit that fits into my application.


Best Regards,
Ilia.


On 10/21/16 09:53, Adrian Godwin wrote:

What is the circuit driving that signal ? It appears to have too little
positive drive to overcome the capacitance. Perhaps it's an open collector
with too large a pull-up ?

On 21 Oct 2016 12:23 a.m., "Ilia Platone"  wrote:


sorry, no attachment, this mail contains two images, one is the previous
attempt, the second (IMG_003.JPG) was taken at 5us/div, 1v/div with a
different oscilloscope setup.

Best Regards,
Ilia.

On 10/20/16 18:12, Attila Kinali wrote:


On Thu, 20 Oct 2016 10:59:21 +0100
"David J Taylor"  wrote:

Actually, of the 15 Raspberry Pi cards I have only one is used in a

graphics
application.


Yes, the rpi are used for all kind of stuff and there is a huge community
around them that helps with all kind of questions. Unfortunately, the
rpi is also used for all kind of stuff that it is a suboptimal choice
(to put it mildly), but people do not care or do not want to check
for alternatives. It kind of works, that's all they care about.

On the positive side they work very well with external devices for control

and measurement,


And for most of these applications a 32bit uC that uses a fraction of
the power would be the right choice. Often a clock of 1MHz would be
enough.

and have a huge amount of software and hardware support for

a vast range of devices which makes for fast and easy development.


That's the only plus side. But then, most of the code written in C
can be used on a uC just the same with little to no modification.

I will be interested to see what is recommended for a 100 kHz event rate.
This is actually a very tough question. 100kHz means that for each event
there is only 10µs available for detection, processing and output. Using
a uC that would be something in the order of 1000-2000 CPU cycles. On an
application processor (rpi and its cusins) that would be 2000 to 20'000
cycles.
While 1000 cycles on a uC is quite a lot, you cannot do any fancy
processing
with so few cycles.

On the application processor 20k cylces is plenty, but you have the
complex
OS that eats up a few thousand cycles itself. Addtionally there comes
the interrupt latency that the application processors suffer from, which
is in the order of 1-10µs... So they would need a kind of (hardware)
system
to queue up the events to process them in badges. Because of this, an rpi
wouldn't work at all (bitbanging takes several µs for each operation).

Going for an uC is easier in that regard as they have very little
interrupt
latency (usually just 5-10 cycles), but then you have problems with
getting the output out of the uC as their I/O subsystems are usually
optimized to work in a stand-alone fashion.

Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an
application
processor) and use their high speed I/O.

For better answers, I would need to know what kind of events these are
and what exactly need to be done/measured.

 Attila Kinali




--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999


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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

[Adrian Godwin]

What is the circuit driving that signal ? It appears to have too little
positive drive to overcome the capacitance. Perhaps it's an open collector
with too large a pull-up ?

On 21 Oct 2016 12:23 a.m., "Ilia Platone"  wrote:

> sorry, no attachment, this mail contains two images, one is the previous
> attempt, the second (IMG_003.JPG) was taken at 5us/div, 1v/div with a
> different oscilloscope setup.
>
> Best Regards,
> Ilia.
>
> On 10/20/16 18:12, Attila Kinali wrote:
>
>> On Thu, 20 Oct 2016 10:59:21 +0100
>> "David J Taylor"  wrote:
>>
>> Actually, of the 15 Raspberry Pi cards I have only one is used in a
>>> graphics
>>> application.
>>>
>> Yes, the rpi are used for all kind of stuff and there is a huge community
>> around them that helps with all kind of questions. Unfortunately, the
>> rpi is also used for all kind of stuff that it is a suboptimal choice
>> (to put it mildly), but people do not care or do not want to check
>> for alternatives. It kind of works, that's all they care about.
>>
>> On the positive side they work very well with external devices for control
>>> and measurement,
>>>
>> And for most of these applications a 32bit uC that uses a fraction of
>> the power would be the right choice. Often a clock of 1MHz would be
>> enough.
>>
>> and have a huge amount of software and hardware support for
>>> a vast range of devices which makes for fast and easy development.
>>>
>> That's the only plus side. But then, most of the code written in C
>> can be used on a uC just the same with little to no modification.
>>
>> I will be interested to see what is recommended for a 100 kHz event rate.
>>>
>> This is actually a very tough question. 100kHz means that for each event
>> there is only 10µs available for detection, processing and output. Using
>> a uC that would be something in the order of 1000-2000 CPU cycles. On an
>> application processor (rpi and its cusins) that would be 2000 to 20'000
>> cycles.
>> While 1000 cycles on a uC is quite a lot, you cannot do any fancy
>> processing
>> with so few cycles.
>>
>> On the application processor 20k cylces is plenty, but you have the
>> complex
>> OS that eats up a few thousand cycles itself. Addtionally there comes
>> the interrupt latency that the application processors suffer from, which
>> is in the order of 1-10µs... So they would need a kind of (hardware)
>> system
>> to queue up the events to process them in badges. Because of this, an rpi
>> wouldn't work at all (bitbanging takes several µs for each operation).
>>
>> Going for an uC is easier in that regard as they have very little
>> interrupt
>> latency (usually just 5-10 cycles), but then you have problems with
>> getting the output out of the uC as their I/O subsystems are usually
>> optimized to work in a stand-alone fashion.
>>
>> Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an
>> application
>> processor) and use their high speed I/O.
>>
>> For better answers, I would need to know what kind of events these are
>> and what exactly need to be done/measured.
>>
>> Attila Kinali
>>
>>
>>
> --
> Ilia Platone
> via Ferrara 54
> 47841
> Cattolica (RN), Italy
> Cell +39 349 1075999
>
>
> ___
> 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] Linux PPS clues?

[Ilia Platone]

I really think that a wired correlator would be the best choice... using 
an FPGA :)

Best Regards,
Ilia.

On 10/21/16 06:45, Bruce Griffiths wrote:

Another issue is that the finer the timestamp quantisation step size the larger 
the signal of interest (Intensity correlation). The signal doesn't vanish as 
the timestamp quantisation step size increases however the signal decreases 
requiring a longer observation time to achieve a given SNR. Handwaving without 
calculation to inform the resultant guesses is likely to result in a required 
observation greater than the age of the universe. This of course is 
impractically long. This fundamental error was made by several investigators in 
the some of the first attempts to do intensity interferometry.
Brue

 On Friday, 21 October 2016 7:32 PM, Chris Albertson 
 wrote:
  


  On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone  wrote:


I need to know how much precise this system can be. How much resolution
can I obtain with a cheap receiver (maximum quantization frequency)?
Formulas are well accepted.



Even a cheap receiver will have error that is orders of magnitude smaller
then the resolution that the linux kernel can work in.

You should expect the system time to have error on the order of about 10
microseconds

The PPS signal error comping out of events low cost GPS receiver has error
oon order of say a few tens of nano seconds, that is 100 to 1000 times less
error

The major source of error is not GPS , but is the interrupt latency
uncertainty. But this is not bad at all, you can expect roughly a 10
microsecond uncertainly in the time stamps more or less.

But a lot depends on how you handle the second GPIO interrupt.  the GPS
interrupt is handled inside a kernel level handler.  The handler snap shots
the system clock and stores it in RAM, then sets a flag that the user space
process checks.Does your GPIO interrupt have a kernel level driver to
snapshot the system clock ir is this happening in a user space process?  If
the later expect worse performance.For best performance copy and paste
the Linux PPS code and then re-build the Linux kernel with your new driver.


Getting event time stamps much better then this requires some purpose built
hardware outside of the computer.

Chris Albertson
Redondo Beach, California
___
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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Anybody want a Thunderbolt power supply?

[Attila Kinali]

On Fri, 21 Oct 2016 10:59:59 +0200
Attila Kinali  wrote:

> And while you are at it, use three LT3090 for the positive supplies :-)

Ermm... LT3045

Attila Kinali

-- 
Malek's Law:
Any simple idea will be worded in the most complicated way.
___
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] Anybody want a Thunderbolt power supply?

[Attila Kinali]

On Fri, 21 Oct 2016 00:20:43 -0400
Scott Stobbe  wrote:

> The bad side of a 7912 is in long-term stability and tempCo, the sample I
> tested had at least a 150 ppm/degC tempCo, which is going to put a serious
> lump/bump in the 10s tau to gps crossover point on an allan deviation plot.

If the Thunderbolt ist most sensitive to the -12V input, why not use
something like the LT3090? Its temperature coefficient is quite low
in the order of a few ppm/°C around room temperature. Using a metal
film resistor that should keep the output variations low as well.
As added bonus, you get a very low output noise.

And while you are at it, use three LT3090 for the positive supplies :-)

Attila Kinali
-- 
Malek's Law:
Any simple idea will be worded in the most complicated way.
___
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] Linux PPS clues?

[Attila Kinali]

On Thu, 20 Oct 2016 21:45:42 +
Ilia Platone  wrote:

> >> I will be interested to see what is recommended for a 100 kHz event rate.
> > This is actually a very tough question. 100kHz means that for each event
> > there is only 10µs available for detection, processing and output. Using
> > a uC that would be something in the order of 1000-2000 CPU cycles. On an
> > application processor (rpi and its cusins) that would be 2000 to 20'000 
> > cycles.
> > While 1000 cycles on a uC is quite a lot, you cannot do any fancy processing
> > with so few cycles.

> I can use one of my boards, which have (checked better) 6MHz sampling 
> frequency on the GPIO, but the sysclock runs at 180MHz, this should be 
> enough except logging support bandwidth. check the NXP3130 uC which is 
> powering these boards: it's old but its dirty job is done perfectly.

[...]

> These events are random photon arrivals (converted to 5vTTL pulses), 
> their rate was measured using the pulse width of the smaller detected, 
> which was 5~10 uS during an observation in low-light environment.
> The photon arrival and pulse width were random with a minimum pulse 
> width of 10uS. What I want to do is measuring the photon arrival 
> precisely (low to high transition - interrupt I guess), consider that 
> the maximum rate would be 100Kcps because the photon events would 
> overlap if higher. If the 3130 controller can handle such rate it would 
> be great :)

The LPC3130 is IMHO the wrong choice. It does neither have capture/compare
timer units (ie units that can capture when an input event happend) nor
does it have interrupts on GPIO. Hence you would need to poll the pins
continuously while at the same time making sure that the USB port is
properly handled. This will give you a high uncertainty when the event
really happend.

I would definitely use a different board than this.

My advice would be to use one of the many high performance Cortex-M4 boards
I recently had a look at the LPC4330, which should be plenty fast for
this job. But really any other uC with an HS USB port and capture/compare
should do. Then run a minimimal OS on it (Nuttx comes to mind) to give
you the basic functionality you need without too much trouble. Upon each
event, store the value of the capture register in a ring buffer(1k-2k large).
Read that ring buffer in the main loop and push the data out of the USB port
in chuncks of 512byte to get maximum throughput. Use a PC to record the
data for later processing.


Attila Kinali
-- 
Malek's Law:
Any simple idea will be worded in the most complicated way.
___
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] KSC big clock

[Adrian Godwin]

Wow .. 24kW for a clock display !


On Fri, Oct 21, 2016 at 6:56 AM, Todd Caldwell  wrote:

> Hi All,
>
>   I've been lurking and assembling gear for the most part, so this is my
> first post I think.
>
>   I was at KSC in May of 2010 for the launch of STS-132.  Attached is a
> relatively closeup pic of the old countdown clock near the press area. As I
> recall, the bulbs are 100W incandescent.  LOTS of them.
>
>   Sadly, they've replaced it with a HDTV like setup of some kind since.
> Video would have been nice I suppose, but the old clock had character.
>
>   Todd - K5SLR.
>
>
> On 10/20/16 04:51, Blair Lade wrote:
>
>> The KSC clock might just use fluroscent tubes in a 7 segment display
>> configuration.Pretty easy to do, just put a set of relay contacts inplace
>> of the starter in the circuit, close the contact, fluro turns off, current
>> flows through heater / filiment keeping them warm.Open the contact, fluro
>> lights..Drive relays off bcd to seven segment decoders, etcWhile it's a bit
>> nasty on the fluro tubes when in the off condition, they are cheap..and the
>> duty cycle isnt all that bad.In actual practise, the relays suffer more
>> than the tubes, and they are cheap too!
>> Blair South Australia
>>
>>
>> Sent from Samsung tablet.
>> ___
>> 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 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] leontp offset

[David J Taylor]

More followup:

I set up and configured a brand new xenial box using ntp, and let it run
for a day (approx 7 hours).  Here are the ntpq -p from that:

$ ntpq -p
remote   refid  st t when poll reach   delay   offset
jitter
==

*172.17.21.11.GPS.1 u  164  512  3770.312   -1.531
0.325
+172.17.21.12.GPS.1 u   60  512  3770.127   -1.137
0.502
x172.17.21.233   .GPS.1 u   60   64  3770.1268.462
0.028
ntp.ubuntu.com  .POOL.  16 p-   6400.0000.000
0.000
-tssnet1.tss.net 131.107.13.100   2 u   64  512  377   39.496   14.121
0.263
+srcf-ntp.stanfo .shm0.   1 u  139  256  377   61.9986.312
0.265
-borris.netwurx. 204.9.54.119 2 u  130  256  377   83.5129.359
0.361
-lithium.constan 18.26.4.105  2 u   22  512  377   98.7919.172
0.709
-alphyn.canonica 132.246.11.231   2 u  247  512  377  110.4368.303
1.354
-chilipepper.can 145.238.203.14   2 u   44  512  377  171.861   11.901
1.374

the .11 and .12 units are the Arbiters.  The .233 is the leontp unit.  This
is two days in a row, on two separate boxes (one a fresh install) that the
arbiters are showing up differently than the rough consensus of others.

As a side note, I really like these leontp units.  They are small and
simple and appear to do what they say very well.  'Leo' in the leontp has
been very responsive, over and above, to working with me on this issue,
even acquiring and poring over the Arbiter 1084C manual to find potential
settings that can introduce offsets.

I will not have a chance to explore some of these Arbiter settings until
next week.  Arbiters are something of a pain to configure.  Arbiter has
some new models in their pipeline that use a web based interface for
settings but those have been in the 'real soon now' stage for over a year.
___


Suggestion: use the configuration above except mark the two Arbiters as 
"noselect".  That way you can monitor them compared to the LeoNTP and the 
Internet servers.


I like Hal's idea of the wrong edge as the minimum pulse width is (likely) 
10 milliseconds.  "Pulse duration is programmable from 0.01 seconds to 600 
seconds, except in one-shot mode, where the output is Low prior to the 
specified time and High thereafter."


 
http://www.arbiter.com/catalog/product/model-1093b-c-gps-satellite-controlled-precision-time-clock-500ns.php#tabs-2

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
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] Linux PPS clues?

[Bruce Griffiths]

Another issue is that the finer the timestamp quantisation step size the larger 
the signal of interest (Intensity correlation). The signal doesn't vanish as 
the timestamp quantisation step size increases however the signal decreases 
requiring a longer observation time to achieve a given SNR. Handwaving without 
calculation to inform the resultant guesses is likely to result in a required 
observation greater than the age of the universe. This of course is 
impractically long. This fundamental error was made by several investigators in 
the some of the first attempts to do intensity interferometry.
Brue  

On Friday, 21 October 2016 7:32 PM, Chris Albertson 
 wrote:
 

 On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone  wrote:

> I need to know how much precise this system can be. How much resolution
> can I obtain with a cheap receiver (maximum quantization frequency)?
> Formulas are well accepted.



Even a cheap receiver will have error that is orders of magnitude smaller
then the resolution that the linux kernel can work in.

You should expect the system time to have error on the order of about 10
microseconds

The PPS signal error comping out of events low cost GPS receiver has error
oon order of say a few tens of nano seconds, that is 100 to 1000 times less
error

The major source of error is not GPS , but is the interrupt latency
uncertainty. But this is not bad at all, you can expect roughly a 10
microsecond uncertainly in the time stamps more or less.

But a lot depends on how you handle the second GPIO interrupt.  the GPS
interrupt is handled inside a kernel level handler.  The handler snap shots
the system clock and stores it in RAM, then sets a flag that the user space
process checks.    Does your GPIO interrupt have a kernel level driver to
snapshot the system clock ir is this happening in a user space process?  If
the later expect worse performance.    For best performance copy and paste
the Linux PPS code and then re-build the Linux kernel with your new driver.


Getting event time stamps much better then this requires some purpose built
hardware outside of the computer.

Chris Albertson
Redondo Beach, California
___
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] Linux PPS clues?

[Chris Albertson]

On Thu, Oct 20, 2016 at 12:02 AM, Gary E. Miller  wrote:

I think your graph only shows 1/2 of the problem.  It is the easy part
because all that code is written and likely already installed on the OP's
computer.

The other half of the problem is responding to events and getting them time
stamped with very low latency and jitter.   In other words the harder job
is actually putting to use that well sync's internal clock.I think the
best way is to copy the design of the Linux PPS system.Then assume the
error in time stamp is a little larger than double your graph.

But if the event time stamp code is not so well designed the results might
to 10X worse not just 2x worse.



> How about a graph, or two?  See attached.  From the histogram, I suspect
> the
> granularity is about 200 nano sec.  From the offset graph you can
> see how the offset jumps.
>
> Here is the offset data on PPS v. the system clock:
> Percentiles..
> Min 1%  5%  50% 95% 99% Max
> -21.645 -2.587  -0.834  -0.020  0.991   0.991   13.557 µs
>
> Ranges..
> 90% 95% StdDev  MeanUnits
> 1.825   5.318   0.850   -0.006  µs
>
> Or see a lot more live graphs here: https://pi4.rellim.com/day/
>
>
> RGDS
> GARY
> 
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> ___
> 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.
>



-- 

Chris Albertson
Redondo Beach, California
___
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] Linux PPS clues?

[Chris Albertson]

On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone  wrote:

> I need to know how much precise this system can be. How much resolution
> can I obtain with a cheap receiver (maximum quantization frequency)?
> Formulas are well accepted.



Even a cheap receiver will have error that is orders of magnitude smaller
then the resolution that the linux kernel can work in.

You should expect the system time to have error on the order of about 10
microseconds

The PPS signal error comping out of events low cost GPS receiver has error
oon order of say a few tens of nano seconds, that is 100 to 1000 times less
error

The major source of error is not GPS , but is the interrupt latency
uncertainty. But this is not bad at all, you can expect roughly a 10
microsecond uncertainly in the time stamps more or less.

But a lot depends on how you handle the second GPIO interrupt.  the GPS
interrupt is handled inside a kernel level handler.  The handler snap shots
the system clock and stores it in RAM, then sets a flag that the user space
process checks.Does your GPIO interrupt have a kernel level driver to
snapshot the system clock ir is this happening in a user space process?  If
the later expect worse performance.For best performance copy and paste
the Linux PPS code and then re-build the Linux kernel with your new driver.


Getting event time stamps much better then this requires some purpose built
hardware outside of the computer.

Chris Albertson
Redondo Beach, California
___
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.