FAQ
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 design limitations. 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 list of channels 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 About page 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 settings.
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 will disappear after stopping. 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 this and this FAQs further down.
Follow First Steps at a busy airport.
Make sure menu item
Plugins > LiveTraffic > Aircraft displayedis on.Verify that OpenSky / ADS-B Exchange do have traffic where you are.
Verify that these channels are enabled in your Basic Settings.
Double-check CSL model installation. Do perform the validation recommended in the installation instructions by looking into
Log.txt.If you see yellow labels but no planes you are missing plane models: Go back to CSL model installation. Really do perform the validation recommended in the installation instructions by looking into
Log.txt.Switch logging level to Debug in the Advanced Settings and wait for 10 minutes, then take a look into
Log.txt. There should be many lines like
Log.txt (extract)OpenSky Live Online: Sending HTTP: https://opensky-network.org/api/states/all?lamin=...OpenSky Live Online: Received #### charactersADSB Exchange Live Online: Sending HTTP: https://public-api.adsbexchange.com/VirtualRadar/AircraftList.json?lat=...ADSB Exchange Live Online: Received 7953 characters
If not you might have setup/network problems. Try getting help in the LiveTraffic Support forum providing your Debug-level Log.txt.
Right in your main X-Plane folder, next to X-Plane.exe/.app.
The very same Log.txt in X-Plane's main folder, but containing more detailed information. In Advanced Settings 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.
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 403andADSB 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.
See this X-Plane forum entry for some background info.
If you have an ADS-B receiver and feed data into the ADS-B Exchange network, then you can request an API key there and enter it into Basic Settings, 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 here 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 Basic Settings, right-hand side: 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 menu item for an up-to-date number of displayed aircraft.)
"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:
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
LiveTrafficfolder with appropriate installation under<X-Plane>/Resources/plugins(so that it didn't get moved or trashed accidently). Basically go back to installations.On Windows, you might be missing the latest required Microsoft C++ redistributable package. Then all what's left in the log is
.../Resources/plugins/LiveTraffic/64/win.xpl : Error Code = 126 : The specified module could not be found.Download and install vc_redist.x64.exe.On Mac OS you might have a security issue. Please see the separate FAQ below 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 Requirements.
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 yourLog.txt. Go and update to latest version.
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.
Download LiveTraffic again and make sure to copy all files to your plugins directory.
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.
Please do check requirements. A couple of tips for Linux are collected there.
And here is a forum thread on Ubuntu 19.04. 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 here and here 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
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.
Yes. Deselect all options in Setting / A/C Labels.
You can also quickly hide/show them in the current view via menu item Labels Shown, which can be bound to a keyboard shortcut or joystick button.
To a large extend, yes. Go to Advanced Settings 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.
Can I increase font size of aircraft labels? Could they move with head movement? Can aircraft labels {put any wish here}?
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 2D.cpp/TwoDDrawLabels()...
Yes, see Settings / Basic / Flight Data Channels. Please also understand the accompanying warning.
Yes, choose Auto Start to your liking in the Settings / Basic.
LiveTraffic's traffic trails the buffering period behind reality (read why). 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. Here is a forum post of a user, which describes how to do that by configuring a delay in VLC's settings.
Technically yes, I can. But legally I am not allowed, sorry. I've checked with FR24 support. They do not yet allow using their data outside their own applications. Maybe, so their answer, they will provide a (paid) model in the future...maybe not.
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 here). 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. see OpenSky's API description). 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 Advanced Settings.)
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.
Following taxi routes also requires some look-ahead buffer to pick the right path.
Currently, there is no option to read historic data, with "historic" meaning to go several days or even months back.
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.
No other publicly accessible historic data is known.
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 step-by-step instructions.
There are 2 known explanations.
Many GA and business jet models of the Bluebell package are known for LOD 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 (a/c info window 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 here.
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.
For picking the right model LiveTraffic (specifically: the multiplayer library) primarily depends on the ICAO aircraft type designator 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 OpenSky's aircraft database by updating or even adding aircraft data. An update there is very quickly available to all users, bascially immediately! (See this forum post for a good example).
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:
Log.txt extractOpenSky Masterdata Online: Data for 'A80A5D' (man 'Cessna', mdl '172S') lacks ICAO a/c type code, will be rendered with standard a/c A320
(Won't happen for A80A5D again as I've updated OpenSky's Aircraft database ;)
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
Log.txt extractTracking data for 'A3DB93' (man 'Airbus', mdl 'A320-251N') lacks ICAO a/c type code, but derived A20N from mdl text
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.
If ICAO aircraft type designator and operator code are available then a matching algorithm starts kicking in to try picking the best matching model with the best matching livery. Check out Advanced Setting Log model matching if you are interested in the details.
The a/c info window always shows you
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.
With v1.5 a safeguard had been entered so that a car that takes off should dynamically change into the default plane. So hopefully, the below issue is not so bad any longer.
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.
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 OpenSky's aircraft database.
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.
Solution: Install CSL models, respectively verify that your installation is successful. The Step-by-Step instructions 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. Model matching 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.
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.
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 a fix 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 a/c info window. 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 OpenSky's aircraft database.
If you are interested in how model matching works switch on Debug: Log model matching in the Advanced Settings and keep looking into Log.txt (see tips on keeping it open here).
Because LiveTraffic sticks to the original file format for CSL models and packages. This is a long story... Here's a forum post on it.
By now, I have provided a Python script called CSL2XSB, which can convert X-CSL package for use in LiveTraffic.
Yes, you can and 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:
In this forum reply I outline the steps necessary, especially to make a new livery available to LiveTraffic and test it;
As a sub item, here is the link to the XPMP2 documentation, where you will find (sooner or later, work in progress) the full documentation of the
xsb_aircraft.txtfile, which defines available CSL models for LiveTraffic.
The Painter's Workshop is the go-to forum for all questions around actual livery painting.
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 roup 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
ICAO airline / 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)
ICAO aircraft type - like A320, A388, B738, B741, C172, MD82, ..
ICAO airline / operator - like AAL, AFR, BAW, DLH, SWA, WJA, ...
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.
Taking a random pick is the most noticable change of model matching compared to pre-v2.0 versions of LiveTraffic. This will make your apron more colorful. There is no "default" livery any longer. The downside is that it is a bit harder to identify non-matching liveries.
If you are interested in how models are picked then you can activate Log model matching in the Debug Settings and at least Log Level "Info" in the Advanced Settings to have LiveTraffic write matching information per aircraft into Log.txt like this:
Log.txt (extract).../CSLFindMatch: MATCH INPUT: Type=BE36 (WTC=L,Class=L1P,Related=128), Airline=N13, Livery=N136HP.../CSLFindMatch: MATCH FOUND: Type=BE20 (WTC=L,Class=L2T,Related=128), Airline=SLG, Livery= / Quality = 56...43/LTAircraft: Added aircraft A09238 (BE36 N136HP), operator '', a/c model 'BE20_CGSAE', flight model [GA], bearing 165, distance 6.5nm, from channel OpenSky Live Online.../CSLFindMatch: MATCH INPUT: Type=B737 (WTC=M,Class=L2J,Related=56), Airline=SWA, Livery=N462WN.../CSLFindMatch: MATCH FOUND: Type=B737 (WTC=M,Class=L2J,Related=56), Airline=SWA, Livery= / Quality = 2...43/LTAircraft: Added aircraft A5A30A (B737 WN1287), operator 'SWA', a/c model 'B737_SWA', flight model [MediumJets], bearing 223, distance 37.1nm, from channel OpenSky Live Online.../CSLFindMatch: MATCH INPUT: Type=DHC6 (WTC=L,Class=L2T,Related=108), Airline=CVU, Livery=N190GC.../CSLFindMatch: MATCH FOUND: Type=BE20 (WTC=L,Class=L2T,Related=128), Airline=JEI, Livery= / Quality = 16...43/LTAircraft: Added aircraft A168C4 (DHC6 N190GC), operator 'CVU', a/c model 'BE20_DIKOB', flight model [MediumJets], bearing 158, distance 11.0nm, from channel OpenSky Live Online.../CSLFindMatch: MATCH INPUT: Type=H500 (WTC=L,Class=H1T,Related=177), Airline=N91, Livery=N911WY.../CSLFindMatch: MATCH FOUND: Type=B06 (WTC=L,Class=H1T,Related=177), Airline=PAT, Livery= / Quality = 8...43/LTAircraft: Added aircraft AC9C6D (H500 N911WY), operator '', a/c model 'B06_US3_31A', flight model [Heli], bearing 359, distance 7.0nm, from channel OpenSky Live Online
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."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 as long as configured in a/c outdated period in the advanced settings.
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.
The a/c info window tells you per plane how old the data is in the Last Data line: 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 -(a/c outdated period).
