"kalibrate-bladeRF" and GSM chanel problem with BladeRF

Discussions related to embedded firmware, driver, and user mode application software development
Post Reply
pedrocab
Posts: 5
Joined: Tue Sep 02, 2014 7:51 am

"kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by pedrocab »

Hello all,

I received my BladeRF a few weeks ago and I want to decode GSM chanels with airprobe. My first step is to scan the available GSM chanels with kalibrate so I have downloaded the kalibrate-bladeRF from Nuand GIT repository.

As I've been doing this before with RTL SDR dongles and USRP B200 board, I already know the GSM chanels available close to me, but when I run kalibrate, it shows very strange GSM chanels: most of them don't exist and the "good" or "real" ones aren't shown or detected. Every time I repeat the chanels scan, the "power" value magnitude is completely different. Here I paste one execution example:

Code: Select all

root@babieca:/opt/kalibrate-bladeRF/src# ./kal -s GSM900
Actual filter bandwidth = 1500 kHz
rxvga1 = 20 dB
rxvga2 = 30 dB
kal: Scanning for GSM-900 base stations.
GSM-900:
	chan: 1 (935.2MHz - 11.197kHz)	power: 21247.06
	chan: 6 (936.2MHz - 1.767kHz)	power: 16291.96
	chan: 7 (936.4MHz - 1.763kHz)	power: 15908.28
	chan: 8 (936.6MHz - 1.742kHz)	power: 16331.60
	chan: 9 (936.8MHz - 1.758kHz)	power: 15854.79
	chan: 13 (937.6MHz - 1.750kHz)	power: 14684.43
	chan: 14 (937.8MHz - 1.742kHz)	power: 14656.51
	chan: 15 (938.0MHz - 1.738kHz)	power: 16614.46
	chan: 16 (938.2MHz - 1.746kHz)	power: 74465.67
	chan: 17 (938.4MHz - 1.750kHz)	power: 83395.16
	chan: 18 (938.6MHz - 1.729kHz)	power: 85727.16
	chan: 19 (938.8MHz - 1.754kHz)	power: 87506.78
	chan: 20 (939.0MHz - 1.758kHz)	power: 83574.33
