AIrNav FlightStick vs FA Pro Stick Plus

[foxhunter]

@GlynH

It’s been a while since l have played with Gain settings but I seem to recall when I reduced the gain the amount & range of aircraft seen reduced as did my position in the RadarBox UK Ranking slipping outside the Top 10 for the first time so knee-jerk reaction was to put it back to where it was! I’ll make this my first point of interest based upon what you knowledgeable guys are suggesting.

Using sites like Radarbox etc are not a good solution finding the best gain.
I would suggest checking with the method @wiedehopf documented on his wiki pages as suggested already.

Optimizing gain · wiedehopf/adsb-scripts Wiki (github.com)

Or this mega thread:
Thoughts on optimizing gain - FlightAware / ADS-B Flight Tracking - FlightAware Discussions

I am always doing it manually and not using the auto gain feature of dump1090.
A while ago i am using readsb only and set gain manually. I find it better than dump even if you have to manually set gain. But i am normally not a fan of too much automatism

Beside checking the graphs there is also a short command line in the wiki article above where you can check the values without waiting for too long.

[wiedehopf]

@GlynH

Well unless dump1090-fa enables Mode A/C by default I don’t have it enabled in the config and looking at SkyAware all 300+ aircraft currently listed are showing altitude but half-a-dozen of those might be missing speed, distance or heading if that is anything to go by?

It can be enabled via a network connection.
rbfeeder does that.

[keithma]

@foxhunter

If i am not wrong @keithma is usnig an FA stick on his second feeder:

Confirmed.

[abcd567]

@GlynH

Not sure why I should have two separate instances of lat/lon but the first instance goes to 5 decimal places where the second instance is to 6 decimal places which mirrors the entry in etc/default/dump1090-fa;

The source of 1st set of lat/lon is the settings you made in file /etc/defaukt/dump1090-fa.

The source of 2nd set of lat/lon is piaware, which obtains it from Flightaware server at login and stores it aslocation.env variable in it’s cache. The dump1090-fa picks these from there.

The following functions in file /user/share/dump1090-fa/start-dump1090-fa read lat & lon values from variable location.env stored in piaware cache.

if [ -f /var/cache/piaware/location.env ]
then 
    . /var/cache/piaware/location.env 
fi 

... ... ...
... ... ...
... ... ...

if [ -n "$RECEIVER_LAT" -a -n "$RECEIVER_LON" ]; then
    OPTS="$OPTS --lat $RECEIVER_LAT --lon $RECEIVER_LON"
 elif [ -n "$PIAWARE_LAT" -a -n "$PIAWARE_LON" ]; then
    OPTS="$OPTS --lat $PIAWARE_LAT --lon $PIAWARE_LON" 
fi

[GlynH]

Thanks for following up on this for me…it’s been a long day and I’m off to bed in a minute so will reply properly tomorrow.

I just wanted to pull another set of graphs by way of comparison after I reduced the gain from 60 to 42.1 to see if I am moving in the right direction and to see what you guys think…here we go. No prizes for guessing what time I reduced the gain;

SkyAware is currently showing the following at 11pm local time;
Aircraft: 109
Positions: 102
Messages: 1868.2

I’ll continue to monitor things over the next 24 hours to see what the 48 hour graphs show.

Thanks once again for your help & support in guiding me towards the optimum setup. This is still using the AN FlightStick which has been in use for the last two years so when I get a better understanding I will try the FA Pro Stick Plus with & without the dark blue 1090 filter to compare the two.

Thanks & kind regards,
-=Glyn=-

[foxhunter]

The numbers are looking better to me. You could even set the gain one or two steps lower ( 38.6 or 40.2)

@GlynH

Aircraft: 109
Positions: 102
Messages: 1868.2

These numbers still doesn’t match to me.
I doubt the messages of almost 1900 is still to high for 109 aircraft only. But - whatever…
As i don’t know the setting for dump1090-fa on disabling the Mode-A/C somebody else might need to help.

EDIT:
found it. You need to add -no-modeac to the config.
I’ve reported a similar thing last year here:

Dump1090 - Message rate too high in Skyaware

Since today i have the phenomenom that dump1090-fa is showing twice the amount of messages / second. This screenshot shows both of my receivers side by side: The upper one is my outoor receiver showing 513 Msg/sec The lower one is indoor and the one showing wrong numbers. With half the number of aircraft it should be around half of the other rate as well Earlier today i had numbers up to 1500/msg which is impossible and never seen before, especially not on my indoor receiver In addition gra…

But different to your setup it only showed the rates on the map, not in graphs. So it could be that your values are correct.

In this thread obj explained where to put the command line switch in the new dump1090 config format.

[wiedehopf]

@foxhunter

But different to your setup it only showed the rates on the map, not in graphs. So it could be that your values are correct.

The graphs are consistently lower than his value on the map.

