Chris, about using one Arduino for two GPSDO controllers:

Even if a microcontroller has lots of capacity I would recommend to use separate controllers for each oscillator. One of the reasons is what Tom van Baak said about using only one interrupt to avoid jitter and even if you trigger both channels from the same PPS and have just one interrupt you will have a problem that you can´t read two ADC´s at the same time.

Even the HC390 I wouldn´t use for two different oscillators to prevent crosstalk. Both the processor and HC390 is so cheap it isn´t worth the risk IMO.

Actually I would also recommend to put them in separate boxes even if it is more work  (and I´m lazy ) to get best performance.

Having two GPSDO´s that you can compare is very nice as long as you understand how they correlate , if that is not what you want to test. Of course you can also set one or both in hold mode to test them freerunning.

I have thought of connecting the M12 to the Arduino and if someone can help with code to get the sawtooth correction value into the Arduino and decoded I would be glad to have it.

Lars

From: Chris Albertson

On Wed, Mar 5, 2014 at 5:43 PM, Didier Juges shalimr9@gmail.com wrote:

Here is my plan for processing saw tooth data.  If it's not going to
work I'd rather hear about it now then a month from now after I've put
in some effort.
This is going into Lars' Arduino based GPSDO.  Every second I read the
voltage on a TIC capacitor.  This tells by the phase in nanoseconds
between the PPS and the OCXO.  Then I add whatever the current GPS
sawtooth value is to whatever my TIC said.  I compare this to a set
point.  This is the phase error.  The OCXO is adjusted based on a
filtered version of this error.
So in short, I don't correct even try to delay the pulse.  I don't see
any need to do that.  I measure the pulse and get a number in
nanoseconds.  then I use sawtooth to correct the number.
It seems way-hard and with no purpose to correct the pulse and then
measure it.  Better to correct the measurement.  I think it is more
accurate too a delay could never be perfect.
The controller has LOT of spare capacity so I don't see way I can't
add one of more TIC channels and a few more DACs  I should be able to
discipline an OCXO and my Rb  oscillator from the same GPS PPS input.
The 74HC360 is only 1/2 used an Arduino has enough spare pins.  Any
one more 74HC4046 and some passive parts would be required to build a
dual channel GPSDO.
It will be interesting to look at andompare the 10MHz outputs of two
oscillators that are being disciplined by the same controller and GPS
receiver.

--

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.

On Fri, Mar 7, 2014 at 10:28 AM, Lars Walenius
lars.walenius@hotmail.com wrote:

You don't have to read both at the same time.  All you need is to have
a constant time between the interrupt and when you read the ADC. That
constant can be any reasonable number so long as it remains constant

Risk?  It's easy to measure.  Risk is when you don't know what is
going to happen.  But in this case we can test.

I think you might be addressing pico seconds on a system that works in
the few nano seconds range.    A serial commanded Rb oscillator moves
in such large steps that I'm 100% sure the step quantization error
will dominate everything.  The step size is something like 5E-11.  But
the stability I expect will be very good.

I'm looking for an OCXO.  Not much reason to start before I find one.
People are over bidding on eBay for 30 year old salvage parts.
eventually I'll win one at a reasonable price.  Then I'll write up my
results.  In the mean time I've started a wholesale refactoring of
the posted Arduino code.  I need t make it  a bit more modular and
"testable."

I have an Motorola Oncore UT+ type GPS.  I think it might have the
same sawtooth.    I'm pretty sure there is code in the standard NTP
distribution to read the Oncore type data and (maybe sawtooth???)  I
plan to read the NTP drivers and borrow whatever is usable.

I did just build and finish testing a serial interfaced LCD display.
Now I can display states using just two Arduino pins.  (Without the
serial interface an LCD takes 6 to 10 pins)  I'm using I2C so I can
add other devices to the same serial interface, like a DAC or whatever

--

Chris Albertson
Redondo Beach, California

On 3/7/14 12:31 PM, Chris Albertson wrote:

there are plenty of Arduino-like boards out there that have ADCs
triggered by the timer, which also fires the interrupt, but you don't
have to worry about reading the ADC late.

