Thanks for the detailed information.
I will definitely look into the timing constraints and evaluate.
I am going through the USRP user manual in detail and looking into
how I can fit custom-logic onto the board if required, so that our
timing constraints are met.
Thanks, again for your time.
Saravanan T S
---- Begin Original Message ----
From: Chris Kilgour <address@hidden>
Sent: Mon, 04 Jul 2005 22:35:58 -0700
To: tss ooty <address@hidden>
Subject: Re: [Discuss-gnuradio] 3G on USRP
tss ooty wrote:
>Dear GNU Radio Team & Members,
> I am looking for using USRP as my development kit for
>implementation of 3G standards 1xEvDO and 1xRTT.
> I would like to know if there is any work already done in
>developing the CDMA2000 PHY on the USRP kit.
> It would even be very helpful if someone points out any
>feasibility of making cdma2000 protocol work on USRP. Is there any
>feature or limitation on the USRP board that makes it suitable or
>unsuitable for 3G standards 1xEVSO and 1xRTT?
IMHO, your biggest challenges stem from needing custom logic,
because CDMA2000 is a synchronous system with fairly tight timing
requirements. For example, one requirement will be power-control
requires the reverse channel to react to a recovered power-control
from the forward channel (and hence alter the reverse power by up to
1dB) within 500us, every 1250us. Given the buffering latencies at
stage of hardware, USB, and processing time in the host, you'll
have to accomplish this power control in the FPGA. In order to
power-control bits in logic you'll need a quadrature despreader and
(masked) long-code generator there too. The despreader will have to
syncronized to the network according to a pilot searcher, and if you
hope to support soft-handoff then it will basically have to be a
rake receiver done in logic. Continuing on that line, soon you
that most of the whole PHY design requires custom logic.
If you can find a way to reduce the latencies to an acceptable
then it may be possible to avoid the custom logic. An interesting
starting point might be a forward-only "monitor" implementation,
of course could be done purely in software since there would be no
tightly-timed reverse transmissions to make.
> Please help me out in this regard since I am finding it very
>difficult to evaluate the same and wondering why there is already
>existing an implementation in the OpenSDR project...
> TIA a lot for all your help.
---- End Original Message ----
Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com
Get your own Web-based E-mail Service at http://www.zzn.com