The 1900 spike on the graph corresponds to 350 aircraft on the graph.
That’s a lot of aircraft in range. Which results in a high message rate.

I’m not certain but i think i did some improvements on the demodulation (and obj used some of those improvements and made some on top).
That was probably after most of the people posting message counts switched to an airspy.
So that could be another 50 to 100 messages i suppose …
The numbers aren’t surprising to me.
I’d be curious to look at his local map … see if there is noise coming through as aircraft or something like that. But i doubt it’s a lot.
It can contribute to the number on the map though (less usual to contribute much to the graph numbers).

Really if you’re gonna compare stuff, you need exactly the same decoder, somehow verify it’s not including bogus stuff … it’s pretty complicated.
Mostly the numbers tell you if you have more traffic / improved your receive chain somehow.
Comparing with others … the graphs aren’t perfect for that, especially with decoders using different approaches in some areas the results aren’t 100% comparable.

[foxhunter]

@wiedehopf

The 1900 spike on the graph corresponds to 350 aircraft on the graph.

I was referring to his statement above:
Aircraft: 109
Positions: 102
Messages: 1868.2

That i interpret at 1868 messages with 109 current aircraft on the map.

But i fully agree to you. Don’t make things bigger as they are.

[GlynH]

@foxhunter

Using sites like Radarbox etc are not a good solution finding the best gain.
I would suggest checking with the method @wiedehopf documented on his wiki pages as suggested already.

Optimizing gain · wiedehopf/adsb-scripts Wiki (github.com)

Or this mega thread:
Thoughts on optimizing gain - FlightAware / ADS-B Flight Tracking - FlightAware Discussions

I am always doing it manually and not using the auto gain feature of dump1090.
A while ago i am using readsb only and set gain manually. I find it better than dump even if you have to manually set gain. But i am normally not a fan of too much automatism

Beside checking the graphs there is also a short command line in the wiki article above where you can check the values without waiting for too long.

Yeah I know. I was using RB as a ‘quick & dirty’ method. Adjust gain/check ranking. As it slipped down after changing gain I just put it back to where it was!

I did read weidehopf’s github, the thread you referred to and more besides. I have even posted in some other thread(s) about gain showing graphs.

Like you I prefer to set things manually but only when I fully understand what I am doing!

@wiedehopf

It can be enabled via a network connection.
rbfeeder does that.

Ah I didn’t realise that. I do use rbfeeder. Is there a definitive way to see if rbfeeder has turned it on or if it is active? To foxhunters point I could add -no-modeac to the config but would rbfeeder still override that? Would be good to see the currently loaded state of modeac.

@wiedehopf

I’d be curious to look at his local map … see if there is noise coming through as aircraft or something like that. But i doubt it’s a lot.

Excuse my ignorance but is that as simple as just zooming in on my home location or is there another way of producing this?

Here is the last two days of charts if it helps;

To my uneducated eye the top chart looks very similar certainly not negatively impacted by lowering the gain. Obviously the ADS-B Signal Level is down but maybe that’s not a bad thing if the messages received are ‘clearer’ but there is a lot more fluctuation unlike the almost flat line in the previous 24 hours but maybe that previous signal is ‘topping out’ or something which may not be ideal?

Just groping around in the dark here until someone who really understands these things turns up and gives an educated opinion…

Thanks & kind regards,
-=Glyn=-

[wiedehopf]

@GlynH

Excuse my ignorance but is that as simple as just zooming in on my home location or is there another way of producing this?

You look at the list and check low message count aircraft in the list if they are actually in the area using a global service like adsbexchange.

Determining bogus messages coming in for legitimate aircraft are hard to detect really
But that’s usually not too terrible with the common decoders.

@GlynH

To foxhunters point I could add -no-modeac to the config but would rbfeeder still override that? Would be good to see the currently loaded state of modeac.

Yes, why would it be mentioned in this context if it didn’t do that?

[LawrenceHill]

@GlynH

Ah I didn’t realise that. I do use rbfeeder.

I use Planeplotter which also turns on ModeA/C messages on my installation with the ProStick plus…
My figures on the map and graphs are pretty close to what you get.
With Planeplotter running the graphs show about 1500 m/s whereas the map shows about 2300.
Stopping Planeplotter (thus turning off the ModeA/C) reduces the figure on the map to around 1500.
Planeplotter also shows the numbers of Mode S and A/C messages and this ties up pretty well (see attached), so it looks pretty convincing that the excess numbers shown on the map are due to ModeA/C

[foxhunter]

@GlynH

To foxhunters point I could add -no-modeac to the config but would rbfeeder still override that?

From my experience, RB does not do any changes to the dump1090 config. It obviously only relies on having the option explicitly mentioned.

I installed dump1090, then RB where the message jump started.
After i added the option to dump1090 config and restarted the service, it turned back to normal, even after a restart of RB

