Closed probonopd closed 4 years ago
Go to Actions
tab. Latest is https://github.com/mryndzionek/composable-sdr/actions/runs/102738008
There is a short note in the README on the devel
branch: https://github.com/mryndzionek/composable-sdr/tree/devel
Thanks. Unfortunately it is a zip which we cannot use for our automated tests over at https://github.com/AppImage/appimage.github.io, please see https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages/cc2441518975caca23e9ce2dba6f08a22c678d1e#common-mistake for an explanation. Thank you very much for choosing AppImage as a format and for your consideration.
GitHub actions https://github.com/actions/upload-artifact works this way: https://github.com/actions/upload-artifact/issues/3#issuecomment-620722206. I think I'll do first official release in few days and upload it unzipped. I can let you know.
Thanks a lot! :+1:
Hi. I've made the release here: https://github.com/mryndzionek/composable-sdr/releases/tag/v0.1.0-alpha
I've messed around now for about an hour trying to build from source just so I could try out the helicopter decode. No luck. Would you happen to have an appImage for that app as well?
Not sure when I'll have time to do an official release, but you can try forking and then pushing master
branch to build
branch. This will trigger a github action that will (hopefully) build the appImage. However this appImage will only contain soapy-sdr
app, not the helidecode
app needed for extracting KML files.
Okay I’ll try that, although the helicopter part is what I really wanted to try. The standalone sdrapp image works fine with at least my rtlsdr but doesn’t see the soapy 7 modules that my other programs (cubicsdr, SigDigger) sees. So I’m unable to test with the hackrf and sdrplay equipment.
I pulled down cable and required ghc, but my first problem was that I had to change the version from <=4.12 in your cable file to 4.9 before I could get cable to do anything. After that things just kind of fell apart when trying to individually build the helicopter decode. I’m not by the computer but some package called repeater something failed to build do to something with anyTell and manyTell.. I’ll probably have to wait till you release something.
Okay, yes, I know that SoapySDR version mismatches can be problematic. librtlsdrSupport.so is bundled with the AppImage and it would probably be best to do the same with the other modules. Current AppImage expects modules0.8
(/usr/local/lib/SoapySDR/modules0.8/).
Regarding building from source you might want to use stack instead of cabal. For more details on building you might want to look at https://github.com/mryndzionek/composable-sdr/blob/master/.github/workflows/build.yml
Thank you. I think I see how I can modify and build this. I figure it’s also worth asking, if you happen to have the time, check out my “DragonOS LTS” project which now includes your AppImage. If by chance you could build all your apps taking into account everything I have presintalled in DragonOS would open up your project to everyone running the distro I’ve been workin on. I’d love for it to use all the soapy7 modules I’ve included which should mean SDRplay equipment would be supported. Otherwise I’ll try and get to it myself when I have time. Thanks!
So it was the ghc version that was killing the process. I figured out I had to add the PPA to get the correct ghc referenced in your build directions. Seeing what the end result will be now that it’s all building.
Yeah, I think build.yml
is ideal reference for adding the steps needed for building on other distros. It should also be possible to compile soapy-sdr
for ARM just using ARM Ubuntu base image (GitHub doesn't provide one yet). Regarding the helicopter example, I think it has only educational value. Is there much sense in distributing an app capable of doing end-to-end decoding? The app is specific to this particular protocol format and isn't a streaming
app - expects all samples being available upfront.
My project is just 18.04 Ubuntu for now. I was able to build your soapysdr AppImage, however, it pulled in all sorts of rtlsdr and soapymodules due to me having a variety of things preinstalled. The end result was a segmentation fault even after went into the AppImage folder and manually deleted things I didn’t think was needed and then rebuilt the AppImage. Very cool process and learned a few things along the way. I think it’s important to use a clean build system with the bare minimum dependencies installed, then add extra soapymodules. I’ll try this soon.
As far as helidecode, I couldn’t get that app to build. I ended up using just a couple of your other examples. Sorry to fill up your thread here. Look forward to whatever else you release.
I was struggling with segfaults also - this is caused by mismatch between SoapySDR and Soapy modules and this mismatch occurs in official release versions (!!!). That's why in my build.yml
I use very specific versions/commits. If you have debug builds of the libraries you can use ordinary GDB to investigate the segfaults.
Regarding AppImage building, did you use cabal2appimage
? This app might be worth a separate repo and its own AppImage (as opposed to helidecode :smiley:).
I'll definitely be developing soapy-sdr
further. Something like this was missing from my toolbox. The UI apps (CubicSDR etc.) are not that great for automated workflows and have limited capabilities. GNU Radio is often too big. On top of that Haskell just makes so much sense for applications like this.
I don't have other SDR hardware to test, but I can add other SoapySDR modules to build.yml
, so that they are bundled in AppImage.
I've added a new issue: #2. Let's move there.
Hi, thanks for making an AppImage for Linux. Is it available for download somewhere?