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