I am trying to implement 3rd order DPLL in software using the DPLL paramete= rs from the article "Controlled-root formulation for digital phase-locked l= oops" by S.A.Stephens and J.B.Thomas (http://sci-hub.cc/10.1109/7.366295). The DPLL is a part of the GPS L1 C/A carrier tracking loop. As a basis, I am using the digital boxcar block diagram from Elliot D. Kapl= an book as shown here http://tinyurl.com/jtm6vau with excluded T multiplier= s, where T is the loop update time. That seem to be logical, if you look at= the equation (4) in the Stephens' article.=20 I am testing the DPLL with a slowly changing Doppler (1Hz/sec) and so far I= have tried different loop parameter values for various BL*T from the look-= up table from the article. The problem is that DPLL does not lock. I am sur= e I made a mistake in the DPLL implementation, but I cannot figure out wher= e. Here is the basic pseudocode I have: phase_acc +=3D phase_error * K3 sum =3D phase_acc + phase_error * K2 phase_vel +=3D sum sum =3D phase_vel + phase_error * K1 carr_freq =3D sum * 1 / T , where=20 K1, K2, K3 are from the from table VIII from the article T is the loop update time in seconds phase_error is the phase error reported by Costas discriminator phase_acc is a phase acceleration. The memory element of DPLL phase_vel is a phase velocity. The memory element of DPLL sum is a temporary variable to keep intermediate sums Any hints are very much appreciated.
DPLL schematics for the parameters computed based on the controlled-root formulation
Started by ●July 20, 2016
Reply by ●July 20, 20162016-07-20
On 20.7.16 11:47, adel wrote:> I am trying to implement 3rd order DPLL in software using the DPLL parameters from the article "Controlled-root formulation for digital phase-locked loops" by S.A.Stephens and J.B.Thomas (http://sci-hub.cc/10.1109/7.366295). > The DPLL is a part of the GPS L1 C/A carrier tracking loop. > As a basis, I am using the digital boxcar block diagram from Elliot D. Kaplan book as shown here http://tinyurl.com/jtm6vau with excluded T multipliers, where T is the loop update time. That seem to be logical, if you look at the equation (4) in the Stephens' article. > I am testing the DPLL with a slowly changing Doppler (1Hz/sec) and so far I have tried different loop parameter values for various BL*T from the look-up table from the article. The problem is that DPLL does not lock. I am sure I made a mistake in the DPLL implementation, but I cannot figure out where. Here is the basic pseudocode I have: > > phase_acc += phase_error * K3 > > sum = phase_acc + phase_error * K2 > phase_vel += sum > sum = phase_vel + phase_error * K1 > carr_freq = sum * 1 / T > > , where > K1, K2, K3 are from the from table VIII from the article > T is the loop update time in seconds > phase_error is the phase error reported by Costas discriminator > phase_acc is a phase acceleration. The memory element of DPLL > phase_vel is a phase velocity. The memory element of DPLL > sum is a temporary variable to keep intermediate sums > > Any hints are very much appreciated.Check your signs. It is not obvious which way the corrections are made here. It seems to me that a positive phase error increases the frequency, and it maybe carries your loop farther away from the true lock. -- -TV
Reply by ●July 20, 20162016-07-20
On Wed, 20 Jul 2016 14:28:53 +0300, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:>On 20.7.16 11:47, adel wrote: >> I am trying to implement 3rd order DPLL in software using the DPLL parameters from the article "Controlled-root formulation for digital phase-locked loops" by S.A.Stephens and J.B.Thomas (http://sci-hub.cc/10.1109/7.366295). >> The DPLL is a part of the GPS L1 C/A carrier tracking loop. >> As a basis, I am using the digital boxcar block diagram from Elliot D. Kaplan book as shown here http://tinyurl.com/jtm6vau with excluded T multipliers, where T is the loop update time. That seem to be logical, if you look at the equation (4) in the Stephens' article. >> I am testing the DPLL with a slowly changing Doppler (1Hz/sec) and so far I have tried different loop parameter values for various BL*T from the look-up table from the article. The problem is that DPLL does not lock. I am sure I made a mistake in the DPLL implementation, but I cannot figure out where. Here is the basic pseudocode I have: >> >> phase_acc += phase_error * K3 >> >> sum = phase_acc + phase_error * K2 >> phase_vel += sum >> sum = phase_vel + phase_error * K1 >> carr_freq = sum * 1 / T >> >> , where >> K1, K2, K3 are from the from table VIII from the article >> T is the loop update time in seconds >> phase_error is the phase error reported by Costas discriminator >> phase_acc is a phase acceleration. The memory element of DPLL >> phase_vel is a phase velocity. The memory element of DPLL >> sum is a temporary variable to keep intermediate sums >> >> Any hints are very much appreciated. > > >Check your signs. It is not obvious which way the corrections are made >here. It seems to me that a positive phase error increases the >frequency, and it maybe carries your loop farther away from the true lock.Yes, sign errors are very easy to make. The sense of the phase detector and other parts of the loop are often implementation dependent, so are always subject to getting it wrong. It's usually pretty easy to reverse the sense of the detector (or the whole loop) and see whether it was a sign error.
Reply by ●July 20, 20162016-07-20
On Wednesday, July 20, 2016 at 7:30:16 PM UTC+3, Eric Jacobsen wrote:> On Wed, 20 Jul 2016 14:28:53 +0300, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: >=20 > >On 20.7.16 11:47, adel wrote: > >> I am trying to implement 3rd order DPLL in software using the DPLL par=ameters from the article "Controlled-root formulation for digital phase-loc= ked loops" by S.A.Stephens and J.B.Thomas (http://sci-hub.cc/10.1109/7.3662= 95).> >> The DPLL is a part of the GPS L1 C/A carrier tracking loop. > >> As a basis, I am using the digital boxcar block diagram from Elliot D.=Kaplan book as shown here http://tinyurl.com/jtm6vau with excluded T multi= pliers, where T is the loop update time. That seem to be logical, if you lo= ok at the equation (4) in the Stephens' article.> >> I am testing the DPLL with a slowly changing Doppler (1Hz/sec) and so =far I have tried different loop parameter values for various BL*T from the = look-up table from the article. The problem is that DPLL does not lock. I a= m sure I made a mistake in the DPLL implementation, but I cannot figure out= where. Here is the basic pseudocode I have:> >> > >> phase_acc +=3D phase_error * K3 > >> > >> sum =3D phase_acc + phase_error * K2 > >> phase_vel +=3D sum > >> sum =3D phase_vel + phase_error * K1 > >> carr_freq =3D sum * 1 / T > >> > >> , where > >> K1, K2, K3 are from the from table VIII from the article > >> T is the loop update time in seconds > >> phase_error is the phase error reported by Costas discriminator > >> phase_acc is a phase acceleration. The memory element of DPLL > >> phase_vel is a phase velocity. The memory element of DPLL > >> sum is a temporary variable to keep intermediate sums > >> > >> Any hints are very much appreciated. > > > > > >Check your signs. It is not obvious which way the corrections are made==20> >here. It seems to me that a positive phase error increases the=20 > >frequency, and it maybe carries your loop farther away from the true loc=k.>=20 > Yes, sign errors are very easy to make. The sense of the phase > detector and other parts of the loop are often implementation > dependent, so are always subject to getting it wrong. It's usually > pretty easy to reverse the sense of the detector (or the whole loop) > and see whether it was a sign error.It looks like it works, if I modify the above implementation like this: phase_acc +=3D phase_error * K3 / T sum =3D phase_acc + phase_error * K2 / T phase_vel +=3D sum sum =3D phase_vel + phase_error * K1 / T carr_freq =3D sum It works for small BL*T values. However I seem cannot make it working for B= L*T values more than 0.1. The article claims it should work for BL*T values= up to 0.4.