root@babieca:/opt/kalibrate-bladeRF/src#
My first approach was to think of a lack of DC calibration, so I took a GSM channel frequency (ARFCN = 116, 1.811Mhz) and executed the process for DC autocalibration for a single frequency (https://github.com/Nuand/bladeRF/wiki/D ... Correction):

Code: Select all

root@babieca:/opt# bladeRF-cli -i
bladeRF> set frequency 1811.0M

  Set RX frequency: 1811000000Hz
  Set TX frequency: 1811000000Hz

bladeRF> cal lms
Calibrating LMS LPF tuning module...
    LPF tuning module: 25

Calibrating LMS TX LPF modules...
    TX LPF I filter: 29
    TX LPF Q filter: 33

Calibrating LMS RX LPF modules...
    RX LPF I filter: 33
    RX LPF Q filter: 15

Calibrating LMS RXVGA2 modules...
    RX VGA2 DC reference module: 27
    RX VGA2 stage 1, I channel: 31
    RX VGA2 stage 1, Q channel: 33
    RX VGA2 stage 2, I channel: 27
    RX VGA2 stage 2, Q channel: 35

bladeRF> cal dc rx
RX DC I Setting = 290, error ~= 0
RX DC Q Setting = 370, error ~= 0
bladeRF> quit
Everytime I repeat the scan, the output is the same; strange chanels that don't exist. So I decide to try with "-m" parameter, but neither "-m6" nor "-m12" change the output:

Code: Select all

root@babieca:/opt/kalibrate-bladeRF/src# ./kal -s GSM900 -m12
Actual filter bandwidth = 1500 kHz
rxvga1 = 20 dB
rxvga2 = 30 dB
kal: Scanning for GSM-900 base stations.
GSM-900:
	chan: 6 (936.2MHz - 1.651kHz)	power: 58250.94
	chan: 7 (936.4MHz - 1.643kHz)	power: 59834.88
	chan: 8 (936.6MHz - 1.626kHz)	power: 62583.47
	chan: 9 (936.8MHz - 1.647kHz)	power: 60081.99
	chan: 16 (938.2MHz - 1.647kHz)	power: 103431.27
	chan: 17 (938.4MHz - 1.651kHz)	power: 92819.21
	chan: 18 (938.6MHz - 1.639kHz)	power: 93522.84
	chan: 19 (938.8MHz - 1.655kHz)	power: 100255.68
	chan: 20 (939.0MHz - 1.639kHz)	power: 93232.49
	chan: 22 (939.4MHz - 1.659kHz)	power: 106057.37
	chan: 23 (939.6MHz - 1.634kHz)	power: 94088.31
root@babieca:/opt/kalibrate-bladeRF/src#
I'm connecting the bladeRF board through USB 3.0 port, all the LEDS are blinking normally (no-one off). I try updating the firmware, but nothing changes. O.S. I'm using is Ubuntu 14 and the Board details are the following;

Code: Select all

bladeRF> info

  Serial #:                 cf91a30fd4c5a161600060a27cf0cf35
  VCTCXO DAC calibration:   0x880c
  FPGA size:                40 KLE
  FPGA loaded:              yes
  USB bus:                  3
  USB address:              2
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0

bladeRF> version

  bladeRF-cli version:        0.11.1-git-0bb0cce
  libbladeRF version:         0.16.2-git-0bb0cce

  Firmware version:           1.7.1-git-ca697ee
  FPGA version:               0.0.6

bladeRF> 
If I try to scan with kalibrate a real single chanel (kal -c XXX), the offset is around 400-600khz and ppm always greather than 500ppm:

Code: Select all

average		[min, max]	(range, stddev)
+ 475.217kHz		[475109, 475287]	(178, 40.488880)
overruns: 0
not found: 174
Found lowest offset of 475184.687500Hz at 959.000000MHz (495.500196 ppm) using DAC trim 0xfff8
Please, Can someone help me ? I'm really stuck and I don't understand How the bladeRF board can show non-real GSM channels and forget about the real ones, Can be my unit broken ? What else could I try ?

Kind Regards,
Pedro
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: "kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by jynik »

Pedro,

I haven't worked with or dug into the kalibrate-bladeRF code yet, but I would suspect that you're running into bugs in that that need to be wrinkled out. Given that you know the "lay of the land" in your area, someone like yourself might be able to provide some useful insight as to why it's reporting bogus results.

I seem to recall someone stating that kalibrate-bladeRF isn't decoding anything -- any signal on neighboring frequencies can "confuse" it. Don't quote me on that though, my memory may be failing me here.

I'd advise that you take a look at some FFT plots in osmocom_fft, gqrx, sdrangelove, etc. to get an idea of what the bladeRF "sees." Perhaps you can share some screenshots here so we can all correlate those with the data you've posted in the prior posts.

Best regards,
Jon
jump
Posts: 58
Joined: Mon Mar 03, 2014 5:31 pm
Contact:

Re: "kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by jump »

Without knowing if the reported channels are right or wrong, I was never able to get kalibrate-bladeRF working.

I tried every GSM band and the algorithm never converged. As the factory calibration is pretty accurate I simply gave up :)
pedrocab
Posts: 5
Joined: Tue Sep 02, 2014 7:51 am

Re: "kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by pedrocab »

Hello all,

Thank you for your responses.

Dear Jon, I have explored with "osmocom_fft" and I have found chanels on arfcns 5 and 20 (936Mhz and 939Mhz respectively). So it looks like "kalibrate-bladeRF" once it finds the arfcn 5, gets "confused" and shows arfcns 6,7,8 and 9 (see the kalibrate output on my previous post) and the same for arfcn 20. Arfcn 17 should be at 938.4 Mhz, but signal is too weak.

I paste screenshots:

936Mhz: arfcn 5 centered at 936.0Mhz
Image

938Mhz: arfcn 17 centered at 938.4Mhz
Image

