Is this field related to enhanced intent based surveillance? I don’t think my aircraft outputs that data, so it may have just been a fluke (though it matches the crossing restriction and preselector setting for that approach), but it made me wonder about the column I had never seen before.
Comm-B BDS4,0 “Selected vertical intention” responses (part of Mode S EHS)
The EHS data requires an interrogation from a SSR before the response is generated, unlike the ADS-B data which is spontaneously broadcast. In the US, very few SSRs interrogate for the EHS data, so this is more likely to be ADS-B data.
Both are intent-related. The exact link between what is set in the cockpit & what gets transmitted is poorly defined but it’ll usually track something like the next altitude the FMS is trying to achieve.
Wow, thanks for the info. It’s easy to forget with such a focus on ads-b that everything we are doing is on the SSR frequency and there is a lot more to mode-s than just ads-b positions/altitudes.
There is no doubt that the reported AP Alt was programmed as an FMS altitude and preselector altitude, so i may have to test it again soon to see if my aircraft is supports/reports more modes than i realized. The local facility does numerous PAR approaches for military birds, so their SSR may be more advanced than most
I did a little testing of this in-flight, and while all STC installs of GTN-750’s with GTX-345r transponders are a little bit different, my aircraft definitely broadcasts the FMS altitude to whichever military SSR is requesting it between Eglin/Tyndall/Sherman. I haven’t seen it much elsewhere, but I created “cross at” altitudes on the GTN-750 that were not assigned by ATC, the aircraft definitely transmits that data, and I can find it in flightaware.
So yes, some SSR’s request the AP Alt and my STC’d garmin install delivers that intent based data for EHS BDS4,0 extended surveillance.
Now the rhetorical question is, what else does it transmit that I didn’t know it was capable of?
I am about 45 nm to your east near KHRT Hurlburt Field, FL. I have been watching mode-s and ads-b in this area for many years. I suspect that the target altitudes you are seeing from your aircraft are actually part of the ADs-B DF17 messages as obj suggested, and not a response to any of the local radar sites.
I decode with dump1090-fa, but normally view my data using Planeplotter software. I never used to see those target altitudes (or headings) until planeplotter was enhanced last year to include the DF17 decoding of that data. The responses to radar site requests which Obj mentioned, has always been decoded by the planeplotter software. Those requests seem to be common in Europe, but not here in the US.
If you are using dump1090-fa and really curious about your local data, you can use view1090-fa to view and log to file just the transmissions from your aircraft. This will give you a log file of all mode-s and ads-b messages. It is not possible to identify your mode-a and mode-c responses since those are not identified by the aircraft transmission. Mode-a and mode-c data is very useful, but that is much more advanced.
Take a look at the command options for view1090-fa:
pi@piaware:~ $ view1090-fa --help
view1090 ModeS Viewer dump1090-fa 6.1~bpo9+1
–no-interactive Disable interactive mode, print messages to stdout
–interactive-ttl Remove from list if idle for (default: 60)
–interactive-show-distance Show aircraft distance and bearing instead of lat/lon
(requires --lat and --lon)
–interactive-distance-units Distance units (‘km’, ‘sm’, ‘nm’) (default: ‘nm’)
–interactive-callsign-filter Only callsigns that match the prefix or regex will be displayed
–modeac Enable decoding of SSR modes 3/A & 3/C
–net-bo-ipaddr TCP Beast output listen IPv4 (default: 127.0.0.1)
–net-bo-port TCP Beast output listen port (default: 30005)
–lat Reference/receiver latitide for surface posn (opt)
–lon Reference/receiver longitude for surface posn (opt)
–max-range Absolute maximum range for position decoding (in nm, default: 300)
–no-crc-check Disable messages with broken CRC (discouraged)
–fix Enable single-bits error correction using CRC
(specify twice for two-bit error correction)
–no-fix Disable error correction using CRC
–metric Use metric units (meters, km/h, …)
–show-only Show only messages from the given ICAO on stdout
–help Show this help
Using a command like below, you could output all data from a single aircraft (identified by hex mode-s code) to the screen: (replace A24C01 with your mode-s code)
The IP 127.0.0.1 and port 30005 are defaults and not required if running on the same device. The approximate lat/lon are only needed for decoding of ground positions and possibly distant first odd/even inflight positions.
To send all your data to a text file for reviewing later would look something like this: (for a military AE aircraft)
Like me, it looks like you are also lucky enough to have a nearby FAA transmitter site with both 1090 ADS-R/TIS-B and 978 ADS-R/TIS-B. My site is located within 3 nm of my home and I receive plenty of traffic being rebroadcast on 1090 that includes some 978 UAT traffic, and also positions for mode-a/c only aircraft. The rebroadcast on 978 includes both 1090 ads-b, 1090 mode-s, and also mode-a/c only aircraft.
Because of the frequent overlap, I like to view my 1090 and 978 traffic on different screens. The 1090 data often fills in gaps for the local military mode-s and mode-a/c only aircraft. The 978 data frequently includes low-altitude traffic I normally can not receive directly including 1090 ads-b rebroadcast.
This site might be dated, but correctly displays my local tower and indicates one is also at your airport. If correct, that explains why you can probably receive the 978 weather and other info while on the ground.