Lars DIY GPSDO with Arduino and 1ns resolution TIC

[iMo]

You may see similar periodicity in Miti's results here. It may come from NEO7M.

[Miti]

However, I do see a 'jump'  in the offset when it's running normally. This does not change when put upside down.

See attached picture, is this normal?

Yes, it is, and mine is locked for 38 days so it is rock stable, see my pictures. A big improvement was when I enabled temperature compensation.

[Satbeginner]

However, I do see a 'jump'  in the offset when it's running normally. This does not change when put upside down.

See attached picture, is this normal?

Yes, it is, and mine is locked for 38 days so it is rock stable, see my pictures. A big improvement was when I enabled temperature compensation.

Hi,

yes, I do see the same, and it stayed locked perfectly for days now, even without the temperature compensation
It looks like there is one bigger step up (still small though!), and two small steps down to compensate for that. :-)

I am wondering, maybe it's possible the add an extra to the software, maybe an auto-calibrate routine?

At the moment I am thinking like this:

To add a separate "autocal" routine that can be called either by an interrupt (a button) and/or an extra software command that does the following:

During the "autocal", stop running,  put a fixed "h1" value and read the offset, after that put a fixed "h65535" value and read the offset again,
and than do the math, to find the difference and use that to calculate the gain and save that instead of a manual gxx [ENTER] ?
Not sure how useful that would be.

Anyway, food for thought...

But first I am in the process of completing my box, I already added 3 channels of an 74HCT14 in parallel with three 150 Ohm resistors as buffer for both the 10MHz and 1-PPS output, so they are able to drive a 50 Ohm load.
I also want to use the rest of the HC390 to create extra divided frequency outputs, or even a second HC390, also buffered by more 74HCT14's, so I can use it as a scope timing calibrator.

To be continued, :-)

Un saludo,

Leo

[cdev]

@tvb has figured out an accurate, inexpensive way to do this that works well on all GPSDOs!
See the following.

http://www.leapsecond.com/pic/picdiv.htm

http://www.leapsecond.com/pic/picpet.htm

http://leapsecond.com/pic/picpet2.htm

Hi,

yes, I do see the same, and it stayed locked perfectly for days now, even without the temperature compensation
It looks like there is one bigger step up (still small though!), and two small steps down to compensate for that. :-)

I am wondering, maybe it's possible the add an extra to the software, maybe an auto-calibrate routine?

At the moment I am thinking like this:

To add a separate "autocal" routine that can be called either by an interrupt (a button) and/or an extra software command that does the following:

During the "autocal", stop running,  put a fixed "h1" value and read the offset, after that put a fixed "h65535" value and read the offset again,
and than do the math, to find the difference and use that to calculate the gain and save that instead of a manual gxx [ENTER] ?
Not sure how useful that would be.

Anyway, food for thought...

But first I am in the process of completing my box, I already added 3 channels of an 74HCT14 in parallel with three 150 Ohm resistors as buffer for both the 10MHz and 1-PPS output, so they are able to drive a 50 Ohm load.
I also want to use the rest of the HC390 to create extra divided frequency outputs, or even a second HC390, also buffered by more 74HCT14's, so I can use it as a scope timing calibrator.

To be continued, :-)

Un saludo,

Leo

[Miti]

Right when I said that my GPSDO is rock solid, it lost the lock after more than a month. Foggy morning, my GPS antenna is in my basement's window, I can only blame it on the GPS.

[bingo600]

@tvb has figured out an accurate, inexpensive way to do this that works well on all GPSDOs!
See the following.

http://www.leapsecond.com/pic/picdiv.htm

http://www.leapsecond.com/pic/picpet.htm

http://leapsecond.com/pic/picpet2.htm

Ulrich B did an AVR version of PPSDIV here (Bottom)
http://www.ulrich-bangert.de/html/downloads.html

Edit:
Seems like a Tiny84 has a full PortA (0..7) , meaning this one:
http://www.ulrich-bangert.de/PPSDivider.zip

Ought to work w.

Code: [Select]

#include <tn84def.inc>

The avr assembler2 runs fine in wine on linux

My avr assembler2 script

Code: [Select]

#!/bin/bash
wine ~/avr/AvrAssembler2/avrasm2.exe -I ~/avr/AvrAssembler2/Appnotes -I ~/avr/AvrAssembler2/include \
 -d$1.obj -m$1.map -l$1.lst -e$1.eep -vs -v2 -fI $1 $2 $3 $4 $5

Result

$ avrasm2 PPSDivider-t84.asm
AVRASM: AVR macro assembler 2.1.43 (build 48 May 30 2011 10:07:37)
Copyright (C) 1995-2011 ATMEL Corporation

