Official bladeRF forum

Hi,
I am using code that do following:
1. Open and Init BladeRF device
2. Enable BladeRF (RX + TX Module)
3. Stream Init
4. Stream ( RX callback copies the samples from p_samples into my output array)
5. Deinit Streams
5. Plot Data
6. Wait till user click the button and go back to Point 3

If I plot the RX data, the first ca. 9720 Samples is filled with the old data. I can understand, that the first buffer is filled with old data, but my stream_buffer_size is 8192. If I change the Sampling Frequency, the number of "weard" samples remains the same. Does someone else have this issue?

Indeed this is a known phenomenon of the hardware. The FPGA isn't holding the samples as we make sure to clear those FIFO's when the RX is disabled, and I thought the DMA area in the FX3 was cleared - but it might be that those values are not quite cleared?

What version of the FX3 firmware are you running? You can get this information using the 'ver' and 'info' command in the CLI.

The obvious user remedy to this would be to ignore the first N samples. Are the number of stale samples a multiple of 512? Are you on USB2?

If you add a "Disable BladeRF (RX + TX Module)" in your code after Deinit Streams and jump back to step 2 instead of step 3, do the stale samples still show up?

Brian

Hi Brian,
The number of old samples is exactly 9728, it's 19x512. The device is connected to the USB2 using libusb. Ubuntu 12.04. I tried to disable and enable the modules as you suggested, but it didn't solved the problem. Sometimes, the old data are only 5632 samples long, followed with the data with accurate frequency but with phase jump at 9728 samples. If I unplug the device, the fist 9728 samples is a signal of the correct frequency, but the phase jump at 9728 happens anyway. If it helps, I can attach the log from the bladerf library.

my bladerf version is :
bladeRF-cli version: 0.10.8-git-28b8ca5-dirty
libbladeRF version: 0.15.0-git-28b8ca5-dirty
Firmware version: 1.6.1-git-b7e6642
FPGA version: 0.0.3

I think I can just draft the first 9728 samples in the RX signal if I know about the issue. Do you know, if the TX path has the same behaviour ?

Thanks

I don't believe the TX has the same issue, but I am not sure. I suppose it would be good to use SignalTap and capture what is happening.

I am really sorry the first 19*512 samples are bad. If you don't mind, could you put that up on the issues page on github?

Brian

Hi,

thank you, I will report the but using the github that everyone knows about this behaviour.