Hi Alfredo, On Thu, Jul 24, 2014 at 1:57 PM, Alfredo Muniz <mun...@seas.upenn.edu> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio