Official bladeRF forum

Afaik i'm the only one currently working on windows support right now (working in win7 x64,not tested on anything else), I have a very basic ExtIO dll which i've tested with HDSDR (winrad doesn't like it, then again it doesn't seem to like any of the 3rd party exio dll's i have fed it..) I also have SDR# support (using their own driver model, not through extio), I haven't tested or put any effort into supporting any of the other apps out there. But basic RX stuff should work in apps that support ExtIO. It needs a lot more polish though so not sure when it'll be 'good enough' to be merged into nuand's main repository.

Whatever the bladerf does support on Windows, it ought to do more than tune a single channel. If the extio.dll based programs can't do this, then maybe the resources ought to put into supporting an application that can.

I'd be more than happy to support anything that is available for free and has extensibility options, as soon as there is a price to be payed, I have very little interest to do the work.

Either way if any of you is desperate enough for windows support and are not afraid of compilers, drop by on irc and i might be able to help you out, if you're looking for a well tested binary download i suggest waiting a little longer for the changes to merge into the mainline.

HDSDR screenie
SDR# Screenie

Think there is a away to feed two concurrent instances of SDR# via a single stream from the bladerf? From what I have read, Unitrunker can command SDR# to tune the voice channel, although I have not tried it since blowing $40 for two rtlsdr dongles seems silly. If that would work, a trunking receiver would be a slick application for the bladerf, and something to listen to above 400 MHz.

madengr wrote:Wow, I apologize if I have offended anybody. Simon, if you can get your software working with the bladerf, and it supports multiple demodulators, that would be slick.

It takes a lot to offend me

The bladeRF is interesting for me as it'll be a good stress-test of the software when running at maximum bandwidth. On Monday at the latest I'll be starting on satellite tracking - graphics display, Doppler correction etc. Although there are six VFOs in the console already I'm happy to come up with a design for many more - some sort of matrix or whatever.

I'm really waiting for a driver announcement before moving to the next step. As soon as there's a driver that will install on Windows 7 64-bit then I'll start the bladeRF support.

Think there is a away to feed two concurrent instances of SDR# via a single stream from the bladerf? From what I have read, Unitrunker can command SDR# to tune the voice channel, although I have not tried it since blowing $40 for two rtlsdr dongles seems silly.

Technically there's no reason why that couldn't be done (making multiple instances share data) just nobody has written the plugin to actually do it.

Any news on Windows support yet? I'm getting quite a few Windows users asking me about bladeRF support in my console.

The current branch builds a dll and has a rudimentary CLI you can use. There are some reported issues with different xhci's in Windows - some work and some don't. One of our developers with a Renesas xhci had to upgrade to the latest drivers before it would work properly.

The wiki has notes on getting started building for Windows. Hearing feedback if it works/doesn't is always helpful.

Thanks,

I'll see if I can get this compiled over the weekend - if so I'll buy the bladeRF.

i was able to do the windows build today. I'm using the 64-bit libusb. The Blade connects on USB2 and USB3 (but only on my ASMedia USB3 controller, NOT on my VIA USB3 controller). When I run the CLI, it tells me it's in legacy mode (expected). I'm stopped at trying to load the FX3 firmware - the flash fails with the following info:

E:\Temp\BladeRF_Win\BladeRF-CLI>bladerf-cli -f latest.img
[INFO] Using libusb version 1.0.16.10774
[INFO] Found a bladeRF
[ERROR] Failed to retrieve serial number
[INFO] Claimed all inferfaces successfully
********************************************************************************
* ENTERING LEGACY MODE, PLEASE UPGRADE TO THE LATEST FIRMWARE BY RUNNING:
* wget http://nuand.com/fx3/latest.img ; bladeRF-cli -f latest.img
********************************************************************************
Flashing firmware...
[INFO] Legacy change to interface 2
[INFO] Erasing 3 sectors starting @ sector 0
[ERROR] Failed to erase sector 0
[ERROR] Received erase failure status from FX3.
Error: failed to flash firmware: File or device I/O failure
Could not flash firmware

Any ideas?

Also tried it with the previous image (1.2.img), which also failed.

dsalomon wrote:Any ideas?

I don't know, but I see exactly the same error. I have a thread going here, but I haven't found an answer yet.

Ahhh...thanks. I guess I could've searched before posting. Doh.

spcutler -

i was chatting with BzztPloink on the #bladerf IRC node, explaining this problem. He checked the source, and fixed it. You can either wait until he merges the change into the source and do a get, or just make the change to the source, as follows (this is what I did):

(7:56:54 PM) BzztPloink: http://pastebin.com/pKH5t8Mf
(7:57:10 PM) BzztPloink: in libusb.c replace the change_setting function with this

After making the change, recompile and it should work. I was just able to load the "latest.img" firmware file to the FX chip, then load the FPGA, then receive samples.

Woo hoo!

That paste expires in 23 hours, but by then with a bit of luck it got merged already.

If there has been any development on the extio.dll front, I'd be happy to do some testing. After successfully building the bladerf platform for windows, I now have nothing to do with it!! (except for bladeRF-cli rx/tx but that is boring )

I've been distracted lately, and plagued by usb controller issues on windows. I just got my SDR# code working (literally minutes ago) again with the official libs since those now offer windows support, I'll eventually get to extio support, but i wouldn't count on it anytime soon, same goes for the release of my sdr# code, it's just not good enough yet.