Various BladeRF/YateBTS Issues

[jim]

Hey everyone,

I've got a BladeRF x40 and I've been having the worst time attempting to get it working with YateBTS (or OpenBTS, for that matter, but I'll stick with YateBTS for now). I'm trying to be thorough so sorry if this ends up being a long winded post (especially for my first one).

The issues are, well, numerous. I'll start with the point I'm at now.

I've got the BladeRF connected via USB3.0 to an HP Gen8 Microserver that's running ESXi 5.5. The device is passed through to an Ubuntu 12.04 x32 VM. Everything on this end seems to be working great. The BladeRF can power on and I can interact perfectly with it using the 'bladerf-cli' command line utility. I can start Yate with ybts/mbts running perfectly well. I can even get several different phones to be able to see the test network (001 01) by doing a network search.

This is where the issues arise. I know some of these can be on the handset end because I'm mixing and matching SIMs/handsets around with various parts I've borrowed/pilfered from various colleagues. With that aside, I've got two phones (a Nexus S with 2.3.6 and an old AT&T branded RAZR) that can see the test network that shows up. Both of these can then attempt a network connection. The issue here is that they are both being fairly immediately rejected with the following message:

Code: Select all

<MM>
  <Message type="LocationUpdatingReject">
    <RejectCause>111</RejectCause>
  </Message>
</MM>

I found this topic (http://forum.yate.ro/index.php?topic=296.0) that somewhat mentions the issue, but that user is talking about OpenLTE (which I'm not messing with at the moment). I'm also not trying to purposely reject mobiles with a specific code, I definitely want them to be able to connect and communicate. This, unfortunately, brings me to the next issue...

After several minutes (sometimes just 1 or 2) of operation, I being to get several of these messages:

Code: Select all

<transceiver:MILD> bladeRFDevice.cpp:489:readSamples: RX Timestamp jumped by xxx at xxx in buffer x/x

I'm aware of several threads that deal with this issue, many attributing it to the bugs in early libbladerf implementations and the fact that the API keeps waffling around which has caused some issues. These are the threads in question:

http://nuand.com/forums/viewtopic.php?f=4&t=3665
https://nuand.com/forums/viewtopic.php?f=4&t=3670
http://forum.yate.ro/index.php?topic=372.0

The problem is that I'm 99.9% sure that I've addressed all of the issues in these and things still aren't working for me. Here's the output of my "bladerf-cli version" command:

Code: Select all

  bladeRF-cli version:        1.1.1-git-unknown
  libbladeRF version:         1.2.0-git-unknown

  Firmware version:           1.8.0
  FPGA version:               0.1.2

I've got other random issues too. My noise is awful (which was slightly mitigated by switching an RX antenna) and OpenBTS, when I am messing with it, is showing odd behavior left and right. I was able to get the RAZR to register with it and even receive one SMS (just one...no more) and now the thing goes off the rails when it reregisters.

I think I need to just concentrate on one thing at a time. Thoughts on the various issues?

[jynik]

A couple things are jumping out as red flags to me -- perhaps verifying whether or not these are actually concerns would be a good start?

I'm definitely not experienced with Yate, so my suggestions will generally lean towards verifying the bladeRF usage is stable. My thinking is if you can ensure the blade performance and operation is where it needs to be, you can then get some more Yate-related insight on their forums?

(1) VM software

You mentioned running this in a VM; we've heard that USB 3.0 support in many VM programs is iffy at best. That timestamp "jump" message suggests to me that there's a sample discontinuity, probably caused by the "host" not being able to consume the RX samples as fast as the bladeRF is producing them.

Dropping samples would very much cause problems, so perhaps one thing to check is whether the setup is able to sustain the neccessary sample rate. IIRC, the YateBTS sample rate is very low. After running Yate, you could run bladeRF-cli -e 'print samplerate' to verify which sample rate is used.

From there, you could follow this wiki page to get a sense of the sample rate at which things start to break.

(2) Older distros: Older kernels, older libusb versions

Along similar thinking of dropped samples... Ubuntu 12.04 ships and "older" kernel and "older" libusb versions. Since 2012, there's been a lot of fixes/improvements with respect to USB 3.0 controllers.

In the past, we've seen people struggle with some USB issues on the aforementioned versions. They generally reported their issues resolved through upgrades. Check out your libusb version, and then take a look at the libusb changelog -- you'll get a rough idea of where some fixes came into play.

So, what I'd suggest here is trying Ubuntu 14.10. If you really can't deviate from an LTS due to some sort of IT policies... 14.04 is an LTS as well. However, I noted that there were some additional USB 3.0 improvements in the former.

If you want to try a newer version natively (as opposed to in a VM), I might suggest installing the Ubuntu 14.10 live image onto a 16 GB USB stick with a persistance file (see Unetbootin, usb-creator-gtk). The persistance option will allow you to keep changes to the live image across reboots (e.g., installing and configuring yate).

I really do think trying a live image rather than a VM would be a good test. Note that bladeRF support is included in Pentoo and the GNU Radio live image.

[jynik]

Just had a few more things to think about, if you haven't already. I suspect you may have already went through these items, but perhaps someone will find these ramblings useful...

• You noted your noise was awful. How are you measuring that? What does your noise floor look like? What are you gain settings, and have you tried changing them?
• What band and ARFCN are you using? Have you already looked at whether you're running into another transmitter on/near that frequency? (Don't forget to consider both the uplink and downlink frequencies!)
  • Perhaps you could use GQRX, osmocom_fft, sdrangelove, etc. here to double check what the spectrum looks like at the frequencies you're intending to operate at.
• Do you know exactly what the gains are of your antennas are at various frequencies? (It should be in their data/spec sheet.)
  • I've seen Yate "just work" out of the box fantastically with proper antennas for the job, and poor perfomance with inappropriate antennas... so this is extremely important.
  • If you don't have the antenna specs on paper, perhaps you could try making some rough measurements over various frequencies using some of the aforementioned programs.

[andrew77]

Hello Jim
I get the same your problem:
Connection: 1

<PhysicalInfo>TA=3 TE=0.039 UpRSSI=-13 TxPwr=6 DnRSSIdBm=-51 time=1429365066.608</PhysicalInfo>
-----
2015-04-18_15:51:07.897885 <ybts-signalling:INFO> Received [0x8fe2698]
-----
Primitive: L3Message
Info: 0
Connection: 1

<MM>
<SkipIndicator>0</SkipIndicator>
<NSD>1</NSD>
<Message type="IdentityResponse">
<MobileIdentity>
<IMEI>3518150500XXXXX</IMEI>
</MobileIdentity>
</Message>
</MM>
-----
2015-04-18_15:51:07.898594 <ybts:ALL> Started location updating thread for (0xb620e4d8) TMSI= IMSI=22288XXXXXXXXXX [0xb6201068]
2015-04-18_15:51:07.899278 <nib:INFO> Got user.register for imsi='22288XXXXXXXXXX', tmsi=''
2015-04-18_15:51:07.899766 <ybts:ALL> Location updating thread for (0xb620e4d8) TMSI= IMSI=22288XXXXXXXXXX terminated [0xb6201068]
2015-04-18_15:51:07.899824 <ybts-mm:ALL> UE (0xb620e4d8) TMSI= IMSI=22288XXXXXXXXXX register failed [0x8fe28f0]
2015-04-18_15:51:07.900405 <ybts-signalling:INFO> Sending [0x8fe2698]
-----
Primitive: L3Message
Info: 0
Connection: 1

<MM>
<Message type="LocationUpdatingReject">
<RejectCause>location-area-not-allowed</RejectCause>

I'm trying to follow this guide (to make a fake BTS):An Approach to Analyze Security of GSM Network

[jynik]

I just wanted to encourage you to first work through some of my points above.

In short, you need to first "get the lay of the land" with your setup. There's so many variables, so the key is to work towards a simple setup to understand your operating setup and environment. Just firing up Yate and seeing it not work leaves one with a rather nebulous problem scope, so the idea is to narrow it down.

Use GNU Radio or your favorite tool to look at the spectrum you're trying to operate in. Perhaps make a few simple flowgraphs to test out some simple communication. It's absolutely required that your antennas have appropriate specs. This is a key step before ever considering installing and firing up Yate.

If you're absolutely positive the hardware side of things is configured well, it might be worth asking some of the Yate experts on their forums, or visiting the #yate channel on Freenode.

Update: andrew77 I see you had noted working on changing antennas in a another thread. You said you see the "same" issue here as jim... you're seeing timestamp jumps? Perhaps a more specific description would help here (or on the Yate forums -- whichever seems more appropriate to you).

[andrew77]

Well,
In reality I don't see " timestamp jumps" but only "LocationUpdatingReject"
I want to implement a fake bts

Some guys say that it is better to install bladeRF libraries and CLI program from "git repositories" than "ppa trusty"