dev-uart_speedup merged

[jynik]

Hi all,

The updates(from the dev-uart_speeup branch) mentioned in the recent blog post have been merged into master:

• Faster UART bridge between FX3 and FPGA
• IQ correction support
• FPGA version number
• Misc fixes

To use the lastest in master, please update to firmware 1.6.0 and FPGA v0.0.1.

Windows may want to wait for issue 183 to get resolved before attempting to flash new firmware.


Because of the change to the UART bridge speed, be sure to disable FPGA autoloading before flashing the firmware. Otherwise, the two devices won't be communicating at the same baudrate.

To disable FPGA autoloading, pass "X" to the bladeRF-cli autoload flash (-L) argument.

Code: Select all

$ bladeRF-cli -L X

If you ever happen to find yourself with incompatible versions or corrupted flash, remember that you can always recover by dropping to the FX3 bootloader and loading firmware to RAM using either bladeRF-flash or the Cypress Control Center program. From there, the CLI could be used to flash the desired versions.


While a number of folks have been kind enough to test drive this branch and have been reporting good results, let's remain on the lookout for any new defects or regressions. As always, please report or comment on defects on the GitHub issue tracker.

Cheers,
Jon




Update:
As noted on the wiki, an si5338 communication failure is likely to be the first symptom of a firmware & FPGA version mismatch.

Just a couple reminders, if you're seeing the "Could not write to si5338" error:

• Ensure you've disabled FPGA autoloading before flashing new firmware.
  • If you don't do this, you'll wind up with firmware using one bridge baudrate, and an older FPGA getting autoloaded that uses the slower baud rate, and therefore, peripheral communication issues.
• Ensure you've flashed FW v1.6.0. For good measure, power cycle the device after successfully flashing firmware.
• The lastest FPGA now has a v0.0.1 version number -- double check that this is what you're attempting to load.

To expand a bit more on how to recover from forgetting to disable FPGA autoloading before flashing, here's a slightly more detailed summary of the "recovery" process.

1. Use the jumper J64 to force the device into the bootloader. Be sure to remove the jumper once you've powered on the device and see that it's in the bootloader. This will be evident via a Cypress entry in dmesg output, Device Manager, etc. If you forget to remove the jumper, you won't be able to access flash in the following steps.
2. Use bladerf-flash or the Cypress SDK tool ("Control Center" in Windows, "cyusb_linux" in Linux) to load the older firmware into RAM, such as v1.5.3.
3. Once the device is running firmware from RAM, you can run

   Code: Select all

   bladeRF-cli -L X

   to disable autoloading.
4. At the point you could also re-flash the firmware. (However, if you're following this procedure, you probably already have it flashed.)

Update 2:
This thread contains more details on the above recovery procedure: http://nuand.com/forums/viewtopic.php?f=4&t=3515

[dk5ras]

Following your instructions works just fine. However it looks to me now like I and Q swapped, when using gqrx, and there is a strong symmetrical image. Swapping I and Q and playing with iqbal and remove DC does not bring it to the previou quality of the spectrum.

Edit: This is the same for SDR# and Windows, so I guess it is not some mix-up in my Linux installation.

Do the files from http://hoopycat.com/bladerf_builds/ include those new features, or should I stay with those from nuand.com?

Ralph.

[drmpeg]

The poor receive spectrum is a known bug. It was mentioned in the blog post at http://www.nuand.com/blog/

"Mitigating any remaining buffering, and spectral inversion issues some of you may be experiencing."

However, the new FPGA does fix the transmitter, so it's very useful for TX projects.

Here's some gqrx pics that show the problem (using an over the air ATSC signal which should have the pilot on the left).

As sample rate is increased, the pilot moves from the left, to both sides, and then finally to the right. A very odd behavior indeed.








Ron

[dk5ras]

Well, they write about mitigating...in fact these problems did not mitigate, but show up with this release

Ralph.

[dk5ras]

This screenshot http://dk5ras.dyndns.org/tmp/bladerf_problem.png is how a LTE1800 signal shows up after this upgrade of firmware and FPGA image (115k). 1808 - 1822 MHz is the real signal, only in the right place when IQ swap is active, the smaller block on the right side is the image that was not there before.

Ralph.

[bpadalino]

Interesting. I couldn't see the LTE image, but I saw the others from drmpeg.

Can you do a version in the CLI to see what version of the library you are using? Have you updated gr-osmosdr as well?

[dk5ras]

Well, I can't update the library, due to my annoying libusbx problem. I only updated firmware and the 115k fpga image. To get back a working system, I went back to the previous versions.

Why did you not see the LTE picture? Did the link fail? Then I can send it by email...

Ralph.

[bpadalino]

Link did not fail - my DNS was flaky. I saw it now. The libusbx problem is a strange one since the libusb_get_version() function has existed since 1.0.12. Are you sure it's trying to load the correct libusb? ldd on the library shows it's pulling in the one you think?

I'll take some time later to look at the conjugate issue.

[dk5ras]

I have written my results regarding the libusb problem in the troubleshooting forum. Maybe some wrong search order or so, but I do not know yet how this is configured in Linux systems. I will find out, sooner or later

Ralph.

[drmpeg]

Here's an update on the receive spectrum issue. Today, I just happened to try a new FPGA image from the Hoopycat build machine (http://hoopycat.com/bladerf_builds/). This FPGA image was built with Quartus 12.1sp1, and did not work. However, when I reloaded the new FPGA image from the Nuand site (http://nuand.com/fpga/) which is built with Quartus 13.1, the spectrum problems magically disappeared.

I don't have a clue why this worked, but it did. Ralph DK5RAS, could you give this a try?

Ron

[dk5ras]

OK, I will try, but I still can't update libbladerf, as it will not work on my Kubuntu 12.04 LTS due to the libusbx thing. Anyway at the moment I am in the process of setting up an additional vm with Kubuntu 13 latest release, hopefully this will allow updating it all.

I will let you know what happens

Ralph.

[dk5ras]

Yesterday I installed a fresh virtual machine, Kubuntu 13.10, 32bit. Gnuradio, osmo-stuff, bladeRF, gqrx, all from the sources to the latest versions, but firmware and FFPGA of the bladeRF still the older versions. Again I got the swapped IQ thing, together with strong image bleeding to the other side. Then I gave bladeRF a -L x, flashed the firmware, restarted the board, flashed the FPGA, and got a failure on the first attempt. On the second attempt it ran through, and now reception was OK, no swapped I and Q, no images. So I assume that something has changed regarding the inner workings of bladeRF, requiring to update both the bladeRF library/tool package and the EEPROM content. Still have to confirm that the Windows behavior is now wrong, but I guess so, judging from the first tests with the new EEPROM content.

Ralph.