Difference between CDMA pilot channel acquistion and tracking
in [DSP]
|
Prev: IIR filter order
Next: Call for Papers: The 2010 International Conference of Signal and Image Engineering (ICSIE 2010)
From: John on 4 Mar 2010 08:03 On Mar 4, 7:46 am, "Laron" <jason.pi...(a)inbox.com> wrote: > >>On Mar 2, 1:11=A0pm, "Frank_os" <spw...(a)gmail.com> wrote: > >>> >On Feb 28, 12:44=3DA0am, "Laron" <jason.pi...(a)inbox.com> wrote: > >>> >> >On Feb 27, 7:00=3D3DA0pm, "Laron" <jason.pi...(a)inbox.com> wrote: > >>> >> >> >On Feb 26, 3:50=3D3D3DA0am, "Laron" <jason.pi...(a)inbox.com> > >wrote: > >>> >> >> >> Hi all, > > >>> >> >> >> =3D3D3DA0 =3D3D3DA0 Did acquisition and tracking with pilot > >chan= > >>nel > >>> sha=3D > >>> >ring > >>> >> th=3D3D > >>> >> >e > >>> >> >> same > >>> >> >> >> process in CDMA2000? the acquisition using xcorr find the > >coarse > >>> >> >> delay,bu=3D3D3D > >>> >> >> >t > >>> >> >> >> how does tracking action? > >>> >> >> >> =3D3D3DA0 =3D3D3DA0 Plan to using 8x oversampling,then fed > the > >s= > >>tream > >>> t=3D > >>> >o a > >>> >> dig=3D3D > >>> >> >ital > >>> >> >> ma=3D3D3D > >>> >> >> >tched > >>> >> >> >> filter to find best one from the eight. But really have no > >idea > >>> wit=3D > >>> >h > >>> >> >> the > >>> >> >> >> tracking process, do i need to using xcorr again when > >tracking? > >>> or > >>> >> pas=3D3D > >>> >> >s > >>> >> >> t=3D3D3D > >>> >> >> >he > >>> >> >> >> eight stream to the digital matched filter to find the best > >one? > >>> >> >> >> when using 256bit DMF, case chip by chip input, tracking will > >>> cause > >>> >> th=3D3D > >>> >> >e > >>> >> >> >> stream chosen vary frequency; case 256 size buffer,then block > >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 =3D3D3DA0 =3D3D3DA0 > > >>> >> >> >The cross-correlation will need to run continuously, so that > you > >g= > >>et > >>> =3D > >>> >a > >>> >> >> >new peak for each repetition of of the shortcode. > > >>> >> >> >John > > >>> >> >> The 32768 xcorr will take a certain long time, should we all use > >th= > >>e > >>> >> 3276=3D3D > >>> >> >8 > >>> >> >> size xcorr during both acquisition and tracking, this will > >introduc= > >>e > >>> >> >> certain amount of delay. > >>> >> >> =3D3DA0 Another question is when everytime xcorr, we get a new > >dela= > >>y, > >>> th=3D > >>> >en > >>> >> sh=3D3D > >>> >> >all > >>> >> >> we shift the local generated pn sequence or shift the input data > >to > >>> >> align > >>> >> >> with local sequence when despreading? > > >>> >> >> Thanks. > >>> >> >> B. R. > >>> >> >> Laron > > >>> >> >Find the XC peak location and then thin off 32678 input samples > >(thos= > >>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 get > >a > >>> >> >new symbol for every N symbols in the 32k inputs. > > >>> >> >Now comes the part you asked about earlier. You need to multiply > >thes= > >>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= > >>ed > >>> =3D > >>> >me > >>> >> listed below. > >>> >> 1.Cause the pilot symbols(all zeros) only transmitted on I-channel > >and= > >> i > >>> =3D > >>> >q > >>> >> use different sequence, so how could we make out i channel's > imagine > >>> part > >>> >> from the complex sampled data? =3DA0 > >>> >> 2.Cause the sync channel's frame head align with 1 after 15 > >consecutiv= > >>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 =A0pilot acquisition, a > digital-delay > >l= > >>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...(a)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 tow > 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 |