[Simulink] TRX buffer-overflow and firmware loopback error

Having issues with the site, hardware, source code, or any other issues?
Post Reply
fumiko
Posts: 6
Joined: Sun Mar 22, 2015 11:15 pm

[Simulink] TRX buffer-overflow and firmware loopback error

Post by fumiko »

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,
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: [Simulink] TRX buffer-overflow and firmware loopback err

Post by jynik »

(1) In general, we've found hooking up a display directly to the output of a device will result will almost always result in lost samples -- the display rate is always vastly less than the sample rate of the device and it will try to display every sample; it simply won't consume data as fast as the bladeRF is producing it. For all intents and purposes, the bladeRF's lowest sample rate is 1.5 MSPS, unless you are using an external LPF.

If you want to display and plot live samples, you'll probably have to perform quite a bit of decimation or add some form of buffer in front of the display, such that samples are still being read from the bladeRF while the display is slowly plotting every single sample.

With respect to the number of samples to RX -- you'll want to make these much larger, on the order of one or more buffers worth (the size of the buffer used to configured the sync stream that are multiples of 1024). Having Simulink only read a few samples out of the buffer per step will inevitably cause overruns; you'll want to consume a much larger value, e.g., 16384.

I would advise you to try performing tests without the display blocks in the graphs and see if you still have the same issue. Could you perhaps instead save samples to a file using a sample rate of 1.5 or 2 MSPS, and then plotting these offline? (We generally advise using a fast SSD when streaming samples to disk.)

(2) Could you enable verbose logging and share the output?

I would advise against using firmware loopback, and instead would recommend one of the baseband loopback modes. Try BB_TXVGA1_RXLPF (you'll need to increase your RXVGA gains). The firmware loopback is really designed more for some USB testing, rather than waveform development.
fumiko
Posts: 6
Joined: Sun Mar 22, 2015 11:15 pm

Re: [Simulink] TRX buffer-overflow and firmware loopback err

Post by fumiko »

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.
streambuffer_and_samples_threshold.png
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.
another_lost_samples_occurred.png
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.
loopbackoptions.png
The other options worked with my computer and very convenient for testing.


Regards,
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: [Simulink] TRX buffer-overflow and firmware loopback err

Post by jynik »

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

(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.)

(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?

(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.
fumiko
Posts: 6
Joined: Sun Mar 22, 2015 11:15 pm

Re: [Simulink] TRX buffer-overflow and firmware loopback err

Post by fumiko »

(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.
receiving_better.png
It might be to gather samples at the TX buffer is critical path.
These are parameters at the time.
transmitting.png

(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.
receiving_question.png
First, the case of left circle may be DAC hold value. This is the same at the middle of
receiving_better.png
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,
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: [Simulink] TRX buffer-overflow and firmware loopback err

Post by jynik »

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?
I'm sorry, I don't know of any way to do this, aside from modifying the HDL to add a mux that switches over from the sample FIFO to a 0+0j constant when an underrun occurs.
Second, the case of right circle is another loss situation. If you have see this case before, please tell me anything.
Unfortunately, I'm not sure of what else can be done if Simulink can't run fast enough to supply samples to the device. Could you enable the use of more TX buffers, with the hope that you'd essentially prefill enough time to compensate for the lags Simulink introduces? (e.g., increase number of buffers to 64, 128, or even 256). Is it possible to play with things like scheduling priority of the Simulink process? In Linux with GNU Radio, I've found that I sometimes have to disable CPU Frequency scaling to keep my processor running at its full rate -- is this possible in Windows?

I too have found Simulink's performance to be vastly unimpressive, compared to a data-flow oriented framework such as GNU Radio, which can easily maintain the full sample rate of the bladeRF (and other SDRs providing even higher sample rates). (However, I recognize that the designers of the tool may not have had this type of use-case in mind, given that it was designed for simulation.)
yoshimifuj
Posts: 15
Joined: Wed May 07, 2014 8:59 pm

Re: [Simulink] TRX buffer-overflow and firmware loopback err

Post by yoshimifuj »

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.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: [Simulink] TRX buffer-overflow and firmware loopback err

Post by jynik »

1. You are correct, when bladerf_enable_module() is called on the TX module, the LMS6002D DAC should be held at 0+0j. (Of course, you may have some LO leakage due to DC offset, which you can try calibrate out).

3. One idea here might be to transmit a few 0+0j samples to force the DAC to hold at 0+0j. If you wanted to modify the HDL to do this when the underrun status bit is set, that may work as well.

Buffer underrun: This occurs when the the the FPGA has not received samples from the host. Typically, you want to keep "Num transfers" of buffers in-flight to the FPGA from the host at all times. "Num buffers" is how many buffers libbladeRF will queue up for you. Thus, "Num Transfers" x "Num Samples Per Buffer" x " Sample Rate" establishes how much time you have before you starve the TX-side, assuming you've got "Num Transfers" worth of buffers already in-flight.

Given the situation you described, I'm almost beginning to think that you might want to port some of your Simulink models to C directly atop of libbladeRF, and then expose that as a higher-level block to Simulink.... just one idea.
Post Reply