939Mhz: arfcn 20 centered at 939.0Mhz
Image

After this, I decided to use arfcn 20 (without any doubt, the one with better signal quality) to calibrate DAC trim value with "kal -c 20". This time I have good news, "kal" finds 50Hz offset and 0.06 ppm:

Code: Select all

average		[min, max]	(range, stddev)
+ 332Hz		[324, 337]	(12, 3.317531)
overruns: 0
not found: 3
Found lowest offset of 56.204552Hz at 939.000000MHz (0.059856 ppm) using DAC trim 0x8400
Important Note: I try to write the DAC trim value to flash with "-w" option (kal -c 20 -w) but it never works. When I use it, after the last step (

Code: Select all

Saving contents to bladeRF flash
) nothing happens, I wait for more than 10 minutes and still nothing happens, so I have to unplug and plug again the bladeRF board and close the terminal.

Ok, now that I have a good DAC trim value, I use it to scan again for GSM 900 chanels (kal -C option). But the number of chanels found are the same that in my previous post. For a better understanding I scan the chanels using an Osmocom phone and paste below the result (rxlev is expressed in dB):

Code: Select all

arfcn 20	rxlev -57	mcc xxx mnc 07
arfcn 985	rxlev -67	mcc xxx mnc 03
arfcn 107	rxlev -67	mcc xxx mnc 01
arfcn 114	rxlev -69	mcc xxx mnc 01
arfcn 110	rxlev -68	mcc xxx mnc 01
arfcn 975	rxlev -72	mcc xxx mnc 03
arfcn 115	rxlev -73 	mcc xxx mnc 01
arfcn 977	rxlev -72	mcc xxx mnc 03
arfcn 116	rxlev -74	mcc xxx mnc 01
arfcn 17	rxlev -79	mcc xxx mnc 07
arfcn 979	rxlev -72	mcc xxx mnc 03
As you can see, arfcn 20 is again the better signal chanel, arfcn 17 has a weak signal quality and there are more GSM chanels not found by kalibrate-bladeRF. The last step I take for troubleshooting is to scan arfcn 116 (958.2Mhz), not shown by bladeRF. What is out there using bladeRF ? and USRP B200 ?

When using USRP I'm able to find the chanel with kalibrate-uhd and decode the traffic with airprobe (I use the same GSM antenas for both tests) but nothing using bladeRF. I paste "osmocom_fft" screenshoots for arfcn 116:

BladeRF (300kHz samplerate)
Image

USRP B200 (300kHz samplerate)
Image

So, after all these tests, I agree Jon, that some bugs must be solved to improve the chanel identification. But, What could be the reason for kalibrate-bladeRF not to show all the chanels ? Bad Calibration ? Signal quality ?

I don't know if there is a connection, but I'm not able to decode the GSM traffic using bladeRF either.

Kind Regards,
Pedro
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: "kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by jynik »

pedrocab wrote: But, What could be the reason for kalibrate-bladeRF not to show all the chanels ? Bad Calibration ? Signal quality ?
I would suspect that it's a more of a matter of the kalibrate-bladeRF code needing some love, debugging, and fixes -- especially if you're clearly seeing the channels in osmocom_fft. But again, I haven't dug into this code or used it, so I can't make any definitive claims. I just know folks have been reporting similar issues, and that it was really just a quick and dirty proof of concept implementation.

People have been reporting successes with YateBTS and OpenBTS, so that implies to me that those transceivers work and may be worth you checking out. I've heard there's a gr-osmosdr patch for airprobe floating around -- perhaps you could ask around about people using that.

Also, you most likely should not need to be recalibrating the VCTCXO -- the factory calibration is darn good, and you can email [email protected] with your serial # to get it back, generally.

If I can get access to a nice fancy signal generator in the near future, I might sit down and try to debug kalibrate-bladeRF to see what the heck is going on.

As an aside...it drives me up a wall that kalibrate just keeps getting forked with the radio code gutted and replaced for a different SDR. Maybe that'll irritate me enough to actually rewrite it with a proper SDR base class that is used by radio specific subclasses. ;)

