Official bladeRF forum

Hi,

I'm using bladeRF A4 with Open Air Interface and the application stops due to this error: "Requested timestamp is in the past" my guess is that the problem is not in OAI but somewhere in bladeRF. It seems like probably the FPGA crashes and resets which causes the internal timers to reset also. I tested the OAI in both machines running the same version of OAI. One of the machines is a Intel i5-4460 and the other one is an HP Proliant ML350 with two Intel Xeon E5-2620 for a total of 24 threads. Surprisingly the problem only happens with the higher spec machine and not on the lower one. It also seems that the USB is reset every time the program crashes and outputs this on Linux log:

"reset SuperSpeed USB device number 2 using xhci_hcd"

Things that I tried and doesn't have any effect:
- Different Linux versions, tested Ubuntu 16.04, 20.04 and 22.04
- Different versions of the FPGA firmware, tested v0.11, v.010, v0.12
- Using external power supply to power BladeRF

bladeRF-cli version: 1.8.0-git-0ffb795c
libbladeRF version: 2.4.1-git-0ffb795c

Firmware version: 2.4.0-git-a3d5c55f
FPGA version: 0.14.0 (configured from SPI flash)

Any ideas as to what might be causing these? or any way I could debug this further?
Please let me know if I should attach some output log.

I'll appreciate any comments.

If OAI is running well on one of the systems, and not the other with the same exact software version, I think this might be related to some power management issue. Can you please confirm the setting of the scaling governors are set to performance?
Please also take a look at this link: https://askubuntu.com/questions/1021748 ... e-in-18-04

Ensure that the timestamps being used by the software and the BladeRF are synchronized. Timestamps are crucial for proper sample alignment and signal processing. Watermelon Game

Although unlikely, the problem could originate from a hardware malfunction within BladeRF itselffnaf. This could be a problem with the internal clock source, memory, or processor, all of which can lead to timestamp inconsistencies.

By default The performance CPU frequency scaling governor will be employed at boot thanks to the configurations of the Ubuntu kernel. The appropriate segment within the kernel configuration file. The CPU frequency of modern processors is scalable, even in performance mode and depending on how deep an idle state they enter.

Since you mentioned that the USB is reset every time the program crashesstrands, it's worth investigating if there are any issues with the USB port or cable.