Has anyone tried PiHPSDR through Soapysdr on a Odroid/RasP-III ?
John hasnāt re-inserted the code for the Lime in PiHPSDR yet. Itās comingā¦
Mike
ok, was just now trying to find where it was removed ā i had hoped it was just REMād out ā¦
and see if it works with the newer soapysdr code ā¦
ok ā¦ i think i found part of it ā¦
in the makefile had to just add one line ā¦ similar to the others ā¦
Found Rafael Micro R820T tuner
lime_discovery: length=2 devs->size=5
lime_discovery:device key=default_input val=True
lime_discovery:device key=default_output val=True
lime_discovery:device key=device_id val=0
lime_discovery:device key=driver val=audio
lime_discovery:device key=label val=PulseAudio
lime_discovery found 2 devices
but the GUI says it found nothing ā¦ ok ā¦ i can wait some more ā¦
Iām also waiting for this next code patch for the Raspberry Pi 3.0. I have a friend of mine that Iāve been working with on the PiHPSDR effort and tells me that LimeSDR on the Pi is the next step. The audio and two receivers at once were things that were added and improved for the Red Pitaya - and Iām not kidding, for that SDR the PiHPSDR works WONDERFULLY. But John has now turned all his intention on getting LimeSDR operating on the PiHPSDR code because when I tried compiling it with the correct resources in place (per the Makefile, I added a SoapySDR subdirectory with the required files in there) and it didnāt compile right. I think there are other SoapySDR resources and libs necessary to make the compiler happy. So I, too, am waiting to see what John will do next. The dude Iāve been working with on the PiHPSDR effort tells me that LimeSDR is next - so something should be breaking loose on it soon - - and thatās not only for two channels of receive for both receive channels for the LimeSDR, BUT TRANSMIT TOOā¦!
More as it becomes available - stay tunedā¦
73 de Marty, KN0CK
I built PiHPSDR from git last year and configured the Makefile appropriately, so as to enable LimeSDR support. it built fine and started up OK, but just didnāt detect the board. So Iām not sure whether support was either work-in-progress and it had not been completed, or perhaps it was originally developed against a much older Lime Suite. Either is possible, but great to hear that working support is on the horizon.
1 Like
Iāve been poking the effort (thereās quite a few of us beta testing Johnās Pi 3.0 PiHPSDR software for several months now) and Iāve been a vocal advocate to get it working on the LimeSDR since itās working so well on the Red Pitaya. John Melton (G0ORX) had early trials of the LimeSDR working on PiHPSDR last year in the June timeframe and now heās back onto it since a lot of the fundamental infrastructure is portable to the LimeSDR. Again, Iām REALLY interested in seeing this go live on transmit because other than Pothos, GNURadio, and FooBar (just for transmit) there arenāt any apps that support transmit/receive with the LimeSDR right now. Simonās SDRConsole is queued to make that happen (we all know receive is working great on that), but we really need a fully functioning app to apply the LimeSDR for modes that itās suited for right out of the chute (and WSPR and PSK31 definitely come to mind).
Iām told by my fellow Beta Tester in California (who is not among the LimeSDR fray, but convinced he needs one based on all my raving about it - he also works directly with John on the software) that John is hard at work to apply the SoapySDR elements to it (and I would also think, like youāve mentioned, the LimeSuite pieces) so the app is compliant and operational for the LimeSDR - - and that the source could be ready within the next 10 days or so. So weāre all holding our breath until that info comes out. I tried compiling the source and adding in the SoapySDR pieces to it like the Makefile wants and there were still compiler errors that I think were driven by other Soapy libs that arenāt present. So Iām just going to sit it out since Iām not familiar with the architecture enough to āroll my ownā on this.
Iāll keep this thread aware of the results as that info is forthcomingā¦Stay tunedā¦
73 de Marty, KN0CK
Marty ā¦
Do you get file warnings about ozzy and cp pihpsdr.desktop ~/Desktop
cp pihpsdr.desktop ~/.local/share/applications
Im not sure why my Odroid/Ubuntu16 complains about these operations when doing the same from terminal works fine ā¦
How do you go about installing pihpsdr ā¦ install.sh or
i used make / make install from pihpsdr
Mike,
Yep - you have to comment-out the USBOZY in the Makefile and then itāll compile greatā¦Has no effect on the PiHPSDR app with other radios (Red Pitaya for now).
73 de Marty, KN0CK
1 Like
Thatās not what i meant ā¦ but your answer also tells me that you donāt use the install.sh script in folder /pihpsdr/release/pihpsdr/ ā¦ i think any way.
Mike,
Iām doing the make on all my compiles - no install script use. #OldSchool 
73 de Marty, KN0CK
1 Like
Thats the way i first did it ā¦ but
i got an instal error of sorts ā¦ then john replied to me here ā¦
But honestly, using the install script can possibly (did) remove a more recent version of soapysdr ā¦
Have you used PiHPSDR with LimeSDR(through SoapySDR)?
Id like to use PiHpsdr with SoapyAudio ā¦ untill my LimeSDR shows up ā¦
The SoapyAudio Wiki is bare ā¦
Mike,
My PiHPSDR hasnāt been compiled with the SoapySDR resources yet and the Makefile isnāt right for it, too (that or the resources and libs arenāt in the right place). I attempted to put a SoapySDR subdirectory within the pihpsdr subdirectory and put the right files in there, but it didnāt compile right. The package thatās out there now for download doesnāt appear to support Lime yet, but itās forthcoming (so Iām told). Even when I try to use the Lime with PiHPSDR it isnāt recognized properly yet - but it can find my Red Pitaya.
73 de Marty, KN0CK
I have the rtl and soapyaudio also built for SoapySDR and they both look like they are detected ā but the gui says nothing detected.
new_discover: looking for HPSDR devices on eth0
new_discover: bound to eth0 10.42.0.1 255.255.255.0
new_disovery: thread_id=0xc6b20
new_discover: bytes read -1
new_discover: recvfrom socket failed for discover_receive_thread: Resource temporarily unavailable
new_discover: exiting new_discover_receive_thread
new_discover: exiting discover for eth0
new_discover: looking for HPSDR devices on wlx00064f7bca1d
new_discover: bound to wlx00064f7bca1d 10.0.0.127 255.255.255.0
new_disovery: thread_id=0xc6b50
new_discover: bytes read -1
new_discover: recvfrom socket failed for discover_receive_thread: Resource temporarily unavailable
new_discover: exiting new_discover_receive_thread
new_discover: exiting discover for wlx00064f7bca1d
new_discovery found 0 devices
Found Rafael Micro R820T tuner
lime_discovery: length=2 devs->size=5
lime_discovery:device key=default_input val=True
lime_discovery:device key=default_output val=True
lime_discovery:device key=device_id val=0
lime_discovery:device key=driver val=audio
lime_discovery:device key=label val=PulseAudio
lime_discovery found 2 devices
1 Like
Mike,
The PiHPSDR Makefile specifies a SoapySDR subdirectory (which I put right under the pihpsdr subdirectory and uncommented the LimeSDR entry in the Makefile and got compiler errors. Where are your Soapy resources located when you put yours together and compiled? Again, mine looked like this:
pihpsdr -----> SoapySDR -----> Soapy Files (*.c *.h)
Keep me advised, Iām just holding off until I see a release from John (G0ORX) before I go much further here, but if you have a breakthrough, Iād like to beta itā¦
73 de Marty, KN0CK
What were your compiler errors ?
Did you build Lime and Soapy from source/git ?
yea, my LimeSDR is in the mail ā¦
1 Like
Mike,
Sorry for the delay - I JUST received notice that thereās a new version of PiHPSDR ready from John and Iāll be pulling that down this evening - so more on that to follow when I compile that for LimeSDR resources.
Stay tunedā¦73 de Marty, KN0CK
I got it compiled on a PC and it started up using the LimeSDR. You have to first āDetectā device then āStartā.
I canāt select antenna and canāt see any signals through any of the connectors. Just the DC spike in the middle. Choppy audio. Crashes every now and then. User interface could use some loveā¦