YateBTS

[boodrow]

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!

[djrevmoon]

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

[boodrow]

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!

[boodrow]

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?

[bpadalino]

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

[boodrow]

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!!