FAQ
Frequently Asked Questions
Last updated
Frequently Asked Questions
Last updated
Try the Search field in the top right corner. Everything explained to anyone once has been put into the documentation...somewhere...
LiveTraffic can only display traffic reported by the channels you selected. Please take the time to understand the . Do not compare what you see with LiveTraffic with any other flight tracking service, but only with the ones available to you. Coverage is not related to the size of an airport, but to the number and geographical distribution of ADS-B receivers that volunteers operate to share their data. Different services/channels have different networks of receivers they rely on. Coverage can therefor also change over time if such receivers are added or go out of service. So even if in the past you enjoyed good coverage at some airports, this can change any time!
The here in the documentations features a column labelled "Check Coverage" with links to where you can check the current live coverage for each channel. And right in X-Plane you can open the and find the same links there behind the button, in case of ADSBEx and OGN even automatically including your current position. If you think you are missing traffic, use these links and go check! I'm 99.9% sure that LiveTraffic displays all that is available as per the channels you configured in the .
If tracking data is limited at your current position, LiveTraffic is limited in what it can do. Approaching planes will try to land, but if tracking data on the ground is missing then they . To show planes taking off, LiveTraffic would need some tracking data on the ground. And that is the hardest to come by simply due to physics: A plane's ADS-B signal doesn't travel far when the plane is on the ground. To catch ground traffic data, there need to be receivers very close (<3nm) to the airport.
If you are interested in some more background on how LiveTraffic uses tracking data I recommend and FAQs further down.
Follow at a busy airport.
Make sure menu itemPlugins > LiveTraffic > Aircraft displayed is on, which is the default.
Open the (menu itemPlugin > LiveTraffic > Status / Information...):
Check the information on the 3rd tab, :
Check "Number of available CSL models": Should be more than 1. Otherwise go back to .
Make sure that the at least one tracking data channel is enabled, like OpenSky, and that it shows a reasonable number for "serving # aircraft".
If no channel is active go to Settings > Input Channels and enable some, at least .
Click on the link at the beginning of the line of that channel. That opens a web page giving you access to that channel's covergae. If the channel doesn't see anything, LiveTraffic can't either. (See for more on coverage.)
At the top of the page you see how many aircraft are "seen" (in principle mentioned in the received tracking data, which means that receiving data from the web works) and "shown live", which means they are actually displayed in LiveTraffic.
The on the 1st tab gives you all the details of received tracking data and displayed planes.
If you see yellow labels but no planes you are missing plane models: Go back to . Really do perform the validation recommended in the by looking into Log.txt.
Switch logging level to Debug in the and wait for 10 minutes, then take a look into Log.txt. There should be many lines like
OpenSky introduced a limit to the number of requests allowed per day. Make sure to register a user with OpenSky to significantly increase this budget. Otherwise, if there aren't other channels available, then traffic will indeed stop after some time depending on your refresh rate.
Log.txt file you keep talking about?Right in your main X-Plane folder, next to X-Plane.exe/.app.
Log.txt file?As of 25-APR-2019 the anonymous public access to ADSBEx data has been discontinued.
Version 1.10 of LiveTraffic stopped the ADSBEx channel with messages
HTTP response is not OK but 403 and
ADSB Exchange Live Online: Channel invalid and disabled after too many errors.
Since Version 1.15, if you don't enter an API key, the channel will be set invalid with message
ADS-B Exchange: API Key missing. Get one at adsbexchange.com and enter it in Basic Settings.
"Seeing" in this context means that there was one data point for an aircraft reported by the channels. Channels tend to repeat stale positions for a while before taking them out of the data stream. LiveTraffic certainly needs live data, at least two positions to have a track to fly. If there's lots of stale data then LiveTraffic believes to "see" many planes, but only few have moving data allowing to follow a flight path.
Remember to check coverage in your area before being disappointed of empty airports.
You Log.txt will tell you, look into it, search for "LiveTraffic"! The following 3 causes are the most often:
On Windows, if LiveTraffic doesn't start and the only thing about LiveTraffic that Log.txt contains looks like
.../win_x64/LiveTraffic.xpl : Error Code = ### ...
then
on X-Plane 11 win_x64/fmod.dll could be missing. This is shipped in the LiveTraffic.zip archive since version 3.2.0.
If you see something like
LiveTraffic 1551304182.7 ERROR src\LTAircraft.cpp:635/ReadFlightModelFile: Config file '.../FlightModels.prf' first line: Unexpected version LiveTraffic 1.0, expected 1.1...trying to continue
in your Log.txt and in the message area then you have probably only updated your LiveTraffic executables in the 64 folder, but not the other files. FlightModels.prf is quite important as it defines parameters of flight modelling. That's why LiveTraffic complains if it expects something newer.
Unfortunately, I don't have a Linux environment myself. And even then there are so many flavours out there that it is difficult to give definite answers for all of them.
The only distribution, which seems to work out of the box, is Ubuntu 18.04 (and many distros basing on it). For all others you may run into version conflicts with the CURL library.
The solution approach I would prefer is the following:
First time you see a security dialog saying "mac.xpl cannot be opened...":
Click [Cancel] in this security dialog.
Right away open your Mac's System Preferences > Security & Privay > General. At the bottom is should say something about "mac.xpl was blocked..."
Click [Open Anyway] or [Allow next time] there.
Now quit X-Plane after it finished loading.
Second time
Restat X-Plane.
If you now see a security dialog saying "mac.xpl cannot be opened..." then now an [Open] button is available. Click [Open].
From now on, X-Plane should start without complaining.
Technically yes, I could. For a long time, it was legally not allowed.
With the 90$/month "Essential paclage" your credits last a little over 10 times that long, 370 minutes or 6.1h.
Tracking data is not continuously updated as some people seem to believe. Even if you keep querying the servers every 10th of a second (which would be an unjustified burden on the often community-driven infrastructure) you'd receive the exact same response for a particular plane over and over again...only every 10 to 20 seconds there really is new data. Which is why Live Data Refresh defaults to 20s: more often doesn't provide more data.
From a single data point A it is impossible to derive a flight path. I could draw the plane into the sky, but wouldn't know where it is headed for. Keep in mind that LiveTraffic needs to calculate positions for each plane during each drawing cycle, so depending on your frame rates this makes 20-60 position updates per second per plane. And you want to see the plane move swiftly.
There is heading/speed info in the tracking data, but that is either derived data based on past observations or - even if it is broadcasted by the plane directly - it is just about what it is at that very moment at location A. Heading and speeds (horizontal and vertical) will all change after passing A. They are not a true and reliable vector to the next location B, which is 10 to 20 seconds later. And a plane travels far in 10 to 20 seconds (for example, 1.4nm in 20s at 250kt).
To calculate accurate positions along a path between A and B you'll need to know both A and B. So a plane can leave A only once we have also received B. The buffering time exists and is required to allow for all planes' B to be known before they reach/leave A.
Strictly speaking, even C would be necessary to compute at which heading and speed to arrive at B so we can smoothly without too sharp edges continue to C...and so on. The smoother the path, the more data is needed in advance. There is hundreds of lines of code about data smoothing in LiveTraffic because the tracking data can be extremely inaccurate and jumpy. And then LiveTraffic even needs to discard unreasonable data items. There's better something in the buffer to keep the plane flying then...
And then we haven't even talked about landing and take-off prediction...also complex matter as the two most important points in time of a flight, the moment of lift-off and the moment of touch-down aren't necessarily those points A or B mentioned above. LiveTraffic receives data points before touch-down and lift off and hopefully also points after that, but not for the precise moment, although this is the moment of a significant change in the flight regime. So where does the plane lift off or touch down? And at which speed? How quickly does the plane accelerate or decelerate? When does it rotate or flare? How steep does it climb after lift-off? You'll need a few points along the take-off path in advance to calculate all that.
There is currently no option to read historic data from other sources like files or databases.
There once was an option to read historic ADS-B Exchange data. The code is still in, just the settings to access it are removed. (Even the dataRefs to control access are still in, so it could be activated using a DataRef editor.) The conditions, under which one could request historic data files from ADS-B Exchange have changed quite a bit since the code came into being. Nowadays, ADS-B Exchange does not provide historic data just for the fun of flight simulation, but only for scientific purposes. So I can't get historic data any longer and hence have no chance to maintain the functionality.
There are 2 known explanations.
Certainly, available models depend on the CSL packages you have installed. LiveTraffic can only render what's available as a CSL package. Install more package for better model coverage.
Here is an example of a default rendering (A320) for an object which likely is a C172S:
You will see a warning in Log.txt like this of there is no ICAO aircraft type available:
And would not happen in similar cases either as of LiveTraffic 1.22 as the include model text "172S" would successfully be mapped to ICAO aricraft type designator C172, which now produces message like this
But there will still be cases out in the wild with no designator and no (matching) model text, and then you'll still see an A320.
the ICAO type received, or "?" if none has been received,
Manufacturer and Model as human-readable free text fields as sent by the network channels,
the CSL model actually used to render the aircraft.
Yea...it happens...a special case of the above issue of a "wrong model". To understand this issue it is necessary to have a bit a background of how LiveTraffic got to display follow-me cars in the first place:
Some ground traffic (this will extend beyond follow-me cars) also has ADS-B transponders on board and this way transmit their positions. In reality, this will help ground control gathering a more complete picture of what is happening on the ground and avoids crashes between ground traffic and actual planes.
So, there is tracking data of ground traffic in the stream of data received from the various channels. In some channels like OpenSky they can most often be very easily identified by some text in some of the message fields. In other channels, and also in some cases at OpenSky, it is pure guess work if that data originated from ground traffic or not. If none of the plane type identifying fields is filled then LiveTraffic will often decide for "ground traffic" and will display the follow-me car.
Apparently, there are a few cases of planes, which are also missing relevant model information in the databases OpenSky and ADSBEx tap on. And so it might happen that for these actual planes LiveTraffic's guess work decides for ground traffic. It will do so only for objects on the ground, for sure. But if that object on the ground then taxis to a runway and speeds off...then we have a flying follow-me car.
The follow me car that you can also see in the above screenshot is the only CSL model shipped with the LiveTraffic package and therefor is always available. If no other CSL models are (successfully) installed then LiveTraffic can only use that single model and will fall back to it for anything it wants to show.
So if you simply don't have the right aircraft/livery combination in your CSL packages then LiveTraffic decides for any random livery of that plane model.
If you want to paint a new livery the community would be thankful! Front-to-back there is certainly way more to explain than what fits into a small FAQ. But here are two/three places to start with:
This process is called "matching" and works based on 3 parameters coming in through aircraft tracking data:
The ICAO aircraft type of the plane,
the ICAO operator code (if unavailable LiveTraffic uses the first 3 characters of the call sign) to identify the airline,
a text to identify a special livery, for which LiveTraffic passes the aircraft's registration number, so that it is in theory possible to define individual liveries per airframe.
Available aircraft / airline / livery combinations are listed in the xsb_aircraft.txt files in your CSL model folders. LiveTraffic reads all of these files into a cache during startup.
Internally, a fourth parameter named related group is added, derived from the ICAO aircraft type: There are many similar looking aircraft models in the world...just think of A319, A320, A321. The file LiveTraffic/Resources/related.txt combines all similar looking models into one line, which make up such a group. Each ICAO type is allowed to appear at maximum once in the entire file. The idea is to use a A320 model if a necessary A319 model is not available.
Model Matching now compares 9 attributes between the live aircraft to represent and the available models and rates them according to the following priority from broad to fine-grained:
"has rotor" - this avoids picking a winged model for a helicopter
ICAO aircraft class type - landplane, seaplane, helicopter, ...
Wake Turbulence Category - a good rough general size indicator
Number of engines
Engine type - jet, turbo, piston
Related group - see above, groups similar-looking models like A319, A320, A321
Special Livery
The better a potential model matches with the live aircraft the more of the above attributes match, the higher is the "match quality". Higher priority attributes count more than lower ones: technically it is a bit mask. The model with the best match quality is picked. If there are several models ending up with the same match quality, then LiveTraffic takes a random pick. This often happens if there are several models available for the expected ICAO aircraft type, but none with the correct livery.
Note that "quality" is reported inverse here in Log.txt: Lower numbers are better matches. For example: The first match (Quality = 56) is a comparibly bad one...just look at the aircraft class: Wanted is a "L1P" aircraft (one piston engine), the best we found is an L2T (two turbo engines).
One out of two things:
"Autoland": If the plane is in flight phase Approach (this is triggered when plane is sinking and below FLAPS_DOWN_SPEED according to FlightModel.prf) then the descend is continued straight ahead with constant sink rate to the ground where the plane flares, touches down, and rolls out to a complete stop, then disappears.
If LiveTraffic finds a suitable runway (+/-10° of current heading, reasonable sink rate) it will guide the plane down there.
This special handling is due to the fact that ADS-B receiver coverage is typically worse the lower planes fly. Missing data during approach is quite common.
LiveTraffic will never simulate taxiing without tracking data.
If during this time the plane descends (in a configuration not triggering Approach phase, e.g. too fast) and hits the ground it will flare, roll out and stop as in "Autoland" - no matter if there happens to be a runway or a skyscraper.
If during this time the plane ascends it will continue to ascend and be taken out of service at FL600.
If not you might have setup/network problems. Try getting help in the providing that Debug-level Log.txt that you just produced.
See for recommended steps, and the same page for more background and tips.
The very same Log.txt in X-Plane's main folder, but containing more detailed information. In change Log Level to "Debug" if you run into problems and want to ask for help in a forum. From that point on LiveTraffic writes fairly detailed infos into Log.txt. Recommended to reset to, say, "Warning" after you problem is solved.
See for some background info.
If you have an ADS-B receiver and feed data into the ADS-B Exchange network, then you can and enter it into , so that you can enable the use of the ADS-B Exchange channel again.
If they roll out to a complete stop and then only disappear then this is actually a feature to prevent them from disappearing even earlier. Read about auto land.
If they disappear the moment they touch down (and there are also no other planes taxiing on the entire airport) then check your : There are two options meant to allow to integrate with plugins for airport traffic. And their job is to hide taxiing planes or planes below a certain height AGL. If any one of these is active LiveTraffic hides planes on the ground.
When starting up initially LiveTraffic reports on the received data to get an idea what you have to expect. These messages stop after the buffering period while receiving data certainly keeps going. (Check the Plugins > LiveTraffic > Aircraft displayed for an up-to-date number of displayed aircraft.)
You don't find the term "LiveTraffic" at all: That means that X-Plane didn't even find the plugin to load at all. Something's wrong with your installation. Make sure there is a LiveTraffic folder with appropriate installation under <X-Plane>/Resources/plugins (so that it didn't get moved or trashed accidently). Basically go back to .
The plugin folder must indeed be called LiveTraffic and nothing else, which is due to : The actual binary to load (LiveTraffic.xpl) must have the same name as the plugin folder (LiveTraffic).
most likely you're missing or it is not up-to-date. Download and install it.
On Mac OS you might have a security issue, although LiveTraffic comes signed and nozarized. Please see the for details.
On Linux you might have a module load issue, most often actually with CURL. Recommended versions and more details are available in the .
Are you still on a beta version? Beta versions are time-limited to make sure beta testers keep updating to latest versions. You were informed with every start about the time limit. And if the limit expires then all what's left from LiveTraffic is the line
LiveTraffic <timestamp> FATAL src\LTVersion.cpp:70/CalcBetaVerTimeLimit: BETA-Version limited to <some date in the past> has EXPIRED -> SHUTTING DOWN!
in your Log.txt. to latest version.
LiveTraffic again and make sure to copy all files to your plugins directory.
Please . A couple of tips for Linux are collected there.
And . At the time of writing it has an open end...but a LT version to try.
With MacOS 10.15 Catalina security requirements further increased. Some users report issues starting plugins with X-Plane, not only LiveTraffic. See and forum posts on the issue with a few solution approaches. You know you have the issue if LiveTraffic doesn't load and Log.txt includes something like
LiveTraffic/64/mac.xpl: code signature in (.../mac.xpl) not valid for use in process using Library Validation: library load disallowed by system policy
Yes. Deselect all options in .
You can also quickly hide/show them in the current view via , which can be bound to a keyboard shortcut or joystick button.
To a large extend, yes. Go to and change the level of messages appearing in the Message Area. If you select Fatal then you should never see anything there...and if so LiveTraffic's probably dead anyway. However, less than Error is not recommended.
Unfortunately not, at least not at the moment. The 3D world is made for objects, not for text. The X-Plane API provides no way of setting a font size. Change the Base Font Size in X-Plane's Rendering Settings may or may not help. So, as long as I don't draw all characters by myself (no, sorry...I won't ;)) this is probably the way it is until somebody comes up with a better idea. Hey...it's open source...check out ...
Yes, see . Please also understand the accompanying warning.
Yes, choose Auto Start to your liking in the .
LiveTraffic's traffic trails the buffering period behind reality (). LiveATC does not trail behind that much (it is still a few seconds behind). But by delaying LiveATC's audio output both can be synched up again. of a user, which describes how to do that by configuring a delay in VLC's settings.
Since around August 2024 or so, Flightradar 24 is offering an actual , which would very likely provide what LiveTraffic needs: Regular positions of aircraft. However, are staggering, which you as a user would need to pay.
Take the 9$/month "Explorer package" as an example and read carefully: The package gives you 30,000 credits. Each flight sets you back 6 credits (for a "Live flight positions light" request), so you can buy just 5,000 flight positions. Let's assume you set at a medium-busy airport with 50 planes around you, then you can inquire their positions 100 times. Doing that 3 times per minute (that's LiveTraffic's standard ) means that after 33 minutes your credits are exhausted already.
Now compare that to 9$/month for unlimited data (in a 12 month subscription), good coverage, weather, and parked aircraft...and I don't think it's a deal.
Technically yes, I could, but it is too expensive for personal use. FlightAware offers API access to their data, the API that would suit LiveTraffic's needs is called , but steep apply that every LiveTraffic user would need to pay individually to FlightAware.
The , that you are if you share the data of your ADS-B Receiver with FlightAware, does also not include access to the API.
No, and I won't provide an option for that because there is an easier way for getting your own data into LiveTraffic and at the same time helping the entire community: Just feed your ADS-B data to OpenSky and especially ADS-B Exchange (further info ). If you feed ADS-B Exchange you are eligible for an API key for free, so in return you can receive all data including your own. ADS-B Exchange also doesn't filter any aircraft, all received planes are in. This way not only you but all users can benefit from your data.
You local data is also not more up-date or faster than data received from the network because it does not matter when LiveTraffic receives a tracking item: All flight path calculations base upon timestamps included in the item (e.g. ). So the data itself tells LiveTraffic when it was valid. (Also read on about the buffering period to understand timing a bit better:)
...and why can't it be just 0 to watch aircraft without delay? (Configuration in .)
also requires some look-ahead buffer to pick the right path.
Currently, of the supported data channels only provides a way to see historic data. For this purpose the RealTraffic app has an option to send historic data. LiveTraffic is adapted to process also this historic data.
Increase X-Plane's Settings > Graphics > Texture Quality, what it may look like.
Most likely you are missing some VERT_OFFSET versions of xsb_aircrafts.txt in your CSL model folders. Copy them again from BB_IVAO_vert_offsets*.zip, see .
Many GA and business jet models of the Bluebell package are known for issues, i.e. some elements of the model simply don't show if the object is "too" far away. This is standard procedure in modeling to save performance. However, it often happens beyond 0.5nm already, which is visible. Move the camera closer than 0.5nm ( tells you your distance) and gear will show. This problem can only be solved by a CSL model developer and looks as in the following screenshots:
2. Less likely, but also reported: It could be a dataRef error: The model might still refer to some other (like WorldTraffic's) dataRefs to learn if gear is extended or not and might not have extended the gear. Also this one can only be solved by the CSL model developer. The correct dataRefs for LiveTraffic (and XSquawkBox and others) are documented .
For picking the right model LiveTraffic (specifically: the multiplayer library) primarily depends on the and the operator code (for the livery) included in the transferred tracking data. If the ICAO aircraft type desginator is not transferred (and that does happen, especially for GA aircraft) then LiveTraffic tries to lookup the human-readable model text (like "172S" in the screenshot below) in the file model_typecode.txt. This file has been compiled from information of the OpenSky aircraft database and includes pretty educated guesses about which model text matches which ICAO aircraft type designator.
If you know type and operator based on whatever other source, then please help maintain by updating or even adding aircraft data. An update there is very quickly available to all users, bascially immediately! (See for a good example). The aircraft's database record at OpenSky is also accessible from the via the button in the "Update" column.
(Won't happen for A80A5D again as I've updated ;)
If ICAO aircraft type designator and operator code are available then a starts kicking in to try picking the best matching model with the best matching livery. Check out Log model matching if you are interested in the details.
The always shows you
And again: You can help maintaining the underlying data: Open an A/C Info Window for that plane, take note of transponder code and/or registration (tail number), search for reference data in the internet and update .
Solution: Install CSL models, respectively verify that your installation is successful. The explain the steps for the Bluebell, X-CSL, and additional individual CSL models in detail.
LiveTraffic relies on the operator information delivered by the channels. (In case no operator info is available the first three characters of the call sign are used, which is only a rough guess but better than nothing.) And then there must be a matching model for the a/c type with matching operator livery to be displayed. slightly prefers the right livery, but still there must be a relatively well matching model with correct livery available for the correct livery to show.
For example, many people find that American Airlines flights are often shown with the wrong livery. Is it a medium Airbus? That is because the Bluebell package does not include AA liveries for the Airbus A32x types, causing American Airlines A319-A321 to be shown in random livery. (BTW...nice people provided for that...)
If you think, however, that you have the correct model, but still it doesn't show, then verify the operator and model information in the . The operator info is as per reported by the tracking data channels. Help the community-maintained data by reporting wrong data or correcting it directly in .
If you are interested in how model matching works switch on Debug: Log model matching in the and keep looking into Log.txt (see tips on keeping it open here).
If you are looking for a download you can , where both CSL models and additional liveries are offered. Once you found something, for installation tips.
I outline the steps necessary, especially to make a new livery available to LiveTraffic and test it;
As a sub item, here is the , where you will find the full documentation of the xsb_aircraft.txt file, which defines available CSL models for LiveTraffic.
is the go-to forum for all questions around actual livery painting.
/ operator and related group together match (this means that a "related" model with matching livery is preferred over an exactly matching aircraft with wrong livery)
- like A320, A388, B738, B741, C172, MD82, ..
/ operator - like AAL, AFR, BAW, DLH, SWA, WJA, ...
If you are interested in how models are picked then you can activate Log model matching in the and at least Log Level "Info" in the to have LiveTraffic write matching information per aircraft into Log.txt like this:
"Continue unchanged": If the plane is not in a phase between Approach and Roll out then it will continue flying with unchanged parameters (heading, speed, vertical speed) for twice as long as the Buffering Period configured in the .
The or the tell you per plane how old the data is in the Last Data line/column: If the number is positive then there is a known data point this number of seconds in the future and the flight will continue at least until then. If the number is, however, negative, then the last known data point is this many seconds ago and we are flying blind already. The number will not grow (much) more negative than -2 * Buffering Period.
