SoapyPlutoSDR module not working in TX mode with QUISK and SdrAngel

[satfan52]

Hello,

I am trying to use my plutosdr with QUISK and it only works in RX mode and not in TX mode. I strongly suspect the problem is not with QUISK or SoapySDR but the SoapyPlutoSDR module that seems deficient to me.

The first reason I believe this, is because other QUISK users have managed to tx with the limesdr using the SoapySDR interface of QUISK and the Soapylimesdr module. So if it works with limesdr it should work with the plutosdr. Also if I can RX with QUISK and soapyplutosdr then I don't see why I could not TX, something is very wrong

The second reason I believe this, is because when I test with Sdrangel using the SoapySdr interface (so not in direct iio mode) and the SoapyPlutoSdr module, I can't TX either, I can only RX just like with QUISK ! (whereas I can TX/RX without any issues with sdrangel and my redpitaya using soapysdr and the soapyredpitaya module).

Of course my plutosdr works perfectly well with iio-oscilloscope and sdrangel in direct mode as well as other iio capable applications like qspectrumanalyzer so I don't think my iio environment is at stake. All applications with direct iio interface are doing fine, but with soapy only the rx part works.

All my evidence seems to suggest some problems in TX mode with the soapyplutosdr module. Is there a way I can verify that this module works in TX mode in combination with soapysdr ? Maybe using another application, but which one ? Using Gnuradio ? What could I do to try to narrow down the problem ? Thanks for your help

[zuckschwerdt]

I use tx_tools to test. Works well enough. Also the simple API examples for TX (some 50 lines of C, IIRC) work too.

[satfan52]

Thanks I will try with tx_tools and post results here

[satfan52]

Can you clarify if this tx_tool has been tested working with the soapyplutosdr module or only with the soapylimesdr module ?. Important for me to know in case it does not work with the soapyplutosdr module. Many thanks

[zuckschwerdt]

