I don’t check for lost samples, but both units manage over 20 MSPS, so I don’t think that will be a problem.
I have been comparing daily position/plane numbers between both units (xu4’s), and interesting to see they are quite close with about +4% difference in AC reported between gains of 21 to 16, and positions reported difference under 1%.
gain 21 gives highest AC count and 16 gives most messages with me.
I will setup the logging sometime - using your manual setup which works very well
Aren’t you very close to SFO? I would expect a gain of 16 or 17 to give better results with an LNA and good antenna above the roof.
I am close to SFO, indeed. Before I left for the office this morning I set the gain to 18. Let’s see how it will run. I may have to play around with the gain a bit to find the optimal one.
There is an Armbian image now available for the N2 - ver.5.86.
I have just loaded the ‘stretch’ version from their download page https://www.armbian.com/odroid-n2/ and whilst it is not officially supported, some clever people have been working on various images for a while.
It works very well indeed - similar cpu% being used compared to the ubuntu image from odroid, but htop etc work on the Armbian image, where I had problems with ubuntu.
Well worth a try - have piaware/dump-fa 3.71 working here fine.
Any ideas how to update to 3.7.1 on the N2 ?
I followed @abcd567 previous recs at: https://github.com/jprochazka/adsb-receiver/issues/471 and changed the version to 3.7.1. That did not seem to do much for the adsb-receiver. Apparently even the compiling was done on version 3.6.3. Do I have to download and compile separately outside of the adsb-receiver install script?
First check out 3.7.1: (the main branch isn’t on 3.7.1 yet.) git checkout v3.7.1
Then follow the build process outlined in the readme.
(Which is different for both projects)
You shouldn’t need dump978 unless you have a 2nd antenna and dongle
I actually do have a second antenna and dongle for 978. Currently they run on an a separate Pi. Would like to consolidate to 1. It is using the regular orange FA dongle. The Airspy is running for the 1090. So, I would need to ensure that the Airspy picks up the right antenna.
dump978 won’t touch the airspy if “rtlsdr” is defined as a driver.
airspy_adsb won’t touch rtl-sdr devices.
So no need for serial numbers.
But yeah you’ll have to build dump978-fa as well.
(Unless you just install it which should be possible now that you have armhf enabled as an architecture on your arm64 device)
just as a regular armhf package? I suppose that works. Will try the compiling first. If that fails I can do the armhf version. Though the package install would simplify future updates… tempting. May have to change my mind
apt-get install piaware
Reading package lists… Done
Building dependency tree
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
piaware:armhf : Depends: tcllib:armhf but it is not installable
E: Unable to correct problems, you have held broken packages.
These are apparently the repositories it is set to look for packages in:
Thank you. I just finished up doing that. Went fine. Although I did it the long way (the way I reall didn’t prefer to - using the adsbreceiver.net script) . It’s working, Airspy and all. But i’ll likely re-image tomrorow and just install things more manually (not use the adsbreceiver.net script). I wasn’t aware of piaware_builder until I saw a reference to it when running the other script.
Thanks for your efforts. Everything went very smoothly after having followed your directions.
git clone https://github.com/flightaware/piaware_builder.git
cd piaware_builder
git checkout v3.7.1
#Note: checking out 'v3.7.1'.
#........
#HEAD is now at 908fdef... Release v3.7.1
CODENAME=(`lsb_release -sc`)
echo ${CODENAME}
# above command outputs distro's codename
#("bionic" in this case)
# if it outputs blank, then in next two lines
# replace ${CODENAME} by bionic
./sensible-build.sh ${CODENAME}
cd package-${CODENAME}
sudo dpkg-buildpackage -b
cd ../
sudo dpkg -i piaware_3.7.1_*.deb
Configure Piaware
(use actual feeder-id in place of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx )
@mtindor
Just using CODENAME=stretch probably provides best results in most cases.
The builds for ubuntu versions aren’t really maintained and ubuntu should be 99% compatible with debian stretch.
I was building on Armbian. It detected stretch properly. Only thing different from what abcd4567 showed as that after build, the deb that i needed to install was piaware_3.7.1_arm64.deb rather than piaware_3.7.1_armhf.deb, since the created package was piaware_3.7.1_arm64.deb.
I haven’t yet switched it over to use the Airspy instead of a dongle yet; haven’t rebooted; am updating piaware-config on the Odroid to match values from my RPI3 (except for feeder ID). I’m going to test this install using the previous feeder ID that was created yesterday, and using no-amp and a 770 mhz yagi lol.