Merge upstream version of srsLTE

[simonft]

This may fix a build issue newer versions of linux are hitting. I gave it a shot and it doesn't seem too hard except for rrc.cc, which has been moved and modified quite a bit. There might only be a few lines that will be difficult to merg in, but I don't understand what they're doing enough to finish it myself.

[cooperq]

merged the latest build in my dev environment, most of it was smooth but it looks like the API has made some changes which break cell_measurement.cc which I will have to fix. I'm on the case but this isn't gonna be a trivial fix. On the other hand cell_measurement.cc is pretty kludgy and rewriting it from scratch is probably worth doing. I'm on the case.

[alphafox02]

Wasn’t able to build the particular version of srslte on 20.04 although I have no issues building newer versions. I’ll reference my notes and get more feedback, but seeing this issue logged already makes me think it’s a known issue already. Should an older version of Ubuntu be used?

[simonft]

For me the build fails on 18.04 and 20.04 with the error error: ‘cabsf’ was not declared in this scope. The build failure doesn't actually stop it from working on 18.04 (and bootstrap.sh just chugs along happily), but on 20.04 I had issue with it detecting the bladeRF that might or might not be related to the build failure.

[alphafox02]

Okay same exact issue as me. I went in to the src/srsLTE/build folder and watched what it was doing. I though I was smart and changed the c to and f but then it failed with another error.. at any rate good to hear it’ll build on 18.04. I’ll try tonight. I’ve got an ettus 205mini that runs srslte okay so hope it’ll be fine. Also have a blade but it’s an xa4.

…

Sent from my Android

On Aug 7, 2020, at 6:03 PM, Simon Fondrie-Teitler ***@***.***> wrote:  For me the build fails on 18.04 and 20.04 with the error error: ‘cabsf’ was not declared in this scope. The build failure doesn't actually stop it from working on 18.04 (and bootstrap.sh just chugs along happily), but on 20.04 I had issue with it detecting the bladeRF that might or might not be related to the build failure. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[alphafox02]

Just checked, the version of srsLTE required builds fine on 18.04. It fails on 20.04, suppose this should be it's own issue