The teensy3.1 (new version of the teensy3 from PJRC) has a dual ADC,
which can simulataneously sample.  I've run the teensy3 at 300ksps+ (48
MHz processor clock).  Right now, I've got software that is interrupt
driven at 50 kHz that does two adc reads in a row and then feeds a 2
stage CIC decimator chain.  It consumes about 60% of the processor, the
bulk of which is the actual ADC read and the first integrators.

for <$20, it's hard to beat.. the only downside is that you can't go
down to radio shack and buy one on the spur of the moment.

They'll also do a not very optimized fixed point 128 point FFT in about
0.9 milliseconds:
N pts μs
128 897
64 402
32 175
16 82

Let's see what is needed.

The ADC is 10-bits so it can read to one part in 1024.  It's a 5 volt
full scale so we are only able to measure 5 millivolt increments

The uP runs about 16 million instructions per second.  What if we wait
1000 instructions to read the ADC what will the error be?  The "1000"
number is conservative by at least a factor of 10.  The discharge
resister has (assume) a one second time constant.

The read delay would be 1000/16,000,000 or 63 uSec.  in that time the
voltage would have changed about  300 microvolts.  The change is about
15 times less then the DAC is able to measure.    But because of the
conservative estimate it might 150 times to small to measure.  So
randomly delayed reads of the ADC will not matter.  That said I'm sure
we can do 100X better then the 63 uS estimate.

On the other side, charging the cap.  Let's say I mis-measured a wire
and it is 1cm longer then I though.  The added delay adds a tiny delay
but this is not going to show up in a 10-bit ADC.  Same if the
propagation delay changes through the 74HC390 based variable loading
of other output pins or noise from the 78ls05 voltage regulator.  The
DAC is set up for 5 mV steps.  I just don't need to worry about errors
that are well under 0.5 mV.

If I were building this using a 24-bit ADC and wanted to take full
advantage of its resolution then tiny things matter.

On Fri, Mar 7, 2014 at 12:47 PM, Jim Lux jimlux@earthlink.net wrote:

--

Chris Albertson
Redondo Beach, California

On 3/7/14 3:33 PM, Chris Albertson wrote:

if you use the teensy3 it has a 16 bit ADC with realistically, about 13
bits performance. The teensy3.1 has a 12 bit DAC, but since I haven't
got one in my hot little hands yet, I don't know the performance.

Hi

With a “real” 12  to 13 bit ADC and a 200 ns TDC pulse you would ideally get  < 200 / 4096 as your LSB. Nothing like this is ever perfect, so you probably aren’t going to get <50 ps. You probably will be below 100 ps. That’s plenty good enough to make sawtooth correction useful.

Bob

On Mar 7, 2014, at 6:38 PM, Jim Lux jimlux@earthlink.net wrote:

On 07/03/14 19:28, Lars Walenius wrote:

Cross-talk typically happens though ground-bounce. Just using separate
chips reduces the effect. May not be much of an issue at ns level, but
below.

Some telecom rubidiums have fairly noisy output. Steering an OCXO for
clean-up might actually provide the best of both worlds. Holdover of the
rubidiums and phase-noise of the OCXO. In that case, keeping them in the
same box makes sense. The arduino could contribute long-term integrator
memory and possibly do temperature compensation of the OCXO as a
feed-forward approach.

I've proposed to some of my local friends here, and we will probably do
something with LPROs. We need to look at what GPS modules there is.

I think sawtooth correction should be added. It's not that hard. One
really wants two serial ports, one for the GPS and one for monitoring.

Cheers,
Magnus

On 08/03/14 00:52, Bob Camp wrote:

When you have sawtooth corrections, the actual time of the PPS is not so
important, but it will be that reference pulse which gives the high
time-resolution info about the oscillators phase. The sawtooth
correction will reduce the GPS modules TCXO into a common view
oscillator which (almost) cancels out.

If you do not have sawtooth corrections, indirect tracking might be
possible to consider.

Cheers,
Magnus