These are notes I've taken while rying to get srslte up and running. This is messy, sorry...

https://wiki.myriadrf.org/LimeSDR-USB

The LimeSDR USB exposes all 10 of the RF ports available on the LMS7002M chip.

• Channel 0
  • TX1_1 = BAND1 (2GHz - 3.5GHz); TX1_2 = BAND2 (10MHz - 2GHz)
  • RX1_L = LNAL (10MHz - 2GHz); RX1_H = LNAH (2GHz - 3.5GHz); RX1_W = LNAW (10MHz - 2GHz)
• Channel 1
  • TX2_1 = BAND1 (2GHz - 3.5GHz); TX2_2 = BAND2 (10MHz - 2GHz)
  • RX2_H = LNAH (2GHz - 3.5GHz); RX2_W = LNAW (10MHz - 2GHz)

UNTESTED:

device_args = rxant=LNAL,txant=BAND1

https://wiki.myriadrf.org/LimeSDR-Mini

The Mini has 2x RF switches that allow the 2x SMA connectors to be routed to one of 5 RF ports on the LMS7002M (2x outputs for TX, 3x inputs for RX). SoapySDR gives these ports slightly different name. These names can be put into device_args to configure the RF paths.

Note: Frequency ranges were taken from the v1.1 schematic

• TX1_1 = BAND1 (2GHz - 2.6GHz); TX1_2 = BAND2 (30MHz - 1.9GHz)
• RX1_H = LNAH (2GHz - 3.5GHz); RX1_W = LNAW (10MHz - 2GHz)

device_args = rxant=LNAH,txant=BAND1

Dependencies:

sudo apt install tree vim git g++ make cmake pkg-config libpython-dev python-numpy swig libi2c-dev libusb-1.0-0-dev libfftw3-dev libmbedtls-dev libboost-program-options-dev libconfig++-dev libsctp-dev gnuradio

# For the graphical LimeSuiteGUI
sudo apt-get install libwxgtk3.0-dev freeglut3-dev

Sources:

git clone https://github.com/pothosware/SoapySDR.git
git clone https://github.com/myriadrf/LimeSuite.git
git clone https://github.com/myriadrf/gr-limesdr.git
git clone https://github.com/srsLTE/srsLTE.git

Build:

For RPi4, apparently, these versions have been tested by the community (not I):

LimeSDR Mini, Gateware 1.30

SoapySDR: 189bc69217846581e34456f391683cc07c43ae0d
LimeSuite: 627c82c76938765e93e85784cb359ea4aa71554e
srsGUI: 31c75d17b61c27271cd7c48a5de8873d15e2bd23
srsLTE: 62d295671510630ea9aea1754835f6c346de6ed7

For my laptop, these versions seem to work:

pushd SoapySDR
git checkout tag tags/soapy-sdr-0.7.2 -b soapy-sdr-0.7.2
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
popd

pushd LimeSuite
git checkout tag tags/v19.04.0 -b v19.04.0
mkdir builddir
cd builddir
cmake ..
make
sudo make install
sudo ldconfig
cd ../udev-rules
sudo sh ./install.sh
popd


pushd gr-limesdr
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
popd

pushd srsLTE
mkdir build
cd build
cmake ../
make
make test
sudo make install
sudo ldconfig
srslte_install_configs.sh
popd

Then write yourself a SIM, cd to ~/.config/srslte, configure srsLTE, and run both the eNodeB and EPC!

I keep getting this issue: SCHED: Could not transmit RAR within the window

I tried to adjust time_adv_nsamples but that didn't get the transmission to happen in time no matter what value I used:

SCHED: Could not transmit RAR within the window

