I’m new to this topic. So please bear with me if I don’t understand everything yet or if I ask “stupid” questions…
I plan to install the Pro-STick-PLUS together with a BananaPI Zero directly under the DIY antenna in the mast. So far, so good…
I chose the BPI because it’s significantly more powerful than a Raspberry Pi Zero and offers several other advantages, such as native network connectivity via a PIN header. It’s only a 100, but it should be perfectly sufficient.
The first problem was even installing an image on the BPI. The images offered by Banana.org are all at least 5 years old. After many attempts, I finally got a headless Ubuntu server running on the RPI, which has been running perfectly so far.
Yes, there is a way to install dump1090-fa and piaware on Ubuntu installed on Banana Pi. But first I need to know some more details. Please post output of following commands
lsb_release -a uname-a
EDIT:
Found. You have Ubintu 16 Xenial. This is too old.
Why not use Armbian 12 Bookworm. Both Desktop & Server images for BananaPi M2 Zero are avaialable for download here:
Good morning all together…
…and thank you both so much for your help.
I wouldn’t have thought of that, of course. There’s no information about this on the operating system download page on the Banana website. All you find there are ancient versions, at least five years old. It actually wouldn’t have occurred to me to check the Armbian website, for example, to see if they offer anything for the BPI; you have to figure that out first.
I’ll give it a try and report back here on my success or failure.
I have one question about Armbian, since I’ve never worked with it before:
Is the method for providing Wi-Fi with the relevant information via the serial console the same as with Debian (derivatives)? So…
At the moment everything seems to be going well, but only superficially:
root@bananapim2zero:~# piaware-status
PiAware master process (piaware) is running with pid 854.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090) is not running.
no program appears to be listening for ES connections on port 30005.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.
got 'couldn't open socket: connection refused'
dump1090 is NOT producing data on localhost:30005.
Why is that? I think I have overseen some steps to get it running?
Webside of the BPI is up at IP:8080 and looks well…
Can it be that dump don’t see the stick on the 2nd USB-port?
How have you connected stick to Banana Pi? Directly inserted into USB port or using a usb extension cable? If using an extension cable remove it and directly plug the stick into usb port of Banana Pi. Also try another usb port.
A direct connection won’t work. The BPI M2 Zero only has µUSB ports. A µUSB to USB-A adapter cable is therefore essential.
Another connection won’t work either: Port 1 is for power supply only, Port 2 is for data and an OTG port.
It should still work. There’s only a 15cm adapter cable between the stick and the BPI. The same thing connected to the PC works with a 3m USB cable.
I’ll use the scope tomorrow to check whether there are any voltage drops directly on the stick. If so, the problem lies with the BPI’s “soft” power supply. A power supply unit (lab power supply set to 5.2V) has been ruled out as the cause.
Yes, that’s one way to at least roughly check the power supply. But it’s actually just a quick snapshot, which doesn’t tell you anything about how the voltage behaves dynamically. This can only be done with a storage oscilloscope, which I’ll use tomorrow. This allows me to detect even extremely short spikes in the microsecond range.
Sure… and also runs very well with dump1090 for windows on a win10prox64 and also on a debian12-netbook, both with the same 3m long cable. So I can be sure that the brand-new stick is well going, also with the long cable and the voltage loss and data smoothing the long cable create.
Based on my gut feeling as an old electronics engineer, I suspect the problem lies with the BPI itself. Either a power supply issue, or a problem with Armbian itself. I’ll figure out the former later, once I’ve gotten my pain under control. If that’s not the case, I’ll try the Debian/Ubuntu image from foxhunter.
Which Armbian image you have used?
The minimal IOT image is stripped down version and lacks many essential firmware & packages. I am using Armbian trixie / sid minimal IOT image on RPi Model 4. It had WiFi moduule missing. I had to install it by following commands:
In minimal IOT image for BPi, some module / firmware for the RTL stick may be missing causing your problem. I recommend instead of minimal IOT image, you try regular bookworm image from Archive
Ok, I will try that after what I’m doing right now…
At the moment, I can say the following:
VCC is stable. Measurement with a Scope only show µsec’s short ripple with a maxima of 1.5µVss while Voltage direct on the Stick are stable at 5,17V. That’s more and better than needed.
This means that the suspected problems regarding the power supply are off the table…
I have flash the SD again with a fresh Armbian as before (using again Armbian_community_25.5.0-trunk.444_Bananapim2zero_bookworm_current_6.12.23_minimal).
After setup and restart I have no problems to see the stick while call cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$" Absolute stable and available, also while writing this and check from time to time nearby!
At this point, it’s clear that this issue isn’t caused by the stick, the cables, the power supply, or the operating system.
I’ll now follow the steps at ./adsb/piaware/install and check again after each step to see if the stick is still visible in the system. I now suspect that either the FlightAware software or the specific dump version is causing the problem.
Installing Keyring and source, run an update and check.
° Stick still visible and online
Installing FlightAware-Software
° Stick still visible and online
Reboot the system and check again
° Stick still visible and online
Shutdown the system, create an backup-IMG to be able to start from later if needet. Fire up and check again.
° Stick still visible and online
Install dump1090-fa and its dependent packages
° Stick still visible and online
Reboot the system
° Stick is gone! Calling ´´´cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$"´´´ take a very long time to response.
So hit me, but I’m now sure that dump1090-fa is the problem at all!
I’m just try the regular armbian-image. Takes a while…
However, I noticed a very unpleasant feature of this version during setup:
Why does it switch from ASCII to ANSI during the WLAN SSID search in the middle of setup? Why doesn’t it stick with ASCII like in the minimal version?
Using a serial terminal, this would inevitably abort the process, since most serial terminals (hTerm, CoolTerm, etc.) can’t handle it…
I believe that you should stick to the lowest common denominator in the setup, at least until the system is on the network and can be accessed via SSH after a reboot.
May be there is some mismatch of BPi hardware & pre-built package of dump1090-fa (which is built by Flightaware for Raspberry Pi hardware).
If you built the dump1090-fa package from source code right on your BPI , it will provide a perfect match with BPI hardware. Use the backup IMG to build & install dump1090-fa from source code.
You can easily built it using the automated built-and-install script I have provided here:
Good idea. I’ll do that.
In the meantime, I’ve also followed the steps mentioned with the regular version. It produces exactly the same result. As soon as dump is installed and the system is rebooted, the stick and port disappear.
But now I have to do something else. I’ll continue tonight…
I restored the backed-up image and started it. Everything was fine.
Then I ran bash -c "$(wget -O - https://raw.githubusercontent.com/abcd567a/piaware-ubuntu-debian-amd64/master/install-dump1090-fa.sh)" from the link you have provided.
Except for three warnings, …
… it ran without errors (large scroll back buffer).
But: Even before I restarted the BPI as clearly indicated, the stick was no longer visible at that point…