[srslte-users] Pi 4 srsLTE

Mon May 11 19:54:01 UTC 2020

Sorry, emails got a little out of sync here..

----

Mark

Sure, I tend to write a setup guide when I do this sort of thing. Copied below. It would be good if there was a community-editable wiki on the srsLTE git for people to share things like this!

Its been running for over 2 hours now with x2 phones attached and streaming live internet radio. B210 in 2x2, tm=2. CPU and memory utilization is not horrendous.

[cid:part1.4922EE7C.92DAB34B at strath.ac.uk]

Pi4 Ubuntu image

http://cdimage.ubuntu.com/releases/20.04/release/ubuntu-20.04-preinstalled-server-arm64+raspi.img.xz

UHD

sudo add-apt-repository ppa:ettusresearch/uhd

sudo apt-get update

sudo apt-get install libuhd-dev libuhd3.15.0 uhd-host

sudo /usr/lib/uhd/utils/uhd_images_downloader.py

sudo uhd_usrp_probe

SoapySDR

git clone https://github.com/pothosware/SoapySDR.git

cd SoapySDR

git checkout a489f3dca9d3ccd9b276b95a608ac3ef0299f635

mkdir build && cd build

cmake ..

make

sudo make install

sudo ldconfig

LimeSuite

sudo add-apt-repository -y ppa:myriadrf/drivers

sudo apt-get update

sudo apt-get install git g++ cmake libsqlite3-dev

sudo apt-get install libi2c-dev libusb-1.0-0-dev

git clone https://github.com/myriadrf/LimeSuite.git

cd LimeSuite

mkdir build && cd build

cmake ../

make

sudo make install

sudo ldconfig

cd ..

cd udev-rules

sudo ./install.sh

LimeUtil --find

LimeUtil --update

SoapySDRUtil --find

srsLTE

sudo apt-get install cmake libfftw3-dev libmbedtls-dev libboost-program-options-dev libconfig++-dev libsctp-dev

git clone https://github.com/srsLTE/srsLTE.git

cd srsLTE

git checkout d045213fb9cbf98c83c06d7c17197a9dcbfddacf

mkdir build &&  cd build

cmake ../

make

sudo make install

sudo ldconfig

sudo srslte_install_configs.sh user

Run software / edit configs

sudo nano /root/.config/srslte/enb.conf
sudo nano /root/.config/srslte/epc.conf
sudo nano /root/.config/srslte/ue.conf
sudo nano /root/.config/srslte/user_db.csv
sudo srsenb sudo srsepc sudo srsue

# eNB conf:
# device_name = UHD / soapy
# device_args = auto < leave as is or it wont connect!

Pi CPU
sudo apt install linux-tools-common
sudo apt install linux-tools-raspi
sudo systemctl disable ondemand

sudo nano /etc/default/cpufrequtils
* GOVERNOR="performance"

reboot

sudo cpupower frequency-info
sudo cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

On 11/05/2020 19:37, mark h wrote:
Kenny,

Great to hear that you got it working. I am beginning to wonder if part of the problem I am having is due to the SoapySDR driver combined with Limesuite. I have been using Soapy because UHD has a lot of overhead. I share your sentiment regarding hardware access, similar situation here where I have been home and have limited hardware, but I do have an ettus N210 on hand so I would like to give it a try. Would you mind sharing your Pi software build/versions so I can try to replicate your results? After seeing that the Pi is capable I am going to dive back into them. I will let you know how it goes when I try the LimeSDR with the UHD driver this afternoon.

Take care
Mark

On Mon, May 11, 2020 at 11:02 AM Kenneth Barlee <kenneth.barlee at strath.ac.uk<mailto:kenneth.barlee at strath.ac.uk>> wrote:

Hey Mark

Good shout on the governor. Changing that to performance, I can run a 2x2 cell with the USRP B210 on the Pi4, and am now getting ~10Mbit downlink and ~3Mbit uplink (srsLTE v19.12). It seems to struggle with dynamic reconfiguration of resource blocks though, so if another UE appears it kills the first one - you have to toggle flight mode to get the two running happily.

One of the things Pi people have been complaining about is that the USB3 bus on the Pi4 is not full USB3. Seems to be ok for the USRP though, which does point to the USB/Soapy/LimeSuite interface introducing too much latency. I don't have any other higher spec dev boards to hand, so can't really try anything else. There are some Intel STK1AW32SC compute sticks on my desk in the office, but I haven't been allowed into the office for over 2 months now! Quad core 1.92GHz/ 2GB RAM and USB3.1; so you never know, they may work well.

I have just received a USRP E320 - may have a shot with that too. Not sure how it will cope though with running srsLTE as it has a lower spec CPU and less RAM than the Pi4! It does have a big FPGA to play with though... potential project in trying to split the PHY off and push it down onto the FPGA fabric.

Cheers

Kenny

From: mark h <markremington47 at gmail.com>
Sent: 11 May 2020 17:19
To: Andre Puschmann <andre.puschmann at softwareradiosystems.com>
Cc: Kenneth Barlee <kenneth.barlee at strath.ac.uk>; srslte-users <srslte-users at lists.softwareradiosystems.com>
Subject: Re: [srslte-users] Pi 4 srsLTE

Kenny,
I have been trying to get SRSUE and ENB to run on Pi-4's and have been experiencing the same issue. When I moved to a faster SBC (UP^2) board I was able to get both ENB and UE to work with the same settings. If I had to guess I feel the latency on the Pi introduces timing issues and it cannot establish the scheduling connection. We are trying to compile a real-time Kernel to reduce the latency so we will see what happens.

