Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Miti]

Hi,

I'm having some troubles with my Lars GPSDO. After more than 7 months (or so) when it stayed locked, it started loosing lock every few days. I caught some events that seem to be satellite related, unless the OCXO shifts phase all of a sudden. Please take a look. What do you think?
First I thought is power loss but it is connected to a UPS and it didn't loose a PPS for almost 9 months.

[iMo]

External GPS antenna is dying?

[Miti]

External GPS antenna is dying?

I don't have an external antenna, it is at the window. It didn't give me any troubles for 7 months.

[metrologist]

It looks like you briefly lost gps lock, then are settled back into lock 12 hours later with a dac value ~30 points higher. How much does your dac vary in a day? I would plot dac variances over a long period to look for a trend.

[bingo600]

Just found this nice PCB
https://github.com/Qw3rtzuiop/Lars-GPSDO-PCB

The pict(s) are for the rev1 pcb , not the rev2.

I just ordered a few on JLCPCB

/Bingo

[Qw3rtzuiop]

Hello bingo600,
im responsible for the crappy pcb design.
I use the rev. 2 happily but im not a timenut and cannot confirm that this design is perfect.
The rev. 1 was missing an output buffer. Even plugging in some cables changed the output signal that the GPSDO unlocks.
Adding an output buffer fixed that problem.
I still have 8 unpopulated rev 2 pcbs if anyone is interested (price: shipping costs from germany).

[9aplus]

@Qw3rtzuiop
PM sent

[Jacon]

@Qw3rtzuiop

PM sent yesterday

[Qw3rtzuiop]

I recieved all of your PMs.
When i looked up the prices I noticed that the German Post dont allow private customers to send goods via international mail. Since 2019 only paper is allowed
They are allowed to open and control the content. Instead I should use DHL (5-10€).

Im sorry but if youre outside Germany it is cheaper to buy them at JLCPCB/Elecrow/OshPark/Aisler.

[Jacon]

Aron,

It would be nonsense to produce another pieces, when you have ready & spare ones 
For me, that cost you mentioned is perfectly OK, just send 2 pcs in that package 

[9aplus]

Agree with Jacon
2 pcs for me too 

[Miti]

It looks like you briefly lost gps lock, then are settled back into lock 12 hours later with a dac value ~30 points higher. How much does your dac vary in a day? I would plot dac variances over a long period to look for a trend.

Ok, I started monitoring the GPS. I think there's a flow in this design or in my implementation. Looks like my HC390 misses some pulses. I've attached a stripped down log of the GPS and one of the GPSDO. By my calculation the event happened around 0:58 UTC but around that time the GPS saw a healthy 11-12 GPS satellites and 9-10 Glonass. At no point around that time the lock was lost. The jump seems to be of about 500ns. I've also attached two more pictures with captures of lock loss, one of them again with a jump of about 500ns. Is like it looses half of the 1MHz pulse, like there's a 180 shift in phase at the 1MHz output.
In the gps.csv, the time is in GGA column 2 and the number of satellites in GSV column 4.
Do you have another idea?

This started happening randomly after 8 - 9 months with no issues.

[iMo]

Try to heat-up or cool-down the HC390..

[metrologist]

I started wondering what it would look like if any one of the four edges were missed? It would be interesting to see the signals on a scope when this phase jump happens, perhaps by using a mask test and halt on fail. I wonder if EMI/RFI could be involved or whether some buffering/filtering could help.

[Dbldutch]

Hi all,

I have build the GPSDO following the original schematic on perf board, although made some small changes. I'm using the Bliley NV47A1282. My version seems to have a finicky output because the slightest loading distorts the sine wave. After trying a couple of things I resorted to using another HCT4046 to create a square wave with an almost 50% duty cycle. I also used 100R in series between the HC390 and the Arduino Nano and another 100R in series with the HC390 10MHz input.

To create a mid-point for the DAC range at the mid-point of the Bliley frequency range, I used the 1PPS signal of my (genuine) NEO-M8T and the free running Bliley output on my scope, and adjusted it with a trimmer to get a steady, non moving drift, creating a manual lock. I then replaced the trimmer setting with a resistor in my case of 200K. The total DAC range now has a adjustment range of 7.9Hz. I verified this all with my counter.

I have noticed two problems.
The first problem is that using H1 to determine the gain does not work for me. The ns results drift linearly way out of range. Same with h65353. Setting the DAC value at mid-point creates a repeating but steady range of numbers, as expected. To calculate the gain, I used the delta of the Bliley in Hz, which is 7.9 Hz, or 790ppB resulting in a gain of 83, if my math is correct.

The second problem is that with the standard lowest offset of 200, I can't get a lock, and if so, only for very brief periods.  The ns value is too far out of range,  beyond -100.  I could cheat by set a higher lockPPSlimit in the code, but then a Lock is reported while there is too much jitter.

