Difference between CDMA pilot channel acquistion and tracking

On Mar 4, 7:46=A0am, "Laron" <jason.pi...@inbox.com> wrote:
> >>On Mar 2, 1:11=3DA0pm, "Frank_os" <spw...@gmail.com> wrote:
> >>> >On Feb 28, 12:44=3D3DA0am, "Laron" <jason.pi...@inbox.com> wrote:
> >>> >> >On Feb 27, 7:00=3D3D3DA0pm, "Laron" <jason.pi...@inbox.com> wrote=
:
> >>> >> >> >On Feb 26, 3:50=3D3D3D3DA0am, "Laron" <jason.pi...@inbox.com>
> >wrote:
> >>> >> >> >> Hi all,
>
> >>> >> >> >> =3D3D3D3DA0 =3D3D3D3DA0 Did acquisition and tracking with pi=
lot
> >chan=3D
> >>nel
> >>> sha=3D3D
> >>> >ring
> >>> >> th=3D3D3D
> >>> >> >e
> >>> >> >> same
> >>> >> >> >> process in CDMA2000? the acquisition using xcorr find the
> >coarse
> >>> >> >> delay,bu=3D3D3D3D
> >>> >> >> >t
> >>> >> >> >> how does tracking action?
> >>> >> >> >> =3D3D3D3DA0 =3D3D3D3DA0 Plan to using 8x oversampling,then f=
ed
> the
> >s=3D
> >>tream
> >>> t=3D3D
> >>> >o a
> >>> >> dig=3D3D3D
> >>> >> >ital
> >>> >> >> ma=3D3D3D3D
> >>> >> >> >tched
> >>> >> >> >> filter to find best one from the eight. But really have no
> >idea
> >>> wit=3D3D
> >>> >h
> >>> >> >> the
> >>> >> >> >> tracking process, do i need to using xcorr again when
> >tracking?
> >>> or
> >>> >> pas=3D3D3D
> >>> >> >s
> >>> >> >> t=3D3D3D3D
> >>> >> >> >he
> >>> >> >> >> eight stream to the digital matched filter to find the best
> >one?
> >>> >> >> >> when using 256bit DMF, case chip by chip input, tracking wil=
l
> >>> cause
> >>> >> th=3D3D3D
> >>> >> >e
> >>> >> >> >> stream chosen vary frequency; case 256 size buffer,then bloc=
k
> >by
> >>> >> block
> >>> >> >> >> input, tracking will introduce a certain mount of delay. How
> >>> should
> >>> >> i
> >>> >> >> do.
>
> >>> >> >> >> Wish your idea and thanks a lot.
>
> >>> >> >> >> B. R.
> >>> >> >> >> Laron =3D3D3D3DA0 =3D3D3D3DA0
>
> >>> >> >> >The cross-correlation will need to run continuously, so that
> you
> >g=3D
> >>et
> >>> =3D3D
> >>> >a
> >>> >> >> >new peak for each repetition of of the shortcode.
>
> >>> >> >> >John
>
> >>> >> >> The 32768 xcorr will take a certain long time, should we all us=
e
> >th=3D
> >>e
> >>> >> 3276=3D3D3D
> >>> >> >8
> >>> >> >> size xcorr during both acquisition and tracking, this will
> >introduc=3D
> >>e
> >>> >> >> certain amount of delay.
> >>> >> >> =3D3D3DA0 Another question is when everytime xcorr, we get a ne=
w
> >dela=3D
> >>y,
> >>> th=3D3D
> >>> >en
> >>> >> sh=3D3D3D
> >>> >> >all
> >>> >> >> we shift the local generated pn sequence or shift the input dat=
a
> >to
> >>> >> align
> >>> >> >> with local sequence when despreading?
>
> >>> >> >> Thanks.
> >>> >> >> B. R.
> >>> >> >> Laron
>
> >>> >> >Find the XC peak location and then thin off 32678 input samples
> >(thos=3D
> >>e
> >>> >> >that went into the XC) starting from the one at the peak location
> >and
> >>> >> >striding by whatever your samples per chip is. Now you have a
> >complex
> >>> >> >32k vector that is aligned with the shortcode.
>
> >>> >> >You can get complex data symbols as sum(input x conj(sc * w64))
> >where
> >>> >> >sc is the shortcode, w64 is the walsh code, and input is your 32k
> >>> >> >vector. The sum is computed over blocks of N inputs depending on
> >the
> >>> >> >symbol repetition. N might be 64 (no repetition, one symbol per
> >walsh
> >>> >> >sequence) or 256 (one symbol per four walsh sequences). So you ge=
t
> >a
> >>> >> >new symbol for every N symbols in the 32k inputs.
>
> >>> >> >Now comes the part you asked about earlier. You need to multiply
> >thes=3D
> >>e
> >>> >> >symbols by conj(pilot) to remove the phase & frequency offset.
> >Pilot
> >>> >> >is just w0, so you can just compute a pilot symbol for every data
> >>> >> >symbol.
>
> >>> >> >HTH,
>
> >>> >> >John
>
> >>> >> Hi John
> >>> >> That's very very helpful and a large step ahead. still 2 points
> >confus=3D
> >>ed
> >>> =3D3D
> >>> >me
> >>> >> listed below.
> >>> >> 1.Cause the pilot symbols(all zeros) only transmitted on I-channel
> >and=3D
> >> i
> >>> =3D3D
> >>> >q
> >>> >> use different sequence, so how could we make out i channel's
> imagine
> >>> part
> >>> >> from the complex sampled data? =3D3DA0
> >>> >> 2.Cause the sync channel's frame head align with 1 after 15
> >consecutiv=3D
> >>e
> >>> >> zeros of short code, so we don't need to do symbol timing and just
> >>> align
> >>> >> walsh code with the short pn sequence, is this right?
>
> >>> >> Thanks
> >>> >> B. R.
> >>> >> Laron
>
> >>> >1. The pilot symbol is complex
> >>> >2. Yes, the symbol timing is taken care of by the xcorr
>
> >>> As far as I understood, after the =3DA0pilot acquisition, a
> digital-delay
> >l=3D
> >>oop
> >>> (DLL) should be used to track the pilot by correcting the on-time
> pilot
> >>> with the 1/2 chip early and 1/2 chip late pilot.
>
> >>By doing the XC at multiple samples/chip (I believe the OP mentioned
> >>8) you effectively have the early and late signals in the sidelobes of
> >>the XC peak.
>
> >>John
>
> >The resolution should be 1/8 chip time i think.
>
> >And John, can you do me a favor and leave your email-address to me? just
> in
> >case when be trapped.
> >my email address is warmfre...@gmail.com, leave me message if you wish.
> :)
>
> >Thanks
> >B.R.
> >Laron
>
> Another question is how to choose rake receiver's finger delay. One or to=
w
> fixed chips or variable, is there any principle?
> I've seen in some implementation that the fingers' delay could be quite
> different like 0(finger0) 14(f1) 30(f2) etc. so could we dynamic adjust
> these delay by some algorithm?
>
> Thanks.
> B.R.
> Laron.

The finger delays correspond to the path delays in the channel, so yes
they are different and changing with time. When you look at the XC,
there will be peaks far off that are different towers. Only look at
the peaks close in.

I haven't looked in a long time, but I remember there not being a lot
of practical open-source info about the RAKE implementation. I figured
it was the secret sauce.

John