Announcing PiAware 3! (Latest version: 3.8.0)

@kenf3

Left one for 978 Mhz, wire cut to length 75 mm
Right one for 1090 Mhz, whip cut to length 67 mm

.

This pic from the eHam site suggests we should cut a bit more off - he shows the antenna section being 52mm but I think it should be 54mm (69-15=54). 978 should be 62mm (77-15=62).

It’s not overly critical. But yes that part should be taken into account.

I have posted this in Flightaware in Feb 2016

Later, these were either posted by me on eham (as user ABCD567), or someone else has posted my images. Can you please provide the link to the eham post from where you got it?

Cutting whips to 67-15 = 52 mm improves to some extent but not much. I dont generally tell people 52 mm, as they start asking why 52, and to avoid giving explaination every time, I generally say 67 mm. In fact the whips in the two photos I have posted above are 52 mm for 1090 and 60 mm for 978

Episode 2 of Improving DVB-T Magmount Antenna.

NOTE:
In above post, images 2, 3, & 4 were knocked down during conversion of forum format to Discource. As I cannot edit old posts, I cannot fix it. I am therefore re-posting these here.

Images 2, 3 & 4

image 2

.

image 3

.

image 4

abcd567, here’s the eham link …

https://www.eham.net/ehamforum/smf/index.php?topic=112703.0

1 Like

Thanks kenf3
Yes, that was posted by me as eham member ABCD567 in Dec 2016.

I have posted same in Flightaware Forum in March 2015.

Three Easy DIY Antennas for Beginners

.

1 Like

Has anyone susccesfully gotten uat2esnt to work with PiAware’s dump978-fa? It seems mutuability has this command built in to allow converting UAT messages to Mode-S messages for software like VRS to listen to feeds from, but dump978-fa does not seem to have the binary available.

Just updated my main feeder to 3.7.1 via the PiAware control panel/Upgrade and Restart PiAware. Maybe it was down for a minute or two. Working fine. Just receiving 1090 ADSB for the moment. Once I finish testing 978 antenna(e) I hope to add another feedline to the tower and add 978 as well.
I do now have the FlightAware 978 antenna that arrived last week hope to be testing that later this week, replacing my current home-made 978 spider antenna.

3 Likes

This is what the logs are showing regarding MLAT:
[2019-05-13 08:04 EDT] mlat-client(722): Server status: clock unstable
This message appears shortly after startup and then the MLAT button goes red. MLAT had worked fine for 4 months on 3.6.3 until I upgraded recently. Actually, I believe it worked on 3.7.0.1 but when I went to 3.7.1 this issue started. When 3.7.0.1 came out I put the image on another SD card and it was working. I upgraded both the image with 3.6.3 and 3.7.0.1 and I have this issue on both now. Wonder if there is something in the config missing.

No changes to explain that as far as i know.

Much more likely it’s a power issue because you now have 2 dongles drawing power via USB.
Try connecting them via a powered USB hub or try using another power supply (preferably 5.1 V: RPi 3 Official Power supply for example)

I monitor my Pis for power issues with dmesg and a Klein UDB Digital Multimeter. I also use the Pi power supplies. I don’t have a power issue. I also discovered something else a while ago. I disabled IPv6 on the Pi and after that Piaware would not start at all, even manually, so I had to re-enable IPv6.

Whatever the issue is, it’s unlikely related to the version and much more likely related to using 2 dongles at the same time.

To verify that disable dump978-fa for a bit:

sudo systemctl mask dump978-fa
sudo systemctl stop dump978-fa

And to turn it back on

sudo systemctl unmask dump978-fa
sudo systemctl restart dump978-fa

(without masking piaware will restart dump978-fa after some time)

On possible non-power reasons: the USB bus might be a bottleneck.
Which RPi version do you use and what Raspbian vesion?

Well dmesg doesn’t help, the dongles want 5V and the supply towards the USB ports seems to drop quite a bit.
If you can cut up an old USB cable and check the actual USB voltage with the multimeter.
The USB specification requires resettable fuses for USB hosts, those might not trip but have high resistance resulting in low voltage on the USB output.
This problem has been observed with the RPi Zero but i wouldn’t be surprised it could happen with other models.

What is the voltage on the RPi 5V rail?

Dmesg will let you know when there is an issue with the power source. For the USB ports I use the meter. I misspelled USB in the name of the meter. It plugs into the USB ports and show voltage and current draw.

It will let you know at 4.7 V or something like that.

The rtl-sdr compatible receivers are picky and want the full 5V, some models are more forgiving than others.

So what is the voltage for the dongle used by dump1090-fa?

This is a bug in the Debian tcl build; a workaround is to remove the IPv6 localhost entries from /etc/hosts if you disable IPv6

The voltage is 4.97. I checked another one of my Pi’s and it was like 5.04 so I swapped the power supplies and now I get 5.02 with the meter inline with the dongle. This appears to have corrected the issue but makes no sense because MLAT had worked fine on 3.7.0.1 with both 1090 and 978 dongles up until the day I upgraded to 3.7.1. I have attached an image of the aircraft graph for my feeder in which you can see the MLAT line was almost steady at 500 until May 9 and then drops to 0. I upgraded to 3.7.1 the day it was announced on Twitter which was May 9.
This is a Pi 3 B+ running Stretch. Well I just noticed that MLAT is no longer synced. I’ll just monitor it for a couple days. Thanks for your help with this.
tahoeadsb

Mlat is quite sensitive to pretty much anything that could affect the USB bus, so it’s not too surprising that adding a second dongle to the same Pi affects it.

I’d suggest running two Pis.

1 Like

This is quite a coincidence. Maybe dump978 wasn’t working correctly before?
Still best way to troubleshoot your issue would be stopping dump978-fa as i suggested before. If that fixes your issue then it’s unlikely the software version is the reason.

Why don’t you try running

sudo rpi-update

This will update kernel and firmware. (Reboot after updating)
I have the impression they have improved some USB quirks in the firmware, so it might help.

Just for kicks you might also try a temporary fan to provide some cooling to the dongles and USB circuitry.

You can also check the logs i suppose maybe there is something interesting:

sudo journalctl -u piaware | grep -v 'reported location\|--lat\|feeder ID' | grep mlat
sudo journalctl -u dump1090-fa | cat

apt-get autoremove problem. Upgrading from 3.6.2 to 3.7.1 via manual apt-get command. This is the PiAware image and uses the FA repositories. The install worked fine and everything came up and ran. At the suggestion of the apt-get upgrade command, I ran apt-get autoremove to get rid of unused code. Unfortunately this removed PiAware, and a bunch of other stuff. The system came up, but none of the FA code was running and lighttpd showed the standard initial webserver installation screen. Fortunately I had a backup so I reverted to that and will do the upgrade again without the autoremove.

Why not re-image with 3.7.1 image?