On 05/01/2018 05:13 AM, Ronakraj Gosalia via USRP-users wrote:
> Hi everyone,
> I am using a USRP E312 with GNU Radio 126.96.36.199. GNU Radio has an inbuilt
> FEC block that supports Turbo Product Codes (TPC). I'm trying to run a
> flowgraph (completely in simulation) on the E312 that includes a TPC
> encoder and decoder. The TPC parameters are:
> parallelism: 0
> row encoding polynomial: 3
> column encoding polynomial: 123
> K Row: 3
> K Column: 18
> B: 0
> Q: 6
> This is a standard 1/2 rate TPC with 6 data byte frame and 12 coded byte
> frame as per slide 6 on
> On my host machine running Ubuntu 16.04 LTS the flowgraph simulates as
> expected and my ASYNC FEC encoding and decoding blocks with TPC work and
> decode properly. I copied across the exact same flowgraph to my E312 and
> ran it on there, but the decoded bits that come out of the FEC Decoder
> (diagnosed using a Message Debug block) are all 0s. It's as if the TPC
> decoder has not attempted to decode at all and prints out the default
> initialised vector of 0s. I tried all types of TPC decoding including
> LOG-MAP C factor, LOG-MAP LUT factor, Constant LOG-MAP, max LOG-MAP and
> Linear LOG-MAP with various levels of iterations from 1-6. All yielded
> the same response. I even tried to use a ZMQ push/pull sink/source and
> offloaded the FEC decoding to my host machine while everything else
> leading up to it was done on the E312 - this works perfectly and the FEC
> decoding performs as expected on my host laptop.
> I suspect there's a subtle bit of code that is malfunctioning on the
> E312, but there's no diagnosis output that hint at where this may be.
> For reference, I followed the instructions here
> to setup my E312. I have not faced an issue like this before with any
> other block either in tree or out of tree.
> Has anyone experienced an issue like this before or know where I should
> Thank you for reading and for your help in advance :).
Phew, that's a tough one. Please consider also asking on the
discuss-gnuradio mailing list, you might find more experts there.
There may be a subtle (or not so subtle) bug in the VOLK kernels
underpinning said decoder. On an x86, different kernels would be running
than on an NEON-based device. Do you know how to configure VOLK kernels?
That would be place to start. I think there's a way you can force to run
generic kernels, if available, I assume they'd be fine.
USRP-users mailing list