New Pi-Aware - Connectivity Issues

First I wanted to thank everyone for their help on my last issue.

Quick summary of what happened was a suspected power spike caused the smoke to escape my Odroid N2+ and damaged my ProStick Plus, but they functioned well enough to “work” but only barely… I recently got the recommended RPi equipment, and am now having a separate set of issues (mostly with FlightAware Feed being in an error state on the PiAware main load screen).

I am now running the following hardware:
*Raspberry PI 4 Model B w/ 1GB RAM
*Blue FlightAware Pro Stick for 1090 Rx
*Orange FlightAware Stick for 978 Rx
*1090/978 Nooelec antennas (have a 1/4 wavelength ground plane antenna for 1090 installed, but can’t easily remove for testing).

On the Welcome page of the PiAware 8.2 GUI, the anomalies are as follows:
*PiAware feeder consistently states normal and that “PiAware 8.2 is running” - no issues here.

*1090 Receiver fluctuates between Normal, and warning “Connected to Mode S Receiver, but no recent data seen” - Is this an element of testing inside and not having a good view of the outside?

  • FlightAware feed: after about 10-15 minutes it usually goes between a normal state and error. When in error it regularly states in “Error Not connected to FlightAware”

  • Multilateration: Usually is either “warning: No clock synchronation” or Error Multilateration enabled, but client not running" - I am going to assume this is a result of the above communication failure.

Open to ideas! Leaning to something on my home firewall/network but not sure if that would cause the issues?

Go to your internal site at http://xxx.xxx.xxx.xxx where that is your internal IP address. What is that telling you? It should look something like this, and you can hover your mouse over the green sections for info.

Take a look at your stats page below. That gives you info about connectivity, when the receiver last checked in, and you can see performance on an hourly basis.

It looks like you’re just not picking things up. Try it with just the Pro Stick Plus to start with, and see if you can get that reporting positions and aircraft. Then add the 978 stick back in and check there’s no impact on the previous performance.

1 Like

Antenna placement is key to getting the best performance. Get it outside and high if possible.
If you can’t get outside, place antenna as high as possible in a window facing the air traffic. I’ve actually taped mine to top my tallest window. Doing other things before you get good antenna placement is usually wasted effort.

Thank you for the replies!

I spent the last few hours working on some firewall permissions which have seemed to come up with no successful resolution.

I do go to the internal site, and it gives me the below status at first,

Then after a few minutes I get this,

then I get “error: Not connected to FlightAware” when I connect via HDMI to the RPi (all tiles are red), then it ends up with “PIAware Feeder: error: could not read piaware status file (piaware may not be running).” It is a very cyclical thing.

Antenna placement is very important I do agree with that. With the prior setup I had used the same antennas with success on receiving packets up to 250-300 miles away which is not terrible for the first floor inside a Condo (restricted from putting antennas outside by HOA - current “Permanent” antenna is in the garage which has worked very well for the past year and a half until I updated! While I am troubleshooting I have to have it tethered).

It seems to be getting positions of aircraft with just the ProStick, but disconnects from FlightAware every few minutes like described above.

*Edit: Doing some network maintenance and running some commands in the command line, it looks like port 8080 is sporadically getting through. Others have done port forwarding, or reverse proxies (I have done forwarding, not the reverese proxies in pfSense). I may explore that avenue next.

Curious how the pi is communicating to your network: ethernet. Or wifi?

Where it will be installed will only have wifi access (which is how I am testing it), ethernet seems to produce similar results when connected.

Make sure your Stick is connected properly to the USB port of your Raspberry. Squeeze the connector of the stick a bit to make sure it fits tight.

If that doesn’t work, try a different USB-Port.
You can also remove the Orange Stick for a while to check if this impacts the Blue stick.

To me it looks like the stick is losing the connect from time to time, therefore dump1090 is not able to gather data from it.

Try just the blue 1090 MHz dongle for now and get that working first.

