Orange Pi PC -- a $15 alternative to RPi 2? So far, so good

Thanks @Johnhawkes2030 - isnt that the same as “bind to all” in the dump1090 setup?

I’ll check that file as you say…

I always set to “bind to all=yes” (pig-scripting!) on each of my setups, this is the first time I’ve had this…

Also, came across this - which shouldnt be the issue, but I’ll check anyway…

"That the /etc/hostname file contains just the name of the machine.
That /etc/hosts has an entry for localhost. It should have something like:
127.0.0.1 localhost.localdomain localhost
127.0.1.1 my-machine
"

*EDIT - I did “bind to all=yes” on my main receiver (which is also running) as well as this Opi (which isnt connected to an ant etc, just setting up to see if it works).
Could the issue be that both receivers are “bound to all” at the same time?

I dont think so, these are independent receivers.

Strange…

Ive got /etc/hosts open in nano…

I leave it ope for a few minutes, then the first line

127.0.0.1 localhost orangepipc

over writes itself with

(UNKNOWN) [127.0.0.1] 30005 (?) : Connection refused

Leaving it open for a few minutes longer, that same line keeps appearing (While om watching it) - in that file.

Would I be right in thinking this is that file updating from an external source (process / service etc) while Im in it?

@cy80rg
What you described seems to be an output from a script trying to connect to 127.0.0.1:30005, and failing, then retrying.

Thanks abcd567 - I think you’re right.

I’m looking to uninstall ADSB-Receiver and it’s releated bits - get back to a clean Armbian image and start again…

@cy80rg:
It may be caused by adsbexchange connection script using netcat to connect. You can disable this scrip by commenting out all the lines:

:~$ sudo nano adsb-receiver/build/adsbexchange/adsbexchange-maint.sh
#contents of the file below. Comment out all lines
#! /bin/sh
while true
do
sleep 30
/bin/nc 127.0.0.1 30005 | /bin/nc feed.adsbexchange.com 30005
done

thanks @abcd567 - doing complete install from formatted-SD up, as we speak.

Understand re ADSBExchange - I’ll not install that this time round.

Do we know why that does that - is there a fix, or does ADSBExchange simply not work on the OPi?

adsbexchange does work on my OPi, but sometimes it has connection problem. This is however a temporary problem, and resolved in couple of hours by itself.

I am not sure on your install it was due to adsbexchange or something else. I suggest you make fresh install without adsbexchange and watch. If all ok, add adsbexchange and watch again. If the problem appears, leave it for couple of hours, it may disappear. If it does not disappear, then disable adsbexchange-maint script.

Hi all,

