OpenBTS 1st test

Blazing blindly ahead - got time to play with OpenBTS using the osmo-trx module and appears to be working (build script was a bear on Ubuntu 14 x64 with the 0mq and libcoredumper packages) with all default settings (arfcn 51), scan for 900Mhz base stations with an rtl-sdr dongle and found (I’m in US so should be none!):

kal: Scanning for GSM-900 base stations.
GSM-900:
chan: 45 (944.0MHz + 29.974kHz) power: 1004305.26
chan: 67 (948.4MHz - 37.434kHz) power: 30032.85

3 Likes

Next try came a bit closer

kal: Scanning for GSM-900 base stations.
GSM-900:
chan: 52 (945.4MHz - 18.590kHz) power: 123024.98

Nice work! You may be the first person to have used OpenBTS with LimeSDR, as to the best of my knowledge all testing to-date has been with OsmoTRX plus the rest of the Osmocom stack.

Any chance for a wiki how-to article? :slight_smile:

I’ll have one up next week for the Osmocom stack.

@cswiger, let me know if you’d like to have a wiki login to add details for OpenBTS.

Will look forward to that - I just used OpenBTS as that’s what the O’Reilly book from Range covered: http://openbts.org/site/wp-content/uploads/ebook/Getting_Started_with_OpenBTS_Range_Networks.pdf
with maybe more up to date instructions on their wiki:
https://github.com/RangeNetworks/dev/wiki

First tried the OpenUSRP (formerly FakeUSRP) w/o luck then found the magic was on:
https://osmocom.org/projects/osmotrx/wiki/OsmoTRX#OsmoTRX-with-OpenBTS

Just build like for a B210, then delete: /OpenBTS/transceiver
and startup osmo-trx -f before start openbts
and it’s up and - doing something.

Looks like the latest OpenBTS dev environment has been updated for Ubuntu16 as build.sh wants to install libzmq5 - I just commented that out and build from source.
Also libcoredumper/build.sh wget http://google-coredumper.googlecode.com/files/coredumper-$VERSION.tar.gz is now a 404, had to manually put it in there from https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/google-coredumper/coredumper-1.2.1.tar.gz

The usual build with lots of external dependencies that are quickly changing :slight_smile:

2 Likes

I take it you used our transceiver fork?

https://github.com/myriadrf/osmo-trx

You should have just received login details. Created a stub page:

https://wiki.myriadrf.org/OpenBTS

Correct: .git/config: url = https://github.com/myriadrf/osmo-trx.git

found in this Compatibility with OpenBTS, YateBTS and OsmoBTS

I’ve been working on osmo-trx and all that and my work so far can be found here: https://github.com/emilf/LimeSDR-GSM-Dockerized

You can escape the freaking dependency hell around all those projects with docker… I tried build all of this on Arch Linux before turning to docker.

I can see my MCC-MNC, but cannot register on the network. Hopefully we can use each others work to get this working properly.
Nb. my project is tuned to 1900 Mhz, as that frequency is not assigned to an operator in Iceland.

3 Likes

I’ll do some testing this week. We’ve had it working fine on 900MHz, but I need to give it a go on 1800MHz. From what I understand there is room for performance tuning.

1 Like

Thanks!! Much agreed, docker is the way to go.

My quick test - osmo-trx, and either: OpenBTS { or } osmobtx-trx + osmo-nitb gives a spectrum (above) that looks like none of the ones published, as to what you should see.

I’m cutting teeth on OpenBTS just because that O’Reilly book explains it very clearly for n00bs.

@emilf, @cswiger do you get error like below when you start trx?

ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=0.270833MHz)
– SoapyLMS7::setBandwidth(Tx, 0, 5 MHz)
– Tx Filter calibrated from cache
– SoapyLMS7::setBandwidth(Rx, 0, 5 MHz)
– Rx Filter calibrated from cache
ERR 140363444696896 14:23:24.5 …/…/Transceiver52M/UHDDevice.cpp:513:get_dev_offset: Invalid device configuration. Your configuration is not yet supported by osmo-trx. Patches are welcome.
> ERR 140363444696896 14:23:24.5 …/…/Transceiver52M/UHDDevice.cpp:513:get_dev_offset: Invalid device configuration. Your configuration is not yet supported by osmo-trx. Patches are welcome.
> ERR 140363444696896 14:23:24.5 …/…/Transceiver52M/UHDDevice.cpp:867:open: Unsupported configuration, no correction applied
> ERR 140363444696896 14:23:24.5 …/…/Transceiver52M/UHDDevice.cpp:867:open: Unsupported configuration, no correction applied
– SoapyLMS7::setGain(Tx, 0, PAD, -26 dB)
– SoapyLMS7::setGain(Rx, 0, LNA, 24.5 dB)
– SoapyLMS7::setGain(Rx, 0, TIA, 0 dB)
– SoapyLMS7::setGain(Rx, 0, PGA, 0 dB)
– Transceiver active with 1 channel(s)

