pothosware / SoapyPlutoSDR

Soapy SDR plugin for PlutoSDR
https://github.com/pothosware/SoapyPlutoSDR/wiki
GNU Lesser General Public License v2.1
58 stars 22 forks source link

Plutosdr Transmits only once #63

Closed Mas313 closed 4 months ago

Mas313 commented 4 months ago

Hi All, I have been trying to send IQ samples, stored in a buffer, multiple times through Plutosdr but the SDR transmits only once, for sending multiple times the executable file needs to be re run. But then again the plutoSDR transmits only once.

My environment is UBUNTU and installed SoapyPlutoSDR with all dependies succesfully, i.e. libiio-v0 (new version cannot be installed, gives error) , libad9361 & SoapySDR and using SoapySDR C API.

I have verified very first transmission by looking into spectrum using SDRsharp on another PC. Strangely, the SoapySDRDevice_writeStream() returns correct number of bytes every time it is called but transmission is done by SDR only once.

if (txStream == NULL)
        {
            printf("setupStream fail: %s\n", SoapySDRDevice_lastError());
            SoapySDRDevice_unmake(sdr);
            return EXIT_FAILURE;
        }
    printf(" After: SoapySDRDevice_setupStream \n");  
    else
    SoapySDRDevice_activateStream(sdr, txStream, 0, 0, 0); //start streaming

After every transmission i also wait for key-press to continue to avoid any timing issue of PlutoSDR, if any , for transmission but no luck. I am setting gain of PLutosdr manually

if ( SoapySDRDevice_setGain(sdr, SOAPY_SDR_TX, 0, 25.0)==0 )
    {   
        printf("-----------------------Manual Gain SET \n"); 
    }
    else
    {
        printf("Gain Set Error\n");
        exit(0); 
    }

Initially, i though that might be somehow the Tx gain is reset to 0 after very first causing transmission with 0 power since writeStream function returns number of bytes sent and not 0, so i called SoapySDRDevice_setGain() after every transmission but no luck. But again its strange that when executeable is re-run than plutosdr transmits but for very first time only. I transmit by filling buf array with IQ samples in a loop

    void *buffs[] = {buf}; //array of buffers
    int flags=0; //flags set by receive operation
    long long timeNs=1000000; //timestamp for tx buffer
    ret= SoapySDRDevice_writeStream(sdr, txStream, &buffs[0], j, &flags, &timeNs, 100000); //100000 

Any solution please.

zuckschwerdt commented 4 months ago

I've just tested and confirmed that this case (continue transmission after some pause) works well, with or without SoapySDRDevice_activateStream()+SoapySDRDevice_deactivateStream(). (using slightly hacked soapy_transmit() in https://github.com/triq-org/tx_tools)

Could there be something amiss in your code?

zuckschwerdt commented 4 months ago

The tx_tools is it's own application with abstractions on backends, you don't need to use any of that. There is no need to insert any pause, I just tried to emulated your waiting on a keypress.

I'll try you code soon, only thing I noticed is that complex float buf[8192] and uint8_t data[8192] are not the same size (8192 samples vs 4096 samples), but that should not matter much with the data loop you have.

zuckschwerdt commented 4 months ago

What you see is not the first data transmission but noise from the setup. Your data transmissions are all "invisible". You need to properly convert your samples to CF32 (or some other format). Also if your samples are not close to 0 dB you might want to increase the gain. Also it should be int ret = SoapySDRDevice_writeStream(sdr, txStream, buffs, j, &flags, timeNs, 100000);, note the buffs and the timeNs

zuckschwerdt commented 4 months ago

Yes, CF32 support in ty_tools is not complete. But CS16 is the native format for the Pluto and for high sample rates (>6M IIRC) CU8 might be better. Your code does work now, right?

Mas313 commented 4 months ago

Yes. IT works now, Thanks alot. Can you tell about min delay between transmissions if any one has measured before or as per your expereince.

zuckschwerdt commented 4 months ago

You should be able to send continuously, I don't know of any needed delay.