K - reinstalled from a blank SD card up, all looking better, but no dump1090 data

  • Installation went as expected (though as before, couldnt set up PlaneFinder at ](http://):30053).
  • Sorted out the missing core temp data as abcd567 details

So, as expected - the system data UI is now working, dump1090 graphs and live map data isnt.

Dump1090 System UI - Broken image icons
Dump1090 Map UI - No birds shown, map loaded on arbitrary point, errMsg suggesting Dump1090 isnt running.

Went through abcd567’s suggestions:

(2) DUMP1090 not working (RTL problem in version 3.4.112)

Looks like Jo’s added this blacklist in the last ADSB-R, has the following already there:


# software defined radios.
blacklist dvb_usb_rtl28xxu
blacklist e4000
blacklist rtl2832
blacklist dvb_usb

However,


~$ sudo lsmod | grep rtl

…shows…



dvb_usb_rtl2832u      351091  0
dvb_usb                15734  1 dvb_usb_rtl2832u


which to me suggests these are actually loaded, despite the blacklist wildcards, which I believe should catch these?

NB - I’ll try and explicitly add these, but I believe they’re already covered?

(5) Only one dvb-t plugged into Orange Pi, but both dump1090 & dump978 installed:

Deliberately didnt install dump978 - I only have one dongle / ant.
As such, that line wasnt there.

dump1090-mutability service reports as Active as expected… (usual “status” output).

Any thoughts?

28xxu does not match 2832u.

Good man @Obj - just explicitly blacklisted that and “Thar be… birds!” (to paraphrase :wink: ).

Are the “xx” not wild cards then?

Nope, just how some version of the driver was named.

no “xx” are not widlcards
you have to write the module name exactly as shown in lsmod

Thanks guys, got this up and running - plugged into habAmp, Ant and stable in attic :slight_smile:

Out of interest, anyone done this on a C.H.I.P ?

(Just thinking of the cheapest possible way to get a station setup, so I can have multiple… the CHIP’s c£15 incl PnP).

Yeah, I’ve got a pair of C.H.I.P.s that I bought with this in mind and found them too unstable, underpowered, and finicky for this work. dump1090 and the various rtl_sdr tools install ok and recognize the receiver, but the board hangs as soon as I fire up dump1090. I messed around for quite a while with firmware/OS/drivers/power supplies and was never satisfied. It was a pretty disappointing outcome – now I just have one of the C.H.I.P.s hooked to the analog input on my TV loading a ThingSpeak graph, and the other sitting in a box looking for a purpose (or new home).

The $10 Orange Pi One and $12 Orange Pi Lite both are looking really attractive now, though – especially with the great work the Armbian folks are doing!

[EDIT – Added 25 June 2016]
This comment spurred me to return to my C.H.I.P.s – and I had a lot more success this time around. It turns out that folks working with C.H.I.P boards have identified a lot of the idiosyncrasies over the last few months and developed workarounds. The most important is that the on-board power management chip will shut it down if the C.H.I.P is drawing over 900 mA through the microUSB port, so we need to bypass the microUSB, disable the power management chip, or use a powered USB hub for peripherals and hope for the best. The C.H.I.P. itself can draw upwards of 1A under heavy load, too.

I have been able to get a C.H.I.P. with FlightAware Pro Stick up and running by using the powered USB hub (a Pluggable 4-port) that I was using to run my old Pi B to power the C.H.I.P. and the Pro Stick. I eventually got dump1090-mutability v1.14 up and running, more or less (had to edit /etc/init.d/dump1090-mutabillity line 68 due to a typo; I sent a pull request on github to fix it). The flightaware dump1090 package isn’t working on my C.H.I.P. I also tried building rtl-sdr and dump1090 from source, which worked ok.

The piaware package appears to be working and happily feeds positions to FlightAware, but every time it reboots it creates a new site. It can’t seem to decide which MAC address to use, as each time it reboots it creates a pair of virtual ethernet adapters at USB0 and USB1 with random MAC addresses (which PiAware then uses, even though WLAN0 is stable). Sigh. Back to the drawing board.

My C.H.I.P. is at about 32% CPU load for dump1090-mutability.

I got an Orange PI PC plus. Some ammendments were made to Armbian earlier this month (July6th). The wifi is working and I have installed Dump 1090 Mutability only with the plane finder client at this stage. there were no issues in the install. Now I am just waiting for an aircraft to flyby so i can capture data.

Update: when I run this command: sudo /etc/init.d/dump1090-mutability status I get the following -

● dump1090-mutability.service - LSB: dump1090 daemon (mutability variant)
Loaded: loaded (/etc/init.d/dump1090-mutability)
Active: active (exited) since Wed 2016-07-20 06:18:09 AEST; 1h 33min ago
Process: 520 ExecStart=/etc/init.d/dump1090-mutability start (code=exited, status=0/SUCCESS)

Jul 20 06:18:09 orangepipcplus systemd[1]: Started LSB: dump1090 daemon (mut…
Hint: Some lines were ellipsized, use -l to show in full.
opi@orangepipcplus:~$

I now have 2 corrupted Transcend cards due to some unknown weird oPi issue. I have a rPi3 coming today and the oPi is going to be relegated to some other benign use. I’m hoping Transcend will RMA these cards.

Are you sure it is due to Orange Pi? Lot of people having RPi also have complaint of corrupted/worn out cards. I dont think this issue is related to make or model of Pi.

I have Pi B+, Pi 2, and OPi PC. None of my microSD cards have corrupted or worn out, though each card has several times faced formatting and fresh install.

One card came out of a Pi 2, the other was brand new. The Pi2 with an old card is still trucking and that is feeding to LiveATC.net 100% of the time with pretty good load. I think the oPi is also getting taxed when the reports/sec get above 400.

I installed Armbian on an Orange PI PC. Got that working smoothly. Installed dump1090-fa and piaware. Piaware is running, successully claimed and reporting data to Flightaware but dump1090-fa is not running. When I invoke it manually it says that the usb receiver is in use by another process. I have tried blacklisting it and also tried recompiling the sdr-rtl drivers to detach at bootup. None of that is working. If anyone has any suggestions I would appreciate it.