Dear Chris,
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.
Regards,
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>
CC: 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,
generally
because CDMA2000 is a synchronous system with fairly tight timing
requirements. For example, one requirement will be power-control
which
requires the reverse channel to react to a recovered power-control
bit
from the forward channel (and hence alter the reverse power by up to
1dB) within 500us, every 1250us. Given the buffering latencies at
each
stage of hardware, USB, and processing time in the host, you'll
probably
have to accomplish this power control in the FPGA. In order to
extract
power-control bits in logic you'll need a quadrature despreader and
(masked) long-code generator there too. The despreader will have to
be
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
whole
rake receiver done in logic. Continuing on that line, soon you
realize
that most of the whole PHY design requires custom logic.
If you can find a way to reduce the latencies to an acceptable
level,
then it may be possible to avoid the custom logic. An interesting
starting point might be a forward-only "monitor" implementation,
which
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
not
>existing an implementation in the OpenSDR project...
>
> TIA a lot for all your help.
>
>regards,
>./tss
>
>
---- 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