That’s my observation from my installation.
Looks like a readsb installation is not impacted because there is a switch to turn Mode-AC on, but it seem to be disabled per default if this option isn’t set

[wiedehopf]

@foxhunter

From my experience, RB does not do any changes to the dump1090 config. It obviously only relies on having the option explicitly mentioned.

No it relies on enabling modeac via the beast network connection.

Yeah readsb has this automatic enabling disabled …
This has come up often enough i consider changing the way tar1090 displays the message rate.
Or maybe work with obj to change both readsb and dump1090-fa to emit a message count that doesn’t include mode A/C messages.
But not sure he’d like such a change and … probably i’ll just forget about it as being not important

[foxhunter]

@wiedehopf

No it relies on enabling modeac via the beast network connection.

Yeah readsb has this automatic enabling disabled …

Or so…
That’s exactly what i meant. Another reason why i prefer readsb over dump1090-fa

@wiedehopf

probably i’ll just forget about it as being not important

Agreed. There are lot more of things in life way more important than an ADS-B message rate

[GlynH]

@foxhunter

found it. You need to add -no-modeac to the config.
I’ve reported a similar thing last year here:

Since today i have the phenomenom that dump1090-fa is showing twice the amount of messages / second. This screenshot shows both of my receivers side by side: The upper one is my outoor receiver showing 513 Msg/sec The lower one is indoor and the one showing wrong numbers. With half the number of aircraft it should be around half of the other rate as well Earlier today i had numbers up to 1500/msg which is impossible and never seen before, especially not on my indoor receiver In addition gra…

But different to your setup it only showed the rates on the map, not in graphs. So it could be that your values are correct.

In this thread obj explained where to put the command line switch in the new dump1090 config format.

Ah…so starting to make sense now…thanks foxhunter. Despite dump1090-fa not enabling mode a/c it seems like AirNav have sneakily enabled it by sending the command across the network by stealth. Sounds like the kind of thing AN would do as they have previous form on overriding user preferences to send data…I wonder what they are doing with MY data this time?

A quick
jq < /run/dump1090-fa/stats.json '.total.local'
returns;

