Do I Need A Filter?

It’s all described in detail right at the top of this thread.

I don’t have a PC running Windows and even if I did, I’d have to raise it up the mast to run it. Neither of those are practical options.

I’ll have a look, thanks.

Hi Jon - I realize your post is 2 years old but I’m hoping you remember your changes for 978. If so, can you post them?

I have a new setup that doesn’t quite work well. I live close to a cell tower (I’m searching for it’s Tx/Rx frequencies). And I live close to 3 GA airports. But I can only see planes within 2-3 miles. So I am worried about interference… (either that or I have bad coax or a bad antenna or a bad something!)

Jon

I run the newer dump978-fa. So much simpler and more reliable to run.
I haven’t managed to get an airspy to work well yet.
I currently use a V1 rtl-sdr with hardwired bias-t and a mast mount uputronics 978Mhzamp /filter, DPD antenna and a custom cavity filter(between the antenna and amp). I did run a pro stick(non-plus) with a custom 978Mhz cavity filter (and using a metal dongle case due to the interference)

Run wiedehopf’s graphs scripts to give you some idea of the range and signal levels

Remember that UAT/978Mhz aircraft tend to fly low. I barely get >90NM

Don’t ask me why I have lots of aircraft at max range.

It looks like you have 1090Mhz and 978Mhz on the same piaware so I can’t see what your range is like. Do you get any mlat timing errors? This could mean that the single USB 2.0 bus (on all RPI’s including the 4) is overloaded.

A metal case (for the RPI and dongles) could reduce noise(if that is your problem). I use 6" quality USB 3.0 extension “pigtails” as the RPI USB ports are too close together.

What is your setup like?

I’ve got wiedehopf’s graphs scripts up & running:

Not sure since I’m not really sure where to search for mlat timing errors. I search thru the logs below and did not find anything:

cat /var/log/syslog | grep mlat
cat /var/log/daemon.log | grep mlat
cat /var/log/auth.log | grep mlat
cat /var/log/messages | grep mlat

Similar. A blue FA Pro Stick Plus. An orange FA Pro Stick. Two quality USB 3.0 extension pigtails. Plugged into a RPi2B. The 1090 MHz antenna is in the attic. And the 978 MHz antenna is in the window about 3 feet away (and waiting for me to finish testing before going in the attic)

I am probably not the right person to add meaningful comments to this. The Uputronics 978 SAW filter and LNA that @jonhawkes2030 is using, and that I am using also (see my 978 site at https://flightaware.com/adsb/stats/user/thespeedycab#stats-101147) adds 13dB of gain. I am running an orange FA stick, and my 978 gain is at 19. I have had it as low as 14. It appears that lower gain is better for UAT (note: this is not necessarily the case for 1090, and many threads explore this topic). Here is my wiedehopf range graph for UAT:

1 Like

I’d be happy with a median distance of 29 nm! Where is your antenna and how high is it?

My antenna is on a 10 ft pole on my chimney. Two story house.
Maybe 40-50ft AMSL.
I have a ridge to my east that blocks a lot of traffic. Apartments block a lot of traffic to the south.

I just found lots of mlat entries in /var/log/piaware.log but no errors or warnings.

More weirdness!

If I view http://piaware/skyaware978 I see a plane, and its Tracks, at a distance of 0 nm to 4 nm.


Yes this (above) is really the UAT page!

BUT if I view http://piaware/tar1090 I see the same plane, and its Tracks, at a distance up to 25 nm.


This (above) is the tar1090 page.

Does this seem right?!?

I think instead of worrying about filters and interference I may want to (need to) rebuild…

I ran this on the receiver in my loft which is a Pi3B+ and a Pro Stick Plus. It’s a lot lower than my main outside feeder.

I have the RTL-SDR-LNA outside which I believe is filtered.

From this, I think I probably don’t need any additional filtering.

No, you do need additional filtering. See the cut-out 920~960 mhz. GSM900 present.

It’s not loud, it’s strong but not excessively and there’s no co-channel interference up at 1090MHz.

If you are using the filtered rtl-sdr LNA … the scan would look quite different compared to the Prostick+.

Your wording isn’t quite making clear that you already have plenty of filtering …

I did say that I don’t think I’ll need any additional filtering :slight_smile:

I rebuilt everything and things are starting to make more sense. I moved the 978 MHz UAT FA gain antenna from a bedroom window and up into the attic. And I went from very few planes to more planes! Yay!

Now I’m back to filters!

I ran the test above:

rtl_power -d 00000978 -f 800M:1200M:100k -i 30 -c 50% -e 30m -g 30 -F 9 > scan.csv

and got these results:

2020-02-04_at_15.34.32-scan

EDIT: added entire scan for reference:

To me this looks like a filter is needed for the orange FA Pro Stick. Does this sound right?

YES

EDIT: Think i found the answer in the FR24 forums…just change to

sudo apt-get install python-pil

Will know in about 30 minutes…thanks!

I get this error:

pi@piaware:~ $ sudo apt-get install python-imaging
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package python-imaging is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
python-pil

E: Package ‘python-imaging’ has no installation candidate

Running PiAware (SD Card) 3.8.0. Buster.

Thanks!

Yes, I am aware of it, but I cannot edit/update the howto (1st post) as it was created over 2 years ago, and this forum does not allow me to edit/update posts older than few months. :frowning:

Anyhow when trying to install python-imaging, the error message tells that python-pil is the replacement for python-imaging, so most of users will install python-pil after seeing this warning.

1 Like

It’s all good. I’m glad you and many others are active elsewhere.

I’ve got something else going wrong, gonna have to dig into this when I have time. Entire scan looks like this:

I found that same pattern when I used very low gains, see the end of that post. It looks like a moiré pattern interaction between the sampling of the scanning and the low signal level at low gains. It went away for me at even slight gains since the signal dominated. Either way it’s an artifact of the sampling and rendering in that form when signal is very low.

If you’re seeing it when you expect to be seeing signal it implies that the scanning software isn’t seeing the signal data. You may also find that certain gains just have the right ‘beat’ interaction with the sampling and render to produce them. You should still see signal clearly when there is some.

1 Like