I have everything working on the DSP through a compiled program that I
load onto the DSP from the ARM. I would now need to send data between
the ARM and the
DSP so that we can interface with GNU Radio. I have a couple of options
MessageQ, Msgcom, and CMEM. The plan is to simply pass a pointer with
all the log-likeihood ratios on the ARM side so that the DSP can process it and then get
the pointer to the resulting hard decisions back to the ARM. Once I can
test that this works the next step would be to get the data from GNU
If you are sticking with LTE decoding, the outer portions of the
receiver (OFDM, precoding, etc.) are probably out-of-scope for this
Yeah I don't know much about
LTE decoding. The TCP3d is capable of operating in three modes: LTE,
WiMax, and 3GPP. If one is easier to work with on the DSP side than
another please let me know as the TCP3d simply does turbo decoding. It
takes in LLRs and outputs the hard decisions though it can also give
other things like soft decisions.
do you think it would be possible to attach and
manipulate the Bit Rate Coprocessor (BCP)?
The BCP operates through the same means as the FFTC using the QMSS and CPPI. It is definitely possible but I think I've spent enough time on it for this summer. I will definitely revisit this issue once I have something more substantial to present for the conference.
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.
Thanks. Any resources to understanding the DSP theory would be helpful and your recommendation on whether to pursue LTE, WiMax, or 3GPP. I'm hoping to be at the point where I need to produce live data sometime late next week. Thanks again!