I’ve been reading your threads, but you’ve done a lot of other work. Let me ask this:
1.) Were you able to install SopaySDR from source, compile/install it, and perform a successful SoapySDRUtil --find with your LimeSDR?
2.) Were you able to install LimeSuite (except for the 3G video driver support that cannot be supported on RPi3)?
Let me know the answers to the above, because I have all Lime and Soapy resources installed…My LimeSDR cannot be ‘discovered’ using pihpsdr. So just trying to figure out if you had successful installs of LimeSuite and SoapySDR.
Okay - then it looks like you’re fully set for any apps that can be used with the LimeSDR when they arrive for the Pi3. Actually, pihpsdr has a dual receive capability that John Melton (G0ORX) is accommodating in the LimeSDR build he’s working on now. When it’s released, you should be able to tune from HF to SHF using those receivers on the Pi3. Keep your ear to the ground on that one…And that’s not to say that @csete may rebuild GQRX for the Pi3, too…But we’ll have to wait until Alex can make that happen.
I made a new package for RPI3 that includes the LimeSDR driver. Sadly, it is not working for me but fails when trying to set the bandwidth. Perhaps the LimeSDR needs more power than what the RPI3 can deliver, so I am making the package available for others to try:
Thanks Alex! I was able to get it to run via ssh -X from my Mac, starting it from the command line. The
window saying it was unhappy with the settings, do I want to edit them, popped up and I said Yes, then the
device IO settings window popped up and I was able to modify the BW from the default 0.0 to 5.0 MHz, left
the sample rate at 1.8 MHz, and the main window popped up, I chose the LNAL antenna, and now have a
waterfall of a portion of the USA commercial FM band. Linux top in another window says gqrx represents ~41%
of the CPU load; sshd, sending the pretty waterfall over to my Mac, is using 11%. When I turn the demodulator
back on (wideband stereo) the gqrx load goes up to ~275% but the water keeps pouring down.
BTW this was the second time I started it. The first time it crashed trying to set the bandwidth, just as you said
happened to you. I am not going to press my luck and try to start it up again tonight!
Don’t forget that on Raspberry Pi Ethernet is hung off the USB, so you’re sharing the bandwidth of a single USB 2.0 port between the LimeSDR and network. This sounds like a recipe for disaster, sadly
A little bit of everything. I think the biggest drawbacks of even the latest Raspberry Pi are:
USB bandwidth shared between USB and Ethernet.
Raspbian keeps binary compatibility with the first generation Raspberry Pis so that the software does not take proper advantage of the CPU features. So sure, you get 4 cores and more MHz but there are useful instructions that are not being taken advantage of.
The last point above is why I started with building my own compiler then build all critical gqrx dependencies from source. Eventually, this lead to gqrx running on the RPI2 and RPI3 whereas the gnuradio and gqrx packages distributed with Raspbian are quite useless.
All that said I’d like to point out that I think they did a really good job with the Rapsberry Pi 3 and Raspbian OS. It’s just that gqrx comes with a lot of bloat and difficult to distribute in a target specific binary form.
I think thats true with any software that is not built by the owners … Quisk is in the same boat.
In the repository of Ubuntu 16.04, Quisk version is 3.7.6 – about 2 years old i think …
Yes, sounds like a train wreck in the making, but I ultimately plan only to control the board remotely (not transport
gobs of data), and it looks as though SoapyRemote will work like a charm for this.
I used a twin lead for power about 7inch long from a 13.8V—>5V@3A switching power supply … it was 5 foot but i was getting crashes from the LimeSDR (i think all LED’s went red – not 100% sure i remember correctly) from low voltage at the LimeSDR.
@robertkb
Perhaps you can run SSH over Wifi instead, to liberate ETH bandwidth?
Also, IIRC you may benefit from installing watchdog and make sure to enable ARMv8.
To tell the RPi3B to start in ARMv8-mode you have to add a new line to config.txt :
arm_control=0x200
But perhaps this is already done in later rpi firmwares… It was a good 6 months ago I last looked at this.
yes it is a problem I have on a different application (SDRdaemon) running on the RPi3. Basically it takes an I/Q flow from the network via UDP and sends it to a HackRF connected to one of the USB ports for RF transmission. I am not able to run the HackRF at more than a sample rate of ~1.2 MS/s reliably. Which is theoretically lower than the minimum but it still works. I suppose this is also a side effect of the sharing of the Ethernet port with the USB.
I thought of using WiFi as I supposed it was not using the USB+Ethernet path thanks to confirm this. I haven’t tried it yet but it looks like an interesting workaround.
