XB 200 - Firmware Update

[SDR-Radio.com]

Hi,

I just tried to test XB 200 support and get a message "A firmware update is required". Please save me time and give me a step-by-step fool's guide to uploading new firmware. I have downloaded and compiled the current GIT code, all is looking good.

Shout at me direct if you want: [email protected] and I'm also on SKYPE.

Time for a bath...

[SDR-Radio.com]

Also I want the new firmware to be loaded automatically when the bladeRF is powered on. As I have moved house and not used the bladeRF for many months I've forgotten...

[Montezuma]

Also I want the new firmware to be loaded automatically when the bladeRF is powered on. As I have moved house and not used the bladeRF for many months I've forgotten...

I thought that electrons helped electronics function automatically, like a built in "plug-n-play". I think I was lied to.

[jynik]

The current Windows installer is very out of date -- I've reminded the maintainer to generate one that will install software, firmware, and an FPGA that are compatible with the XB-200. When this is up, it will be probably be the preferred route for your users. For now, building the libs and host tools from source as you're doing is the right way to go.

Below is the requested summary, for more information see the firmware upgrade wiki page.

1. Download the lastest firmware (v1.7.0) and the latest FPGA (v0.0.5). The latter is absolutely required to use the XB-200.
2. Identify your current firmware version. This can be done via bladeRF-cli.exe, using the 'version' command in interactive mode (or bladeRF-cli.exe -e version)
3. If you have an FPGA autoloading from SPI flash, disable this via bladeRF-cli.exe -L X
4. If your firmware version is 1.6.0 or higher, you can program new firmware to flash via the CLI: bladeRF-cli.exe -f <path to firmware>, or from within interactive mode: load fx3 <path to firmware>
5. If your firmware version is earlier than 1.6.0, you will have to follow the wiki page on using the FX3 bootloader.
6. After programming the firmware to flash, it will boot and take effect following a power cycle of the board.

[SDR-Radio.com]

Thanks,

I can now start the bladeRF but streaming times out .

Will take dog for a walk & a beer, with luck a clear brain will help.

[jynik]

It might be worth doing a "sanity check" to ensure the bladeRF stuff is all good before any potentially unneccessary banging your head against code.

When building the host libs and tools, bladeRF-cli.exe and libbladeRF_test_sync.exe should be built. Both can be used to receive samples to a file -- ensuring these are operating without timeouts is probably a worthwhile test. The help text in these should hopefully make it clear how to receive samples; if not I'll stop by later to clarify.

When debugging code issues with bladeRF.dll, I recommend setting the bladeRF.dll verbosity to verbose, and sharing log output here when trouble arises.

If you're using the synchronous device streaming interface (which is a lot easier than the async interface), you can enable extra output about the state of the underlying buffer managment (when the log level is "verbose") by setting the following option to "ON" when running CMake: ENABLE_LIBBLADERF_SYNC_LOG_VERBOSE. When you do this, you'll quickly see why this is a compile time option -- it's a ton of output, but it's been very valuable when debugging the sync interface.

[SDR-Radio.com]

First problem - you only allow small attachment sizes which makes uploading screenshots a problem

Anyway, here's the status of the libbladerf components:

Code: Select all

08:48:57>     FPGA configured: status = 1, OK
08:48:57>         libbladerf version = 0.16.0-git
08:48:57>         Firmware version   = 1.7.0-git-ee89b79
08:48:57>         FPGA loaded        = Yes
08:48:57>         FPGA version       = 0.0.5

I've not changed anything else. Full log is at the bottom of this posting. I see the stations, the frequencies are correct but there are 'issues'. I've tried many combinations of the various gains and filters. I'm using a USB 3 port, same when using USB 2. Using same libusb as before.

So the questions are (I assume):

1) Is this combination of versions correct?
2) What buffer sizes and buffer count did you use in bladerf_init_stream when testing the bladeRF with XB-200 with your own software?
3) If you look at the screenshot you see that something's going wrong with the data inside the bladeRF DLL, I wonder if there's an option I should set etc?

Can we talk on SKYPE please? I'm very busy and would like to get this software working for your user community. I'm sdr-radio.com on SKYPE.

Code: Select all

