Hi, I’m successfully using LimeSDR-mini for connecting to QO-100 satellite using Sdrangel software. However, now comes winter into Europe and I would like to use it from inside and keep cables for 2.4GHz as short as possible.
Could someone recommend a working remote solution? Via WiFi or Ethernet. I was trying RaspberryPI:
usbip - sharing USB over ethernet - does not work because of some not implemented reset function
remote OsmoSDR - TX products snatchy sound, receive almost OK
remote source in Sdrangel - not implemented
VNC - does not forward sound, on RbPi4 even receives snatchy
Any other ideas on what to try? Appart building a tent near my satellite dish?
Install Lime Suite, SoapySDR and SoapyRemote on the RPi and then execute SoapySDRServer on this. Then make sure you have SoapySDR and and also I think SoapyRemote on the client computer, e.g. laptop, along with SDRangel. Then when you start SDRangel it should detect the remote Pi running SoapySDRServer and allow you to use this as a network SDR, streaming samples over your LAN.
Tnx fer answers. I’ve tried SoapySDR with both Sdrangel & SdrGlut. In both is receive just fine. However sending is terribly snatchy and occupies the whole spectrum. I’m using RbPi4, 100Mbit ethernet, 500 000 sample rate. It’s logging heavily error: samples sent: 357/21504
RbPi4 with PiSDR image is running as a server solely for SoapySDR. LimeSDR-Mini is connected to USB3 Port, nothing else. Pi and my laptop with i7-8550U are connected via 100Mbit ethernet both via 1m cat5 cable to the switch. On Laptop I have devel version of Sdrange and SdrGlutSdrGlut.
With the sample rate I went down to 100k, but without any difference.
Yes indeed. I’m trying to transmit with LimeSDR-Mini on 2.4GHz to QO-100. I need to leave RbPi4 outside near the Antenna (amplifier and filter) and would like to sit in warm. I’m primary using Ubuntu 20.04
I made an addition to SdrGlut - you can now set the send sample rate and I fixed a bug in the send routine. Between my MacBook pro and the PI 4, I could not get the transmit to work. Between my Windows 7 machine and the PI 4, by setting the send sample rate to 200000 - it actually worked with a little delay in the sound and a little noise. Using my Hackrf One it was consistent, but the LimeSDR mini worked now and then. I think my LimeSDR mini is just about dead - it has been giving me lots of trouble. SoapyRemote, in the transmit mode, has minor problems on some system and major problems others. If you want to try you luck, clone a new version and build SdrGlut from source -
Nice work. It helped a little, and the readme is now fine. Still, what comes from from LimeSDR is completely incomprehensible. I’ve tried compiling it and running on RbPi4 as well. The continuous tone sound then like morse. Remotely it’s full of spurious signals around. Probably it’s some issue with RbPi ↔ LimeSDR communication :-/
I looked into the source code of SoapyRemote and it is amazing clean. It the first time that I have ever seen operator overloading used to good effect. I can see where the problem should be, but it looks correct. He uses a alternate set of commands from what I use - may be they have bug in them - perhaps I can switch it to use the commands that work for me.
I make a video showing the problem on MacOS High Sierra and make a report at the Pothos User group.
It works for me now, MacOS High Sierra -> Ubuntu 20.04 and MacOS High Sierra-> Raspberry Pi 4. AM, NBFW, and USB all worked OK. I went into the SoapyRemote source code and I found that I was using one of the routines incorrectly. It was a one line fix. You will need the latest version of SdrGlut to try it.
Wow, good work. TX works now! Just one small issue left. I’m receiving at 433525000Hz 200000 sample rate USB in SdrGlut my TX from Icom and it works well. Then I transmit from SdrGlut with default sample rate 400000. Its fine now RX in Icom. From now the RX in SdrGlut is broken.
The issue is, that both sample rates (RX/TX) has to be same for LimeSDR. When is the sample rate in Transmit changes, the RX in SdrGlut don’t get it and the signal is than distorted.