PPSDivider-t84.asm(1): Including file '/../avr/AvrAssembler2/include\tn84def.inc'
PPSDivider-t84.asm(87): No EEPROM data, deleting PPSDivider-t84.asm.eep

Notice:
The register and instruction counts are symbol table hit counts,
and hence implicitly used resources are not counted, eg, the
'lpm' instruction without operands implicitly uses r0 and z,
none of which are counted.

x,y,z are separate entities in the symbol table and are
counted separately from r26..r31 here.

.dseg memory usage only counts static data declared with .byte

ATtiny84 register use summary:
r0 :   0 r1 :   0 r2 :   0 r3 :   0 r4 :   0 r5 :   0 r6 :   0 r7 :   0
r8 :  13 r9 :   5 r10:   5 r11:   5 r12:   5 r13:   5 r14:   5 r15:   5
r16:  18 r17:   4 r18:   0 r19:   0 r20:   0 r21:   0 r22:   0 r23:   0
r24:   0 r25:   0 r26:   0 r27:   0 r28:   0 r29:   0 r30:   0 r31:   0
x  :   0 y  :   0 z  :   0
Registers used: 10 out of 35 (28.6%)

ATtiny84 instruction use summary:
.lds  :   0 .sts  :   0 adc   :   0 add   :   0 adiw  :   0 and   :   0
andi  :   0 asr   :   0 bclr  :   0 bld   :   9 brbc  :   0 brbs  :   0
brcc  :   0 brcs  :   7 break :   0 breq  :   0 brge  :   0 brhc  :   0
brhs  :   0 brid  :   0 brie  :   0 brlo  :   0 brlt  :   0 brmi  :   0
brne  :  15 brpl  :   0 brsh  :   0 brtc  :   0 brts  :   0 brvc  :   0
brvs  :   0 bset  :   0 bst   :   0 cbi   :   0 cbr   :   0 clc   :   0
clh   :   0 cli   :   0 cln   :   0 clr   :  16 cls   :   0 clt   :   1
clv   :   0 clz   :   0 com   :   0 cp    :  14 cpc   :   0 cpi   :   0
cpse  :   0 dec   :   2 eor   :   0 icall :   0 ijmp  :   0 in    :   0
inc   :   7 ld    :   0 ldd   :   0 ldi   :   5 lds   :   0 lpm   :   0
lsl   :   0 lsr   :   0 mov   :   0 movw  :   0 neg   :   0 nop   :   1
or    :   0 ori   :   0 out   :   3 pop   :   0 push  :   0 rcall :   0
ret   :   0 reti  :   0 rjmp  :   1 rol   :   0 ror   :   0 sbc   :   0
sbci  :   0 sbi   :   0 sbic  :   0 sbis  :   0 sbiw  :   0 sbr   :   0
sbrc  :   0 sbrs  :   0 sec   :   0 seh   :   0 sei   :   0 sen   :   0
ser   :   0 ses   :   0 set   :   1 sev   :   0 sez   :   0 sleep :   0
spm   :   0 st    :   0 std   :   0 sts   :   0 sub   :   0 subi  :   0
swap  :   0 tst   :   0 wdr   :   0
Instructions used: 13 out of 105 (12.4%)

ATtiny84 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x000000 0x0000a4    164      0    164    8192   2.0%
[.dseg] 0x000060 0x000060      0      0      0     512   0.0%
[.eseg] 0x000000 0x000000      0      0      0     512   0.0%

Assembly complete, 0 errors. 0 warnings

/Bingo

Edit: AVRasm2 - http://www.mikrocontroller.net/attachment/26295/AVR2.zip

AVRA, avrasm2 compatible - https://sourceforge.net/projects/avra/
            apt-get install avra

[cdev]