{
  "samples_processed": 407824629760,
  "samples_dropped": 0,
  "modeac": 70186894,
  "modes": 2725158433,
  "bad": 1098770878,
  "unknown_icao": 1105093835,
  "accepted": [
    232700323,
    8651569
  ],
  "signal": -14.1,
  "noise": -24.4,
  "peak_signal": -0.4,
  "strong_signals": 1302636

So Mode A/C is definitely turned on despite my not enabling nor being aware of it.

I have tried putting NO_MODEAC_AUTO=yes in EXTRA OPTIONS as suggested by obj but that seems to stop dump1090-fa from running altogether?

Looking at my dump1090-fa where should I insert either NO_MODEAC_AUTO=yes or --no-modeac-auto or -no-modeac (which one is it?) for it to work as expected please?

Also looking at that same file should I comment out those lines that don’t have a value and should I remove the second occurrence of my lat/lon under EXTRA OPTIONS?

To make things easier (I hope) here is my dump1090-fa below;

# dump1090-fa configuration
# This is sourced by /usr/share/dump1090-fa/start-dump1090-fa as a
# shellscript fragment.

# dump1090-fa won't automatically start unless ENABLED=yes
ENABLED=yes

# SDR device type. Use "none" for a net-only configuration
RECEIVER=rtlsdr
# serial number or device index of device to use (only needed if there is more than one SDR connected)
RECEIVER_SERIAL=""
# Initial receiver gain, in dB. If adaptive gain is enabled (see below) the actual gain
# may change over time
RECEIVER_GAIN=42.1

# Adjust gain to try to achieve optimal dynamic range / noise floor?
ADAPTIVE_DYNAMIC_RANGE=no
# Target dynamic range in dB (leave blank to autoselect based on SDR type)
ADAPTIVE_DYNAMIC_RANGE_TARGET=
# Reduce gain when loud message bursts from nearby aircraft are seen?
ADAPTIVE_BURST=no
# Gain range to allow when changing gain, in dB (empty = no limit)
ADAPTIVE_MIN_GAIN=
ADAPTIVE_MAX_GAIN=

# Turn on options to reduce load on slower CPUs, at the expense of slightly worse decoder performance.
# Setting "auto" will enable these options only if the CPU appears to be a slow CPU (currently this
# means armv6 only, e.g. Pi Zero)
SLOW_CPU=auto
# Local wisdom file used to select DSP implementations; uses built-in ranking if the file is missing
WISDOM=

# Correct CRC errors where possible
ERROR_CORRECTION=yes

# Receiver location, used for some types of position decoding. Provide the location as
# signed decimal degrees. If not given here, dump1090 will also try to read a receiver
# location from /var/cache/piaware/location.env (written automatically by PiAware, if installed)
RECEIVER_LAT=
RECEIVER_LON=
# Maximum range, in NM. Positions more distant than this are ignored. No limit if not set.
MAX_RANGE=360

# Network ports to listen on for connections
NET_RAW_INPUT_PORTS=
NET_RAW_OUTPUT_PORTS=30002
NET_SBS_OUTPUT_PORTS=30003
NET_BEAST_INPUT_PORTS=30004,30104
NET_BEAST_OUTPUT_PORTS=30005

# Accuracy of location written to JSON output
JSON_LOCATION_ACCURACY=1

# Additional options can be added here:
EXTRA_OPTIONS=" --lat 52.****** --lon -1.******"

Thanks & kind regards,
-=Glyn=-

[GlynH]

@LawrenceHill

I use Planeplotter which also turns on ModeA/C messages on my installation with the ProStick plus…
My figures on the map and graphs are pretty close to what you get.
With Planeplotter running the graphs show about 1500 m/s whereas the map shows about 2300.
Stopping Planeplotter (thus turning off the ModeA/C) reduces the figure on the map to around 1500.
Planeplotter also shows the numbers of Mode S and A/C messages and this ties up pretty well (see attached), so it looks pretty convincing that the excess numbers shown on the map are due to ModeA/C

Yup…that’s exactly it Lawrence. As per my post immediately above a quick jq < /run/dump1090-fa/stats.json ‘.total.local’ shows “modeac”: 70186894 & “modes”: 2725158433 hits.

Just need to disable Mode A/C now when I figure out how to do it as my previous attempt was unsuccesful…

Thanks & kind regards,
-=Glyn=-

[GlynH]

Looking at my graphs now I can see that the number of Messages >3dBFS has dropped from around 15% to a new low of 0.6%

That must be good right?

To the expert eyes out there do the other graphs look better than before?

I’d be lost without you guys so thanks again for making this hobby of mine much more enjoyable and easier to use!

Thanks & kind regards,
-=Glyn=-

[foxhunter]

@GlynH

Ah…so starting to make sense now…thanks foxhunter. Despite dump1090-fa not enabling mode a/c it seems like AirNav have sneakily enabled it by sending the command across the network by stealth.

That’s not what i was saying.
My assumption is that dump1090-fa does not have the setting explicitly disabled but simply not used (that is different from each other) and the RB feeder client is using it. That has an impact to the numbers dump1090 is showing.

For readsb it is different, there you have to explicitly enable it, that’s why RB can’t use it silently.

[GlynH]

@foxhunter

That’s not what i was saying.
My assumption is that dump1090-fa does not have the setting explicitly disabled but simply not used (that is different from each other) and the RB feeder client is using it. That has an impact to the numbers dump1090 is showing.

For readsb it is different, there you have to explicitly enable it, that’s why RB can’t use it silently.

Actually it’s what I was saying!

Your explanation and real-world example told me that it is rbfeeder that is enabling Mode A/C across the network.

As I mentioned in my post AirNav has previous form of activating network data by stealth. I remember many years ago 2008/2009 when using the RadarBox hardware and PC app that one of the options in Preferences was to Share Flight Data on RadarBox Network.

There was a discussion around this at the time when it was discovered that for those who turned it off and saved their own user preferences the very next time you loaded RadarBox it was mysteriously turned back on again! So much for user preferences.

It left a bad taste in some users mouths and there were more than a few who decided to toggle it off from then on at every restart by way of protest at ignoring user preferences and syphoning data.

When I realised AirNav were doing a ‘similar’ thing by triggering Mode A/C I regressed 14 years! I don’t recall seeing anything about a recent version of rbfeeder suddenly deciding to change behaviour of dump1090-fa but then again I don’t recall looking for it specifically. Old habits die hard it seems but AN have a long of history of doing things ‘differently’.

Sorry for the misunderstanding.

Whichever way I cannot disable Mode A/C from being triggered by rbfeeder. I have tried --no-modeac-auto, --no-modeac-auto=yes in various places in /etc/default/dump1090-fa and also in quotes after EXTRA OPTIONS all to no avail. I still see in excess of 2000 messages per/sec and jq < /run/dump1090-fa/stats.json ‘.total.local’ shows a large number of messages against modeac.

I am of course issuing sudo systemctl restart dump1090-fa after every edit but nothing seems to disable it. What am I doing wrong?

Thanks & kind regards,
-=Glyn=-

[foxhunter]

@GlynH

Your explanation and real-world example told me that it is rbfeeder that is enabling Mode A/C across the network.

Then you have read my explanation wrong

If it would be across the network, it would impact the other installed feeders as well…

I think there is no real “enablement”. RB simply use it what it found. And if Mode-A/C is not disabled, RB assume it’s enabled.
Similar to “If something is not explicitly forbidden, it’s allowed”