Need assistance for transmission

[lsup91]

Hello,

I'm developing VHDL on bladeRF, just keeping original sources and adding functionality to it. I was running some test on an unknown version (the only thing I know is that it was on Ubuntu 14.04 and windows seven). Then, I decided to update from git repository to the last version of client/code for bladeRF and that's how the troubles starts

My setup:
bladeRF (several x115 or x40, to be sure that it's doesn't come from the board), the Rx connected to the Tx through an attenuator, bladeRF connected to a PC using USB2 (to avoid USB3 troubles).
On my Windows:
bladeRF-cli version: 1.0.0
libbladeRF version: 1.0.0
Firmware version: 1.8.0
FPGA version: 0.1.2

On my Ubuntu 14.04:
bladeRF-cli version: 1.0.0
libbladeRF version: 1.0.0
Firmware version: 1.8.0
FPGA version: 0.1.2
And (the up to date one)
bladeRF-cli version: 1.1.2-git-f188315
libbladeRF version: 1.2.1-git-f188315
Firmware version: 1.8.0
FPGA version: 0.1.2

I am also testing using gnuradio (3.5.7.1 and 3.7.3) and gr-osmosdr.

On Ubuntu all the setup has been made following this tutorial (https://github.com/Nuand/bladeRF/wiki/G ... d%3A-Linux) following the "Building bladeRF libraries and tools from source" part.

On windows, I just use the windows installer.

To debug, I'm using the USB blaster from Alter connected to the JTAG port of the bladeRF.

Running test:
By using the simple test (the joint file is a py file that just send through a bladeRF a sin waveform and get it back on the Rx line) I ensure that everything is running smoothly.

An other test, from the client I'm sending a waveform using the "tx start" (after setting tx config file=<path_to_file>\file.bin format=bin repeat=0) and then send the "rx start" command (after setting rx config file=>path_to_file>\samples.csv format=csv n=10M) with my binary file and I validate that its working.

So know, let's activate my mode.

What I'm doing actually is adding a waveform stored in a ROM within the FPGA. With a simple MUX I'm driving the output of the ROM to the "iq_correction(tx)" module inputs when we activate a mode by pushing a button from the expansion board.

So basically, we push the button on the expansion board and enter in the client "rx start" the bladeRF trasmit the waveform and listen.

Before updating my configuration, I was receiving the content of my ROM transmitted by the bladeRF (I first had to send a random file before entering in reception mode otherwise I did not work either).
After, it's like the board never send signal. By looking at the SignalTap records, my ROM's content is drived to the LMS as I want it to be, the IQ_sel signal is asserted/deasserted as it should but on the Rx side, no signal at all.

So my question is, have anyone experiment this kind of trouble and is there any kind of modification regarding the LMS control for transmission that has been made ? (as far as I get it, for the transmission, it is controled by the "nios_gpio(2)" signal which is always set to '1')

I tried, several old version of bladeRF (branch master) and same result, I'm out of idea to fix this issue

Sorry for this long post, it is not easy to explain my problem.

[jynik]

Hi there,

Just to make sure we're clear, am I understanding the following correctly?

• The "simple test" works
• The "tx start" followed by "rx"start works
• "rx start" followed by triggering your FPGA customization does not work?

If I'm getting this right, you have a mux that throws away the samples coming from the host and instead transmits your signal from ROM. With your FPGA customization, it sounds like the TX front end may not be (fully) enabled?

Could you try having the host TX samples with repeat=0 while running your FPGA customization and the RX stream? This would ensure the logic to set up the TX front end is all executed. If that works, you could enable log verbosity to get a sense of what's being configured.

Let us know how that goes,
Jon

[lsup91]

Hi, thanks for your response,

You are correct for the three point you mention. I executed the test like this (Tx connected to Rx through external attenuator):
1:from the bladeRF client) tx config file=<path_to_file>\file.bin format=bin repeat=0
2:from the bladeRF client) rx config file=>path_to_file>\samples.csv format=csv n=10M
3:from the bladeRF client) tx start
4:from the bladeRF client) rx start
5:from the expansion board) press switch to activate custom FPGA mode

Then I check the result file samples.csv and it works as it should. So if I understand it right, there is something that is done at the begining of the transmission following the client order that I haven't duplicate on my FPGA custom code, but what exactly ?

You talk about the verbosity mode, can you please tell me how to activate it (in gnuradio it's verbosity=debug but in the client I don't know).

[jynik]

Verbosity in the bladeRF-cli can be enabled by using the -v verbose argument. This will print out lots of info, such as register writes to the LMS6002D (programming manual).

I believe where you'll want to start looking is at the bladerf_enable_module() function and downwards.

You'll see that it calls lms_enable_rffe(), which toggles the TXEN bit in the LMS6002D's register 0x40.

The dev->fn->enable_module() results in a vendor command being sent to the FX3 firmware here.

When the firmware on the FX3 handles this vendor request, it sets the GPIO_TX_EN output connected to the NIOS (which it sounds like you had already found), and also resets the USB endpoint (i.e, flushing out DMA buffers).

I suspect LMS register 0x40 might be what you're missing, but it might be worth reviewing the code paths here anyway.

By the way, this sounds like a nice setup you're putting together. Any chance you'll be able to write it up and share a demo of this at some point in the future?

[lsup91]

Thanks for your assistance, I really appreciate.

I haven't found what is missing to be able to control the transmission from the FPGA. I check the signals coming from the NIOS and it doesn't seems to come from here. I mean I saw some signals (lms_sdio and lms_sen) that are asserted deasserted (as shown on joint pictures). And if I refer to the link you provide [the LMS6002D (programming manual)] we can see that there is a read operation that occurs on the serial port interface but nothing that configure the LMS through a writing operation.

I haven't time to look forward on that issue and I will use the transmission (with repeat=0) of a nul file so that the LMS will be configure even if it's not perfect it offer us the ability to show our proof of concept.

For your last question, unfortunately, I don't have the authorization to talk about what we are developing, sorry for that.

Best regards.

[Helper]

Hi,

Did you get any success in this? I am stuck in a similar situation. Controlling bladerf with windows, in the source code, I found lms6002d.vhd in which spi signals were controlled by the nios processor. I inserted my own spi signals in there along with reset and clock, and tried programming tx RF registers of LMS. This did not work though and bladerf did not transmit anything.

Please let me know if you are able to use vhdl to control bladerf. Apart from glowing leds, I am unable to do anything so far.


Thanks,
Helper

[lsup91]

Hi Helper,

I have to move on an other project so I haven't time to investigate deeper this issue. I haven't found a possibility to control lms in transmission using vhdl control.

I stay on using the "start tx" command with sending a file with no data and repeat it infinitely.

Regards.

[jynik]

Any chance you could dump the contents of the LMS register set from your modifications?

Note that when controlling the device from the host-side, you can dump the register contents from bladeRF-cli via:

Code: Select all

bladeRF> peek lms 0x00 0x7f

Just thinking that you might find a missing register access by comparing the relevant registers...

[Helper]

Hi jynik,

So I did program the device from C and -cli and got rx samples. But I wanted to ensure that I don't lose any samples (continuous recording). Moreover, I am using these samples for further processing so I won't be able to command -cli to keep getting samples since then I won't be able to access them real-time. I tried multithreading with C to simultaneously command to fetch the values and process them parallely but that did not work. Hence I decided to move to fpga.