Hi all, with Covid lockdowns and plenty of time now, I thought I might set back up my ADSB trackers. I still follow the posts but just some clarifications re best guide to set up now days. I think I can determine that Joe is no longer actively involved, but ABCD etc still going strong. My equipment for testing and tracking will comprise Odroid N2s and RPi 4’s. Still keen to be using the graphs etc and will be feeding Flighaware, flighttrader24 and Opensky. If someone can point me to the current best guides for these set ups. Appreciate the N2’s cant use the standard piaware flight aware set up and believe RPI side of thing, an imminent release of Raspberry PI OS 64, which might suit the N2’s?? Thanks in advance :).
Brows automated install scripts at following GitHub page.
https://github.com/abcd567a/piaware-ubuntu20-amd64/blob/master/README.md
Not sure if it will work for Odroid N2s.
However I have tested and it works on many Hardware/OS including following:
RPI Model 4 (32-bit & 64-bit) Raspbian, Ubuntu, and Kali (armv7l & aarch64)
It builds and installs following using source-code:
(1) dump1090-fa
(2) paware
(3) dump978-fa
(4) piaware web
1 Like
Re-imaging Made Easy
Scroll down to:
- 3.1 - Planefinder
- 3.2 - Flightradar24
- 3.3 - Radarbox24:
- 3.4 - Graphs by @wiedehopf
Not included in above How-to:
ADSBEXCHANGE
sudo bash -c "$(wget -nv -O - https://raw.githubusercontent.com/adsbxchange/adsb-exchange/master/install.sh)"
OPENSKY NETWORK
wget https://opensky-network.org/files/firmware/opensky-feeder_latest_armhf.deb
sudo dpkg -i opensky-feeder_latest_armhf.deb
Hey thanks for the reply. I had sus’d out some of those links in research but just wanted some confirmation in what I was looking at was the latest. Re the RPI OS 64, if it works with Raspbian and Ubuntu, you would think it will work with a N2. I will let you know after I throw it on a test unit. With the added extras and re imaging, would you suggest using this procedure, which I imagine is the same as installing it cold?? Oh one thing I forgot to add re equipment, using Airspy R2, so I suppose that nifty script you have made for attaching an Airspy to your rig.
Jeff
N2 needs a 64bit system, you’ll have issues installing fr24.
This will also not work as N2 is aarch64 and not armhf.
RPI OS 64 bit won’t help you either it’s aarch64 just the same.
You can install multi-arch support to run armhf stuff on aarch but it’s a bit annoying.
Just use an RPi4 if you want to feed fr24 and stuff. Or suffer incompatibilites and a lenghty install process.
Thanks for pointing out
Use this one for 64-bit
wget https://opensky-network.org/files/firmware/opensky-feeder_latest_arm64.deb
sudo dpkg -i opensky-feeder_latest_arm64.deb
Try this
sudo dpkg add-architecture armhf
sudo apt-get update
dpkg --print-foreign-architectures
dpkg --print-architecture
Hopefully after this FR24 32-bit armhf will be installed.
Unfortunately I dont have Odroid N2 to test all this
You can try with Raspbian OS 64bit if you feel like it, that should behave very similar as it’s aarch64 as well.
You can use it on a RPi3 or 4 without issues.
Index of /raspios_arm64/images/raspios_arm64-2021-05-28
All feeder how-tos I have posted above is what I have successfully installed on RPI Model 4 with following OS:
2021-05-07-raspios-buster-arm64-lite.img
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v8+ #1414 SMP PREEMPT Fri Apr 30 13:23:25 BST 2021 aarch64 GNU/Linux
pi@raspberrypi:~ $ dpkg --print-architecture
arm64
pi@raspberrypi:~ $ dpkg --print-foreign-architectures
armhf
sudo dpkg --add-architecture armhf
sudo apt update
sudo apt dist-upgrade
sudo apt install libc6:armhf libstdc++6:armhf libusb-1.0-0:armhf
I believe this was required on the N2 to make the airspy armhf binary work.
But this has now aarch64 as well so it’s not needed for that anymore.
But it might be needed for the feed client binaries as well.
1 Like
In the " 2021-05-07-raspios-buster-arm64-lite.img" on RPI Model 4, both architectures (arm64 and armhf) are enabled by default, i.e. one does not have to issue command sudo dpkg --add-architecture armhf .
Because of above situation, when the bash scripts for feeders tries to install dependencies for a 32-bit (armhf) feeder binary, the apt automatically select dependencies for armhf. User dont have to specify package_name:armhf.
Wiedehopf, I did try your Raspbian Lite: ADS B receiver install, but it did not work. But scratching the chin, not sure whether that dodgy lead that has been running me around thinking Airspy failures, wasn’t the lead that might have been connected. At the moment, I have 2 PI4’s set up with ABCD’s latest suggestion, but can you install the graphs on such an install. And I think the other thing I was interested in was gain changes and from what I think, you can manually change the gain with your set up, can’t use the auto version as running Airspy.
No auto for airspy indeed.
And you’d have to be more specific than “does’t work” …
I am thinking it was the lead that caused the problem now, so won’t give exact details re your install. But once I have this current install where I like it, I will try your scripts again 
. Working on the current install, that so far is looking like what I might be happy with. Have installed graphs and great to see this feature has survived from the mutability days. Optimizing gain though and as mentioned, Airspy, so no auto feature, but find the task of tweaking things to get the best invigorating …(you should see what I tweak with my Blitzortung lightning detector systems…)
I have tried your manual method script (will be shown shortly) to get a percentage of strong messages and got this result possible error highlighted??:
grep -sh /run/{dump1090,dump1090-fa,readsb}/stats.json -e ‘’ | jq ‘.total.local | ((.accepted | add), .strong_signals, .signal, .noise)’ | xargs -n4 echo | awk ‘{printf “\nPercentage of strong messages: %.3f\nSignal: %.1f\nNoise: %.1f\n”, $(2) * 100 / $(1), $(3), $(4)}’
-bash: jq: command not found
Percentage of strong messages: nan
Signal: 0.0
Noise: 0.0
Now in your github description, you state you can use your graph data of: ““the percentage given in graphs1090,”” What data field are you getting this percentage from, can’t see something obvious that is “measuring message strength” ?
Another graph question. Has anyone tried to install these graph scripts on a Radarcape set up??
Radarcape doesn’t run dump1090 or readsb so no data source for the graphs.
The radarcape has limited CPU so you can either try it or run it on another device that uses the radarcape as datasource.
In both cases you’d install like readsb like this and tell it to get the data via network instead of an SDR: Automatic installation for readsb · wiedehopf/adsb-scripts Wiki · GitHub
Well install jq.
With the airspy all this gain stuff will not work.
Rough guideline is to put the weakest signal (cyan line in graphs1090) around -30 dBFS.
You’ll likely notice that going up an down in gain a bit will not influence the results at all with the airspy, it’s pretty tolerant to running a wide range of gains.
Have you increased -e to 8 or 9?
That’s one of the things compared to the defaults you will want to do if you have enough CPU for it.
What is jq??? I do not eat or sleep linux scripts sorry, thats why I ask the community.
Sorry you lost me there, might have remembered that 2 years ago … lol
I take it that line is in the ADBS signal level, only data field with negative numbers, but how do I alter something to get that level?
Jeff
Then google how to install packages on the system you’re running.
Google what jq is …
It says command not found: jq
Anyhow it won’t be useful as with airspy you can’t get a percentage of strong messages.
The -e setting is in the airspy configuration file, read the explanations in the config file: GitHub - wiedehopf/airspy-conf: Configure airspy_adsb for use with readsb or piaware.
Change the gain in the airspy configuration.
It’s not working because significant things are missing.
Radarcape is running rcd as data source and does not provide any of the data in the way graphs1090 can use it. Most of the things are running in RAM to reduce SDCard write attempts.
Beside that the device does not have a sufficient CPU for doing that.
You will need to setup a seperate device which collects the information via the network port.
It should work running a Raspberry with dump1090 or readsb in network mode, capturing the stream from the Radarcape network port.