Despite the NodeB's best efforts, the transmissions from the mobiles will not arrive at the NodeB at precisely the same time. The timing offset for each mobile needs to tracked. The best way to do this is to correlate against each mobile's scrambling code.
If, in Miguel's case he's trying to receive the uplink and is not physically located near the NodeB, the mobile transmissions most definitely will not be arriving at the same time. On Wed, Oct 26, 2011 at 10:55 PM, John Wu <[email protected]> wrote: > Michael is correct. before demodulation the received signal should be > correlated. Michael, you said UMTS using scrambling code to do the > timing recovery. But the scrambling code is to distinguish MS in the > uplink, each MS use different scrambling code so I think the correlation > shouldn't be related to distinguish user. Is there any document about UMTS > timing recovery tech? > > Regards! > > > On Tue, Oct 25, 2011 at 10:59 PM, Michael Johnson < > [email protected]> wrote: > >> Hi Miguel, >> >> You're correct that the rake receiver combines multipath effects. If there >> is little or no multipath then a rake receiver is not necessary. >> >> However, in any real world system a receiver needs to track timing offset >> with respect to the transmitter. To do this the receiver needs to correlate >> against the transmitted scrambling code at a series of lags to find the >> peak. The result of these correlations is the channel impulse response, so >> in reality implementing a rake receiver isn't much more difficult than a >> single path receiver. >> >> There actually is a pilot "channel" on the uplink, just not a dedicated >> one. For the standard QPSK uplink transmission, the control information is >> on the Q (imaginary) axis (see 3GPP TS 25.213 section 4.2.1.1). Uplink >> control channel formatting varies (see 3GPP TS 25.211 Section 5.2.11), but >> at least some of the control bits in a frame are pilot bits. You can use >> these bits to derotate the data channel, similar to the way the CPICH is >> used on the downlink. >> >> Furthermore your signal processing chain isn't correct. You need to first >> descramble, then despread, then you can use a QPSK slicer/demodulator. You >> might consider first implementing a UMTS downlink receiever as it's similar >> to the uplink, but a bit simpler. >> >> Finally, if you plan on using this receiver to receive actual UMTS uplink >> signals keep in mind there are 2^24 possible codes (if the system is using >> long codes). If you don't know the code number, it will take a very long >> time to crunch through all the possibilities. >> >> Good luck! >> >> Michael Johnson >> Software Radio Architect >> Epiq Solutions >> www.eqiqsolutions.com >> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