I modified the code to allow me to set the offset as low as 10. At an offset of 100, I got a lock, but still with too much drift. When I changed the gain from 83 to 830, the resulting lock has been running for 24 hrs without a glitch and with minimal jitter, I think. I have steadily increased the damping and I'm now running at a damping level of 10. I'm not sure if the damping counteracts the higher gain that I needed to set, but even at a damping factor of 0.5, everything seemed to work fine.  See the attached scope capture of the 5MHz signal and the signal at the anode of the Schottkey Diode.

Can anybody enlighten me on these two issues?

Tks, Paul

[Dbldutch]

Miti,

I don't think your problem is related to the GPS. The HC390 is not connected to it, only to the oscillator. The missing pulse must be found in that chain.
While monitoring my system for hours, while attached to a scope, I also noticed missing pulses or strangely distorted ones.
They can be observed or found easier if you can use the persistence setting of your scope, as I do. I doubt it is the HC390.
Below you can see such a strange behavior. Note that the small wiggle on the 5MHz caused a serious glitch or missing pulse on the anode side of the diode.
It probably caused the irregular entries in the trace.

I use a Bliley NV47A, but have two other types on order because I don't really trust mine yet, also because it has a very weak output driving capability.

Good hunting,

Paul

[iMo]

..I then replaced the trimmer setting with a resistor in my case of 200K. The total DAC range now has a adjustment range of 7.9Hz. I verified this all with my counter.

How did you wire that 200k resistor, plz?

[Dbldutch]

Hi Imo,

The 200K resistor is between the VC of the Bliley and ground.

[iMo]

See the attached scope capture of the 5MHz signal and the signal at the anode of the Schottkey Diode.

Where the 5MHz signal is coming from? It should be 1MHz, afaik.
1MHz signal is 1us period.

Lars assumed the 1PPS rising edge sets the RS FFlop (aka phase comparator III) high, the RC starts charging via the schottky.

The upcoming edge of the "1us" pulse from HC390 then resets the RSFF to low, the RC stops charging and you get a voltage at the 1nF capacitor. The voltage is measured with the ADC afterwards.

The RC is set such the midpoint of the 1us period (500ns) is in middle of the 1.1V range of the atmega's ADC, that is about 0.5V.

Any phase diff between the 1PPS edge and the "1us" edge will create a different voltage, while 500ns diff is 0.5V.
The control loop via the MCU/DAC then sets the OCXO's freq such the phase difference between the 1PPS edge and "1us" edge is always as close as possible to 500ns (that means 0.5V at the ADC's input).

One problem I see is the simple RS FFlop. It is level sensitive, not edge sensitive. The phase comparator II is edge sensitive,
its output (pin1) inverted could be a better solution, imho.

With the current phase comparator III you may use a 74HC00 instead. My guts feeling is with such a simple RS FFlop the phase may revert suddenly and instead of, say, +15ns phase diff it will show -485ns next step (that is 500ns difference, the half of the 1us period).

Needs to be analysed somehow by experts, imho..

[Miti]

Hi all,

I have build the GPSDO following the original schematic on perf board, although made some small changes. I'm using the Bliley NV47A1282. My version seems to have a finicky output because the slightest loading distorts the sine wave. After trying a couple of things I resorted to using another HCT4046 to create a square wave with an almost 50% duty cycle. I also used 100R in series between the HC390 and the Arduino Nano and another 100R in series with the HC390 10MHz input.

To create a mid-point for the DAC range at the mid-point of the Bliley frequency range, I used the 1PPS signal of my (genuine) NEO-M8T and the free running Bliley output on my scope, and adjusted it with a trimmer to get a steady, non moving drift, creating a manual lock. I then replaced the trimmer setting with a resistor in my case of 200K. The total DAC range now has a adjustment range of 7.9Hz. I verified this all with my counter.

I have noticed two problems.
The first problem is that using H1 to determine the gain does not work for me. The ns results drift linearly way out of range. Same with h65353. Setting the DAC value at mid-point creates a repeating but steady range of numbers, as expected. To calculate the gain, I used the delta of the Bliley in Hz, which is 7.9 Hz, or 790ppB resulting in a gain of 83, if my math is correct.

The second problem is that with the standard lowest offset of 200, I can't get a lock, and if so, only for very brief periods.  The ns value is too far out of range,  beyond -100.  I could cheat by set a higher lockPPSlimit in the code, but then a Lock is reported while there is too much jitter.

I modified the code to allow me to set the offset as low as 10. At an offset of 100, I got a lock, but still with too much drift. When I changed the gain from 83 to 830, the resulting lock has been running for 24 hrs without a glitch and with minimal jitter, I think. I have steadily increased the damping and I'm now running at a damping level of 10. I'm not sure if the damping counteracts the higher gain that I needed to set, but even at a damping factor of 0.5, everything seemed to work fine.  See the attached scope capture of the 5MHz signal and the signal at the anode of the Schottkey Diode.