I have also been struggling to get higher bandwidths using the LimeUSB's with i7 and i5 laptops but get a real stable connection that runs for hours at 1-2 MBPS. one thing I have found is that the signal cleans up significantly when I put the governor in performance mode rather than on demand. I also no longer get late errors. I have attached a couple of images that show a change in the signal when the governor is changed. You can see the significant jump in SNR. I also see a bandwidth increase when running a IPERF3 test.

Summery of things I have found got me closer:
Cool and overclock the Pi
Set cpu governor to "performance"
Ensure the Pi has plenty of power
power the LimeSDR externally
Build SRSLTE and dependencies from source

setup-1: Not working fails at the same point yours is but ENB signal looks good on the SPEC-AN
Pi-4
LimeUSB (on an externally powered USB)
Raspian latest Distro

Built from source:
SRSLTE 20.04
SoapySDR 0.7.01 (I had issues building the mos recent release they changed a variable type and SRSLTE no longer builds)
LimeSuite 20.01

Setup-2: working at Nprb=15
Up^2 SBC
LimeUSB (on an externally powered USB)
ubuntu 18.04

Built from source:
SRSLTE 20.04
SoapySDR 0.7.01 (I had issues building the mos recent release they changed a variable type and SRSLTE no longer builds)
LimeSuite 20.01

Hope this helps.

Mark

On Wed, May 6, 2020 at 11:51 AM Andre Puschmann <andre.puschmann at softwareradiosystems.com<mailto:andre.puschmann at softwareradiosystems.com>> wrote:
Kenneth,

frankly speaking we don't do much over-the-air testing ourselves with
the Pi4. All success or failure stories so far have been from users on
the list.

Anyway, we'll have a look into this over the next days.

Thanks
Andre

On 6/5/20 15:49, Kenneth Barlee wrote:
> Hey guys
>
> I have been having a play with a Pi 4B /4GB rev 1.2 running the new
> Ubuntu Pi Server 20.04 x64 image, and trying to get srsLTE working. I
> know several others have been talking about trying this, but haven't
> noticed my issue coming up elsewhere.
>
> I started with the latest versions of UHD, SoapySDR, LimeSuite, srsLTE
> (commit ID e3e38482100f5bf13f15af3bc09df882e937bc60). Everything
> compiles happily (no need to change those lines in CMakeLists.txt), and
> the srsenb/srsepc software runs successfully (after an initial wait of
> ~5 mins after first launch for any change in n_prb). However, no phone
> is able to fully connect when using a USRP B210/ LimeSDR-USB/
> LimeSDR-Mini. It seems to start the attach, and there is a core
> handshake, but the core reports that the "UE is not ECM connected" and
> the UE never shows the signal bars.
>
> Decided to roll the Pi back to srsLTE v19.12, commit ID
> d045213fb9cbf98c83c06d7c17197a9dcbfddacf, as I have been running this on
> my desktop for a while now, and know it is stable. Again, this compiles
> without issue. With this version, a phone will join a USRP B210 (not the
> LimeSDRs, but that is probably another issue). It seems relatively
> stable, and can continue running for several hours with a phone attached
> running internet ping tests.
>
> I have attached logs and PCAPs for the two setups.
>
> A potentially related sidenote, with both srsenb versions, and all
> radios, "SCHED: Could not transmit RAR within the window (RA TTI=2591,
> Window=10, Now=2608)" type messages appear repeatedly in the terminal.
> Running cellmapper on the phone, the LTE timing advance is estimated to
> be '~250m' when using the USRP, but over '3.5km' with the LimeSDRs. This
> is likely one of the reasons the LimeSDRs do not work with srsLTE v19.12.
>
> For reference, the UE used was a Samsung S20 Ultra 5G; LTE B3 earfcn
> 1934, n_prb=15, SISO tm=1 nof_ports = 1.
>
> Has anybody experienced similar? Happy to do more testing if it helps
> with debugging!
>
> Thanks
>
>
> Kenny Barlee | Research Associate
> Software Defined Radio Research Laboratory
> Department of Electronic and Electrical Engineering
> University of Strathclyde
>
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.softwareradiosystems.com%2Fmailman%2Flistinfo%2Fsrslte-users&data=02%7C01%7Ckenneth.barlee%40strath.ac.uk%7Cdce4540fc8864ebbe62d08d7f5c70421%7C631e0763153347eba5cd0457bee5944e%7C0%7C0%7C637248107424662945&sdata=LqFjpVkTAhHFdyHYlYumo2QX8QlJR4u%2Fj3sYUWu9llY%3D&reserved=0>
>

_______________________________________________
srslte-users mailing list
srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
http://www.softwareradiosystems.com/mailman/listinfo/srslte-users<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.softwareradiosystems.com%2Fmailman%2Flistinfo%2Fsrslte-users&data=02%7C01%7Ckenneth.barlee%40strath.ac.uk%7Cdce4540fc8864ebbe62d08d7f5c70421%7C631e0763153347eba5cd0457bee5944e%7C0%7C0%7C637248107424672939&sdata=LmWWWjBg5jGROr5O6aYWfcZ%2BscuvXb3skmI3PgNPzqU%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20200511/53bec775/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 285194 bytes
Desc: image001.png
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20200511/53bec775/attachment.png>