Can two applications use one bladerf board ?

Having issues with the site, hardware, source code, or any other issues?
Post Reply
blrfuser
Posts: 9
Joined: Tue Oct 13, 2015 11:21 am

Can two applications use one bladerf board ?

Post by blrfuser »

I have a single bladeRF board.

I am sucessfully running a single application like this:

airprobe_rtlsdr.py -f 1960.8M

and everything works fine.

However, I would like to monitor *two* GSM base stations at the same time with just the single bladeRF by running two difference 'airprobe_rtlsdr.py' commands, each on a different frequency. Is this possible ? Can you timeshare the bladerf device, perhaps configuring timeslices to switch back and forth on ?

Thanks.
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: Can two applications use one bladerf board ?

Post by bpadalino »

No, this doesn't work especially with USB.

What are the two frequencies you want to see? How are you configuring your device?
blrfuser
Posts: 9
Joined: Tue Oct 13, 2015 11:21 am

Re: Can two applications use one bladerf board ?

Post by blrfuser »

The two freqs would be something like 1960.8mhz and 850mhz ...

I was hoping I could hop frequencies every second or so ... spending one whole second on each frequency.

Maybe I could just do that myself with a script ... run airprobe for one second, capturing the output, and then kill that process and run it again with a different frequency ... I could just timeshare the device myself.

So am I correct that the gnu radio framework locks the device and only lets one process access the bladeRF at a time ? When I start a second 'airprobe' process simultaneously, it does not work because it can't access the bladeRF instance... ?
Zortz
Posts: 15
Joined: Mon Oct 26, 2015 1:50 am

Re: Can two applications use one bladerf board ?

Post by Zortz »

blrfuser wrote:The two freqs would be something like 1960.8mhz and 850mhz ...

I was hoping I could hop frequencies every second or so ... spending one whole second on each frequency.

Maybe I could just do that myself with a script ... run airprobe for one second, capturing the output, and then kill that process and run it again with a different frequency ... I could just timeshare the device myself.

So am I correct that the gnu radio framework locks the device and only lets one process access the bladeRF at a time ? When I start a second 'airprobe' process simultaneously, it does not work because it can't access the bladeRF instance... ?
Any program that opens the bladeRF locks it - that is my experience.
I would suggest investing into GNURadio. You could make a flow graph to suite your needs.
But it is not going to be easy...so if time = money then maybe best option is to just buy another bladeRF :)
blrfuser
Posts: 9
Joined: Tue Oct 13, 2015 11:21 am

Re: Can two applications use one bladerf board ?

Post by blrfuser »

Out of curiousity, is it the same situation with a RTL-SDR device ? If I started a second userland program (like airprobe) that listens on the device, it will be locked out by the first instance of the program ?
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Can two applications use one bladerf board ?

Post by jynik »

Considering that both libbladeRF and the RTL-SDR library use libusb, then I would guess that the same implementation details are relevant.

The Windows Cypress driver actually does not require this, and could allow multiple processes to both open the device. However, we utilize a global mutex ("shared" across processes) to make the API behave the same way it does with the libusb backend.

Having a single process "own" the device certainly simplifies things from the development side of things, in there's less to think about in terms of device arbitration and multiple "users" trying to do conflicting things.

On thing I've been interested seeing done/doing is to add a socket backend to libbladeRF. One program would open up the device locally using one of the existing USB backends and additionally start up the "server" socket. A "client" could use libbladeRF but specify bladerf host and port in the bladerf_open() string. The server-side backend implementation would have to arbitrate control calls, and block access to RX/TX streams depending on who initializes it first (client, vs server). The beauty of this would be that the "client" is still just using libbladeRF the same as it always has, without necessitating application-level changes.

Not that while I say "client" and "server" that needn't be over a network. This could simply be Unix Domain Sockets.

Cheers,
Jon
Post Reply