08:48:57> bladeRF
08:48:57>     ++Open
08:48:57>     Opening libusb:serial=7e54ea5b56c88e5db82bd7312a00a601, status = Success
08:48:57>     FPGA configured: status = 1, OK
08:48:57>         libbladerf version = 0.16.0-git
08:48:57>         Firmware version   = 1.7.0-git-ee89b79
08:48:57>         FPGA loaded        = Yes
08:48:57>         FPGA version       = 0.0.5
08:48:57>     Enabling XB-200, status = Success
08:48:57>     Setting filter to 3dB points, status = Success
08:48:57>     Initial values from bladeRF
08:48:57>     Get bladeRF version: 0.16.0-git
08:48:57>     Get RX frequency: 96.600.000
08:48:57>     Get RX bandwidth: 3.000.000
08:48:57>     Get RX sample rate: 4.000.000
08:48:57>     Get RX LPF mode: Disabled
08:48:57>     Get LNA gain: Max (12dB)
08:48:57>     Get RX VGA gain 1: 20dB
08:48:57>     Get RX VGA gain 2: 30dB
08:48:57>     Set frequency: 98.000.000, status = Success
08:48:57>     Set sample rate: 4.000.000, actual 4.000.000
08:48:57>     Set RX LPF bandwidth: 3.000.000, actual = 3.000.000
08:48:57>     Get RX frequency: 98.000.000
08:48:57>     Get RX bandwidth: 3.000.000
08:48:57>     Get RX sample rate: 4.000.000
08:48:57>     Get RX VGA gain 1: 20dB
08:48:57>     Get RX VGA gain 2: 30dB
08:48:57>     Get RX LPF mode: Normal
08:48:57>     Get LNA gain: Max (12dB)
08:48:57>     Set RX LPF mode: Normal, status = Success
08:48:57>     --Open
08:48:57>     ++Starting sending
08:48:57>     Set sample rate: 4.000.000, actual 4.000.000
08:48:57>     Set RX LPF bandwidth: 3.000.000, actual = 3.000.000
08:48:57>     Get RX frequency: 98.000.000
08:48:57>     Get RX bandwidth: 3.000.000
08:48:57>     Get RX sample rate: 4.000.000
08:48:57>     Starting RX thread
08:48:57>     Starting RX stream
08:48:57>     Initialise RX stream: buffers            = 4
08:48:57>                           samples per buffer = 16384
08:48:57>                           max simultaneous   = 4
08:48:57>                           status             = Success
08:48:57>     Enabling RX stream...
08:48:57> Input Reader (Part 1)
08:48:57>     Starting sending, bandwidth 4000000
08:48:57> bladeRF
08:48:57>     --Starting sending
08:48:57>     Set RX VGA gain 2: value 30dB, status = Success
08:48:57>     Set RX LPF mode: Normal, status = Success
08:48:57>     Set RX VGA gain 1: value 20dB, status = Success
08:48:57>     Set LNA gain: Maximum, status = Success

[bpadalino]

Hi Simon,

1) Is this combination of versions correct?
2) What buffer sizes and buffer count did you use in bladerf_init_stream when testing the bladeRF with XB-200 with your own software?
3) If you look at the screenshot you see that something's going wrong with the data inside the bladeRF DLL, I wonder if there's an option I should set etc?

1) The versions seem good to me.
2) You should probably be using more buffers than number of buffers in flight. Moreover, you should probably use many more buffers at a 4MHz sample rate. Try changing it such that you have 32 or 64 buffers of size 16384 samples with 20 or so that can be in flight at any given point in time.
3) I suspect that might be an artifact of discontinuities in the received sample stream. We're working on getting metadata flags working so you can know when there have been discontinuities. Did you do what jynik suggested?

When debugging code issues with bladeRF.dll, I recommend setting the bladeRF.dll verbosity to verbose, and sharing log output here when trouble arises.

If you're using the synchronous device streaming interface (which is a lot easier than the async interface), you can enable extra output about the state of the underlying buffer managment (when the log level is "verbose") by setting the following option to "ON" when running CMake: ENABLE_LIBBLADERF_SYNC_LOG_VERBOSE. When you do this, you'll quickly see why this is a compile time option -- it's a ton of output, but it's been very valuable when debugging the sync interface.

That would show discontinuities which may be happening.

As for the screen shot, I can only recommend that you can use a site like imgur and linking to the screen shots instead of uploading them with the post? They have a pretty good retention policy and you can even make galleries for multiple pictures.

Brian

[SDR-Radio.com]

Brian,

Thanks - I'll try now with more buffers and report back. It was OK before I upgraded the firmware, libbladerf, installed the XB 200. I'll report back.

[SDR-Radio.com]

Brian,

No joy at all, I've increased the number of buffers as suggested, also I'm using the asynchronous interface (uses the steam_callback). Somewhere a change made by the Nuand team has made subtle difference which has broken my code. The test utility does not report errors, as it doesn't generate waterfalls though it's not a great test .

I have the same problems with 32-bit and 64-bit images.

Please can we talk on SKYPE?

[bpadalino]

Sorry - I didn't get to this post until late tonight.

You can try to use the synchronous interface instead of the async one. It should be much simpler to work with. Just be sure you are thread safe when calling the functions.

Do you have verbose log outputs from the library? You can set the output using bladerf_log_set_verbosity().

If you remove the xb200, do the samples look normal again? Do these problems only exhibit themselves in the FM band?

There is a way to put the FPGA in a 32-bit counter mode if you want to look for discontinuities in your data.

Hopefully this is helpful in some sense. Like jynik said, looking at the verbose logs from your output with the USB transactions would be useful.

Brian

[SDR-Radio.com]

Hi Brian,

I think I'll try the synchronous interface, IMO the asynchronous interface is clearly broken. I don't know when I'll get time - this evening maybe.

If this approach doesn't work I'll remove support for the bladeRF until your next software release, this will ensure there's no confusion.

As an aside I've now got the waterfall running very smoothly with a 30MHz span.

[SDR-Radio.com]

As you say, the sync interface is much simpler - let's see. It'll be a nice sunny day here, things to do in the garden.

[bpadalino]

Hi Simon,

Sounds great that you've gotten the waterfall to work. Not sure if it means using the sync interface that things are much better now, or since the day was nice and gardening had to get done - you put away the technical things?

Are there still issues? Sorry for the confusion.

Brian

[SDR-Radio.com]

Hi Brian,

Weather's nice, I've looked at your sync program and it does seem simple, so I'll give it a go this evening. Currently I'm in and out of the garden, when in the office I'm writing a shapefile class to draw timezone info on a map of the world.

So there!