search

unixpunk / PlutoWeb

PlutoWeb
73 stars 19 forks source link

SoapySDR crashes the device #56

Closed jhart99 closed 5 years ago

jhart99 commented 5 years ago

I've been trying to run SoapySDR on the device with the latest 2.9.3 release. While I can use SoapySDRUtil to find and probe the AD9361, when I try to do a streaming test, it causes the whole device to crash.

Steps to reproduce:

  1. SSH into device
  2. SoapySDRUtil --args "driver=plutosdr,uri=local:" --rate=1000000 --channels=1 --direction=RX
unixpunk commented 5 years ago

Are you using the SoapyRemote option instead of openwebrx in the config.txt file so SoapyRemote starts at boot instead of openwebrx?

jhart99 commented 5 years ago

Just to be clear, I didn't alter anything with the device config.txt. I was just trying to figure out how high of a transfer rate was possible between the AD9361 and the the ARM processor. I was doing this by plugging in the device and then SSHing into it at 192.168.2.1 and running SoapySDRUtil. The find and probe commands were working fine, but turning on the receiver using the --args command would lead to some sort of crash and unsafe disconnect error from the host system. I tried to capture it by looking at the console output, but it was too fast to catch.

Anyway its resolved and I will close this.

For anyone that might have this problem in the future, the problem is that when the receiver was started there was high current draw through the USB port which was causing my USB hub to disconnect the device.

This issue can be resolved by using the second USB port to power the device. Also there is no problem to transfer up to 10Msps from the AD9361 to the ARM core on the device. It should be possible to go higher, but I need to modify the SoapyPlutoSDR library to support higher rates.

unixpunk commented 5 years ago

I see, would you be able to share your use-case as well? Sure, you could get soapyplutosdr to allow more than 10Msps and sure the ARM can handle that but if you're going to do any sort of signal processing on the ARM itself, 10Msps is way too high for the ARM to do any sort of DSP on it...In my experience, at least. Its not so much the streaming of IQ into the ARM that is an issue, its anything beyond that you want to do with the signal that will use up all the on-board CPU.

jhart99 commented 5 years ago

What I wanted to do was get rx_tools rx_power running with a wider bandwidth on the Pluto itself. Would it be possible to do a simple I/Q -> FFT -> binning. It does work. I added 20, 30 and 40 Msps to SoapyPlutoSDR and found that they can stream to the ARM processor without any drops. I was then able to up the maximum bandwidth in rx_tools and recompile it. Even with 40MHz of bandwidth into 1500 bins it was only using about 0.2 CPU. The maximum I was able to get was about 1-2 kHz resolution over 40MHz. I was thinking you could make a wide bandwidth spectrum analyzer with this without too much hassle. I don't care about actually demodulating anything, just seeing a lower resolution FFT would be enough.

unixpunk commented 5 years ago

Ah I see. You're looking for a live spectrum, I assume? If you have any technical details you want to share on your testing, even without the code changes, I will consider adding them to the web interface. Been working on SNA/VNA with LamaBleu and he's come up with a working model, but its 2Msps at a time and takes about 60 seconds to scan 10Mhz, but I need to fix gnuplot for that to be useful. He's using a libiio port he made of limeSNA. (Can see discussions in other tickets on Issues page here)

In short, depending how much effort you want to put in here, I will add it to PlutoWeb if we have something workable, whether that's a live spectrum or not.