Official bladeRF forum

Hi,
I want to transfer data between two bladeRF boards, I have tried using GNURadio to do this. The receiver received the data sent but lost the first part of the packet. For example, when sending: 1 2 3 4 5 6, only receive 4 5 6. Is there a way to solve this problem?
Since I want to make modulation and demodulation using FPGA instead of using software (GNURadio), I have modified the fifo_reader and fifo_writer blocks on the bladeRF-hosted.vhd file. Then I built and loaded 2 boards, I plan to use bladeRF-cli, but I don't know how the receiver can capture the transmitted data. Can bladerf-cli do this?
The last question, I want to use loopback mode in LMS6002D chip to test the design, but I don't know how to observe the data after loopback.
I am new to using bladeRF, so there are many questions, please help me!
Thank you very much.

Best regards,
Hai

Do you have a delay between starting the receiving radio and starting the transmitting radio?

To answer your other question, yes, you can do this with the bladeRF-cli. A rough guideline is:

• Set RX & TX freqs/bandwidth/samplerates/gains
• cal lms; cal dc rx; cal dc tx
• rx config <params> (type "help rx" for parameter options)
• tx config <params> (type "help tx" for parameter options)
• rx start
• tx start

For LMS loopback options, you would follow the same procedure as above, but use the "set loopback" command before running the rx/tx start and choose the mode you want. The received data will be in the file you specified in the "rx config" parameters. If you choose to run in loopback, we advise using the smallest amount of gain possible to avoid saturation issues.

Note that there is also the "rx_mux" parameter that controls the routing of RX samples within the FPGA only. Type "help set" and look for the "rx_mux" parameter for the list of options.

Thank you for your support.
Yes, how to eliminate the delay between starting the receiving radio and starting the transmitting radio when communicating between 2 bladeRF boards, include loopback options.
For LMS loopback options, I did the following steps:


sample_t:
sample_r:

The data received is different from transmitted data. I think it caused by above delay?

Best regards,
Hai

Here are some things you can try:

• Issue the start commands on the same line, separated by a semicolon: "start rx; start tx". You'll still see a delay with this method, but it'll be much less than typing each command on a separate line.
• Use timestamps to tell the receiver and transmitter to start at exactly the same time in the future. This also works with multiple boards as long as all boards use the same common 38.4 MHz reference. If you don't have a reference, you can use one bladeRF as the source so it outputs its own 38.4 MHz out of its SMB port, while the other boards accept this signal as an input on their SMB ports (the SMB port direction is configurable).

Pls go easy on me and a new to SDRs


challenge I've encountered while conducting an experiment involving two Nuand BladeRF 2.0 micro xa4 software-defined radios (SDRs).

Experiment Overview:

I aim to establish a communication setup where one BladeRF serves as a transmitter and the other as a receiver. The objective is to transmit a simple message in ASCII text format which we would convert to binary and send and convert back to ASCII, and successfully receive and interpret it.

Progress So Far:

I've successfully set up both BladeRF devices on separate computers – one for transmitting and the other for receiving.

During a test run, I created a binary file using a Python script and utilized the following commands for transmission:
On the transmitter:
```bladeRF> tx config file=samples.bin format=bin```
```bladeRF> tx start```
```bladeRF> tx```
On the receiver:
```bladeRF> rx config file=samples.bin format=bin n=10```
```bladeRF> rx start```
```bladeRF> rx```

I've ensured that the sample rate, frequency, and power levels are appropriately configured on both the transmitter and receiver.

Issue Encountered:

Despite believing that the message was transmitted successfully, upon attempting to open the file on the receiving laptop, the received binary did not resemble what was sent.

I would greatly appreciate any assistance someone can offer in resolving this issue.