90 samples
(RA TTI=7011, Window=10, Now=7029   18

100 samples:
(RA TTI=3201, Window=10, Now=3245)    44

150 samples:
(RA TTI=8641, Window=10, Now=8661)     20

250 samples:
(RA TTI=6641, Window=10, Now=6656)        15

The Carrier Offset Frequency (CFO) reported by srsue was around 1kHz off so I adjusted it with freq_offset = -1100 and it got the CFO much closer to 0 Hz

I noticed that sometimes the prefix's being sent by the UE are not the same as those being picked up by the eNB running on the RPi4 so I ran the pdsch_ue app from my laptop to check out the channel conditions visually:

cd srsLTE/build
QT_X11_NO_MITSHM=1 lib/examples/pdsch_ue -f 2685.0e6 -F

After adjusting things to get clean signal, I still hit the same issue I've been hitting all along. The RAR isn't transmitted in time.

Last thing I can think of is making sure the clocks on both the UE and RPi4 eNB are in sync.

I'm not sure what else I can do.

I'm running linux.

• Install all your SDR stuff first. I'm using a BladeRF, a LimeSDR, and a LimeSDR-Mini. That means I had to install all the stuff for each of those including soapy and the pothos stack since that's what was to implement limesdr support
• Compile from source. rtfm
• Install the config files to ~/.config/srslte/ or whatever

This is where things get tricky.

• Write a SIM (see below)
• Configure the EPC to match the SIM (apn settings, MCC, MNC, probably more)
• Add the IMSI and other SIM data to the user_db.csv

You need to be able to write your own SIM cards. Encryption is pretty important in LTE and without USIMs with custom stuff on them, you're going to have a bad time.

I purchased two sim reader/writers from aliexpress:

• A black one: It came with 5 USIMs and a PCB adapter board. Name on the box is PC/SC CCID ISO7816 USB Smart Card Reader
• A white one: Like a USB thumb drive ACR38T-D1

I had to ask the seller for the software after purchase. They sent me to some Bidu site to download two archives. The software in both archives required Windows.

I ended up spending way too much time getting the CardTool software working. It required VB6 components and wasn't clear enough about what settings to use to actually flash the cards I had. I did realize that the ACS website provides a pretty reasonable driver installer package for the thing though, so that worked out well.

The best software had the name SIM Personalize tools(Copyright: XCRFIDSIMWrite Ver 3.1.0). This worked with both reader/writers after I had installed the drivers!

After it loads up, I unplugged the SIM writers, plugged in a sim, plugged the SIM writers back into the computer, and pressed read. Without this process, it was touchy.

The SIM values popped up on screen and I was able to start going through and editing the values manually.

NOTE: It felt like some fields were locked! Apparently Copy/Pasteing into some fields is blocked. WTF, whatever, I can type just fine.

For the Common Parameter section, I only touched the ICCID field! Many SIM cards will brick themselves if you try to read them with the wrong PIN too many times. Like, three times. So don't muck with them unless you've okay losing a few SIMs figuring it out! I don't know why and I ain't gonna test it yet, but it feels like the PIN1 and PIN2 fields should both be 1234 for the SIMs I got? Whatever. I'll play with these later.

For srslte, I used the right hand LTE/WCDMA Paramater section, and clicked the Same with LTE button on the left hand panel every once in a while to copy the data back over to the GSM/WCDMA/LTE side of the interface. I don't know if it matters.

These are the values I changed:

Note about MCC and MNC: Use 001 and 01. These are correct test values! If you're spoofing AT&T towers, you run the risk of fucking with 911 calls! Unactivated phones basically roam to make emergency calls. Lots of kids and disadvantaged people have unactivated phones for saftey! Don't be a dick!

IMSI15: 001010000000001               Combination Field! [MCC+MNC+ID] and the ID usually increments
AD: 00000002                          This sets the phone's operation mode and the format of the MCC+MNC part of the IMSI
KI: 12341234123412341234123412341234  The special key! #1 thing you can't read or write on a normal SIM!
OPC: Empty. Click the radio button next to OP instead.
OP: 11111111111111111111111111111111  Another part of the KEY! #2 thing you can't read or write on a normal SIM!
MSISDN: A phone number                I'm sure there's a correct "test" number to use here, but I don't know it.
SPN: CMCC                             Again, there is probably a correct test value for this...
Algorithm: Milenage                   XOR is usually only used for testing, srslte supports Milenage so just use that.

I feel like I'm missing something in here still. The user_db.csv documentation has more fields that don't match any fields in this SIM tools interface.

These are the default srslte configs:

ue2,mil,001010123456780,00112233445566778899aabbccddeeff,opc,63bfa50ee6523365ff14c1f45f88737d,8000,000000001234,7,dynamic
ue1,xor,001010123456789,00112233445566778899aabbccddeeff,opc,63bfa50ee6523365ff14c1f45f88737d,9001,000000001234,7,dynamic

This is another tricky bit.

Your UE/test phone likely supports a bunch of different LTE bands. Use https://www.frequencycheck.com/ to look up your device and the bands it supports.

From there, you can get more info about the those bands on the LTE Frequency Bands Wikipedia page. This includes some information about the frequency ranges used in each band as well as whether the band is FDD (Type 1) or TDD (Type 2).

stslte defaults to Type 1 out of the box. This means the uplink and downlink data channels are separated by frequency. This is called Frequency Division Duplexing (FDD). The documentation says it can also support Time Division Duplexing (where time is used to separate the uplink and downlink channels) but I'm not positive how that works.

FDD (Type 1) means two different frequencies are involved, one for uplink, one for downlink. TDD means just one is involved.

So how do we get from a supported band (Say, LTE B2 (1900 PCS)) to actual frequency values?

This is where I needed to dig into LTE physical layer specs.

In LTE land, we don't usually have to worry about picking exact frequencies. Instead, we use an EARFCN. When you see an EARFCN like 3400, a calculation will spit out the frequency values for the uplink and downlink channels. There are differeny EARFCN's for uplink and downlink, but they are related. Look for the dl_earfcn setting in enb.conf.

Here's a calculator and a post that explains the calculation:

• LTE Frequency band EARFCN Calculator
• Quora post explaining some of the EARFCN math

In LTE land, we also don't usually have to worry too much about channel bandwidths. Instead, we use a Number of Physical Resource Blocks. The channel bandwidth and the Number of Physical Resource Blocks are directly related. More resource blocks require more channel bandwidth (and a higher sampling rate in your SDR, btw). Look for the n_prb setting in enb.conf.

This LTE Overview page helped a bunch while sorting this out. Here is a chart from that page describing the relationship for the bandwidths supported by LTE:

Let's work backwards from the default dl_earfcn and n_prb values that come with srslte.

dl_earfcn = 3400
n_prb = 50

The dl_earfcn setting is the dpwnlink EARFCN. It puts us in Band 7 (IMT-E). The DL=2650.0 Mhz, UL=2530.0 MHz values logged when starting up the eNB confirm this.

The n_prb setting is the number of Physical Resource Blocks. It gives us a bandwidth of 10MHz.

To do that process manually I worked through the details without the calculator.

Band 7 has an uplink range of 2500–2570MHz (70MHz wide) and and downlink range of 2620–2690MHz (also 70MHz wide), with a Duplex spacing of 120MHz.

The srslte uplink and downlink frequencies are:

• 30MHz above the lower edge the each band (which leaves plenty of room for the full 10MHz bandwidth; leaving 5MHz on either side of the carrier/center frequency)
• 120MHz apart from each other (which matches the Duplex spacing for Band 7)
• Integer multiples of 100kHz (which matches the channel raster for LTE Release 8)

So now let's figure out the downlink EARFCN and RBs config for a band supported by my old unlocked iPhone 5c: LTE B2 (1900 PCS)

Band 2 is FDD, with an uplink of 1850-1910MHz and a downlink of 1930-1990MHz with a duplex spacing of 80MHz. It supports channel bandwidths of 1.3, 3, 5, 10, 15, and 20 MHz and those values correspond to 6, 15, 25, 50, 75, and 100 Physical Resource Blocks.

NOTE: Band 2 is used in the United States. Using this band for testing comes with two caveats: At least you'll be operating "in band". However, you may cause intereference with a real tower! While using an international LTE band likely won't cause interference with a cellular service, you may end up transmitting in another REALLY important band. Like, say, a military satellite uplink band (look up AWS-3 sell off). This is why you should really have a valid test license. Too bad no one knows how to get one of those and the no one in the HAM radio world actually give a shit about modern radio technologies...

The Downlink EARFCN range for Band 2 is 600-1199 (from here). While we could just go with that, we'd have to sort out the bandwidth details.

So, instead, I started by finding the uplink frequency, and worked backwards from there to find a reasonable downlink EARFCN.

We know want to be at least Bandwidth / 2 MHz above the bottom edge of the uplink band. We'll stick with the default n_prb setting, leaving the Number of Physical Resource Blocks at 50 giving us a bandwidth of 10MHz. That means we need to be at least 5MHz above 1850MHz... but it'd be good to have a bunch of extra space in case we want to bump n_prb to 100 for 20MHz of bandwidth in the future.

Since the uplink band is (1910 - 1850 MHz =) 60MHz wide, and we'd like to have a bit of extra spacing, let's go with 20MHz above the low edge of the band, (1850 + 20 MHz = ) 1870MHz. (That checks out okay in the EARFCN calculator link above.)

Now let's find the downlink frequency.

The duplex spacing for Band 2 is 80MHz. We should just be able to add 80 to our chosen uplink to get (1870 + 80 MHz = ) 1950MHz. This lands correctly in the provided downlink range, so we should be okay! (This also checks out okay in the EARFCN calculator.)

That gives us our final values as:

Bandwidth: 10MHz (with enough room for 20MHz in the future!)
Uplink: 1870.0 MHz
Downlink: 1950.0MHz

Plugging 1870 and a bandwidth of 20MHz into the calculator passes the Bandwidth check, and provides us downlink EARFCN of 800. This is in the range of 600-1199 but it also provides enough bandwidth for 100 Physical Resource Blocks (if we want that in the future). Just picking 600 wouldn't have cut it.

So we get these values for our enb.conf:

n_prb = 50
dl_earfcn = 800

That should be enough to sort out how to move srslte to any band your phone/LTE test device/UE supports.

• In 2 different terminal windows, cd into ~/.config/srslte/ and run sudo srsenb and sudo srsepc

This allows you to emulate User Equipment. That means a "mobile handset"/phone or other some other LTE device.

This means you'll need 2 computers, 2 SDRs, and 2 installs of srslte. One setup running the eNB (and probably also the EPC) and one running the UE.

Some advantages of using the UE:

• You don't need to write SIM cards to test things
• You can tunnel through the LTE link

I don't really care about running the UE right now.

Built in Release mode using commit d045213f on branch master.
17:17:34.577122 [PHY0] [I] [    0] Component Carrier Worker 0 configured cell 50 PRB
17:17:34.577321 [PHY0] [I] [    0] Worker 0 configured cell 50 PRB
17:17:34.814501 [PHY1] [I] [    0] Component Carrier Worker 0 configured cell 50 PRB
17:17:34.814637 [PHY1] [I] [    0] Worker 0 configured cell 50 PRB
17:17:35.052768 [PHY2] [I] [    0] Component Carrier Worker 0 configured cell 50 PRB
17:17:35.052891 [PHY2] [I] [    0] Worker 0 configured cell 50 PRB
17:17:35.062798 [RRC ] [I] SIB payload - Tx systemInformationBlockType1 (15 B)
17:17:35.062825 [RRC ] [I] SIB payload - Tx systemInformation (27 B)
17:17:35.062833 [RRC ] [I] Allocating 2 PRBs for PUCCH
17:17:35.062856 [S1AP] [I] Proc "MME Connection" - Starting new MME connection.
17:17:35.062859 [S1AP] [I] Connecting to MME 127.0.1.100:36412
17:17:35.062976 [S1AP] [I] SCTP socket established with MME
17:17:35.063404 [S1AP] [I] Sending s1SetupRequest to MME
             0000: 00 11 00 2d 00 00 04 00 3b 00 08 00 00 f1 10 00 
             0010: 00 19 b0 00 3c 40 0a 03 80 73 72 73 65 6e 62 30 
17:17:35.063449 [S1AP] [I] Proc "MME Connection" - S1SetupRequest sent. Waiting for response...
17:17:35.066484 [S1AP] [I] Received S1AP PDU
             0000: 20 11 00 25 00 00 03 00 3d 40 0a 03 80 73 72 73 
             0010: 6d 6d 65 30 31 00 69 00 0b 00 00 00 f1 10 00 00 
17:17:35.066544 [S1AP] [I] Received S1SetupResponse
17:17:35.066578 [S1AP] [I] Proc "MME Connection" - S1Setup procedure completed successfully
17:17:35.086144 [PHY0] [I] [    0] Starting RX/TX thread nof_prb=50, sf_len=11520
Closing log