snstac / adsbxcot Goto Github PK

I have notice you have the US and CAN mil Hex codes.
The UK HEX codes for military AC are
43C000 - 43CFFF

Hope this helps

Using adsbxcot with TAK Server 4.2 and both ATAK and WinTAK EUDs, airplanes appear to be going in 'slow motion'.

I have run an adsb rpi system for almost a decade. can we do this locally and not using adsbexchange.com

provided by ADSBExchange.com and requires an API key from that service

Try to align with adsbcot which uses FEED_URL.

Per classes.py, line 103:

                        if filter_key and filter_key in a_known_craft[self.known_craft_key].strip().upper():

Unfortunately that will match a filter_key of 441F to a a_known_craft[self.known_craft_key].strip().upper() of 441FA.

Instead what we should do is be explicit with something like:

                        if filter_key and filter_key is a_known_craft[self.known_craft_key].strip().upper():

Assuming the filter_key and a_known_craft[self.known_craft_key].strip().upper() are "clean" inputs (that is, no special characters inserted by the dump1090 decoder and a good-faith effort on the end-user on normalizing their filter data (e.g. no spaces/newlines/special characters/ALL CAPITALS/NO TRICK SPELLING).

https://www.youtube.com/watch?v=gSJeHDlhYls

https://www.youtube.com/watch?v=nzUY6Iiur6E

This feature was added for a special project last year, the use case was to 'only show SAR missions below a certain altitude'. Revive and integrate this feature.

adsbxcot & pytak require some additional packages and libraries on CentOS, to install:

1. Build tools (gcc, et al):

sudo yum groupinstall 'Development Tools'

2. Python Library headers:

sudo yum -y install python3-devel

Fresh install with pip3 after a working install of adsbcot.

Comamnd:
adsbxcot -A https://adsbexchange.com/api/aircraft/v2/lat/xx.xxxxx/lon/xx.xxxxx/dist/100/ -X XXXXX-XXX-XXX-XXXXXX -I 20 -U 192.168.1.XXX:8087

Output:
File "/home/tak/.local/lib/python3.8/site-packages/pytak/functions.py", line 84, in protocol_factory
return reader, writer
UnboundLocalError: local variable 'reader' referenced before assignment

It seams that protocol_factory is not entering any of the IF / elif statments and returing reader which has not been assigned.

From a user:

It looks like all headings are off by some fixed offset between the Magnetic heading and the on-icon caret

Per https://www.dev.adsbexchange.com/version-2-api-wip/:

track: true track over ground in degrees (0-359)

Per CoT Spec:

The track element specifies direction and speed of travel. It has two required attributes: course and speed. It also has optional attributes for specifying the vertical component of the motion vector (slope) and errors associated with course, speed, and slope.
Course denotes the direction of motion and is specified as the number of degrees measured clockwise from true North. Speed is specified in meters per second as speed over ground.
There is no constraint on the precision used for these values.

TISB tracks from Airport Surveillance Radars include vehicles and clutter up the map. Adding a flag to exclude any TISB tracks with an altitude of Ground would be helpful to clean up the map.

Use alternate altitudes if Baro altitude can not be derived from the ADSB message. Some TISB or MLAT messages do not provide the same altitude field as standard ADSB messages. If the preferred field is not available, substitute with what is available and add a remark to the CoT.

Steps to reproduce:

1. Set a search area to a place unlikely to have any aircraft flying in it, say where you are within one nautical mile in the middle of the night.

Expected results:

1. Script will continue to poll and if any aircraft do enter that space, it'll do the adsbxcot thing.

Actual result:

1. Script raises an Exception.

$ adsbxcot -U udp:127.0.0.1:8087 -A https://adsbexchange.com/api/aircraft/v2/lat/34.4487586/lon/-116.9369205/dist/1/ -X xxx -I 60
2021-08-26 22:31:54,463 pytak INFO - Running EventReceiver
2021-08-26 22:31:54,463 pytak INFO - Running EventWorker
2021-08-26 22:31:54,463 pytak INFO - Running ADSBXWorker with URL 'https://adsbexchange.com/api/aircraft/v2/lat/34.4487586/lon/-116.9369205/dist/1/'
Task completed: <Task finished name='Task-4' coro=<ADSBXWorker.run() done, defined at /Users/gba/Dropbox/Projects/TAK/src/adsbxcot/adsbxcot/classes.py:158> exception=TypeError("object of type 'NoneType' has no len()")>
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-4' coro=<ADSBXWorker.run() done, defined at /Users/gba/Dropbox/Projects/TAK/src/adsbxcot/adsbxcot/classes.py:158> exception=TypeError("object of type 'NoneType' has no len()")>
Traceback (most recent call last):
  File "/Users/gba/Dropbox/Projects/TAK/src/adsbxcot/adsbxcot/classes.py", line 184, in run
    await self._get_adsbx_feed()
  File "/Users/gba/Dropbox/Projects/TAK/src/adsbxcot/adsbxcot/classes.py", line 155, in _get_adsbx_feed
    self._logger.debug("Retrieved %s aircraft", len(aircraft))
TypeError: object of type 'NoneType' has no len()

Culprit:

https://github.com/ampledata/adsbxcot/blob/49718e0f004be040fb2712952464ccec4ba8e19a/adsbxcot/classes.py#L154

We don't check that 'ac' exists before calling len().

Documentation lists adsb.fi as a supported aggregator but it appears their messages are in a slightly different format.

Example: https://api.airplanes.live/v2/point/38/-78/25
{ "ac": [ { "hex": "ac2f18", "type": "adsb_icao", "flight": "SWA5633 ", "r": "N8840Q", "t": "B38M", "desc": "BOEING 737 MAX 8", "ownOp": "SOUTHWEST AIRLINES CO", "year": "2023", "alt_baro": 34000, "alt_geom": 33625, "gs": 295.3, "track": 220.05, "baro_rate": 0, "squawk": "7025", "emergency": "none", "category": "A3", "nav_qnh": 1013.6, "nav_altitude_mcp": 34016, "nav_heading": 246.8, "lat": 37.919632, "lon": -78.055699, "nic": 8, "rc": 186, "seen_pos": 0.353, "version": 2, "nic_baro": 1, "nac_p": 10, "nac_v": 2, "sil": 3, "sil_type": "perhour", "gva": 2, "sda": 2, "alert": 0, "spi": 0, "mlat": [], "tisb": [], "messages": 4214, "seen": 0.4, "rssi": -15.7, "dst": 5.499, "dir": 208.7 }, { "hex": "ad6ecd", "type": "adsb_icao", "flight": "AVA077 ", "r": "N965AV", "t": "A20N", "desc": "AIRBUS A-320neo", "ownOp": "BANK OF UTAH TRUSTEE", "year": "2022", "alt_baro": 28000, "alt_geom": 27475, "gs": 315.9, "track": 219.99, "baro_rate": 64, "squawk": "7023", "emergency": "none", "category": "A3", "nav_qnh": 1012.8, "nav_altitude_mcp": 28000, "lat": 37.980194, "lon": -77.991301, "nic": 8, "rc": 186, "seen_pos": 0, "version": 2, "nic_baro": 1, "nac_p": 10, "nac_v": 2, "sil": 3, "sil_type": "perhour", "gva": 2, "sda": 2, "alert": 0, "spi": 0, "mlat": [], "tisb": [], "messages": 3610, "seen": 0, "rssi": -15.8, "dst": 1.236, "dir": 159.1 } ], "msg": "No error", "now": 1708203924153, "total": 2, "ctime": 1708203924153, "ptime": 0 }

Example: https://opendata.adsb.fi/api/v2/lat/38/lon/-78/dist/10
{ "now": 1708203928.719, "aircraft": [ { "hex": "ac2f18", "type": "adsb_icao", "flight": "SWA5633 ", "r": "N8840Q", "t": "B38M", "desc": "BOEING 737 MAX 8", "alt_baro": 34000, "alt_geom": 33625, "gs": 295.3, "track": 220.05, "baro_rate": 0, "squawk": "7025", "emergency": "none", "category": "A3", "nav_qnh": 1013.6, "nav_altitude_mcp": 34016, "nav_heading": 246.8, "lat": 37.914505, "lon": -78.061134, "nic": 8, "rc": 186, "seen_pos": 0, "version": 2, "nic_baro": 1, "nac_p": 10, "nac_v": 2, "sil": 3, "sil_type": "perhour", "gva": 2, "sda": 2, "alert": 0, "spi": 0, "mlat": [], "tisb": [], "messages": 30708950, "seen": 0, "rssi": -9.3, "dst": 5.85, "dir": 209.4 }, { "hex": "ad6ecd", "type": "adsb_icao", "flight": "AVA077 ", "r": "N965AV", "t": "A20N", "desc": "AIRBUS A-320neo", "alt_baro": 28000, "alt_geom": 27475, "gs": 315.1, "track": 220.11, "baro_rate": 0, "squawk": "7023", "emergency": "none", "category": "A3", "nav_qnh": 1012.8, "nav_altitude_mcp": 28000, "lat": 37.975267, "lon": -77.996541, "nic": 8, "rc": 186, "seen_pos": 0.085, "version": 2, "nic_baro": 1, "nac_p": 10, "nac_v": 2, "sil": 3, "sil_type": "perhour", "gva": 2, "sda": 2, "alert": 0, "spi": 0, "mlat": [], "tisb": [], "messages": 17540559, "seen": 0, "rssi": -9.1, "dst": 1.494, "dir": 173.7 } ], "resultCount": 2, "ptime": 0.02 }

Adsbfi does use a format that works for https://opendata.adsb.fi/api/v2/mil

Is it worth updating get_adsbx_feed to allow for "aircraft" in addition to "ac"?

With TAK now allowing 3D viewing of COTS I have done a streaming KML with this type functionality. Looking through this code it looks like it does LAT an LONG but not ALT. is that something you can add? we would really like to implement this way with our TAK server as we would not have to setup each user with a streaming KML. Also is it possible to get the icon to point in the direction that the aircraft is traveling?

Make all icao hex codes that are preceded by “~” show as a-u-A for consistency.

Forgot to add a script attribute to setup.cfg

Current callsign PAT0166-TAIL-TYPE.

Add macro ability for remarks, ie: PAT0166-140AVN

The macro add remarks, as in 140AVN.

Add a column for custom remarks to add to the Remarks Element of the CoT. ie OV-22 Air2Air Freq in the remarks.

https://www.adsbexchange.com/version-2-api-wip/

alt_baro: the aircraft barometric altitude in feet
alt_geom: geometric (GNSS / INS) altitude in feet referenced to the WGS84 ellipsoid

MLAT traffic tracks do not have the API alt_geom populated. This results in a CoT hae="9999999" value and does not work for 3D awareness.

For MLAT traffic tracks, if alt_geom is not populated, fail down to use alt_baro value, and calculate HAE based on:

Request a normal ADS-B aircraft with alt_geom within 25 NM of MLAT traffic of interest, compare the full ADS-B aircraft's alt_geom to alt_baro to calculate offset to apply to the MLAT target's alt_baro to get the missing alt_geom. Then use this "CALCULATED" geometric altitude in place of a missing alt_geom API value.