Sorry I couldn't be of more help. Perhaps someone with more experience with kalibrate, GSM, etc might be able to chime in...
pedrocab
Posts: 5
Joined: Tue Sep 02, 2014 7:51 am

Re: "kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by pedrocab »

Hi all,

Yes, absolutely right. "airprobe" is working fine with bladeRF, decoding GSM traffic and all the problems I had come from bugs or code, but never calibration:

Code: Select all

root@babieca:/opt/airprobe/gsm-receiver/src/python# ./gsm_receive_hackrf_3.7.py -f 957.2e6 -s 2e6
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.001-84-gd99ce4ef

gr-osmosdr v0.1.1-9-gc65d205d (0.1.2git) gnuradio v3.7.4git-273-g0ae33fc6
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
[bladeRF source] Using nuand LLC bladeRF #0 SN cf91...cf35 FW v1.7.1 FPGA v0.0.6
sample rate: 2000000
Using Volk machine: avx_64_mmx_orc
WARN: fractional_interpolator is deprecated. Please use fractional_resampler instead.
Key: 'XXXXXXXX'
Configuration: '0B'
  Configuration TS: 0
configure_receiver
gr::buffer::allocate_buffer: warning: tried to allocate
   115 items of size 568. Due to alignment requirements
   512 were allocated.  If this isn't OK, consider padding
   your structure to a power-of-two bytes.
   On this platform, our allocation granularity is 4096 bytes.
2376615 0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2376619 0: 25 06 21 00 05 f4 88 11 f4 4c 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
2376625 0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
...
Now that I'm more relax about the bladeRF, I will focuss on OpenBTS and bladeRF.

Thank you very much for your help, I look forward to seeing kalibrate working on baldeRF, so if you need anything I can help you with, don't hesitate to contact me.

Kind Regards,
Pedro
jquirke
Posts: 12
Joined: Sat Oct 25, 2014 12:51 am

Re: "kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by jquirke »

Please, Can someone help me ? I'm really stuck and I don't understand How the bladeRF board can show non-real GSM channels and forget about the real ones, Can be my unit broken ? What else could I try ?
There are several issues with the port of kalibrate to the bladerf. Your issues are a symptom of issue #1.

Issue 1. The bladerf device is opened with large total buffers and the buffers are not flushed between channel changes. This results in stale data seeping through even when kalibrate "thinks" it has changed the channel. Hence several subsequent channels will show up as having a carrier. E.g. if ch8 has a real carrier, ch8,9,10 may show up.

This also interferes with the frequency measurements when changing the DAC value.

The solution is fairly easy; I have modified my kal to open/close the bladerf at the start of the channel search loop and the DAC calibration loop. Now works a treat in this regard.

Issue 2. The bladerf is configured with the minimal 1.5MHz filter supported by the device. This allows several adjacent GSM carriers through to the fcch detector and may confuse the results.

The solution is fairly simple; simply tune the bladerf to the real strongest carriers. This is still only a problem if there are carriers of similar power within 1.5MHz. In this case, add a digital LPF to the code.

Issue 3. DC offsets will cause a problem in some cases. Either they will upset the tone detector and prevent it from working at all, or even if the tone detector works, the FFT may find that the DC impulse is stronger than the FCCH impulse. The symptoms of this are a negative offset of GSM_RATE/4, or approx -68kHz.

The solution here is also simple; calibrate your bladerf correctly to remove DC offsets at the frequency and gain settings used for the calibration.
pedrocab
Posts: 5
Joined: Tue Sep 02, 2014 7:51 am

Re: "kalibrate-bladeRF" and GSM chanel problem with BladeRF

Post by pedrocab »

Thank you for your answer jquirke.

Please, I will appreciate if yiu could you share your code modifications (or patches) to solve issues 1 and 2 ("I have modified my kal to open/close the bladerf at the start of the channel search loop and the DAC calibration loop." and "...within 1.5MHz. In this case, add a digital LPF to the code.") ?. Is not a matter of laziness.

Pedro
Post Reply