search

pothosware / SoapyBladeRF

Soapy SDR plugin for the Blade RF
https://github.com/pothosware/SoapyBladeRF/wiki
23 stars 19 forks source link

More problems with 2 channel reception #46

Closed righthalfplane closed 2 years ago

righthalfplane commented 2 years ago

@guruofquality

I modified a simple SoapSDR example to read from two channels from my bladeRF 2.0 micro xA5.

https://github.com/righthalfplane/rfspace/blob/master/simpleReceive3.cpp

It reads successfully reads 254 samples and then gets a SOAPY_SDR_OVERFLOW (-4) error - over and over again

0ret=254, flags=4, timeNs=222220000614250 rec 4096 ret=-4, flags=4, timeNs=222220000741250 rec 3842 0ret=254, flags=4, timeNs=222220000741750 rec 3846 ret=-4, flags=4, timeNs=222220000868750 rec 3592 ....

Then it starts erroring in a different fashion -

[ERROR @ host/libraries/libbladeRF/src/streaming/sync.c:337] wait_for_buffer: Timed out waiting for buf_ready after 1000 ms ret=-1, flags=0, timeNs=0 rec 4096 [ERROR @ host/libraries/libbladeRF/src/backend/usb/libusb.c:1090] Transfer timed out for buffer 0x7fd8d7821800 ret=-1, flags=0, timeNs=0 rec 4097 ....

If I read one channel, every thing works OK.

if I read 254 samples, it goes with out errors for a short time and then it gets the "wait_for_buffer" error again.

righthalfplane commented 2 years ago

@guruofquality

I solved this problem and troubles with transmission, by going to a simple rx_sync and tx_sync model - there was some bugs in what you had done. I think I deleted 148 lines changed 2 lines and added one line. I seems to run just as fast as what you did on the BaldeRF xA5 and it works.

https://github.com/righthalfplane/SoapyBladeRF

guruofquality commented 2 years ago

Thanks for trying that. There is a lot of fluff in that code to support the burst API and BLADERF_FORMAT_SC16_Q11_META mode. I kind of think there is a bladerf drive issue with that mode (and or possibly something from the API being used a little wrong here).

Im not entirely sure what to do, BLADERF_FORMAT_SC16_Q11 mode clearly works, and is simpler, and better tested. But I dont want to remove all of that support either. I wonder if I can set the BLADERF_FORMAT_SC16_Q11/BLADERF_FORMAT_SC16_Q11_META conditionally in the stream setup and just goto/if out the code you deleted based on the mode. Since a lot of it can be bypassed in continuous streaming mode.

righthalfplane commented 2 years ago

@guruofquality

The code you had always fails when I try to do two streams of rx. If I send the tx data in large blocks, it fails often and will not recover with out a complete shut down and setup. If I send 4096 blocks, it occasionally fails on a full duplex single stream tx and rx and It does not recover. I think that the error handling is wrong - it seems to flag the error on the current and next pass. Without all of the fluff, it automatically recovers from the occasionally errors that come when I start the tx stream and so the errors are not really a problem. When I start a tx stream, it always errors for a few blocks on the rx stream - they are in different threads - it claims to be full duplex, but it does not act like it.

guruofquality commented 2 years ago

@righthalfplane I pull together a pull request for this https://github.com/pothosware/SoapyBladeRF/pull/47 . Basically I made the "meta" mode default to off for dual channel. I have no idea whats really wrong, but streaming is better than no streaming.

I agree all of the flags are basically fluff, but it looks like they don't do anything when not set. I hope that can work for you.