Alright, I'm going to read all the sources you gave me and I'll get back to you if I have any more questions. For the moment what I plan on doing is: - Compute the S-curve of my detector to have an idea of the slope at the origin - Modify the detector so that its output is zero when there is no change in symbols - Chose a damping factor of 0.707 and implement a proportional-integral loop I just have one more question concerning the natural frequency of the PI. Kevin wrote I should chose it around 250 the sampling frequency while Tim pointed out it should be well below the symbol rate. Which of the two is true? Regarding the "canal" as a matter of fact you were almost right, it's not german but french. Also I know of some application that communicate not through a canal but through mud in a hole, pretty fun! _____________________________ Posted through www.DSPRelated.com
Gardner Timing Error Detector - Loop Filter
Started by ●July 10, 2013
Reply by ●July 11, 20132013-07-11
Reply by ●July 11, 20132013-07-11
On Thu, 11 Jul 2013 02:32:28 -0500, "Gracchus" <98125@dsprelated> wrote:>Alright, I'm going to read all the sources you gave me and I'll get back to >you if I have any more questions. > >For the moment what I plan on doing is: >- Compute the S-curve of my detector to have an idea of the slope at the >origin >- Modify the detector so that its output is zero when there is no change in >symbols >- Chose a damping factor of 0.707 and implement a proportional-integral >loopYou are well on your way to solving the problem.>I just have one more question concerning the natural frequency of the PI. >Kevin wrote I should chose it around 250 the sampling frequency while Tim >pointed out it should be well below the symbol rate. Which of the two is >true?The clock recovery loop should be very narrow. Depending on the application and the channel environment it should be symbol rate/many thousands. In most applications there aren't any impairments that significantly affect the symbol frequency at the receiver. In other words, if the symbol frequency is transmitted even reasonably accurately, it'll be very closely known at the receiver. So the clock loop doesn't have to acquire any significant frequency offset, only phase. And since clock slips are catastrophic to things like descramblers, FEC, frame synch, decoding, etc., etc., you don't want them to happen. Basically, in most cases, all tradeoffs point to a very narrow clock loop.>Regarding the "canal" as a matter of fact you were almost right, it's not >german but french. Also I know of some application that communicate not >through a canal but through mud in a hole, pretty fun!Yes, to both French and mud hole comm. ;)> >_____________________________ >Posted through www.DSPRelated.comEric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●July 11, 20132013-07-11
On Thu, 11 Jul 2013 02:32:28 -0500, Gracchus wrote:> Alright, I'm going to read all the sources you gave me and I'll get back > to you if I have any more questions. > > For the moment what I plan on doing is: > - Compute the S-curve of my detector to have an idea of the slope at the > origin - Modify the detector so that its output is zero when there is no > change in symbols - Chose a damping factor of 0.707 and implement a > proportional-integral loop > > I just have one more question concerning the natural frequency of the > PI. Kevin wrote I should chose it around 250 the sampling frequency > while Tim pointed out it should be well below the symbol rate. Which of > the two is true?You don't know me from Adam so you can't take me as the tie-breaker. But consider: if you had a loop with a natural frequency higher -- or even approaching -- the sampling rate, then the actual value of the natural frequency would be lost in aliasing. Basically, the math does not make sense. For that matter, the timing error detector is a time-varying element. It's not quite a sampler, but aliasing still sorta-kinda applies at the rate that the TED coughs up measurements -- and that slows down the available natural frequency even more. And to cap it all off, you want the PLL to track phase and frequency through noise. The amount of time that a loop averages over is roughly proportional to 1/(natural frequency). You want the PLL to ignore noise (which is splattered all over the spectrum) but pay attention to the timing error (which in most cases moves slowly). To do that you want to average over a long time, which points you in the direction of a low natural frequency. Hopefully Eric or Vladimir will weigh in on this (or Kevin will think about exactly what he said), so you don't feel like you're getting pulled apart by dueling experts.> Regarding the "canal" as a matter of fact you were almost right, it's > not german but french. Also I know of some application that communicate > not through a canal but through mud in a hole, pretty fun!I am sorry about tweaking you about that. I just couldn't resist. I've done work for mud-pulse communications. It's all very routine and boring until you consider the amount of time spent per bit, and the medium, then it's kind of fun. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 11, 20132013-07-11
On 7/11/2013 11:59 AM, Eric Jacobsen wrote:> The clock recovery loop should be very narrow. Depending on the > application and the channel environment it should be symbol rate/many > thousands.The clock recovery should provide timing reference just enough accurate so the impairment due to inaccuracy would not be significant compared to impairments caused by unavoidable factors such as noise. Starting from this point, derive the numbers and calculate optimal loop BW. Acqusition is entirely different story; with different set of considerations and requirements. It depends.> Basically, in most cases, all tradeoffs point to a very narrow clock > loop.Jacobsen = amateur and windbag.
Reply by ●July 11, 20132013-07-11
>Alright, I'm going to read all the sources you gave me and I'll get backto>you if I have any more questions. > >For the moment what I plan on doing is: >- Compute the S-curve of my detector to have an idea of the slope at the >origin >- Modify the detector so that its output is zero when there is no changein>symbols >- Chose a damping factor of 0.707 and implement a proportional-integral >loop > >I just have one more question concerning the natural frequency of the PI. >Kevin wrote I should chose it around 250 the sampling frequency while Tim >pointed out it should be well below the symbol rate. Which of the two is >true? > >Regarding the "canal" as a matter of fact you were almost right, it's not >german but french. Also I know of some application that communicate not >through a canal but through mud in a hole, pretty fun! >I would recommend computing the S-curve both analytically and through simulations. The former will give insight about how the TED gain will change with different parameters, and the latter will verify it. The loop bandwidth should be very narrow. Remember it's the symbol rate tracking you are after. _____________________________ Posted through www.DSPRelated.com
Reply by ●July 12, 20132013-07-12
> > Kevin wrote I should chose it around 250 the sampling frequencyThis was a mistake. I had a divide in my notes instead of multiply. I found another rule-of-thumb for carrier recovery loops that wn should be about 1/500th the symbol rate. I'm not sure about for Gardner loops, but yes, the natural frequency should be a small fraction of the bandwidth.
Reply by ●July 12, 20132013-07-12
> I've done work for mud-pulse communications.Are you guys making this up? I'm not sure I'd want that phrase on my resume: "Mud-Pulse Communications". It sounds steampunky, like in the same realm as the pnuematique intertube network (actually used at one time in Paris and Berlin!) or the voice-pipes on old steamships.
Reply by ●July 12, 20132013-07-12
On Fri, 12 Jul 2013 11:32:42 -0700, Kevin Neilson wrote:>> I've done work for mud-pulse communications. > > Are you guys making this up? I'm not sure I'd want that phrase on my > resume: "Mud-Pulse Communications". It sounds steampunky, like in the > same realm as the pnuematique intertube network (actually used at one > time in Paris and Berlin!) or the voice-pipes on old steamships.https://en.wikipedia.org/wiki/Mud_pulse_telemetry#Mud_pulse_telemetry -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 12, 20132013-07-12
On Fri, 12 Jul 2013 15:20:24 -0500, Tim Wescott <tim@seemywebsite.really> wrote:>On Fri, 12 Jul 2013 11:32:42 -0700, Kevin Neilson wrote: > >>> I've done work for mud-pulse communications. >> >> Are you guys making this up? I'm not sure I'd want that phrase on my >> resume: "Mud-Pulse Communications". It sounds steampunky, like in the >> same realm as the pnuematique intertube network (actually used at one >> time in Paris and Berlin!) or the voice-pipes on old steamships. > >https://en.wikipedia.org/wiki/Mud_pulse_telemetry#Mud_pulse_telemetryand http://en.wikipedia.org/wiki/Pneumatic_tube These things used to be in big office buildings, too. Early in my career I worked a few places that still used these.>-- > >Tim Wescott >Wescott Design Services >http://www.wescottdesign.com >Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