[ 35%] Building CXX object srsue/src/upper/CMakeFiles/srsue_upper.dir/rrc.cc.o
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=incompatible-pointer-types’ is not valid for C++
/home/dragon/crocodilehunter/src/srsLTE/srsue/src/phy/phch_worker.cc: In member function ‘int srsue::phch_worker::read_ce_abs(float*, uint32_t, uint32_t)’:
/home/dragon/crocodilehunter/src/srsLTE/srsue/src/phy/phch_worker.cc:1599:31: error: ‘cabsf’ was not declared in this scope; did you mean ‘fabsf’?
1599 | ce_abs[g+i] = 20 * log10f(cabsf(ue_dl.ce_m[tx_antenna][rx_antenna][i]));
| ^~~~~
| fabsf
make[2]: *** [srsue/src/phy/CMakeFiles/srsue_phy.dir/build.make:89: srsue/src/phy/CMakeFiles/srsue_phy.dir/phch_worker.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4923: srsue/src/phy/CMakeFiles/srsue_phy.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

It'll go on building but ultimately fail at the end due to this.

[jamesaisenberg]

Just checked, the version of srsLTE required builds fine on 18.04. It fails on 20.04, suppose this should be it's own issue

[ 35%] Building CXX object srsue/src/upper/CMakeFiles/srsue_upper.dir/rrc.cc.o
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=incompatible-pointer-types’ is not valid for C++
/home/dragon/crocodilehunter/src/srsLTE/srsue/src/phy/phch_worker.cc: In member function ‘int srsue::phch_worker::read_ce_abs(float*, uint32_t, uint32_t)’:
/home/dragon/crocodilehunter/src/srsLTE/srsue/src/phy/phch_worker.cc:1599:31: error: ‘cabsf’ was not declared in this scope; did you mean ‘fabsf’?
1599 | ce_abs[g+i] = 20 * log10f(cabsf(ue_dl.ce_m[tx_antenna][rx_antenna][i]));
| ^~~~~
| fabsf
make[2]: *** [srsue/src/phy/CMakeFiles/srsue_phy.dir/build.make:89: srsue/src/phy/CMakeFiles/srsue_phy.dir/phch_worker.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4923: srsue/src/phy/CMakeFiles/srsue_phy.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

It'll go on building but ultimately fail at the end due to this.

I was having this issue as well. A quick fix is to remove the C++ compiler flag "-std=c++11" from srsLTE/CMakeLists.txt, line 257. After that it compiles fine in Ubuntu 20.04. There's probably a more elegant solution, but hey, it works.

[alphafox02]

Excellent, I’ll give it a try and compare how it works to 18.04.

[alphafox02]

Works just like it did on 18.04, but this time I’m trying a bladerf. Following the success started PID to you get an “Exception in thread Thread -3” follower by some reference to threading.py with the ending line talking about invalid literal for int() etc etc? It continues to run and I see the same thing in 18.04. Just wondering if it’s just me.

[jamesaisenberg]

Oh right, I remember having that issue as well.

But first: does the build work for you? In other words, did the "cabsf was not defined in this scope" error go away?

To fix the "invalid literal for int" error, you need to modify your config.ini file. The problem is the comments. So for example:

crash_timeout = 30 ;number of seconds until we assume process has crashed. On a raspberry pi this needs to be more like 120

What's happening is it doesn't recognizing the ';' as a comment, and it is having trouble turning "30 ;number of seconds until we assume" into an integer. The lazy fix is get rid of the comment. So the whole line is just:

crash_timeout = 30

Check the whole file, it happens a few more times. Specifically:

run_us_centeric_heuristics = false ;run US based heuristics like MCC and MNC checks

should be:

run_us_centeric_heuristics = false

Let me know how it goes!

[alphafox02]

That makes sense and yes, it built. I let it run till it found a cell and also checked the webgui. Everything appeared to be working. I’ll do the cleanups and do some further testing. Really appreciate the help.

[alphafox02]

Just curious, are you finding that it actually works? I tried with my b205mini and while it starts to load it keeps having issues when trying to load the FPGA firmware which doesn’t happen in 18.04. I’m wondering if the far newer uhd version is an issue.

With the bladerf I was apparently lucky to get one cell because it too dies after trying to run. I’ve also tried to force the use of soapy to see what’s up, that doesn’t work either. On 18.04 with older uhd/bladerf firmware it works. Just curious what you are using and what your results are.

[jamesaisenberg]

Mine works! It finds about 5 cells.

I was having similar issues with the bladerf in ubuntu 20.04. Here is my solution: EFForg/srsLTE#11

The only change is to crocodilehunter/src/srsLTE/lib/examples/cell_measurement.cc, so if you want to try it, you can replace that file with my version:

https://github.com/jamesaisenberg/srsLTE/blob/cell_measurement_hang/lib/examples/cell_measurement.cc

Let me know how it goes!

[alphafox02]

It works.. I had to raise the crash time and now the usrp is working. I’ll have to test your patch and my xa4 this evening.

…

Sent from my Android

On Aug 20, 2020, at 12:13 PM, jamesaisenberg ***@***.***> wrote:  Mine works! It finds about 5 cells. I was having similar issues with the bladerf in ubuntu 20.04. Here is my solution: EFForg/srsLTE#11 The only change is to crocodilehunter/src/srsLTE/lib/examples/cell_measurement.cc, so if you want to try it, you can replace that file with my version: https://github.com/jamesaisenberg/srsLTE/blob/cell_measurement_hang/lib/examples/cell_measurement.cc Let me know how it goes! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[cooperq]

I have fixed the build errors and the memory leak in our fork of srsLTE as of 0804ca3. If you pull that version and update srsLTE you should see these issues fixed.

As for actually merging the upstream, the API has changed significantly. I spent several days of work fruitlessly trying to rewrite the cell_measurement code but didn't get a working version. I am moving on to other bugs and closing this for now.

[alphafox02]

I just want to touch on this again. Using the mainline Crocodilehunter code with an xA4 or xA9 typically leads to the process dying, however, if I use @jamesaisenberg branch it runs great. What I'm confused on is what's actually been merged, if anything? I see there's a memory leak fix, but can we also roll in @jamesaisenberg patch for the cell measurement?

[alphafox02]

Here's what I've tried this morning.

1st. Attempted to add @jamesaisenberg patch into the existing croc hunter code. Still timed out.

2nd. Blew away the srslte directory and used @jamesaisenberg entire branch. Still times out.

3rd. Used @jamesaisenberg entire branch, but disabled UHD and copiled with bladerf support. Going strong now.

Now i need to start over and build only bladerf support with mainline crochunter and then repeat each additioanl step till I find what works best.

• 06:35:55 default - DEBUG Error timed out while receiving samples from UHD.
• 06:35:55 default - DEBUG Error receiving samples
• 06:35:55 default - DEBUG Error calling srslte_ue_sync_work()
• 06:35:56 default - DEBUG [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1000 ms
• 06:35:55 default - DEBUG Error timed out while receiving samples from UHD.
• 06:35:55 default - DEBUG Error receiving samples
• 06:35:55 default - DEBUG Error calling srslte_ue_sync_work()
• 06:35:56 default - DEBUG [ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:336] wait_for_buffer: Timed out waiting for buf_ready after 1000 ms

[cooperq]

Sorry I've been out. @alphafox02 did you have any success with this? Should I re-open this issue?

[alphafox02]

@cooperq I still need to check a clean install of crocodile hunter, but build it specifically either UHD or Bladerf. In DragonOS Focal it has both the UHD drivers and Bladerf drivers, so when running crocodile hunter it of course goes for UHD first. This doesn’t seem to work well. Then add in the possibility of applying the bladerf patch mentioned above I just need to clear up a couple things and see what works best. For sure for me at least when having both sets of drivers available, stock crocodile hunter from git, and then running a bladerf it doesn’t seem to want to work properly with UHD taking control of the bladerf.

That’s probably not really an issue easily resolved but probably not really a situation most people would be dealing with unless they had both UHD and bladerf drivers installed? It doesn’t seem like there’s any way to specifically tell the crocodile/srsLTE example cell search or whatever it’s called which driver to use. That’s why I go back and rebuilt by altering the cmake file.

Hope that makes sense. What happens if you use your x40 with uhd drivers installed?

[cooperq]

I've had both UHD and bladerf drivers installed for a while and haven't had this problem, but are you using the native drivers or the soapysdr drivers?

[alphafox02]

So for me if I have uhd and bladerf drivers installed and start it with a bladerf plugged in it actually comes up and gets used by the “uhd soapy” something something driver. However, if I blow away the build directory, change the Cmakelists to yes for bladerf and no for UHD, rebuild and use it works great and actually shows it’s only using the specific bladerf driver and not the uhd / uhd soapy thing. I’ll seems I did not need to apply that other git branch patch for bladerf, only using what you’ve put together but specifically building only with bladerf enabled. Like in this video https://youtu.be/_Govz8lgjuY

[cooperq]

good to know. perhaps I should update the setup script to change this automatically when building for bladerf.