I was searching the forums and apparently there’s a known issue with the current AIRAC update where it defaults to AIRAC 2101.
The thread was closed but I didn’t see a solution. The link I clicked on to take me to a temporary solution is broken.
FF757v2 X-Plane 12 on MacOS Ventura.
Thanks.
Assuming a new revision isn’t imminent, it would be excellent if the temporary fix could be reposted somewhere. I am buzzing with excitement to fly the 767… just my luck I bought it today!
Edit: It would appear that in another post it was reported the workaround wasn’t working for FF aircraft. Perhaps that’s why it was removed. All we can do now is be patient.
Second edit: The workaround is pinned now. Unfortunately it did not work for the FF767. I’ll have to content myself with some GA flying this weekend 
Hello;
Not sure if I am responding to the correct thread but had problems on 2 different fronts since this latest update. 1) FSHud update did not work initially and it reverted back to AIRAC 2101, after a few tires over the past 2 days disconnecting and reconnecting it finally worked.
I have not seen an overall statement acknowledging that there is an issue with the Data Manager since the last update, so I am not exactly sure if something is actually been worked on other than snippets I have seen on another post by another concerned customer.
Wrong Cycle Data for 2307 (All FMS Data Manager updates) - Navigation Data / FMS Data Manager - Navigraph
Cheers.
I am unable to load current Cycle 2307 imto PRO ATC X. Has 2306 but want’s to default back to 2101 if I try to import the newer cycle 2307. The backup file folder is also empty. Not sure where it is getting 2306 from since there is no navdata folder under PRO-ATC-X. I have the latest version of FMS Manager and tried deleting PRO ATC X folder assignment and rescanning but no luck.
Hello
I’m afraid I’m not the only one to notice the problem but the cycle info file giving an AIRAC of 2021 means that for the B752 I have the NAVDATA OUT OF RANGE message. Yesterday, on a flight from SLVR to SUMU, I couldn’t load the plan on an A320 Jardesign (problem on an AIRWAY), which was visible in the file. It was while looking at the files that I noticed the erroneous info cycle.
Flying on IVAO, this situation is penalizing if it continues, and I hope you’ll be able to take it into account as soon as possible, given that the flight plans generated from SIMBRIEF are not compatible in terms of info_cycle with what is loaded in the x-plane directories.
Best regards
Richard COPIN
The calling cycle_info.txt file has nothing todo with the database itself. It will be only used (wrongly used!) by some 3rd party developers to display the correct cycle-number in their addons.
So, this “issue” is only an viewing issue in the FMC/S. The data itself are correctly AIRAC 2307 and therefore 100% compatible with SimBrief and the charts.
You see with the temporary solution, that only changing these file solve your issue. So again, it´s not a global data issue with the cycle itself - it´s only the cycle_info.txt file, which shows you the wrong cycle-number. The data are 2307
But we will update the whole cycle files with this file (which I offered as temporary solution), that you also see the correct cycle-number in your FMC/S. So, revision 2 is coming …
Cheers,
Richard
Hello
After reading Richard’s post, I replaced the cycle-info uploaded by FMS manager with the correct cycle_info written by Richard, this solves the problem and the data is OK.
Thanks in advance for avoiding having to make the correction manually each month.
Best regards
Can you tell me where you found the instructions? I cannot find them.
Cheers,
Richard
I found the temp fix and it’s working so far.
Thank you!
Richard, are you or are you not reverting to the AIRAC build code that creates the “internal” cycle_info.txt that contains the dates that 3rd party developers have been using to determine if the loaded nav data is current - whether that’s “right” or “wrong?”
While no one wanted to offend you or cause dismay of any sort, we are taking your response to the topic Wrong Cycle Data for 2307 that Navigraph is reversing the recent determination that the cycle_info.txt would no longer be provided.
I see this reversal as a wise decision and one that is best for the flight sim community as a whole, regardless of whatever the original reasons for removing the cycle_info.txt. Users, not just developers, need this file so that they can easily and conveniently determine the currency of their AIRAC data without the need to seek reference elsewhere. It’s a file and convenience that is also offered by your competitor, and one would not want to provide less than someone else - especially when the products are essentially identical. Or at least should be, given the wild and crazy complexities of ARINC 424.
As a developer and user of the data myself, I find it to be amazing that anyone can keep their course straight when it comes to current data. The only constant is change when it comes to aviation, so any time we can avoid change, it is a good thing. Stability and consistency is part of aviation safety, something we all try to embrace, whether real world pilots or desk top pilots.
Thanks for the hard work you do, and I sympathize with your situation, to be honest!
Cheers!
Exactly, this is the ONLY reason, to use this simple text file, which we (Navigraph) had created for many years to make our support more efficient. It´s nothing else as an information file which we provide.
But, and thats important - when it was our intention to use the file for parsing, we had used another format (like json, xml, csv, or any other structure format) to avoid EXACTLY such situations. All these 3rd party devs which uses this file has done this without asking if it´s ok, if the file is stable, will not be changed, removed … because in that moment, where I change anything in this file, we had the same situation. So for us, it´s a dead file which we can´t use.
This file goes back in FSX times, but in this time every add-on developer had designed his “own” cycle file which we supported. Started with LevelD, PMDG, ATR72, Fokker, … no one had used this file because it was clear for the “old” devs, that this file is just a info file (therefore the file name) in text format.
Cheyenne/Fokker, FS-Flightcontrol, … dataset:
X,2307,13JUL10AUG/23,2306,15JUN12JUL/23
PMDG, iFly, LevelD, AivlaSoftv1, … dataset:
[Ident]
NavData=AIRAC-2307
OpProgram=JUL13AUG10/23
CoData=JEP-2307
FSC (FlightSimCommander) dataset:
AIRAC-2307 Rev.2
JUL13-AUG09/23
JeeHell dataset:
2.10|1307|0908|2023|
FSiPanel dataset
LittleNavMap dataset:
SimToolKit, Pilot2ATC, … and so on, and so on … all these addons have used their own way. They have merged the cycle information which are necessary for their addon directly in their datasets.
Yes, I have reverted the code but the point here was, that I have also revert my whole workflow now with a lot of work on my backend systems, different tools and parsers. I have created over 100 file-formats in the last 20 years, not all are active but the testing-effort in the last days was enormous. As you possible know, we are also creating a new cycle.json file for every add-on. This file is a structured file, which can easily read and where we can add tags/elements without loosing the other information. It´s a newer technology which we use now. But all these efforts are useless (at least for me) now because I must stay with this simple text file.
A personal note (I´m also only a human), I´m very disappointed about this discussion because my intention was to improve the service to bring it to a next level and not to remove something and to annoy someone.
I didn’t know that anyone was using this file to extract data, because if I had known, I would have announced it beforehand.
Revision 2 is out now and all datasets have now again included the cycle_info.txt file. This file will not be removed or changed anymore.
Cheers,
Richard
Thanks for the clarification and assertion.
Wow. All I can say. You do have a substantial work flow when it comes to supporting a wide variety of data formats - all one has to to do is to examine the very long page of the various download options (for we old-fashioned users!) to completely validate what you’re saying.
You would not be the first person to change something innocently and to discover someone dependent on an unintended resource, I’m sure. It’s happened to me too, IIRC.
Again I appreciate your efforts, and thank you for restoring the cycle_info.txt as I think the impact of this reversal could save many devs a bunch of work, some of it rather complex if one tries to programmatically determine the correct AIRAC dates.
Cheers!
PS: I confirmed that the cycle_info.txt is present and correct for X-Plane 11, but X-Plane 12 is still showing 2101 for some reason. It’s cycle.json file shows 2307. Perhaps the re-generation process is still in work?
If the cycle.json file were to include the effective dates, that would be an improvement for future developers. Legacy code will likely need cycle_info.txt for quite some time, though, especially for products that are no longer in active development.
Thanks!
Hello DasApollo
I think I’m a bit late with the answer, but here it is to describe what I did.In Richard’s message, there’s a cycle_info file containing the correct cycle references (2307). As the data is a priori correct, the ADDON fms that checks the cycle info validates the FMS DATA. All you have to do is replace the cycle info file in the custom_data directories where they were deposited by FMS manager with Richard’s cycle_info file.
Good installation
Agreed - this is what I’ve shared for X-Plane users in case their X-Plane 12 download remains affected. Thanks!
Hi again,
I have tested it now but I can´t reproduce - the files are all from today approx. 12 o´clock and when I open the cycle_info.txt file, I see the right cycle-number/revision:
Try to delete the cycle_info.txt file and re-run the AIRAC update for X-Plane 12 please …
Cheers,
Richard
Actually, it was a manual download, Richard, and I was looking inside the zip file. That may be the key difference. I’ll recheck though… and the AIRAC for XP12 is correct now. Might have been some kind of repository update that I got caught in - we run into this sort of thing with product updaters too.
All good!
The manual updates take a little bit longer due the releasing process - so it´s possible that you have downloaded the old one - but it should be ok now. I have checked the manual-installer now too for XP12 …
Thanks again!
Richard
Hello Richard;
Not sure what was done behind the scenes but it’s now working for me. The FMS Manager successfully updated to 2307 and Pro-ATC X detected and picked up the updated file and I was able to update so everything is now in sync.
Cheers.
Forshaw.