Yes - found this interesting patch http://cgit.osmocom.org/osmo-trx/commit/?id=a4f5c2f4c96d8a3ceee12af58485e576a6ccfe3f

It’s in: osmo-trx/Transceiver52M/UHDDevice.cpp uhd_device::get_dev_offset finds no matching offset:


            /* Search for matching offset value */
            for (size_t i = 0; i < NUM_UHD_OFFSETS; i++) {
                    if ((dev_type == uhd_offsets[i].type) &&
                            (tx_sps == uhd_offsets[i].tx_sps) &&
                            (rx_sps == uhd_offsets[i].rx_sps)) {
                            offset = &uhd_offsets[i];
                            break;
                    }
            }
    }

    if (!offset) {
            LOG(ERR) << "Invalid device configuration. Your configuration is not yet supported by osmo-trx. Patches are welcome.";
            return 0.0;
    }

Altho is IS in there:

static struct uhd_dev_offset uhd_offsets[] = {
{ USRP1, 1, 1, 0.0, “USRP1 not supported” },
{ USRP1, 4, 1, 0.0, “USRP1 not supported”},
{ USRP2, 1, 1, 1.2184e-4, “N2XX 1 SPS” },
{ USRP2, 4, 1, 8.0230e-5, “N2XX 4 SPS” },
{ B100, 1, 1, 1.2104e-4, “B100 1 SPS” },

{ UMTRX, 4, 4, 5.1503e-5, “UmTRX EDGE mode (4 SPS TX/RX)” },
{ LIMESDR, 4, 4, 8.6e-5, “STREAM/LimeSDR EDGE mode (4 SPS TX/RX)” },
{ LIMESDR_PCIE, 4, 4, 4.8e-5, “STREAM/LimeSDR EDGE mode (4 SPS TX/RX)” },
};

struct uhd_dev_offset {
enum uhd_dev_type type;
size_t tx_sps;
size_t rx_sps;
double offset;
const std::string desc;
};

Yeah… I figured this out… It was configuration issue anyway…

What was the specific solution ? I built per https://wiki.myriadrf.org/Osmocom_GSM and tried running (for OpenBTS) osmo-trx -f -a ‘driver=lime,device=0’ and still get a bad, unrecognized signal like this:

uhd_usrp_probe --string /name

linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-71-g2016126f

– Make connection: ‘LimeSDR-USB [USB 3.0] 9060B00471F23’
Estimated reference clock 30.7193 MHz
Selected reference clock 30.720 MHz
– Device name: LimeSDR-USB
<…>
– SoapyLMS7::setBandwidth(Tx, 1, 30 MHz)
– Tx Filter calibrated from cache
STREAM <-- this is what osmo-trx is looking for to set dev_type

