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_telemetry
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.
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 Kevin Neilson●July 12, 20132013-07-12
>
> Kevin wrote I should chose it around 250 the sampling frequency
This 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 commsignal●July 11, 20132013-07-11
>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!
>
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 Vladimir Vassilevsky●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 Tim Wescott●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 Eric Jacobsen●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
>loop
You 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.com
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
Reply by Eric Jacobsen●July 10, 20132013-07-10
On Wed, 10 Jul 2013 18:57:55 -0500, "commsignal" <58672@dsprelated>
wrote:
>>On Wed, 10 Jul 2013 16:14:18 -0700 (PDT), Kevin Neilson
>><kevin.neilson@xilinx.com> wrote:
>>
>>>
>>>>
>>>> g2 = if(sgn(si)!=sgn(sl), sh*(sgn(si)-sgn(sl)),0)
>>>>
>>>
>>>This sounds good, except I think it would only work for BPSK/QPSK, not
>QAM or 8-PSK.
>>
>>Gardner's detector works for m-PSK/m-QAM, but the gain may change a
>>bit between modulations. As long as the modulation is symmetric
>>around zero the oddball transitions still wind up contributing to the
>>output on average, which is all you need. Often for higher-order
>>modulations only a single sample/symbol is available and M&M is a more
>>suitable detector.
>>
>>
>>Eric Jacobsen
>>Anchor Hill Communications
>>http://www.anchorhill.com
>>
>
>Is there any specific logic behind working with only 1 sample/symbol for
>higher-order QAMs?
There's nothing stopping anyone from using more than 1 sample/symbol
if they really want to, but it usually (in my experience) incurs
unnecessary complexity. So a system designed with cost and/or power
sensitivity in mind may opt to go with 1 sample/symbol, especially if
the symbol rate is high.
Since higher-order modulations are typically used at reasonable SNRs,
there's often not a compelling reason to use more than 1
sample/symbol.
Gardner's TED was originally developed for systems where rotational
invariance is necessary, i.e., there's no phase lock. That's
generally not possible with higher-order modulations.
Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com