Well the “unfortunate” bit is that installing a completely unrelated soapysdr driver suddenly requires that existing software needs new permissions. That’s arguably a bug in soapysdr. Users of the generic soapysdr API shouldn’t need to know / grant the union of all possible permissions that any device might require…
It sure is a bug. But waiting for a fix and that to propagate… i would opt for the in this case easy work-around.
And having some user in the audio group shouldn’t be a problem security or whatever-wise.
Or is it?
Yeah we’ll have to just do a workaround for this release. Giving the user extra permissions that aren’t needed isn’t ideal (the whole point of sandboxing it under a separate user is to limit the permissions needed) but it’s probably not too bad in this case.
I’m slowly leaning towards actually building our own soapysdr when packaging, because the stretch version is pretty old to start with (notably, it’s missing the PPM correction API) and there are some other improvements that I’d like to make too. We’ll see.
Thanks Oliver for the advise. I will now slip-out the trial microSD card from RPi and slip-in the regular microSD card, and wait for release of SD card image.
soapysdr … something new for me… need to study it.
Thanks for sharing these instructions. I am using a Raspberry Pi Model B Rev 1 and while building piaware, gcc ran out of memory. After creating a swap file and enabling swap, I was able to build everything and run it successfully. Just thought I’d add that as a tip for anyone else using old model Raspberry Pis.
Please do NOT use Ver 3.7.0 as it is still in development stage, as advised by developer in Post #58 above.
Either use Piaware SD card image 3.6.3, or Raspbian image with package install of dump1090-fa & piaware, ver 3.6.3.
If you are interested to build dump1090-fa and Piaware from source code, built version 3.6.3 using method given in this post. In this method, omit step 1.3 (removal of bladeRF). This step is not needed for Raspbian on RPi. It is required for Linux on amd 64 & i386 PC.
It’s only an issue with piaware.
(Because the servers aren’t at the new version yet and don’t understand the new split between UAT and ADS-B positions which internally are probably represented differently. So those positions can’t be properly processed by the FA servers and that of course shows in your statistics)
dump1090-fa and dump978 don’t interface directly with the flightaware servers so using those on the new version shouldn’t be a problem.
It should be perfectly fine for you to run dump1090-fa and dump978 and skyview978 to checkout how they work together.
The options for dump978 are a bit different and the dongle selection is going to be interesting.
Too late.
The ver 3.7.0 is no more there. I have already re-imaged the trial microSD card with Raspbian Stretch Lite image.
EDIT:
The dump978 has failed to start on the now erased install. Please see my last few posts.
Didn’t you catch the
sudo adduser dump978 audio
?
No, I did not, but did catch these:
Adding user dump978 to group plugdev'
std::exception::what: RtAudio init error 'RtApiPulse::probeDeviceOpen: unsupported sample rate
You misunderstand, that is the solution to the problem.
Did you post this solution (sudo adduser dump978 audio
)? Where?
You have posted this one below, which I tried, but it did not solve the problem
sudo usermod -a -G audio dump978
That didn’t work for you? It does the same.
Can you try modifying the service file:
/lib/systemd/system/dump978-fa.service
Make the User=root to check if it’s a permission problem.
You could also try removing the soapysdr audio module
apt remove soapysdr0.5-2-module-audio
No, It did NOT
.
Too late, the card has been re-imaged.
Anyway, I will now build & install ver 3.7.0 of dump1090-fa & dump978 (no Piaware) on the reimaged trial card.
User=root
OR
Usr=root
(like /usr/share/
and /usr/bin/
)
Just uncomment the User line then
@wiedehopf
Let me first install dump978 and dump1090-fa, then only I can make changes to permissions and User.
Anyway, using root as user either explicitly (User=root), or by commenting-out (#User=foo) on permanent basis is not a good idea.
Yeah yeah
It’s just for testing.
Just want to exclude a permission problem.
Yeah seems like there is another error going on with dump978-fa on the Rpi on stretch.
Just tried myself:
Found Rafael Micro R820T tuner
SoapySDR: using maximum manual gain 0.0 dB
Uncaught exception: Dynamic exception type: std::runtime_error
std::exception::what: failed to construct stream
Oh that problem was with choosing a dongle by serial.
If i just use the default options it works.
pi@raspberrypi:~ $ groups dump978
dump978 : nogroup plugdev
pi@raspberrypi:~ $ sudo adduser dump978 audio
Adding user `dump978' to group `audio' ...
Adding user dump978 to group audio
Done.
pi@raspberrypi:~ $ groups dump978
dump978 : nogroup audio plugdev
pi@raspberrypi:~ $ sudo systemctl restart dump978-fa
pi@raspberrypi:~ $ sudo systemctl status dump978-fa
● dump978-fa.service - dump978 ADS-B UAT receiver
Loaded: loaded (/lib/systemd/system/dump978-fa.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Sun 2019-03-31 09:24:51 EDT; 1s ago
Docs: https://flightaware.com/adsb/piaware/
Process: 1020 ExecStart=/usr/share/dump978-fa/start-dump978-fa (code=exited, status=1/FAILURE)
Main PID: 1020 (code=exited, status=1/FAILURE)
Mar 31 09:24:51 raspberrypi systemd[1]: dump978-fa.service: Failed with result 'exit-code'.