[Openlte-discuss] v21 compilation errors, liblte_phy_test fails, osmoSDR device concerns
An open source 3GPP LTE implementation.
Status: Alpha
Brought to you by:
bwojtowi
From: Dan Dole-M. <dan...@bs...> - 2021-12-10 21:06:57
|
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 |