I have been playing around with getting YateBTS to work and have ran into a snag.
Yate and YateBTS starts up successfully, runs for about 30seconds to a minute and I start to see LED1 begin to flicker like crazy and then I see:
CRIT 140245251057408 15:41:55.7 bladeRFDevice.cpp:857:checkHealth: Excessive I/O errors, bailing out
<transceiver:WARN> bladeRFDevice.cpp:857:checkHealth: Excessive I/O errors, bailing out
Received shutdown signal
Shutting down transceiver...
EMERG 140277564081920 15:41:55.7 OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 0. Exiting.
<mbts:GOON> OpenBTS.cpp:155:startTransceiver: Transceiver quit with status 0. Exiting.
YateBTS then reloads itself starts the transceiver back up and the process happens again. I'm not sure if its buffer underrun's or overrun's or what. Any troubleshooting steps would be greatly appreciated!
You both likely know vastly more than myself on the matter, but I just wanted to share something I saw on IRC the other day. Take it with a grain of salt.
When running either Yate or OpenBTS, someone was seeing the current draw of the unit reach ~ 510mA, which would be exceeding what's allowed for USB 2.0. It might be worth verifying whether this observation is consistent on your setups, and supplying external power to the bladeRF via the DC barrel jack when on USB 2.0. (This requires both jumpers on J71 to be moved - check the schematic for details.)
The bandwidth is not the issue at all. The extra power requirement from a USB3 superspeed port is nice for the headroom and the full duplex nature of the signals, especially for doing multi-ARFCN and wanting to maintain nice linearity in the TX PA.
The code in the FPGA needs to be changed to handle the USB2 versus USB3 DMA transfer sizes otherwise.
