[srslte-users] Problem with srsLTE captures using bladerf

[Nicola Bui]

Dear Ismael, all,

I solved by changing the bandwidth configuration for bladerf set rx_srate
function: since, bladerf can only choose one out of a set of filters and,
lte does not use all the carriers that are recorded I set the bandwidth to
be:
bw = rx_srate * used/fftlen
then the board piccks the closest filter. In particular, I have been able
to remove the high power noise using a 10MHz filter on a 11.52 Msps
sampling rate (filtering down to 8.75 MHz also works, but I am afraid the
filter start attenuating the signal).

Below is a snippet of my code.

---------------------------------------------------------------------
double rf_blade_set_rx_srate(void *h, double freq)
{
  uint32_t bw;
  rf_blade_handler_t *handler = (rf_blade_handler_t*) h;
  int status = bladerf_set_sample_rate(handler->dev, BLADERF_MODULE_RX,
(uint32_t) freq, &handler->rx_rate);
  if (status != 0) {
    fprintf(stderr, "Failed to set samplerate = %u: %s\n", (uint32_t) freq,
bladerf_strerror(status));
    return -1;
  }
  if (handler->rx_rate < 2000000) {
 status = bladerf_set_bandwidth(handler->dev, BLADERF_MODULE_RX,
handler->rx_rate, &bw);
 if (status != 0) {
   fprintf(stderr, "Failed to set bandwidth = %u: %s\n", handler->rx_rate,
bladerf_strerror(status));
   return -1;
 }
  } else {
 status = bladerf_set_bandwidth(handler->dev, BLADERF_MODULE_RX,
handler->rx_rate*0.8, &bw);
 if (status != 0) {
   fprintf(stderr, "Failed to set bandwidth = %u: %s\n", handler->rx_rate,
bladerf_strerror(status));
   return -1;
 }
  }

  printf("Set RX sampling rate %.2f Mhz, filter BW: %.2f Mhz\n", (float)
handler->rx_rate/1e6, (float) bw/1e6);
  return (double) handler->rx_rate;
}
---------------------------------------------------------------------

Best regards,
Nicola Bui

Research Engineer
IMDEA Networks Institute
Av. Mar del Mediterraneo, 22
28918 - Leganés (Madrid) - Spain
mobile: +34 657 633 987
phone: +34 91 481 6986
fax: +34 481 6965

On Wed, Mar 23, 2016 at 12:02 AM, Ismael Gomez <
ismael.gomez at softwareradiosystems.com> wrote:

> Hi,
>
> It could also be the LO leakage. I think you can mitigate that by adding
> some frequency offset to the frequency tunning process. You can play with
> the bladeRF driver as much as you want. The interface is implemented in
> srslte/lib/rf/src/rf_blade_imp.c
>
> Hope that helps, let me know if you need any further info
>
> Cheers
> Ismael
>
> On Tue, 22 Mar 2016 at 17:24 Nicola Bui <nicola.bui at imdea.org> wrote:
>
>> Dear all,
>>
>> first of all let me thanks the team for the great job and the support
>> they gave me throughout my development.
>> I am capturing some lte traces with both a bladerf x40 and usrp x310.
>> Both are fine in most of the cases, but I found the bladerf x40 to
>> introduce some high power noise inband. You can find attached two pictures
>> related to similar captures:
>> - frequency 1854.1 MHz
>> - samplerate 11.52 Msps
>> - resource blocks 50
>> As you can see the bladerf capture shows two high power carrier on the
>> right side of the spectrum, which, usually are not a big problem, but when
>> I try to decode DCIs using that part of the spectrum (ncce 5, 24, etc.)
>>
>> I tried a similar capture with bladeRF-cli and gnuradio (osmosdr
>> interface): the former got the same problem, the latter did not. My guess,
>> it is something related to how the bladerf is opened (I am thinking about
>> how the signal is filtered), but I have no clue on how to test it.
>>
>> Is there any way to control the bladerf configuration from within
>> pdsch_ue or usrp_capture_sync?
>>
>> Thanks a lot,
>> Nicola Bui
>>
>> Research Engineer
>> IMDEA Networks Institute
>> Av. Mar del Mediterraneo, 22
>> 28918 - Leganés (Madrid) - Spain
>> mobile: +34 657 633 987
>> phone: +34 91 481 6986
>> fax: +34 481 6965
>> _______________________________________________
>> srslte-users mailing list
>> srslte-users at lists.softwareradiosystems.com
>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20160323/11a4ad82/attachment.htm>