Running BananaPI M2 Zero

Good morning community,

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.

After that, I wanted to continue following the instructions at PiAware - dump1090 ADS-B integration with FlightAware - FlightAware.
I’ve already encountered the problem that the specified source simply doesn’t exist:

Ign:7 https://flightaware.com/adsb/piaware/files/packages xenial InRelease
Err:8 https://flightaware.com/adsb/piaware/files/packages xenial Release
404 Not Found

Now, as a Linux idiot, I’m pretty stuck. I’ve already contacted support, but haven’t received a response yet.

So the question is, how should I proceed?

DLzG / 73 De
Micha

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:

(1) Latest image here (minimal server)

https://www.armbian.com/bananapi-m2-zero/

Scroll down to bottom of above page.

(2) Archieves (desktop & server)

 

NOTE:
Armbian images on first boot;
default username: root
default password: 1234

 

1 Like

You have a way too old OS on your Banana named Xenial. It’s Ubuntu 16 and not supported any longer since 2021 (even the LTS version)

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…

wpa_passphrase NETWORK_NAME NETWORK_PASSWORD > /etc/network/wpa_supplicant.conf

wpa_supplicant -B -iINTERFACE_NAME -cPATH_TO_CONFIG -DDRIVER

??

If not, it would be great if one of you could link me to a suitable how-to page where I can learn the procedure.

The question of “how” is now resolved. It was easier than expected and simply exemplary!

Installation via serial console was a breeze, and now I can continue via SSH…

If you’ve set it up this far, then continue as described at PiAware - dump1090 ADS-B integration with FlightAware - FlightAware ?

Some alternative downloads:

Ty a lot. I will check that out also later.

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?

root@bananapim2zero:~# lsusb -v | grep -E '\<(Bus|iProduct|bDeviceClass|bDeviceProtocol)' 2>/dev/null
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  bDeviceClass            9 Hub
  bDeviceProtocol         0 Full speed (or root) hub
  iProduct                2 Generic Platform OHCI controller
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  bDeviceClass            9 Hub
  bDeviceProtocol         0 Full speed (or root) hub
  iProduct                2 EHCI Host Controller
root@bananapim2zero:~# cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$"

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 6.12
S:  Manufacturer=Linux 6.12.23-current-sunxi ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=1c1a000.usb

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 1
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0001 Rev= 6.12
S:  Manufacturer=Linux 6.12.23-current-sunxi ohci_hcd
S:  Product=Generic Platform OHCI controller
S:  SerialNumber=1c1a400.usb
root@bananapim2zero:~#

EDIT say:
If I fresh restartet (reboot) the BPI and fast call "
cat /sys/kernel/debug/usb/devices | grep -E “^([TSPD]:.*|)$” I see the stick:

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=2832 Rev= 1.00
S:  Manufacturer=Realtek
S:  Product=RTL2832U
S:  SerialNumber=00001000

If I do it again some seconds after, the stick is gone…

Hell! What’s that?

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.

On my RPi, I check voltage by following command:

sudo dmesg --ctime | grep voltage

If above command gives no output, then voltage is OK.

 

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.

There is a possibility that your stick has gone bad.
If you have another stick, try it in your BPi.

If you plug the stick into your Computer (Windows or Mac) does it show up?

Good morning all together…

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:

sudo apt update
sudo apt install firmware-brcm80211
sudo reboot

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.

1 Like

Upate:

  • 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:

https://github.com/abcd567a/piaware-ubuntu-debian-amd64/blob/master/README.md

 

Ok, I will give it a try. I’m a professional at hardware but I’m a idiot if it comes to software ^^
Be prepared if I loud cry for help :zany_face:

Try it on the backup IMG you have created, so that you have a clean start.

1 Like

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…

Little time between other works…

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, …
img-2025-04-27-13-44-37
… 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…

DUMP1090-FA INSTALLATION COMPLETED
REBOOT Computer
REBOOT Computer
REBOOT Computer

root@bananapim2zero:~# cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$"

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 6.12
S:  Manufacturer=Linux 6.12.23-current-sunxi ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=1c1a000.usb

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 1
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0001 Rev= 6.12
S:  Manufacturer=Linux 6.12.23-current-sunxi ohci_hcd
S:  Product=Generic Platform OHCI controller
S:  SerialNumber=1c1a400.usb

If I then uninstall dump again, the stick is back after a reboot. So it’s definitely a dump problem, which probably only affects the BPI…

To be sure I just have ordered a Raspberry Pi Zero 2 W. Touch down here in the middle of the coming week …