[Openlte-discuss] v21 compilation errors, liblte_phy_test fails, osmoSDR device concerns

[Dan Dole-M. <dan...@bs...>]

Hello everyone,

I have been hoping to use openLTE v21 as a jumping-off point for an
LTE-related project, but have run into errors with the physical layer
library. Presently, it appears as though neither the scanner or generator
programs work due to this. I have tried this installation both on Ubuntu
20.04, and 18.04 and on the PiSDR image (only the PiSDR image installation
was possible with minor edits to the source code).

Specifically, compiling with gcc 8.3 returned an error:
In file included from
/home/pi/Desktop/openLTE/v21/openlte_v00-21-00/liblte/tests/liblte_mac_tests.cc:34:
/home/pi/Desktop/openLTE/v21/openlte_v00-21-00/liblte/hdr/liblte_mac.h:428:114:
error: narrowing conversion of ‘-6’ from ‘int’ to ‘int8’ {aka ‘char’}
inside { } [-Wnarrowing]
 static const int8
liblte_mac_rar_tpc_command_num[LIBLTE_MAC_RAR_TPC_COMMAND_N_ITEMS] = {-6,
-4, -2, 0, 2, 4, 6, 8};

I was able to fix the compiler error by replacing that line with the
following:
static const int8
liblte_mac_rar_tpc_command_num[LIBLTE_MAC_RAR_TPC_COMMAND_N_ITEMS] =
{(int8) -6, (int8) -4, (int8) -2, 0, 2, 4, 6, 8};

I was able to satisfy my compiler this way, but I'm unsure if this has
unintended side effects--especially as this header is referenced by several
files.

I've included my make log here
<https://drive.google.com/file/d/1Fkt1cSeMJ8_gibq4ZPcNEbCKthbHx8IB/view?usp=sharing>
or those interested in seeing the full gamut of errors and warnings. Some
appear to state changes in gcc 7.1 may affect the code--but this particular
version of gcc was released in May 2017, what version of gcc have people
used to successfully compile openLTE v21?

That said, when I run the liblte_phy_test, the following tests fail:

pusch_channel_encode_decode_test
pdsch_channel_encode_decode_test
pdcch_channel_encode_decode_test
pss_sss_test

I have been stepping through the code trying to find the source of the
error for the PUSCH test, below are a couple of interesting things I've
discovered thus far--will update you again when I have more.
- Fails because msg.msg[i] and alloc.msg[0].msg[i] are unequal when checked
at the end of the test
- alloc.msg[0] is populated at start of pusch_channel_encode_decode_test with
alternating 0s and 1s, put through the encoder, put back through the
decoder and the resulting msg.msg[i] is all 0s
- msg.msg[i] is returned by liblte_phy_pusch_channel_decode, within the
function it's defined as out_bits
- out_bits in turn is populated by a_bits (within ulsch_channel_decode),
which is in turn populated by ulsch_b_bits, which are reset to 0 at the
start of ulsch_channel_decode
     - This is because in order to decode an ULSCH message, the NULL bit
pattern must be determined by encoding a sequence of 0s
- However, when the ulsch_b_bits are later “recovered” later on as a_bits
 and p_bits, both end up as 0s
- ulsch_b_bits are modified both in liblte_phy_code_block_segmentation and
liblte_phy_code_block_desegmentation, perhaps the error is here? Or,
perhaps the rabbit hole goes deeper--this is as far as I've gotten, though
my work continues…

Lastly, I had some concerns about the osmoSDR device selection. The check
for a hackRF device in the code prior to rtl-sdr/other SDRs exits the
program with a no-device-detected error. I was able to bypass this and
utilize our rtl-sdr by checking for that device before the other supported
peripheral SDRs (by rearranging the if statement), and I recommend that we
consider making this change in a future release.

I would love to hear any thoughts on these matters--currently the physical
layer library issues are the most pressing, though I'm certainly curious to
hear about the other issues mentioned as well.

Thanks for your time, this is an excellent project and I would love to
build on it!

Best,
Dan Dole-Muinos