I’m currently flight tracking with an RPi1 B. It is getting a little overloaded and the plan was/is to get an RPi2 for the job.
As it happens I have an RK3066 based Android HDMI stick that is gathering dust which I fancy utilising. It is possible to install debian/ubuntu on this so that’s where I’ll start.
Dual-core Cortex A9 1.6GHz CPU
1GB RAM DDR3
8GB Storage
It has WiFi built it, but I also have a USB ethernet adapter in case that isn’t reliable.
Apart from it being a totally different piece of hardware to what we’re used to, does anyone expect any issues with running the dump1090-mut software? FA software? etc?
If anything I expect the main issue could be librtlsdr.
I guess time will tell, but if anyone can see any obvious obstacles then let me know.
I’ll try and document everything in case someone else happens to have one.
It’ll probably be OK. dump1090 et al is fairly architecture independent (there were a few endian bugs but that shouldn’t affect little-endian arm anyway)
I had the same issue - I did ‘sudo raspi-config’ and overclocked the pi to ‘Medium’ problem solved.
(I also took the top off the pi case off, and the dongle cover off - and put a 12v fan on a 5v supply nearby to stir the air around the receiver at the same time - the Pi is now running about 10C above ambient, that’s a good 25C drop)
After a couple of evenings of misreading guides, searching for various bits and not doing things properly I’ve now got a nice minimal ubuntu 14.04 installation on my rk3066 based device.
If it’s of any interest I used this guide: github.com/sgjava/ubuntu-mini
The kernel used was picuntu-rc3 because that was the only pre-built one I found with the asix ethernet module I needed for my USB ethernet adapter.
dump1090-mutability looks to have built absolutely fine first time round which is good. I’m going to do some overnight file transfer tests to make sure it is stable enough to put into fulltime use.
Device plugged into a powered hub to power and provide extra USB ports. Currently using a microSD to SD adapter because I didn’t have a spare microSD card.
Change over complete, all seems to have gone pretty well apart from killing a 5V2A power supply. I assume it was just poor quality. I took it apart but can’t see which component has died, it does though have the lovely burnt electronics smell!
Where possible I’ve compiled from source which has worked great. Other cases I’ve installed the armV7 packages where available (same as RPi2).
dump1090-mutability, piaware, fr24feed and mlat-client are all working smoothy.
One thing that tripped me up was I compiled the mlat-client and ended up with 0.2.3 which has changed parameters in the config files. Instead I then downloaded 0.2.2, tried to install but I had a version of python that was too new (3.4 where mlat-client seems to depend on <3.3). I went to the compiled 0.2.3 and figured out what needed changing.
If you use piaware_builder it should pick up the right versions of everything.
I don’t know of any problems with running mlat-client under python 3.4 (assuming you build it yourself) - what was the issue you saw? The prebuilt Raspbian package does depend on the version of Python in Raspbian, but, uh, it’s a raspbian package so that’s working as intended
I’m a bit confused about what you did with 0.2.2 vs 0.2.3. The only change between the two versions was making basestation-format output work with VRS, there were no config changes, all the config changes happened between 0.2.1 and 0.2.2.
I was using dpkg-buildpackage to build dump1090-mutability and mlat-client.
I used the prebuilt deb for piaware.
I haven’t used the piaware_builder, maybe I should have!
The issue was mlat-client 0.2.2 when installing the deb using dpkg depends on python <3.3, whereas I have 3.4 installed, so it wouldn’t install fully.
The only reason I went to 0.2.2 after building 0.2.3 was because of the changes to /etc/default/mlat-client - which I think are literally just combining host and port into a single line. I wasn’t looking at everything right at the time so it was easy enough to sort.
But you’re totally right, the 0.2.2 package is for raspbian so it makes sense it’s built for that! Just a bit of a quirk I saw, and got around by using my compiled 0.2.3 and learning to read.
11:49:30 up 16:06, 1 user, load average: 0.08, 0.14, 0.21
It would usually be well over 1 on the RPi1.
If anyone has a spare RK3066 or RK3188 device lying around doing nothing then this might be worth doing, otherwise I’d just buy an RPi2 due to the vastly superior support all round.
