dev-uart_speedup merged

[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.