On 05/01/2018 05:13 AM, Ronakraj Gosalia via USRP-users wrote: > Hi everyone, > > I am using a USRP E312 with GNU Radio 3.7.10.2. 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 > https://kirankarra.files.wordpress.com/2016/01/sep18_02_karra_turbocodes.pdf. > 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 > https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source > 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 > look? > 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. -- M _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