Can anybody enlighten me on these two issues?

Tks, Paul

Yes, I have the same issue with the sine wave. That's why I did what you did but the output was still distorted. So in the end I added a resistor divider, something similar to Brooks Shera but different resistors, I don't remember the exact values, see attached, and I think that's the weak point that misses some pulses.

I also saw the other issue with H1, H65535, TIC_Offset. Don't bother changing the code. Measure your voltage at the VC pin of the OCXO with H1 and H65535. and scope the A0 pin. I bet it doesn't stay at 0V in between pulses. You need shorter and thicker ground wires. Here are the parameters that I'm using now.

EEPROM content:
restarts = 18
totalTime3h = 3159
temperature_Sensor_Type =  11
ID_Number = 0
TICmin = 120
TICmax = 1012
x2 = 100
TIC_Offset = 500
filterDiv = 2
warmUpTime = 300
damping = 300
tempRef = 417
tempCoeff = 200
dacValueOut = 22679
gain = 122
timeConst = 500
k = 111

Edit: See some screenshots in Reply #49.

[Dbldutch]

imo,

Thanks for the explanation.
I should point out that my circuit works well, even with a TC of 500 over 24 hours. I have not gone beyond that yet.
I understand the working of the hardware, and verified the working of it, but still have problems with the presented results from the software though.

For my scope screenshot, I simply used the 5Mhz signal (output of the HC390 going to D5 of the Nano) as a reference for the diff_ns signal at the anode of the diode. I could have used the 10Mhz, or the 1MHz of course, to see the drift and jitter. I don't think that makes a difference?

After realizing that I should use the diff_ns values for the gain calculation, and not the ns values, I was able to get a decent gain value. I simply used Excel to let it calculate the average of the diff_ns values out of about two pages of the report. H1 produced +240 and H65K -166, resulting in a gain of 161.
Why this is significantly different from using the "real" frequency values for H1 & H65K of the OCXO itself (gain is 83) is one of the puzzles I have.

I appreciate the time and effort you guys put in to help others! 

Paul

[Dbldutch]

Miti,

Thank you for the elaborate answers. As with imo, I applaud you for your help in this forum! 

I'm still struggling to understand what the software tells me, because in essence, my hardware seems to work very well.

Attached is a screen dump of both sides of the diode. As you can see, the ground level for the ADC has no issues. I took several precautions. As you know, the pulse height is compromised due to the X10 probe loading. The signal is a bit noisy probably because of my rather long probe ground lead and even more the fact that I use proto-board without a ground plane.

BTW, just for fun & learning, I also measured at what part of the pulse the ADC reads it, by adding a port output to the code that creates a pulse around that operation. The rising edge is pretty linear, but the discharge is not, and here is where the ADC measurement takes place. Does not matter much I think.

What I'm still struggling with is the relationship of what I'm seeing on the scope in terms of the width of the delta pulse signal (anode of diode), and what gets reported by the code.
If I understand the explanation from Lars, the filtX10 number includes the offset. If I take that number and subtract the offset, I get very close to what I see on the scope.

However, I still don't quite get the diff_ns reports in relation to filtX10 and also the ns numbers. They don't seem to jive with each other although Lars went through great pains in the code to get everything converted to ns. Maybe it's the damping? Mine is currently at 3 now. I need to play with that setting more.

I will certainly look at your settings and try them, and see if there are any glaring differences.

Tks,
Paul

[Dbldutch]

The Bliley NV47A1282 where I already suspected a flaky output amplifier, just died on me. No signal out anymore. 
These used Blileys have a long but very sad history with me now. The first one that arrived was DOA, never had an output. A replacement never arrived, and the third one died after a few weeks.
With 4-6 weeks shipping time for each one, I've given up. Be aware...

[Satbeginner]

The Bliley NV47A1282 where I already suspected a flaky output amplifier, just died on me. No signal out anymore. 
These used Blileys have a long but very sad history with me now. The first one that arrived was DOA, never had an output. A replacement never arrived, and the third one died after a few weeks.
With 4-6 weeks shipping time for each one, I've given up. Be aware...

For what its worth: I have a (used and aged) Bliley running for almost two years now with no problems.....

Just my two cents,

Un saludo,

Leo

[metrologist]

BTW, just for fun & learning, I also measured at what part of the pulse the ADC reads it, by adding a port output to the code that creates a pulse around that operation. The rising edge is pretty linear, but the discharge is not, and here is where the ADC measurement takes place. Does not matter much I think.

Thanks for your presentations. Does the ADC sample at the shown pulse falling edge? I'd expect the discharge to follow a classic decay curve.

I was never able to get mine to remain locked much above TC 120 and only a few days around TC 240 ( I always needed a better GPS though). It's been a while since I had it on so getting inspired to connect it back up and remember what I was doing.