discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [GSoC] Co-Processors Update #7


From: Tom Tsou
Subject: Re: [Discuss-gnuradio] [GSoC] Co-Processors Update #7
Date: Fri, 25 Jul 2014 00:19:16 -0400

Hi Alfredo,

On Thu, Jul 24, 2014 at 1:57 PM, Alfredo Muniz <address@hidden> wrote:
> - Good news is that I have successfully run the turbo decoder on the DSP
> through loading in a program from the ARM. I fed it some data and it returns
> the appropriate hard decisions for LTE at 93 Mbits/second with a very simple
> setup (non segmented so no parallelism). Yay! So we are going to decode LTE
> turbo codes now as it's the most painless thing to work with since it
> doesn't rely on the queue manager which is a pain to setup with arm+dsp. If
> anyone knows good resources to read about LTE turbo codes please let me know
> as I'm fairly new to it and could use some more theory than is provided in
> TI's TCP3d reference guide. Also there are 2 LTE carriers in the area that I
> can hopefully use for testing once I set things up. Need to update wiki.

This is a great result since the turbo decoder is perhaps the most
difficult component to achieve high bandwidth using a GPP or DSP. Any
thoughts on the next milestone?

If you are sticking with LTE decoding, the outer portions of the
receiver (OFDM, precoding, etc.) are probably out-of-scope for this
project, but do you think it would be possible to attach and
manipulate the Bit Rate Coprocessor (BCP)? That would link the upper
receiver chain and allow feeding in raw I/Q symbols. Though, the
tricky aspect may be that the BCP receive portion is typically setup
for the eNodeB side to recover UE uplink signals and not the downlink
that you mention.

Those are just random thoughts. If you need captures, myself or some
of the other LTE folks can probably provide live (or canned) signals
at various test points.

  -TT



reply via email to

[Prev in Thread] Current Thread [Next in Thread]