[GPS_Standard] GPSstd_PLL - what's next
Bob Stewart
bob at evoria.net
Wed Dec 11 19:08:30 EST 2013
Hi Michal,
"May be I'm getting old but working with H/W for almost 40 years
I'm concluding that with a plenty of high class components
available, the time spending on tricked "low cost solution" is
not worth this small extra cost"
I appreciate the sentiment, but I'm disabled, and I chose this as a good, long project within my capabilities. It's damn near impossible to accomplish reliably, which makes it an even more interesting project. =) My goal isn't really to have a whiz-bang almost state of the art commercial-grade GPSDO to use in my "lab". If it were, I could probably have bought one with the money I've spent doing this. My goal is exactly what I'm doing: puttering around with code in a new environment. Back in the day I wanted to do something interesting as a programmer. Now I have the opportunity.
As to going to a 16-bit hardware DAC, I thought about it, but the problem isn't really the limitations of the onboard PWM. It can be summed up easily: There is only a binary go/no-go phase detector and the data feeding it has serious problems because of the sawtooth. So, there is no way to correct the sawtooth on the 1PPS from the GPS receiver. Here's another plot that exemplifies the problem. Notice the nasty S-curve on the DAC voltage at 17:00, then look down at the mess coming from the GPS that caused it. And yet, it dropped back into phase lock, after spending about 30 minutes in what was for all intents and purposes, holdover. Of course, sometimes there's a phase slip, and that's probably just the way it's going to be with this board. Hey, what do you expect for free? =)
http://www.evoria.net/AE6RV/GPSstd_PLL/Plots/Sawtooth-Sine.png
Bob
>________________________________
> From: SP2IQW <michal at e2000.gdynia.pl>
>To: Bob Stewart <bob at evoria.net>
>Sent: Wednesday, December 11, 2013 5:06 PM
>Subject: Re: [GPS_Standard] GPSstd_PLL - what's next
>
>
>
>Hi Bob,
>
>I think that you are touching at least three limits which may be
hard to solve with the basic Bert's hardware design.
>
>1. current DAC PWM scheme is the first limitation which needs a
lot of tricks to minimize the side-effects.
>
>You can try what I did to get a clean and low noise voltage
reference for PWM D/A converter. Some phase jumps may be supply
voltage referenced. The 7805 voltage regulator is a good
solution for general purpose but not a precise analog circuits.
See attached CD.
>
>More radical step is to use proven 16-bit DAC with internal
voltage reference or with external reference.
>As I have mentioned some time ago, take a look at TI's
DAC8560. Costing only $8,92 at Digikey (DAC8560ICDGKT) this
device looks like a perfect solution.
>All versions has 16-bits monotonicy and either 25 or at few
more cents 5ppm/°C internal voltage reference stability.
>This way all DAC related problems should be far eliminated.
>
>You have said that you want to keep original Bert's H/W design.
I understand you but some times it may be to costly (in terms of
time spend on code) and with no big chance to surpass some
limitations.
>We can still keep the original H/W with some unused pins
connected to the real DAC At this point the software will probably go in two branches (one PWM and the second "real" DAC).
>
>As I'm preferring such DAC solution I can make the schematic and
the PCB project and either to share the Gerber files or even the
PCB board (I can order locally few pcs as I have few friends
which are interested also in such solution).
>
>2.
>Some limitations may be still GPS related as you have observed.
As you remeber I have commented MTK chipsets (my e-mail dated
Nov. 15).
>Without special customized software for timing application the
standard GPS (also MTK) receiver will be targeted to keep
navigation solution (not timing). Some level of customization
for Mediatek receivers is availble through distrributors
(usually expecting some volume of sales).
>The better solution is to use dedicated timing receiver but more
recent design than an old one Oncore. The choice is simple -
Trimble modules (my friend dealing with Trimble devices said
that Trimble on the GPS market is like a BMW on a car market).
>Easly available and at resonable cost are Resolution SMT™ GG
module. Although PPS is specified as ± 15ns (MTK states ± 10ns)
the PPS delivered by Trimble should be free from cummulated
errors and can be precisely monitored by available Trimble
timing S/W tools (at no cost).
>
>3.
>It is worth to monitor the quality of GPS signal. Then the GPS
will lost sattelite view the PPS is kept from its TCXO or even
32768Hz watch crystal in a backup state. In such situation the
GPS should immediately go to the holdover state (not waiting for
the lack of PPS signal which usually is supplied some more time
after loosing navigation solution).
>Is there a place in a flash for monitoring GPS data frame ? I
think not (it needs also to use the second UART). The better
solution is to use another microprocessor additionaly
controlling LCD display and with some GPS initialization
procedures build-in) with one extra line "validity flag" fed to
PIC182220 uP.
>
>May be I'm getting old but working with H/W for almost 40 years
I'm concluding that with a plenty of high class components
available, the time spending on tricked "low cost solution" is
not worth this small extra cost.
>
>
>References:
>http://www.ti.com/lit/ds/symlink/dac8560.pdf
>http://www.digikey.com/product-search/en?vendor=0&keywords=DAC8560ICDGKT
>http://www.trimble.com/timing/resolution-smt-GG.aspx >> Support (files)
>http://www.trimble.com/timing/pdf/022542-039A_Resolution_SMT_GG_DS_0412_US_LR.pdf
>
>http://www.dpieshop.com/trimble-resolution-smt-gg-gpsgnss-timing-receiver-p-1251.html?osCsid=nfhk9j21ijiblvfg64fuoderk0
>http://www.dpieshop.com/trimble-resolution-smtx-gps-timing-receiver-p-1250.html?osCsid=nfhk9j21ijiblvfg64fuoderk0
>
>Best 73!
>Michal
>sp2iqw
>
>
>
>
>W dniu 2013-12-11 05:06, Bob Stewart pisze:
>
>Hello the list,
>>
>>This is rather long, so if you're not interested in details,
this post is probably not for you.
>>
>>Until now, my code has been focused on trying to get as
accurate and stable a frequency as possible. But, from the
beginning, as the name GPSstd_PLL implies, I have been
targeting phase lock. I have code that I am not quite ready
to release, but I thought I'd show a couple of plots: one
showing the success I'm seeing, and the other a case when the
code fails.
>>
>>First, the success:http://www.evoria.net/AE6RV/GPSstd_PLL/Plots/Success.png
>>
>>The plot has a number of debug fields, so let me try to
explain what's going on. First of all, in green is the phase
error line. I've rotated it so that 180 degrees of phase
error is sitting more or less at the "0" tic, on the right.
This makes it easier to see the lock to phase. It rises a
bit, which I think is probably drift in my HP 5334B, though I
could be wrong. This shows a 10MHz signal that is held pretty
tightly to the phase of the 1PPS signal from my Adafruit
Ultimate Breakout GPS Receiver. But, there are a number of
problems, if you look at it. The biggest problem seems to be
that the 1PPS signal suffers from sawtooth. It's not nearly
as bad as that from the Oncore UT+, in that it doesn't move
more than 10ns - usually. However, like the Oncore, it does
tend to concentrate to one side or the other from time to
time. But, instead of a 370 degree phase jump, we see
something more like an 18 degree (or so) phase jump,
>> and the
>> width of the phase scatter (thickness of the green line)
decreases. Since it moves to one side and narrows, the code
has to move the frequency of the OCSO there and hold it in a
very tight range, in order to keep the phase relatively
centered. This doesn't always work.
>>
>>Next on the plot is the familiar blue line of the DAC
voltage. Notice that I have done some more tinkering with the
binary search. It now reaches the best solution about as
quickly as is possible, without any double-backs, once the DAC
stops moving in steps of 0x80. If you follow the blue line,
you will notice that suddenly it gets thick. This is when I
turn it into a PWM (Pulse Width Modulator). Think of it like
this: the OCXO is only tunable in steps. In the case of the
14-bit DAC that Bert implemented, that works out to one step
being equal to the OCXO's tuning range divided by 18384. So,
if 10MHz lies exactly on one of those steps, we are good to
go. But if, as is usually the case, it lies between two of
those steps, we have a problem. We can either accept the
frequency error, or we can skip back and forth between the
step on either side. If we choose our timing carefully, we
will, on average, get 10MHz. If we are
>> even more
>> careful, we can keep the phase of our 10MHz signal within a
very narrow range; which we have done on this plot.
>>
>>But, there is a problem with this simple PWM. What happens
if, due to heat or crystal aging, the exact 10MHz spot moves
to the next pair of steps over? The answer to that is to move
the PWM over so that it skips back and forth between the two
steps surrounding our new perfect 10MHz spot, which you can
see happening.
>>
>>Unfortunately, there's a problem keeping the phase locked when
the spot lies almost exactly on one of the steps. In that
case, our PWM will have to hunt back and forth between two
pairs of steps to keep the phase correct. You can see that
happening throughout the plot, with it getting even more
complicated as we add in the sawtooth from the GPS receiver.
>>
>>In about the middle of the plot we have the red lines. These
lines indicate how long it's been since the most recent DAC
update. When it reaches 28 seconds (found by trial and error)
the DAC is moved one more step in the same direction as it's
most recent step from our PWM. If that's not enough, then we
lose phase lock; which will be seen in another plot.
>>
>>At the bottom of the plot is a broken black line. This is a
"debounce" count. It turns out that since we move the DAC in
discrete steps, sometimes there is an overshoot big enough to
get some invalid frequency errors. Again, by trial and error,
I am using a value of 6 to debounce the DAC update.
Essentially, after the hand of god moves the DAC to the next
step pair, we have to wait until it's well and truly locked
before we allow the hand of god to touch the DAC again.
>>
>>And finally, at the top of the plot are brown lines. These
are proportional to the duty cycle of our PWM. The lines
going upward from the 30 tic (on the right) are the duty cycle
for steps in the positive direction. And conversely, the
lines going down are the duty cycle for steps in the negative
direction. Notice that large movements of the duty cycle
correspond with changes by the hand of god. I don't have them
directly tied to the movement yet, but I'm giving it some
thought. Getting more and more data out of the two simple
inputs we have, and understanding what to do with it, has been
a long and arduous task.
>>
>>Now, the failure:http://www.evoria.net/AE6RV/GPSstd_PLL/Plots/PhaseBork.png
>>
>>
>>Well, it's not so much a failure, as a limit to our success.
Notice that there are two points where the phase line (green)
suddenly jumps. One is at about 11:18 and the other is at
about 12:36. Notice also, that if you grabbed the whole green
line between them and moved it down, would seemingly join with
the rest of the green trace, other than the phase skip,
represented by the line cycling through 360 degrees. This
sudden movement was just more than my code could account for,
and it lost phase lock for one full cycle of phase. But, on
the other hand, the result is no worse than what happens with
the best of my frequency-control only code, so I can't really
count it as a failure.
>>
>>I'm not really sure what caused this sudden lurch, but I have
my suspicions. There is a command that you can send the
Adafruit to set the Nav Speed Threshold. This is supposedly a
speed below which the Adafruit will not change its location,
and thus it's computation of the 1PPS signal's phase. But,
due to fresh satellites appearing on the horizon, combined
with multi-path errors, the Adafruit must eventually warp to
wherever it's drifted to. Eventually, it will warp back as it
gets a better solution from the satellites, but the damage is
done. I had set my Nav Speed Threshold to 1.8, and I suspect
that that's what caused this particular "tearing" of the phase
line. I'm not sure how, or even if I can address this. I'll
eventually have to set it back to 0.0 and see what the result
is.
>>
>>
>>So, anyway, this is where I am with GPSstd_PLL, and it is the
future direction of my code. At this point, I think it will
always be at least as accurate, frequency wise, as previously
released versions. There is the cost of phase noise, though,
from the new PWM switching the DAC back and forth. But, don't
forget that Bert's least significant 4 bits are the result of
dithering the internal PWM. So, there is phase noise there,
in any case - even from the hardware PWM. Unfortunately, I
don't have good enough test equipment to quantify it. Nor do
I have the budget for it. =)
>>
>>
>>I will try to clean up my code enough to release it before
Christmas. I've gotten most of the junk out of it, but there
are comments scattered here and there, as is usual for me. It
will still not be Version 1.0. Oh, by the way, I have
achieved this phase lock mostly by butchering State Machine
2. At this point, I don't plan to put that back in in its
original form. Like I said, my goal has always been to lock
to phase. But, if someone has a specific reason to get SM2
back, or to just turn off the phase lock PWM, I can
accommodate that.
>>
>>And I'd like to issue a plea for help testing this. As it is,
I can only test my setup. If you have a good Universal
Frequency Counter, like my 5334B, and a GPIB adapter, I'd
really appreciate it if you could do some testing for me and
give me the results. I have sample code to run the GPIB, but
it's coded for a Prologix Ethernet GPIB adapter running on
Linux.
>>
>>Thanks for reading through this long-winded mess.
>>
>>Bob - AE6RV
>>______________________________________________________________
>>GPS_Standard mailing list
>>Home:http://mailman.qth.net/mailman/listinfo/gps_standard
>>Help:http://mailman.qth.net/mmfaq.htm
>>Post:mailto:GPS_Standard at mailman.qth.net
>>
>>This list hosted by:http://www.qsl.net
>>Please help support this email list:http://www.qsl.net/donate.html
>>
>>
>
>
>
>
More information about the GPS_Standard
mailing list