Official bladeRF forum

Hello Fellow BladeRF Enthusiasts!

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!

I saw this too when I was on USB2. USB3 was fine.

Hmm... that figures. I'm on travel using this on my MBP which only has USB2.

I'll try it on the USB3 machine later to see if that clears it up.

Thanks!

That really begs the question on why it requires the BW necessary for USB3 when I am using one AFCRN carrier with this basic setup.

Thoughts?

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.

Brian

Ah, yes that makes sense.

I'd love to see an updated FPGA that support USB2. Looks like I'll be working on USB3 for the time being.

Thanks!!