discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Polyphase clock sync ccf symbols needed ?


From: Sam mite
Subject: Re: [Discuss-gnuradio] Polyphase clock sync ccf symbols needed ?
Date: Mon, 29 Apr 2013 13:10:33 +0500


On Sun, Apr 28, 2013 at 8:39 PM, Tom Rondeau <address@hidden> wrote:
On Mon, Apr 15, 2013 at 12:25 AM, Sam mite <address@hidden> wrote:
>
>
>
>> > Hi list,
>> >
>> > I want to calculate the number of symbols taken by my Polyphase clock
>> > sync
>> > ccf block after which it locks. Although I am getting 0 BER (except at
>> > start) but I want to know after how many symbols loop get lock. And then
>> > by
>> > varying different parameters I want to observe the lock time/symbols
>> > needed.
>> > From which plot I can get this information and how? . Current parameters
>> > set
>> > are:
>> >
>> > Sample/symbpol= 4
>> > Loop BW= pi/100
>> > damp factor= 0.707
>> > filter size = 32
>> > output sps = 1
>> > max rate dev = 1.5
>> > initial_phase=16
>> >
>> > Phase plot is showing some sinusoidal output. Attached are the two phase
>> > plots. phase2.jpg is zoomed in version of phase1.jpg.
>> >
>> > Thanks ahead of time.
>> >
>> >
>> > --
>> > Best Regards,
>> >
>> > Sam
>>
>> Sam,
>>
>> Yes, the phase output port of the sync block is the one you want to
>> look at. The phase rounded to the nearest integer (unless it's the
>> floor) is the number of the filterbank being used at that time, which
>> represents the phase offset of the signal.
>>
>> Are you tracking a real signal being received or a simulated signal?
>> You're going to see some movement, plus or minus, around the closest
>> phase, though. If its a real signal being received, there's going to
>> be some small jitter in the timing between the two radios that the
>> algorithm is trying to track. Also noise will affect if somewhat as it
>> tries to keep a lock. The fact that it looks like it's actually
>> oscillating is interesting. Have you tried to reduce the loop
>> bandwidth to see how that affects things?
>>
>> Tom
>>
>
> Thanks Tom,
>
> Currently, I am tracking a simulated signal (although I am getting zero BER
> through USRPs as well). There is currently no additive noise. Reducing loop
> bandwidth by a factor of 4 gives nice plots, as tracking become good by
> reducing noise bandwidth. But, steady state value of 24 reaches after
> approximately 9000samlples. That means my loop is taking 9000/4 symbols to
> get lock? And after that it 'll produce desired output.  Am i doing
> something wrong? Something I am missing?
>
> Attached are the snapshots of new phase plots.
>
> --
>
> Best Regards,
>
> Sam


Sam,

No, I don't think that you are doing something wrong here. But those
figures you've posted look like the circuit is under-damped. It should
be critically damped,

Why the circuit should be critically damped? In my first mail, I said that I am  using damp_factor= 0.707. It should be under-damped. No? The problem, i think, is that its taking too long 9000/4 symbols to get lock. No ?

so it'd be interesting to see what's going wrong
inside of the algorithm. I've looked at it with this in mind, but I
can't see that anything is being done differently than the normal
control loops that we use, and the parameters should be set to be
critically damped.
This sounds like something we can develop and discuss on the signal
processing wiki page. Would you be able to start something here?
There's already a section for Synchronization. Maybe just create a new
page off that for discussing this particular algorithm/block. 
 
I'll be glad to :)

(for signing up to post on the wiki:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-can-I-post-on-this-wiki-use-the-bug-tracker)

Thanks!
Tom


--

Best Regards,

Sam

reply via email to

[Prev in Thread] Current Thread [Next in Thread]