Errors calibrating bladeRF x40

Having issues with the site, hardware, source code, or any other issues?
Post Reply
wpats
Posts: 9
Joined: Tue Aug 18, 2015 8:13 pm

Errors calibrating bladeRF x40

Post by wpats »

Hi,

I just purchased one of these devices and followed the instructions to generate a dc offset table. I ran into a couple of issues doing this. Every time I run the "cal lms" command in bladeRF-cli I get different values printed out for "LMS RX LPF modules...". For example in this the Q value looks suspicious:

Calibrating LMS RX LPF modules...
RX LPF I filter: 25
RX LPF Q filter: 1

On another run it gives:

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

Why does the Q value change so much with each run ?
The second issue happens when I run "cal table dc rx". I get the following error several times:

[WARNING @ lms.c:1887] vtune_norm_to_low: VCOCAP hit max value.avg: 1 )

What is causing this ? Is the hardware defective ?

I would appreciate any help.

--Patrick
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Errors calibrating bladeRF x40

Post by jynik »

Hi Patrick,

There are some pending items I need to fix in the DC calibration routines, so it might be a good idea for everyone in general to follow those items on the GitHub issue tracker. (Looking to tackle them over the course of these next couple weeks).
One thing that's come to my attention recently is that doing calibration with RX and TX tuned to the exact same frequency is not ideal (because their PLLs may interfere) -- so that's something I'll have to change.

The warning you receive was recently added and was what drove us to make some adjustments that I pushed to the repo yesterday (with a new FPGA image) to close Issue #417.

Basically, when tuning to a frequency we must select one of four VCOs to use. Each of these VCOs operates over a certain frequency range, and these ranges overlap. However, we've found that when you get too close to the edge of this range we hit a limit in our tuning algorithm before we can identify a nominal "VCOCAP" register value. We output the warning in this case. To address this, we made some changes to the frequencies at which we switch VCOs based on some experimental data with a number of boards. We also added some changes to the tuning algorithm, which includes a second attempt. Due to variations between parts and boards, folks might still see a similar warning when using host tuning mode, which we've reworded to better indicate that the device isn't failing, it just couldn't find a nominal value. If we hear about a lot of these warnings, we'll have to think about how to allow people to generate their own VCO tuning calibration tables, and optionally use those instead of the default.

The RX LPF Q filter change you're showing is definitely concerning to me; it should not change mode than a couple counts. Note that it jumps between 1 and 33 -- a difference of a single bit. Do you find that this is always the case?

Could you record some samples (with no antenna connected) and post them somewhere (e.g. Dropbox) for us to take a look at? I want to see if the data on the Q channel is exhibiting any strange behavior. Below is a script for this:

Code: Select all

set frequency 915M
set samplerate 3M

set lnagain 6
set rxvga1 30
set rxvga2 10

rx config file=samples.bin n=6M
rx start
rx wait
You can save this to a file (I saved it to ~/Desktop/record_samples.txt), and then execute it as follows. The samples will be saved in the current working directory,

Code: Select all

bladeRF-cli -s ~/Desktop/record_samples.txt
If you'd like to dig in more, see this wiki page and these MATLAB/Octave routines to take a look at the IQ samples in MATLAB/Octave.

Best regards,
Jon
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Errors calibrating bladeRF x40

Post by jynik »

I'm able to reproduce this on a board and have some recommendations from Lime that I am looking to implement.

I've opened up issue tracker item #425 for this. I'll let you know when that's merged to master and will ask you here to confirm results.

- Jon
wpats
Posts: 9
Joined: Tue Aug 18, 2015 8:13 pm

Re: Errors calibrating bladeRF x40

Post by wpats »

Hi Jon,

Thanks for following up on this. Sorry, I haven't had the time to experiment with the bladeRF and post a recording of the samples. I am assuming that you no longer need that since you have a repro.

The RX LPF Q value is now varying less and it seems to have settled to low values like between 5 and 12. Could this be due to more use ? What is the root cause - I hope it is not a defect in some hardware component ?

I would be happy to confirm that your fix works when you publish it.

Thanks,

--Patrick
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Errors calibrating bladeRF x40

Post by jynik »

Hi Patrick,

In short, there's a number of things we need to do in software to improve results and be more resilient to expected board-to-board variations. In the event that your device is somehow defective, rest assured that the team has the historical records of your concerns here, should the fix not solve the issue for you. We can certainly figure something out if that turns out to be the case.

I wouldn't be surprised by slight variations over gain & frequency settings as well as time and temperature. However, as I mentioned the variation you noted is a symptom I suspect is related to some other failures I'm currently debugging.

At this point, there's a few recommendations we've found/gotten on reducing some undesirable signal artifacts when doing the cal routines. Specifically, Lime Micro recommends that the RX and TX paths be kept 1 MHz away from one another. It seems the PLLs interfere with one another when tuned too closely. However, our cal routines have them tuned to the exact same frequency. When doing this and plotting some results I see that the signal is "messier" than it should be, which is likely contributing to some inaccurate results.

Additionally, there is some degree of variability between boards. Some folks have reported RXVGA2 calibration errors. The RXVGA2 calibration is known to be a bit noisy, and Lime published some recommendations on how to achiever better results in their FAQ. I believe our code may be not retrying "enough" such that the results converge on some boards.

As far as workaround for the time being, I'd say you could try dialing in the RX/TX cals manually (cal dc [rx|tx] <value>), or compensate in software by subtracting off a long-running average (yielding a trade-off in dynamic range.) When using the gr-osmosdr block, be aware of that block resetting the cals to 0 when DC offset mode is set to "Off." You'll want to set that block to "Manual" to ensure it doesn't touch the DC offset correction values. It also seems that osmocom_siggen and osmocom_fft resets the cal values to zero during their initialization code, regardless of mode. That might be worth getting a patch to the authors for...

Best regards,
Jon
Post Reply