Nuand BladeRF x40/x115 Packet mode

[marjoriecarp]

Hello,
Has anyone successfully managed to send PDUs to and from the host computer to a BladeRF x40/x115? I have a few questions as I cannot get the FPGA to act on those packets. i.e. set LED2 high if the second byte is 0xFF for instance.

I know it is supported, and the libbladeRF does not return an error, but I must do something wrong on the FPGA side.

Any advice?

[socialespresso]

I would recommend checking the FPGA code to ensure that it is correctly configured to interpret the incoming packets and respond accordingly. You may want to verify that the FPGA is properly configured to check the second byte of the packet and set LED2 high if it matches the desired value of 0xFF. Double-checking the logic and debugging the FPGA code could help identify any potential issues.

[hayar]

RX and TX timestamps are driven from the same clock, so they should stay aligned if everything is configured correctly. Most issues people see usually come from setup or misunderstanding how the timestamp mode works rather than actual drift in the hardware.нулс бравл

[Echolinna]

If you use BLADERF_FORMAT_SC16_Q11_META, the first 32 bytes are a header. Your 2048"second byte" is likely still inside this header, not your actual payload.

[jasperwilde45]

One thing I would check is the metadata/header handling first. If you're using BLADERF_FORMAT_SC16_Q11_META, the data reaching the FPGA may not start where you expect, so checking byte 1 directly could be looking at the packet header rather than the payload.

It might help to send a very small, known test packet and monitor the FPGA input word-by-word. That would make it easier to confirm where the actual payload begins before adding the LED condition.