Make sure you are using a decent power supply for your Pi, ideally the official Raspberry Pi Power Supply for that model. A third-party one may not be capable of supporting both dongles at once, or even a single dongle.

Check for any system messages relating to voltage problems by running the command in your PiAware terminal. Does it reveal anything?

dmesg | grep -i -C 5 "voltage"

You stated you have two SDRs, one for 1090 one for 978, Do you have both SDRs attached to the Pi? If so did you serialize them? It also looks like you didn’t configure for UAT as your status screen is missing the 978 UAT Radio status tile.

1 Like

Antenna placement is very important I do agree with that. With the prior setup I had used the same antennas with success on receiving packets up to 250-300 miles away which is not terrible for the first floor inside a Condo (restricted from putting antennas outside by HOA - current “Permanent” antenna is in the garage which has worked very well for the past year and a half until I updated! While I am troubleshooting I have to have it tethered).

Just a side note here, but if you live in the US and you have an outdoor location connected to your condo that is for your exclusive use, such as a patio, balcony, etc., then thanks to the Over-The-Air Reception Devices Rule you are permitted to put up an antenna to receive broadcast television signals (including satellite), as well as other signals. While there are limitations on this “right” to put up an antenna, there are lots of ways you can use your “exclusive” space to set up what you need to receive such signals. Co-locating an ADS-B receiver with a TV antenna could get you around your HOA restrictions. The onus is on your HOA to prove that their requirements aren’t burdensome, and the rules heavily favor residents in most circumstances.

ADS-B antennas are not covered by this law by name, but could be interpreted to be based on how Flight Aware and especially SkyAware work. You may be restricted from, say, drilling into the side of the building or extending the mast beyond the exterior walls. There’s a mast height limitation. It doesn’t give you access to community areas (e.g. a community garden or a hallway) or the roof. If there is an existing “community” TV antenna that you can access, then your HOA could require you to use that. There are other limitations to the rule, which you can read about in detail here.

Apologies for the long follow up, but, tried a few things this evening as suggested.

@foxhunter Connector is secure. I had a USB extender connected between the dongle and RPi and removed that, plugging straight into the RPi - this symptom was similar to what I had on my Odroid N2+ as well, would connect, then disconnect, then repeat. I have primarily been using the blue dongle as that is intended for the 1090 in my setup with the filters as I am in a very RF noisy environment (the amount of interference I get on ham bands is equally a challenge).

@chrislfa & @kmm0000 I do have two SDR’s, right now I only have the one SDR attached. The software installed is a fresh install with no modifications other then wifi information as on the FlightAware site. I figured once I got the 1090 side of things working I could dabble in the UAT side. I had previously had them serialized on the Odroid N2+.

