Official bladeRF forum

Hi, I tried to transmit and receive signal with Simulink and met the following cases.

1. After transmitting and receiving with the lowest sampling rate,
I found missing IQ samples in receiving window. I attach an image[simple_trx.png] and Simulink program[simple_loopbacktest.slx.txt].
In this upper image, Number of samples to RX during each simulation step is 8 and very slow.
In this lower image, Number of samples to RX.. is 16 and over. Missing occurred in this lower case.

In my PC, Number of each missing IQ sample is always 8.
Why this missing occurred ?
I would to try more higher sampling rate with Simulink, and what kind of value set?


2. I can not use firmware loopback function with Simulink.
This error message displayed

'C:\Program Files\bladeRF.2016.05.rc2a2\matlab\bladeRF.m' at line 111
'C:\Program Files\bladeRF.2016.05.rc2a2\matlab\bladeRF_XCVR.m' at line 454
'C:\Program Files\bladeRF.2016.05.rc2a2\matlab\bladeRF_Simulink.m' at line 395'

libbladeRF error (-1) in bladerf_enable_module(): An unexpected error occurred

Please tell me if there is anything I can do.

Regards,

Thank you for your advice.

(1)
I understood difference of consuming rate for bladeRF and block.
Firstly, testing without display and saving sample to file does not work for avoiding previous problem.
(But I did not test with SSD.)

After another testing, I recognize the "Size of each stream buffer, in samples"
related to max threshold of "Number of samples to RX during each simulation step".
With these follow parameters, it does not lose samples such as previous.
Size of each stream buffer, in samples: 16384
Number of samples to RX during each simulation step: 128
Max threshold of Number of samples... is 128, and with over 128 the previous problem occurred.


Second, I found another lost samples. There is receiving data at the upper-right window, but it is not the same of transmitting and step-wise signals.
Correct samples received intermittently. I think this is because of tx buffer-underun or rx buffer-overflow, but I can not optimize parameters.


(2)
Could you enable verbose logging and share the output?
I changed libbladeRF verbosity to the verbose logging at Miscellaneous Tab,
but I can not find outputs at Matlab command window.
Please tell me verbose setting with Simulink.

And I want to try with BB_TXVGA1_RXLPF, but there is no BB_TXVGA1_RXLPF option at Device Tab. The other options worked with my computer and very convenient for testing.


Regards,

(1) You are correct -- there is a very important relationship between the size of buffers (S), the number of buffers (N), and the number of samples (S2) consumed/produced in each step.

libbladeRF internally maintains N buffers of S samples. At your sample rate, you can calculate how much time this leaves you until they free up, and how fast you have to consume/produce samples to avoid under/overflow.

Thank you for your advice. I undertood libbladeRF sends number of samples after one buffer queue completed.
In these follow case, libbladeRF sends 16384 samples to bladeRF after 16384 samples completed at the tx buffer for 1024 x 16 steps.
-------------------------------------------
Sampling rate : 1.5MHz
Number of stream buffers to use: 32
Number of USB transfers to use: 16
Size of each stream buffer .. : 16384
Stream timeout: 5000
Number of samples to TX .. : 1024
-------------------------------------------

(1a) Could you try to narrow down whether this a TX or RX problem?

If you have a second bladeRF, I would recommend TX'ing from Simulink to the second device RX'ing with the bladeRF-cli.

Do you see LEDs on the board dim or turn off while running? (These are underrun/overrun indicators -- you could place an oscilloscope probe on them if the LED flickering is too quick to see.)

I use two bladeRF and oscilloscope to probe signal, but the LED did not blink.
Because the situation does not change with bladeRF-cli, I changed the TX parameters as your advice.
And then, after I changed "the Number of samples to TX" to the sample value of "Size of each stream buffer...",
The current situation is better than the previous one. It might be to gather samples at the TX buffer is critical path.
These are parameters at the time.

(1b) My guess is that you're experiencing TX underrun, because the DAC will hold the last sample value until new samples are provided. Your zoomed in picture is very good evidence of this, I think -- the sinusoid is discontinuous with a value held in between the discontinuities. Can you try TX'ing at least a full buffer's worth of samples per simulation step?

Tx's parameter worked for transmitting better. By the way, I want to ask these follow cases. First, the case of left circle may be DAC hold value. This is the same at the middle of In Simulink, I don't know to manage signal stop and go.
So, I want to stop signal or change signal to zero from the last sample value at buffer under-run.
Do you think what is the better way?

Second, the case of right circle is another loss situation. If you have see this case before, please tell me anything.

(2) libbladeRF log output is written to stderr. It looks like you're using Windows, and I'm not sure where it writes stderr in this case. Perhaps could you try launching MATLAB from cmd.exe to see if stderr output is written to that console?

You are correct -- it looks like BB_TXVGA1_RXLPF is missing from the list in the Simulink block. I see that this is indeed the base MATLAB implementation. I have opened Issue #478 for this.

Thank you for your making ticket. I tried to launch MATLAB from cmd.exe, but I can't see any message.
Continuously, I will try to find how to show messages.

Regards,

I guess bladeRF Tx with a Simulink model works like follows.

1.Buffer is not filled
[Simlink model(Sim mdl)] Simulink model starts calculation to fill the buffer.
[libbladeRF(bladeRF)] Waiting for the Tx buffer be filled.

2.Buffer is filled
[Sim mdl] Stop calculation of the next PHY frame if there is no input bitstream in FIFO.
[bladeRF] Start TXing I-Q samples in the buffer.

3.Buffer is empty again
[Sim mdl] Still waiting for the input bitstream
[bladeRF] Stop TXing I-Q samples when it exhausted the I-Q samples in the buffer.

This shows just one case and there should be some variations.
However, thinking of WiFi like radio systems, I assume that:

(1) At the stage 1, bladeRF shouldn't emit any RF power at all. Maybe just write 0+0j to DAC port and wait.
(2) When the Tx buffer become empty again at the stage 3, bladeRF should switch off RF power and stop emitting RX power until the next RF frame is filled in the buffer.

Buffer underrun is a different story.
If it happens when Simulink process occupy CPU and prevent TX process(?) from transfering I-Q samples in the buffer to bladeRF through USB, lowering Simulink process could be an effective way.
Other than that, buffer underrun must not be happened unless the TX buffer's parameters are inappropriate.
Even though Simulink is very slow and cannot provide I-Q samples in a specific duration, we can expand timeout parameter as long as we need to accept it.