It should get better the longer you leave it on. See if you can move it outward so it has a better sky view. Also if you are using a patch antenna, try putting a larger ground plane underneath it in the center. (don't tilt the ground plane but be aware that if you are in the northern hemisphere most sats will be to the south and vice versa if you are in the Southern hemisphere more will be to the north) I often use a failed CD or DVD as a ground plane, that should be the minimum size you use. A bigger piece of metal is even better.

Right when I said that my GPSDO is rock solid, it lost the lock after more than a month. Foggy morning, my GPS antenna is in my basement's window, I can only blame it on the GPS.

[texaspyro]

Pizza pan to the rescue!

[metrologist]

I was going to ask why is the 1V ADC range used? It seems you could use a 280 ohm resistor after the diode and have less noise on the higher range? But then I see how non-linear the charge curve is and you only get to use ~80% of the higher range anyway.

My new build did not work and I was having a hard time triggering on the ADC signal due to the noise and low signal level. I was able to get a good capture when triggering on the 1pps instead and discovered I had miswired the phase detector reset pin!

Here is a timelab plot with TC=4. Now I have set TC=400 but I think I can go much higher.

I'll build two of these with different oscillators and GPS. Still need to add a temp sensor and determine if I want to replace the divider pot with a couple precision resistors. Then I'll pack the box with fiberglass insulation.

[cdev]

Pizza pan to the rescue!

I'm ashamed to show what I use because it has this weird paint on it that is coming off that looks just horrible, but suffice it to say it was literally saved out of the garbage- its not perfectly flat, its an old pot lid with a shallow depression on the curvilinear top for its long ago lost handle just large enough for a typical GPS patch antenna. Unfortunately its made out of aluminum. So I have to figure out other ways to keep GPS antennas in place, or rely on gravity.

Its totally unscientific why I use it. I have no evidence that putting the gps in the depression would reduce multipath like a choke ring. It might even make it worse.

But it seems to work well as a ground plane.

[metrologist]

I use an old circular saw blade.

[metrologist]

I plot the self-reported ns, dac, and diff-ns for t=24h to t= 48h, right after I set tc=400.

[iMo]

I was going to ask why is the 1V ADC range used?

Because there is 1.1V Vref inside the atmega328.

[metrologist]

Wouldn't it be better though if you could use the full 5V ADC range with a well regulated 5V supply? It seems the application is just for relative measurements where more resolution/less noise is a benefit.

[iMo]

The default 1ns/1LSB resolution is given by the RC of the pulse integrator (1000ns/1V) and the ADC resolution (1000 levels off the 1024 used) at Vref=1.1V.

You may try to decrease the tau=RC five times and use 5V Vcc as the ADC_Vref.

PS: ..or, you may try with 100ns/5Volt and the internal 10bits ADC. That gives you 100ps/LSB. Not sure what else would be impacted in the sw.

Mind with lower C you will get larger drop on the C because the leakages and dynamic parasitic capacitancies (ie the schottky diode and the ADC input), thus the non-linearity will be much higher.
Also with 5V Vcc at the 4046 the theoretical Vmax at the C will be around 4.6V only.

PPS: it may help to add a fet-input opamp as the ADC buffer.. And a fet switch for the C discharge, of course

[metrologist]

Yeah, more would be needed. It looks ugly.

[iMo]

This works fine

[metrologist]

It looks beautiful, but wouldn't that overload the 4046? That's why I used a 250 ohm resistor.

[iMo]

It will not work with 4046 (its phase_comparator_3 output is a voltage source).
You need a current source, feeding the diode. And the current source must be switched on/off by the 4046 (or an other faster phase comp). And all must be pretty fast.
The 100M is the input of a fet-opamp buffer put in front of the ADC.
You also need a switch for discharging the C after the ADC conversion.

[metrologist]

Couldn't you just put an op-amp before the diode? I recall Lars acknowledging similar designs that used a current source here and with the full ADC range, and whether there was really any advantage. He seemed to have a similar tone about using a hardware DAC as well. I should review those designs that he referenced.

What I am seeing in my circuit now is a 10 ns oscillation on an approximate 50 seconds cycle,  and I'm trying to understand what it could mean. I would suspect PPS jitter, but the UCCM reference I'm using should be very good.

[iMo]

Try to decrease the ocxo's gain.

[texaspyro]

One PID tuning technique is to set the D and I terms to 0.   Then crank up the P term until it starts oscillating.  Next increase D until it stops.   Finally, mess with I until your brain leaks out your nose.

[metrologist]

My last plot shows the dac in red trace - it is not changing over periods of 30 mins or maybe more. The dac does track/correct longer term drifts. What could oscillate with such a long period (50s)? I am powering this from a linear supply into a 7805 regulator.

[Miti]

My last plot shows the dac in red trace - it is not changing over periods of 30 mins or maybe more. The dac does track/correct longer term drifts. What could oscillate with such a long period (50s)? I am powering this from a linear supply into a 7805 regulator.

Assuming your blue trace is diff_ns, I see a similar behavior but with a different period and I think it is normal. The way the PPS is generated, if I understand correctly, from a clock that in case of Ublox is 48MHz, the CPU selects the best 48 millionth (+/- 1) or so edge to trigger the PPS. If your GPS's clock is so close to, let's say, 48MHz and the same (48th millionth) edge is the best for awhile, it will select that same edge, that drifts slowly however, to trigger the PPS pulse. Until one point when the 48th million and 1 is the best edge , and at that point you see the jump.
Or maybe your GPS has a VCXO and it keeps adjusting the clock.

[metrologist]

The blue trace is ns. The green is diff_ns.

I could suspect the GPS/PPS if its jitter was expected to be around 25ns. Someone had posted their Trimble UCCM GPSDO measurements were much better (2ns?). Which edge is more likely to be moving?