uhd_device::parse_dev_type()
limesdr_str = dev_str.find(“STREAM”);

    } else if (limesdr_str != std::string::npos) {
            tx_window = TX_WINDOW_USRP1;
            dev_type = LIMESDR;

I may be barking down the wrong rabbit hole, but the reason we get the error print is the rx_sps: 1 does not match the uhd_offsets[i].rx_sps: 4 - I can make it go away by changing the dev_offset_struct, without understanding what I’m doing, to this:

    //{ LIMESDR, 4, 4, 8.6e-5, "STREAM/LimeSDR EDGE mode (4 SPS TX/RX)" },
    { LIMESDR, 4, 1, 8.6e-5, "STREAM/LimeSDR EDGE mode (4 SPS TX/RX)" },

Taking advantage of open source, we found above the offset entry for STREAM (LimeSDR) is set for rx_sps =4 and tx_sps =4 - however whenever I startup osmo-trx -f -a ‘driver=lime,device=0’ we would get:

Config Settings
Tx Samples-per-Symbol… 4
Rx Samples-per-Symbol… 1

and fail to match the offset structure - so digging into osmo-trx.cpp we found where rx_sps would be set to 4 and that’s:

            case 'e':
                    config->edge = true;
                    config->rx_sps = 4;
                    break;

So trying

osmo-trx -f -e -a ‘driver=lime,device=0’

Tx Samples-per-Symbol… 4
Rx Samples-per-Symbol… 4

That’s good, no more “Invalid device configuration.” ERR - check the spectrum

Oh yes, looks much better - try out the cheapie phone with an H2O (att mvno) sim:

I’d say it’s working - can even hear the usual gsm noises in a nearby desk speaker :slight_smile:

Now, we can save others that 4 hours of climbing the learning curve but just putting “use -e with osmo-trx” in the wiki.

2 Likes

I actually solved it that way… by using “osmo-trx -e -s 4” nonetheless I am not able to see the network on my GSM device :(.
I tried different band (850) because where I live 1900 is crowded.
When I got back from work I’ll try to use rtl-sdr to see if my Lime is transmitting at all.

I did everything as described in the wiki, but i get some errors (included the whole output though)
Could this be a driver problem? I get the same errors with the BLE sniffer.

opening configuration table from path :memory:
Config Settings
   Log Level............... NOTICE
   Device args............. driver=lime,device=0
   TRX Base Port........... 5700
   TRX Address............. 127.0.0.1
   Channels................ 1
   Tx Samples-per-Symbol... 4
   Rx Samples-per-Symbol... 4
   EDGE support............ Enabled
   External Reference...... Disabled
   C0 Filler Table......... Disabled
   Diversity............... Disabled
   Tuning offset........... 0
   RSSI to dBm offset...... 0
   Swap channels........... 0

-- Make connection: 'USB 3.0 (LimeSDR-USB)'
Estimated reference clock 30.7197 MHz
Selected reference clock 30.720 MHz
-- Device name: LimeSDR-USB
-- Reference: 30.72 MHz
-- Init LMS7002M(0)
LMS7002M values cache at /home/c5e3/.limesuite/LMS7002M_cache_values.db
-- Ver=7, Rev=1, Mask=1
-- LMS7002M calibration values caching Enable
CGEN: Freq=80 MHz, VCO=2.4 GHz, INT=77, FRAC=131072, DIV_OUTCH_CGEN=14
-- SoapyLMS7::setFrequency(Rx, 0, BB, 0 MHz)
-- SoapyLMS7::setFrequency(Tx, 0, BB, 0 MHz)
-- SoapyLMS7::setAntenna(Rx, 0, LNAL)
-- SoapyLMS7::setAntenna(Tx, 0, BAND1)
-- SoapyLMS7::setGain(Rx, 0, PGA, 0 dB)
-- SoapyLMS7::setGain(Rx, 0, LNA, 0 dB)
-- SoapyLMS7::setGain(Rx, 0, TIA, 0 dB)
-- SoapyLMS7::setGain(Tx, 0, PAD, -50 dB)
-- SoapyLMS7::setSampleRate(Rx, 0, 10 MHz), CGEN=80 MHz, ADC=20 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=20MHz, rx=10MHz)
----- FPGA PLL #0 CONFIG -----
M=112, N=7, Fvco=640.000 MHz
C0=16, Fout=40.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=16, Fout=40.000 MHz, CNT_IND=3, nSteps=35, phaseShift=98.4
----- FPGA PLL #1 CONFIG -----
M=93, N=3, Fvco=620.000 MHz
C0=31, Fout=20.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=31, Fout=20.000 MHz, CNT_IND=3, nSteps=78, phaseShift=113.2
-- SoapyLMS7::setSampleRate(Tx, 0, 10 MHz), CGEN=80 MHz, DAC=20 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=10MHz, rx=10MHz)
----- FPGA PLL #0 CONFIG -----
M=93, N=3, Fvco=620.000 MHz
C0=31, Fout=20.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=31, Fout=20.000 MHz, CNT_IND=3, nSteps=65, phaseShift=94.4
----- FPGA PLL #1 CONFIG -----
M=93, N=3, Fvco=620.000 MHz
C0=31, Fout=20.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=31, Fout=20.000 MHz, CNT_IND=3, nSteps=78, phaseShift=113.2
-- SoapyLMS7::setBandwidth(Rx, 0, 30 MHz)
-- Rx Filter calibrated from cache
-- SoapyLMS7::setBandwidth(Tx, 0, 30 MHz)
-- Tx Filter calibrated from cache
-- SoapyLMS7::setFrequency(Rx, 1, BB, 0 MHz)
-- SoapyLMS7::setFrequency(Tx, 1, BB, 0 MHz)
-- SoapyLMS7::setAntenna(Rx, 1, LNAL)
-- SoapyLMS7::setAntenna(Tx, 1, BAND1)
-- SoapyLMS7::setGain(Rx, 1, PGA, 0 dB)
-- SoapyLMS7::setGain(Rx, 1, LNA, 0 dB)
-- SoapyLMS7::setGain(Rx, 1, TIA, 0 dB)
-- SoapyLMS7::setGain(Tx, 1, PAD, -50 dB)
-- SoapyLMS7::setSampleRate(Rx, 1, 10 MHz), CGEN=80 MHz, ADC=20 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=20MHz, rx=10MHz)
----- FPGA PLL #0 CONFIG -----
M=112, N=7, Fvco=640.000 MHz
C0=16, Fout=40.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=16, Fout=40.000 MHz, CNT_IND=3, nSteps=35, phaseShift=98.4
----- FPGA PLL #1 CONFIG -----
M=93, N=3, Fvco=620.000 MHz
C0=31, Fout=20.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=31, Fout=20.000 MHz, CNT_IND=3, nSteps=78, phaseShift=113.2
-- SoapyLMS7::setSampleRate(Tx, 1, 10 MHz), CGEN=80 MHz, DAC=20 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=10MHz, rx=10MHz)
----- FPGA PLL #0 CONFIG -----
M=93, N=3, Fvco=620.000 MHz
C0=31, Fout=20.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=31, Fout=20.000 MHz, CNT_IND=3, nSteps=65, phaseShift=94.4
----- FPGA PLL #1 CONFIG -----
M=93, N=3, Fvco=620.000 MHz
C0=31, Fout=20.000 MHz, CNT_IND=2, nSteps=0, phaseShift=0.0
C1=31, Fout=20.000 MHz, CNT_IND=3, nSteps=78, phaseShift=113.2
-- SoapyLMS7::setBandwidth(Rx, 1, 30 MHz)
-- Rx Filter calibrated from cache
-- SoapyLMS7::setBandwidth(Tx, 1, 30 MHz)
-- Tx Filter calibrated from cache
CGEN: Freq=8.66667 MHz, VCO=2.32267 GHz, INT=74, FRAC=637155, DIV_OUTCH_CGEN=133
-- SoapyLMS7::setSampleRate(Tx, 0, 1.08333 MHz), CGEN=8.66667 MHz, DAC=2.16667 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
-- SoapyLMS7::setSampleRate(Tx, 1, 1.08333 MHz), CGEN=8.66667 MHz, DAC=2.16667 MHz, interp=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
-- SoapyLMS7::setSampleRate(Rx, 0, 1.08333 MHz), CGEN=8.66667 MHz, ADC=2.16667 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
-- SoapyLMS7::setSampleRate(Rx, 1, 1.08333 MHz), CGEN=8.66667 MHz, ADC=2.16667 MHz, decim=2
ConnectionSTREAM::ConfigureFPGA_PLL(tx=1.08333MHz, rx=1.08333MHz)
-- SoapyLMS7::setBandwidth(Tx, 0, 5 MHz)
-- Tx Filter calibrated from cache
-- SoapyLMS7::setBandwidth(Rx, 0, 5 MHz)
-- Rx Filter calibrated from cache
-- Setting STREAM/LimeSDR EDGE mode (4 SPS TX/RX) (offset 0.086 ms = 23.2917 samples)
ERR 140134437009216 03:51:52.0 UHDDevice.cpp:871:open: TS_OFFSET = 93 rx_rate = 1.08333e+06
ERR 140134437009216 03:51:52.0 UHDDevice.cpp:871:open: TS_OFFSET = 93 rx_rate = 1.08333e+06
-- SoapyLMS7::setGain(Tx, 0, PAD, -26 dB)
-- SoapyLMS7::setGain(Rx, 0, LNA, 24.5 dB)
-- SoapyLMS7::setGain(Rx, 0, TIA, 0 dB)
-- SoapyLMS7::setGain(Rx, 0, PGA, 0 dB)
-- Transceiver active with 1 channel(s)
Warning popping from TX, samples popped 0/1360
L 174080
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Tx: 0.000 MB/s, Fs: 0.000 MHz, failures: 0, ts:0
Rx: 3.273 MB/s, Fs: 0.000 MHz, overrun: 0, loss: 0 
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360
Warning popping from TX, samples popped 0/1360