We have added many new exciting features and improvements to bladeRF in the past couple of weeks. By upgrading to the latest FX3 image ( http://nuand.com/fx3/latest.img ) you can now store FPGA images on the SPI flash by running `bladeRF-cli -L hostedx40.rbf`. This will allow your bladeRF to read an FPGA image from flash and program the FPGA without the need of a host computer. Autoloading was used to get the UAV-SDR operational ( http://www.nuand.com/blog/heading-to-defcon/ )!
Simon Brown of SDR-Radio fame has recently added bladeRF support to SDR-Radio v2.1 (which is still in beta). To download and try out SDR-Radio follow this link: http://v2.sdr-radio.com/Download.aspx . Scrolldown for a screenshot of SDR-Radio looking at 38.4MHz of bandwidth in the 2.4GHz band. A moderately active 802.11 device can be seen at 2.437GHz (which coincides perfectly 802.11 channel 6!). The narrower signals between 2.448GHz and 2.451GHz belong to Bluetooth devices.
Preliminary Matlab support with included instructions can be found at http://nuand.com/downloads/matlab.tar.gz . We will update everyone as soon as a separate git repository is launched to address Matlab support for bladeRF! There is also preliminary support for bladeRF in PyBOMBS now at https://github.com/nuand/pybombs . A quick guide to using PyBOMBS can be found at http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart , please ensure you clone our git repository when following those instructions.
Lastly, the HF/VHF transverter has undergone multiple architecture revisions, although they all seem to work we have felt like there might be room for a little more performance increase. We have taken into consideration many people’s requests and suggestions about the overall architecture of the transverter on IRC, the forums, and over email. We hope the proposed improvements we have come up with will be well worth the wait. We will present the semi-final block diagram and performance characteristics of the expansion board shortly.
We have come a long way with our platform support in the past couple of weeks. We have added and tested DC calibration, sped up FPGA programming, added a new bladeRF-flash tool and several streaming examples, and moved most of the API over to asynchronous calls.
To benefit from these changes you must upgrade your device, instructions on upgrading the bladeRF can be at https://github.com/Nuand/bladeRF/wiki/Upgrading-from-v1.0 .
Within the next week we will merge the SPI flash based FPGA loader, which allow the bladeRF to not require a computer to load the FPGA and in effect run headless. Afterwards, our focus will switch to back to merging in timestamped transmissions support, this will enable OpenBTS to run on the bladeRF.
There is now a Windows based installer for the bladeRF that will install all of the relevant drivers, user mode utilities, and FX3/FPGA images. The file can be directly downloaded from http://nuand.com/downloads/bladerf_win_installer.exe .
We would also like to thank the community contributors that have provided patches, and pointed out issues to us. (Bugs and requests for features can be filed via Github athttps://github.com/Nuand/bladeRF/issues/new ).
Lastly, RTucker (HoopyCat) has created an autobuilder for the FX3 and FPGA images. The autobuilder recompiles everything on every commit that is merged into master on Github. The autobuilder can be found at http://hoopycat.com/bladerf_builds/ .
We have spent the last week working on platform support. Windows and Linux installation procedures have been updated and can be found at https://github.com/nuand/bladerf/wiki(OSX installations should flow very similarly to Linux).
We are also trying to debug a SuperSpeed USB3.0 issue that occurs with libusb and certain XHCI controllers. So if at all possible, if you have an ASMedia or Renesas XHCI and are running Windows, could you please tell us via Kickstarter, or email ( bladeRF@nuand.com ) if you bladeRF-cli is able to see the device?
As you might have guessed bladeRF-cli now has interactive support on Windows as well!
There is also another firmware upgrade available (v1.2) that has minor fixes that is avaiable at http://nuand.com/fx3/1.2.img .
A community member who goes by handle Acceleron uploaded designs for a case for the bladeRF to thingiverse this past week ( http://www.thingiverse.com/thing:137021 ). We also uploaded the mechanical DXF files to bladeRF to our site in case anyone would like to get specific measurements of the board, https://nuand.com/bladerf_top.dxf .
We spent a great deal of time integrating our libusb changes into our master branch this past week. From all of the regression testing we have done, libusb support seems to be stable and working pretty well on Linux. There are a few Github issues regarding OSX and Windows that are being worked out this week, so hopefully by the next update we’ll have good news for all three platforms (Windows, Linux, OSX). Libusb and OsmoSDR support is on its way but we still suggest that users use the Linux driver until the libusb async support that has been added is made to work with OsmoSDR.
Lastly, if you haven’t received your unit and haven’t yet placed an order claiming your reward please look through the Kickstarter messages we sent a while ago to see how to go about this process.
bladeRF is now officially in stock! Thank you all so much for backing us and making this project a reality.
For those of you that have already claimed your rewards by placing an order on our site you should have received your unit by now, been sent a tracking number, or been sent an email with questions or been given a personalized update. If you claimed your reward and none of these things have happened, please reply to the order confirmation email you received from our site. If you haven’t claimed your order, please check your Kickstarter message box to see how this should be done.
If you are a developer or enthusiast backer, we will contact you shortly about additional steps we have for fulfilling our commitments to you.
We’ve been working tediously on libusb support ( https://github.com/nuand/bladeRF/tree/dev-libusb_support ) that so many of you have asked us for. Once libusb is stable the codebase will default to using libusb as the default method of communicating with the bladeRF. The driver will remain available for advanced users who need low latency, and zero copy buffering. Libusb support should be finished soon, and then we’ll finally have time for some really fun things.
Lastly, we’ve been asked if we will continue our weekly updates, and the answer is yes! There are many projects and updates we would like to keep all of you up-to-date with.
PS. Greetings to everyone we met at DEFCON this year!