As for power, I am using the RPi official brick that came with the unit. I am unable to remote into the device (cant get the " or | to work on the RPi), but at least from what I can tell in command line nothing looks out of the ordinary.

The only other abnormality is when plug in the ethernet cable I get eth0 stating down. Which I know the cable works. I have a suspicion port 8080 that FA is trying to use is causing some of the issue as doing some port testing, I got a failure on that side of things. As there are a few other ports that FA uses that I would rather not open to the general web, I am exploring how to implement a reverse proxy for the device (this method looks like it has worked for others while maintaining network security).

I did the following test:

grep RECEIVER_SERIAL /etc/default/dump1090-fa 

rtl_test -t  

And got - which seems acceptable:

Found 1 device(s):
  0:  Generic, RTL2832U DVB-T, SN: 00001090

Using device 0: Generic RTL2832U
usb_claim_interface error -6
Failed to open rtlsdr device #0.

I then stopped dump1090-fa, and did rtl_test -t -d 0 and got:

Found 1 device(s):
  0:  Generic, RTL2832U DVB-T, SN: 00001090
  
Using device 0: Generic RTL2832U
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 
[R82XX] PLL not locked!
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.

@fhmiii Good to know on the antenna front!

Thank you!

Hi,

When running rtl_test, the “-t” command does NOT mean test. It is actually a switch designed to test some of the older, original RTL devices. The older E4000 tuner devices had a small gap in coverage, and that switch would allow you to display where the gap was. When you specify “-t” with your R820T, that gives the warning message you show, and also inhibits the actual test.


pi@raspberrypi:~ $ rtl_test --help
rtl_test: invalid option – ‘-’
rtl_test, a benchmark tool for RTL2832 based DVB-T receivers

Usage:
[-s samplerate (default: 2048000 Hz)]
[-d device_index (default: 0)]
[-t enable Elonics E4000 tuner benchmark]
[-p[seconds] enable PPM error measurement (default: 10 seconds)]
[-b output_block_size (default: 16 * 16384)]
[-S force sync output (default: async)]

Just run “rtl_test” by itself, and it will run a test on the default device. Normally when testing a device used for ads-b, I also specify the “-s 2400000” option, to sample at the 2.4 MHz sample rate dump1090-fa and most of the other versions of dump1090 sample at. Dump978 samples at a slower rate.

Good luck,
-Dan

@MC130E I appreciate the insight! The more I learn about the capabilities of the pi’s the more impressed I am with the capabilities. I had previously used the “-t” command when attempting to use another SDR, I believe a NESDR SMArtee SDR for 978 Rx. That did have a E4000 tuner if memory recalls (have a few SDR’s could easily be confusing it). I will keep in mind dropping the “-t” going forward.

Bright side, since my last post I managed to sort out the port issue on my network (I think), and data seems to be processing much smoother now. I also reflashed the microSD card, and ran Sudo apt update which had a significant number of updates (and it updated to PiAware 9.0.1). I got dump978 installed, both seem to communicate (as best as they can where they are located), but I believe I switched intended devices around, which is not the end of the world, I can change those easily enough. Fingers crossed, it should be stable. Get RDP or SSH installed, button up testing and deploy it and should be good to go!

Thank you everyone for your assistance.

Hey your stats are looking better now, you’ve got both dongles recognised and some reception on the 1090 stick. Once you’re happy it’s stable you can play with the antennas as zoomie38 mentioned. If it’s not working out, I would once again take the 978 dongle out the equation and focus on trying to get the 1090 dongle working reliably and with decent reception, then again for the 978 once you’ve proven that it works. Keep at it and most of all have fun experimenting.

Appreciate it!

Good stopping point for this evening while it works! The culprit appears to have been the network 5GHz vs 2.4GHz, and updates.

Little more tweaking and we should be good to go! I appreciate the help.

Looking at your stats page, it shows all your reception is within 50 miles. Are you sure your coax has a good connection to the antenna?
I know it sounds silly but, if you have no antenna at all, you will still receive some nearby aircraft. In my setup for example, if I forget to turn on the LNA I can still receive nearby aircraft – that’s like having no antenna. Also, as others have suggested, try to get 1090 MHz working first without 978 MHz. Good luck.

Just got RDP installed, and set up the kit in a window with a view of the sky, considering the antenna is connected directly to the USB dongle, there is not any coax between the device and antenna. Normally with my final setup I was getting around 250-300 miles (which for being in my garage is not terrible - with some heavily shielded cable it was good). If it works tonight and tomorrow I will try putting it in its final location. Not sure what is going on with the 978 MHz setup.

Thank you to everyone for all your help, and a Happy New Year! Finally got everything mounted, and in its final “home”. 978 UAT is installed and on a separate stick but I am getting nothing for signals. Open to suggestions!

UAT is for those planes flying under 19,000 ft. It is mostly local fliers with their own planes as I understand it. Not much traffic in a good day, and often nothing during the evening / nite times. Hand in there, and if your system is working you should start seeing results in the next couple of days. Have fun with your new systems.
Gene

Just for comparison, when I was running a UAT dongle, positions reported from 1090Mhz were between 150 and 300 to 1. That is, if I was reporting 150,000 ADS-B positions that day, I might have reported 500 to 1,000 UAT positions. That despite UAT being mostly local, low-flying aircraft out of nearby general aviation fields.