I tested LimeSDR USB, LimeSDR Mini and ADALM-Pluto (both SoapyRemote and on the device itself). The txtool maninly concerns with creating I/Q signals. The actual TX is just some setup and a loop writing the samples. To get a minimal test you can call the `SoapySDRDevicesetup functions with fixed parameters fitting your case, then basically loop [SoapySDRDevice_writeStream`](https://github.com/triq-org/tx_tools/blob/master/src/tx_sdr.c#L439).

[satfan52]

Hello, I have compiled it and ran "tx_sdr -f 152000000 -l -1 "with the aim of producing a cw signal at 152Mhz It does indeed produces a signal of -25 dBm (see picture, this seems to me rather low power, I was expecting in the order of -10 dBm).

I amp not sure the what to do with the error in the console implies.

So does this test demonstrate that the module is working right ?

root@on7yi-ubuntu:/opt/build/tx_tools# tx_sdr -f 152000000 -l -1 Input form stdin. Unknown input format "", falling back to CU8. [ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.7/libPlutoSDRSupport.so) duplicate entry for plutosdr (/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libPlutoSDRSupport.so) Using device ADALM-PLUTO: ad9361-phy,model=ad9364 ad9361-phy,xo_correction=39999835 backend_version=0.18 (git tag: v0.18 ) fw_version=v0.31 hw_model=Analog Devices PlutoSDR Rev.B (Z7010-AD9364) hw_model_variant=1 hw_serial=104400b8399100140b0027004b28656d80 library_version=0.18 (git tag: 5674795) local,kernel=4.14.0-42540-g387d584 usb,idProduct=b673 usb,idVendor=0456 usb,libusb=1.0.21.11156 usb,product=PlutoSDR (ADALM-PLUTO) usb,release=2.0 usb,serial=104400b8399100140b0027004b28656d80 usb,vendor=Analog Devices Inc. Found 1 antenna(s): A Found 1 gain(s): PGA Found 1 frequencies: RF Found 1 frequency range(s): 70000000 - 6000000000 (step 0) Found 11 sample rate range(s): 65105 1000000 2000000 3000000 4000000 5000000 6000000 7000000 8000000 9000000 10000000 Found 11 bandwidth range(s): 200000 - 200000 (step 0) 1000000 - 1000000 (step 0) 2000000 - 2000000 (step 0) 3000000 - 3000000 (step 0) 4000000 - 4000000 (step 0) 5000000 - 5000000 (step 0) 6000000 - 6000000 (step 0) 7000000 - 7000000 (step 0) 8000000 - 8000000 (step 0) 9000000 - 9000000 (step 0) 10000000 - 10000000 (step 0) Found current bandwidth 18000000 Found 3 stream format(s): CS8 CS16 CF32 Found native stream format: CS16 (full scale: 32768.000000) [INFO] Using format CS16. Using input format: CU8 (output format CS16) Sampling at 2048000 S/s. SoapySDRDevice_hasHardwareTime: 0 SoapySDRDevice_getHardwareTime: 0 Tuned to 152000000 Hz. Writing samples in sync mode... Pipe end? 0 samples written

Library error 0, exiting...

[satfan52]

I got rid of one of the two copies of libPlutoSDRSupport.so so that error is gone.

But the error " Library error 0, exiting... " at the end stays..

The behavor is somehow erratic, after I issue the command; sometimes the signal shows up on the spectrum analyzer at -57dBm or -25 dBm or -65 dbm or sometimes it does not at all. I notice that there can be a "transient" signal up to -5 dBm right after I issue the command !! but it does not last! It is seems the amplitude of the signal is somehow related to the -g parameter (-g 70 gives -57 dBm). I can't restore a CW signal of -25 dBm that I had in my first test

How can I issue a command so a full scale CW signal appears and stays stable until I issue another command at another frequency?

root@on7yi-ubuntu:/opt/build/tx_tools# tx_sdr -f 142000000 -l -1 Input form stdin. Unknown input format "", falling back to CU8. Using device ADALM-PLUTO: ad9361-phy,model=ad9364 ad9361-phy,xo_correction=39999835 backend_version=0.18 (git tag: v0.18 ) fw_version=v0.31 hw_model=Analog Devices PlutoSDR Rev.B (Z7010-AD9364) hw_model_variant=1 hw_serial=104400b8399100140b0027004b28656d80 library_version=0.18 (git tag: 5674795) local,kernel=4.14.0-42540-g387d584 usb,idProduct=b673 usb,idVendor=0456 usb,libusb=1.0.21.11156 usb,product=PlutoSDR (ADALM-PLUTO) usb,release=2.0 usb,serial=104400b8399100140b0027004b28656d80 usb,vendor=Analog Devices Inc. Found 1 antenna(s): A Found 1 gain(s): PGA Found 1 frequencies: RF Found 1 frequency range(s): 70000000 - 6000000000 (step 0) Found 11 sample rate range(s): 65105 1000000 2000000 3000000 4000000 5000000 6000000 7000000 8000000 9000000 10000000 Found 11 bandwidth range(s): 200000 - 200000 (step 0) 1000000 - 1000000 (step 0) 2000000 - 2000000 (step 0) 3000000 - 3000000 (step 0) 4000000 - 4000000 (step 0) 5000000 - 5000000 (step 0) 6000000 - 6000000 (step 0) 7000000 - 7000000 (step 0) 8000000 - 8000000 (step 0) 9000000 - 9000000 (step 0) 10000000 - 10000000 (step 0) Found current bandwidth 18000000 Found 3 stream format(s): CS8 CS16 CF32 Found native stream format: CS16 (full scale: 32768.000000) [INFO] Using format CS16. Using input format: CU8 (output format CS16) Sampling at 2048000 S/s. SoapySDRDevice_hasHardwareTime: 0 SoapySDRDevice_getHardwareTime: 0 Tuned to 142000000 Hz. Writing samples in sync mode... Pipe end? 0 samples written

Library error 0, exiting...

[zuckschwerdt]

tx_sdr transmits sample files, you need to create a sample file first, then pass that. E.g. code_gen -r examples/fsk.txt -w sample.cu8 then add sample.cu8 to the tx_sdr command line. You can review the sample file with https://triq.org/iqs/

[satfan52]

ok, I was able to generate a test.cu8 file using the fsk.txt below.

[1 (0kHz 0 1ms) ]
[P 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 ] PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP

then I ran

../tx_sdr -f 150000000 ./test2.cu8 Using device ADALM-PLUTO: ad9361-phy,model=ad9364 ad9361-phy,xo_correction=39999835 backend_version=0.18 (git tag: v0.18 ) fw_version=v0.31 hw_model=Analog Devices PlutoSDR Rev.B (Z7010-AD9364) hw_model_variant=1 hw_serial=104400b8399100140b0027004b28656d80 library_version=0.18 (git tag: 5674795) local,kernel=4.14.0-42540-g387d584 usb,idProduct=b673 usb,idVendor=0456 usb,libusb=1.0.21.11156 usb,product=PlutoSDR (ADALM-PLUTO) usb,release=2.0 usb,serial=104400b8399100140b0027004b28656d80 usb,vendor=Analog Devices Inc. Found 1 antenna(s): A Found 1 gain(s): PGA Found 1 frequencies: RF Found 1 frequency range(s): 70000000 - 6000000000 (step 0) Found 11 sample rate range(s): 65105 1000000 2000000 3000000 4000000 5000000 6000000 7000000 8000000 9000000 10000000 Found 11 bandwidth range(s): 200000 - 200000 (step 0) 1000000 - 1000000 (step 0) 2000000 - 2000000 (step 0) 3000000 - 3000000 (step 0) 4000000 - 4000000 (step 0) 5000000 - 5000000 (step 0) 6000000 - 6000000 (step 0) 7000000 - 7000000 (step 0) 8000000 - 8000000 (step 0) 9000000 - 9000000 (step 0) 10000000 - 10000000 (step 0) Found current bandwidth 1000000 Found 3 stream format(s): CS8 CS16 CF32 Found native stream format: CS16 (full scale: 32768.000000) [INFO] Using format CS16. Using input format: CU8 (output format CS16) Sampling at 2048000 S/s. SoapySDRDevice_hasHardwareTime: 0 SoapySDRDevice_getHardwareTime: 0 Tuned to 150000000 Hz. Writing samples in sync mode... 49844592 samples written

Library error 0, exiting...

I think it kind of worked (see picture) though I am not really sure I understand what I was doing. I just don't understand why the power of the CW signal generated that way is only -33 dBm it should be much stronger between -10dbm and 0 dBm. Is there a way to boost it up ? Also, what is very strange is that after the file finished playing, the CW signals persists on the same frequency but it weaker at -65 dBm instead of -33 dBm.

[zuckschwerdt]

Did you try playing with the gain setting (-g), either as summary value or for the components?

Yes, I notice that too. There is some noise while the tuner sets up and a narrow carrier is always present, even after ending the tx.

If you don't have any data in the sample (a sequence of different symbols) then you can just increase the symbol length. Valid units are us, ms, and s. In my experience DC won't work well, better to offset the frequency. E.g. this should do:

[_ (50kHz 0 3s) ]
_

(and reduce the tx frequency by 50k, e.g. -f 149.05M)

[satfan52]

I tried -g 70 it does not help

I don't understand what you mean by "either as summary value or for the components", I don't see that option in tx_sdr ?

I tried to offset by +50k and then compensating on f by -50k but does not work for me, it just produces two CW signals the first one on 149950000 and the second one 150000000

[satfan52]

ok rebooting the pluto helps, I get a CW signal between -22 and -17 dBm which is much more reasonable (I get -7dBm when transmitting in direct iio mode with Sdrangel)

I guess the conclusion is that the soapyplutosdr module works in TX mode, my problem is some place else

[zuckschwerdt]

Ah, sorry, the Pluto only has one gain element "PGA". You can set individual gain elements with e.g. -g PGA=70. But that's not useful here.

You mentioned multiple SoapySDR installs. That's a common problem, headers and libs get mixed up for strange results. Make sure you only have one version installed, then recompile all modules like SoapyPlutoSDR and the apps using Soapy. Worth a try.

[satfan52]

Hi, thanks for all info.

-g PGA=89 gives best results with -13 dBm, that is not as good as -7dBm but it is good enough.

Normally I use only one version of SoapySDR, the one I compiled for use with sdrangel as per the linux wiki tutorial/The problem is that the libs are installed in a non standard directory, they are installed in /opt/install/SoapySDR/lib and other similar directories under /opt/install

tx_sdr does not find those libraries, so I have to install SoapySDR and librtlsdr using synaptic so they libraiiries gets installed some place tx_sdr likes it, such as /usr/local/lib for instance

How can I compile or run tx_tool so it uses the exact same SoapySDR and librtlsdr librairies as the ones used by sdrangel ?

[satfan52]

SoapySdr is compiled that way: cmake -DCMAKE_INSTALL_PREFIX=/opt/install/SoapySDR .. make -j4 install

librtlsdr this way: cmake -DCMAKE_INSTALL_PREFIX=/opt/install/SoapySDR -DRTLSDR_INCLUDE_DIR=/opt/install/librtlsdr/include -DRTLSDR_LIBRARY=/opt/install/librtlsdr/lib/librtlsdr.so -DSOAPY_SDR_INCLUDE_DIR=/opt/install/SoapySDR/include -DSOAPY_SDR_LIBRARY=/opt/install/SoapySDR/lib/libSoapySDR.so .. make -j4 install

SoapŷRemote that way cmake -DCMAKE_INSTALL_PREFIX=/opt/install/SoapySDR -DSOAPY_SDR_INCLUDE_DIR=/opt/install/SoapySDR/include -DSOAPY_SDR_LIBRARY=/opt/install/SoapySDR/lib/libSoapySDR.so .. make -j4 install

[zuckschwerdt]

In your case there should be /opt/install/SoapySDR/share/cmake/SoapySDR/SoapySDRConfig.cmake CMake uses that module to configure things. Use CMAKE_MODULE_PATH to point to the base dir. E.g. something like cmake -DCMAKE_MODULE_PATH=/opt/install/SoapySDR/share/cmake/SoapySDR... is perhaps needed. But the SOAPY_SDR_INCLUDE_DIR is also honored by that module. But you may need to use SOAPY_SDR_ROOT not SOAPY_SDR_LIBRARY. Not sure. In any case grep SOAPY_SDR_ build/CMakeCache.txt should reveal what happend: e.g.

CMakeCache.txt:SOAPY_SDR_INCLUDE_DIR:PATH=/opt/install/SoapySDR/include
CMakeCache.txt:SOAPY_SDR_LIBRARY:FILEPATH=/opt/install/SoapySDR/lib/libSoapySDR.so

[satfan52]

Thanks Christan, I am traveling, I will resume working on tbis after March 3rd

On Thu, 20 Feb 2020, 10:41 Christian W. Zuckschwerdt, < notifications@github.com> wrote:

In your case there should be /opt/install/SoapySDR/share/cmake/SoapySDR/SoapySDRConfig.cmake CMake uses that module to configure things. Use CMAKE_MODULE_PATH to point to the base dir. E.g. something like cmake -DCMAKE_MODULE_PATH=/opt/install/SoapySDR/share/cmake/SoapySDR... is perhaps needed. But the SOAPY_SDR_INCLUDE_DIR is also honored by that module. But you may need to use SOAPY_SDR_ROOT not SOAPY_SDR_LIBRARY. Not sure. In any case grep SOAPYSDR build/CMakeCache.txt should reveal what happend: e.g.

CMakeCache.txt:SOAPY_SDR_INCLUDE_DIR:PATH=/opt/install/SoapySDR/include CMakeCache.txt:SOAPY_SDR_LIBRARY:FILEPATH=/opt/install/SoapySDR/lib/libSoapySDR.so

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/pothosware/SoapyPlutoSDR/issues/32?email_source=notifications&email_token=ADR72WKGLETXZU6SPYDTS2LRDZF6BA5CNFSM4KW7C4V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMMUFZI#issuecomment-588858085, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR72WNZXPERTADXRUUVAQTRDZF6BANCNFSM4KW7C4VQ .

[guruofquality]

Generally, if a client project is configured with the same CMAKE_INSTALL_PREFIX, you do not need to specify any additional arguments for it to find the project config sources. When the prefixes are different, its possible to tell it where to look using -D<proj>_DIR, so in this case -DSoapySDR_DIR=/opt/install/SoapySDR/share/cmake/SoapySDR I believe

• reference https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#config-file-packages

[zuckschwerdt]

@satfan52 in tests with other software it looks like the powerdown state could be set on the TX. Can you test the branch fix-power? That should reliably enable TX.

[satfan52]

Thanks Christian, will test this after 3 March and report results here

On Fri, 21 Feb 2020, 11:55 Christian W. Zuckschwerdt, < notifications@github.com> wrote:

@satfan52 https://github.com/satfan52 in tests with other software it looks like the powerdown state could be set on the TX. Can you test the branch fix-power https://github.com/pothosware/SoapyPlutoSDR/tree/fix-power? That should reliably enable TX.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pothosware/SoapyPlutoSDR/issues/32?email_source=notifications&email_token=ADR72WOF4SM3U4WKCYZTIXTREABQ7A5CNFSM4KW7C4V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMTLQFI#issuecomment-589740053, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR72WP56SN64FBKCYA57MDREABQ7ANCNFSM4KW7C4VQ .

[satfan52]

I am reopening the isssue as I am convinced that something is wrong with this module in TX mode as neither QUISK nor sdrangel manage to transmit correctly with the plustosdrmodule. see https://github.com/f4exb/sdrangel/issues/478 and https://groups.io/g/n2adr-sdr/topic/plutosdr_tx_support_via/71401835?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,71401835

[zuckschwerdt]

Please update (pull) the latest changes in tx_tools, rebuild and test with both native Pluto backend (-d "pluto:") and SoapySDR (-d "driver=plutosdr") backend. Both work for me.

[zuckschwerdt]

Also, did you test fix-power branch here? Does it change anything? Note that you do need to set the gain. Preferably don't transmit a DC signal, try maybe a 50k carrier.

[satfan52]

Also, did you test fix-power branch here? Does it change anything? Note that you do need to set the gain. Preferably don't transmit a DC signal, try maybe a 50k carrier.

not yet, will be done in the comming days

[satfan52]

Please update (pull) the latest changes in tx_tools, rebuild and test with both native Pluto backend (-d "pluto:") and SoapySDR (-d "driver=plutosdr") backend. Both work for me.

will do in the coming days

[zuckschwerdt]

What exactly are you seeing in SDRangel? I did some tests, there might be problems with my setup but the observation so far: Lime, Lime over Soapy, and IIO work for TX. But Pluto over Soapy (Add sink, pick device, start, add NFM, toggle tone) does not output anything. The TX loop is running but the calls transmit empty buffers (size=0). Different than the other devices I do not see a DC line in the waterfall and also no tone. That matches the observation that the buffers are emtpy, no data is produced?

[zuckschwerdt]

Fixed the bug with bbd16b0. Somehow this regression went in when we overhauled the threading a year ago. Also the stream muting is fixed with 2cf04f6. Thanks for sticking with this and all the testing!

[satfan52]

Hi Christian, Many thanks. I just came back from a (tiring) business trip. I will retest everything this week, probably tomorrow already.

On Tue, 3 Mar 2020, 00:44 Christian W. Zuckschwerdt, < notifications@github.com> wrote:

Fixed the bug with bbd16b0 https://github.com/pothosware/SoapyPlutoSDR/commit/bbd16b0b17ce16fc2d0553914b763818f25dfc03. Somehow this regression went in when we overhauled the threading a year ago. Also the stream muting is fixed with 2cf04f6 https://github.com/pothosware/SoapyPlutoSDR/commit/2cf04f64e2458dd824ebfded757897a5aab4584b . Thanks for sticking with this and all the testing!

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/pothosware/SoapyPlutoSDR/issues/32?email_source=notifications&email_token=ADR72WJ5UPGMJM2GR4VN5KLRFRAEPA5CNFSM4KW7C4V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENRNU5I#issuecomment-593681013, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADR72WLDZO4ZGRKZL7X6SATRFRAEPANCNFSM4KW7C4VQ .

[satfan52]

Confirmed working with sdrangel, many thanks Not yet working yet with QUISK but I suspect it is more of a configuration issue

[satfan52]

Ok, with sdrangel I can "stably" TX/RX with the following settings RX sampling = RX bandwidth = TX sampling = TX bandwidth = 1000 Khz The rf output signal in SSB is of good quality

However with QUISK the same settings do not work at all. The rf-output SSB signal is completely distorted and audio appears "slowed". Even a simple CW signal is not clean (some very low frequency modulation). Actually even in reception mode, the audio reception is "hashed" when TX is activated with a sampling rate of 1000 Khz as if there was some kind of resource bottleneck. In the console of QUISK there is a warning message asking to set a FIR rate… Reducing the TX sampling rate to 96 Khz instead of 1000 Khz results in no changes.

If I set the TX sampling rate to a more modest value of 48 khz or 50 Khz, the audio in reception is no longer "hashed" but QUISK states that these two TX sampling rates are not supported !!! With 48 Khz there is just no rf-output and with 50 khz, there is an rf-output but it is distorded.

My question is simple: What would be the ultra minimal optimal settings to apply for TX & RX sampling rate and bandwidth for the lowest possible ressource constraints. Something that MUST work and that I can use as a reference for QUISK testing purpose and that developper of QUISK can use for debugging purpose ?

[zuckschwerdt]

2084k (not a typo) is the lowest sensible sample rate.

[satfan52]

2084k (not a typo) is the lowest sensible sample rate.

OK so I should use TX sampling rate = RX sampling rate = 2084k and TX bandwidth = Rx bandwidth = ? Is the bandwidth supposed to be > or < to the sampling rate ? I'd say a little less but not sure

[zuckschwerdt]

I mostly use 2.5M or 3M sample rate with bandwidth depending on the signal, but yes somewhat lower.