TL;DR Call not present in Rest API data for some aircraft. Help! I'm using the Rest API to obtain data on some local aircraft and plot them on a Google map. I'm also providing a feed to ADSBX using a Raspberry pi and the ADSBX image. Some aircraft do not populate the 'call' field in the JSON data. It's just not there but otherwise the JSON data is correct and complete. HOWEVER ... on my local instance of 'tar1090' the call is definitely present. In other words, I'm receiving a valid ICAO from the aircraft (on 1090 MHz), displaying it on my local tar1090, ostensibly feeding the valid ICAO to ADSBX, but when I get it back on the Rest API feed there's no 'call' in the data, just ICAO. How can this be? I cannot figure rhyme nor reason which ones will fail to show a call. Moreover, this may be intermittent (varying from day to day) as I've seen one particular aircraft (ICAO A2B5F0) have this problem a few minutes ago but I'm quite certain the call (N274GB) was present on other occasions. Thanks for any insight into fixing this.
tar1090 displays the registration or icao hex with an underscore added to the start instead of a callsign if no callsign is available. That's only done for labels and the table on the right to help identify aircraft. The aircraft details will show no callsign when there is no callsign. Maybe you got mixed up by that? Oh one more thing, even if the callsign is old, the webinterface will still show it even though it's not been heard for a long time. So i doubt check your local json. The API is at the moment still based on VRS ... so it's possible it's an issue with that. It will be converted to the new readsb based aggregation, so when that happens the API and https://tar1090.adsbexchange.com/ should show the same information.
Thank you, wiedehopf. Don't you ever eat or sleep? I did check my local json (first thing) and it's definitely not there (blank 'call'). No underscores. tar1090 is working perfectly (both my local pi and the server at ADSBX). It's my vague recollection that dump1090-mutability (and others) convert ICAO to callsign for US registered aircraft. I say 'vague' because I read the source once but don't have it handy now. So 'call' is not transmitted via UAT or ES I think. I'm not very sure about anything I wrote in this paragraph except that the 'call' field is definitely missing in the JSON I receive from the Rest API. It's doing it right now for ICAO AE5751 but not 7 other aircraft I am receiving on the same Rest query. Ah ha! This must be it. I did not realize that; I thought ADSBX's association with VRS was dead, ended, fini. OK, that is not so -- not yet. I will quit banging my head again and wait for this "new readsb based aggregation" of which you speak. Thanks again, Joe
Not a database lookup: agreed. I maintain call is derived from the ICAO number. I need to find the dump1090 code I once saw that converted ICAO to call for various countries (USA and S. Korea come to mind). Edit: the code I'm referring to is in public_html/registrations.js of the dump1090-mutability-master repository on GitHub. Maybe we're confused on terminology: what I'm referring to as 'call' is really registration (e.g. N227JD) and not comm. radio callsign (e.g. United 1263). The JSON data 'call' field is the one I'm interested in. And besides, there's an "anonymous mode" for UAT (not ES) that doesn't transmit either 'call' or ICAO as far as I know. What I do know is that the 'call' field is occasionally blank on my Rest API feed.
https://www.adsbexchange.com/data/datafields/ In the aircraft.json it is called "flight": "flight":"CPA037"
My mistake: the 'reg' field is the missing one. In general aviation, the registration (N-number in the US) is commonly used as the callsign. Definitely not talking about the 'call' field. So the problem remains. Occasionally and for no discernible reason the 'reg' field in the Rest API is blank. And of course this screws up my software because it doesn't know to whom to attribute the latitude, longitude, groundspeed, altitude, etc. So the position report is discarded and that means there's no track for that particular aircraft.
I have an API key and noticed all the datafield values are strings instead of the appropriate data types (int, float64, bool, etc) like I see in FA's aircraft.json file, will the datfield formats change when the rest API gets updated or will they all remain strings?
