BruceKnowles 0 Posted August 21, 2014 Share Posted August 21, 2014 Hi, Todays Navigraph 1409 update seems to have corrupted all the route definitions. Although they appear to complete the bulk validation checks on the entire list this is definitely not the case in practice. When one selects all 5100 (or so) routes and then executes the check function, they all seem to pass. Their background changes from yellow to white and they acquire a green tick mark. At this point one can now close down the routes database window and then quit the application. However, when restarting the application and re-opening the routes database window, all of the routes are once again unchecked and have orange text on a yellow background thus signalling an out of date error. Selecting a number of routes at random I find that in the fourth field with the heading 'Database' is also Orange on a Yellow background. This field always contains the value NG1409. Right clicking on the same route and then choosing validate triggers no activity. Editing the route and then performing validation mostly yields the error message "®ROUTE152 FLIGHT NOT APPLICABLE TO IFPS". This is the most common error but not the only one. Other errors seen regularly are: "ROUTE165 THE DCT SEGMENT <snip>... IS TOO LONG ... <snip>" and "PROF204 <snip> ... FORBIDDEN ROUTE <snip> ..." In each case, after validating the route and closing the editor window, the Route Database list now has the route with a green check mark and black text on a white background. IMHO given we now know that at least one error has occurred during the validation cycle, this latter state cannot possibly be the correct display setting. Notwithstanding the above mentioned repeatable error, I suspect another underlying error exists that may well require the combined effort of personnel from the PFPX team and the Navigraph team to resolve. Link to comment Share on other sites More sharing options...
srcooke 421 Posted August 21, 2014 Share Posted August 21, 2014 Hello Bruce, I agree that once checked the database routes should remain cleared. However don't confuse an AIRAC update check with Validation. The first simply checks for any breaks in your routes following changes in the airway structure whereas the latter requires individual route submission through CFMU and can require route and or altitude amendments. The ROUTE152 FLIGHT NOT APPLICABLE TO IFPS indicates that validation is been tried out of the EuroControl zone. As for the DCT segment too long you'd need to address the route IF you wish to validate them. Certainly not a Navigraph issue. Link to comment Share on other sites More sharing options...
alpha117 51 Posted August 21, 2014 Share Posted August 21, 2014 I have the same issue, Checked as normal and all got the 'green tick'. No if I go back into the route database all routes are 'outdated' there are no current routes. Don't think that has a big knock on with planning though? PS: Good one on you hours on VATSIM Stephen Link to comment Share on other sites More sharing options...
BruceKnowles 0 Posted August 21, 2014 Author Share Posted August 21, 2014 Hi Stephen, I guess I was as clear as mud in detailing my thoughts. What I in fact have done is highlight 3 different observations in a single rather wishy washy descriptive story. To clarify: 1. Characteristic behaviour of the check procedure normally performed at implementation of each AIRAC update has changed on data set AIRAC 1409. 2, I also stated that the characteristic behaviour of the Validation process had also changed, and that I was getting failures on every route I checked. 3. Based on the observation noted in 2, I asserted that I believed it an error to subsequently flag a route as checked if it fails validation. Hopefully, it is now clear that these three items are related but not all are necessarily dependant consequences of failures of the others, In particular, 1 is independent of 2 and 3. Now, as for point 2, I must admit that I am indeed in error. I have discovered that I was a little negligent with my testing of the validation. During a second round of these tests I paid more attention to the detail of the error messages delivered. With just a small amount of thought I realised I have been pretty dumb indeed. If I put an acceptable cruise altitude which would match the requirements of a high/low airway then validation is likely to be successful. Since I have discovered this bit of stupidity I now realise that my assertion in 3 is also off target. It is evident to me now that the check flag only signals that all the way points can be found in the current database. They are not invalid just because a pilot does not satisfy the altitude constraints when planning a flight. Now, after all of this self deprecation I can clearly confirm that I have nevertheless tracked the exact condition which causes the problem defined in 1. I can also state that this problem will not be seen tomorrow. The problem noted is induced by an erroneous logic test in the application. Code equivalent to the following semantics is in operation: IF date(TODAY) <= CYCLE_START_DATE then mark_route(Route_ID, OUT_OF_DATE) ENDIF The code should in fact be: IF date(TODAY) < CYCLE_START_DATE then mark_route(Route_ID, OUT_OF_DATE) ENDIF This can be proved by experimentation by anybody with the courage to do a little bit of experimentation. In directory C:\Users\Public\Documents\PFPX Data\NavData (Normal case for Win 7 users) a file named navdata.nav exists. This is a text file where the first part is readable text, the balance has been encoded to presumably protect the data. This is the clear text. PFPX NAVDATA NG1409 2014/08/21 2014/09/17 NAVIGRAPH The meaning of these rows should be obvious to all readers. The condition reported can be triggered by changing the first date (2014/08/21 in this case) to the current machine date. Starting PFPX and following the process mentioned in the earlier postings will show the error condition as reported. This is a trivial fix and clearly this fault will only affect those who are on the ball and update their AIRAC on the day of release. Link to comment Share on other sites More sharing options...
alpha117 51 Posted August 22, 2014 Share Posted August 22, 2014 OK today, so if you 'check' routes on day of Navigraph release then routes will be 'outdated'. Check after day of release then all is OK. Thanks Bruce Link to comment Share on other sites More sharing options...
srcooke 421 Posted August 22, 2014 Share Posted August 22, 2014 The change in 'check' behaviour appeared to come about in v1.15 where the activation time also moved to 0800Z on the AIRAC date ( however the actual time this occurs in PFPX is currently 0900Z) Link to comment Share on other sites More sharing options...
jpgmultimodal 61 Posted August 22, 2014 Share Posted August 22, 2014 Hi, i think it has been mentionned before but to avoid problems with the update date and time it is better to change your computer one day ahead, to apply the new AIRAC and after you come back to the actual date on your computer. if you update today (on the 22nd) it should be OK. We have to keep in mind that some of us would have a day difference with Europe. Regards, JP Link to comment Share on other sites More sharing options...
srcooke 421 Posted August 22, 2014 Share Posted August 22, 2014 Hello JP, In changing the PC date it created issues for me previously when returning to the current date where, the date stamps on files throw a spanner in the works. The problem needs addressing as per Bruce's post. Link to comment Share on other sites More sharing options...
jpgmultimodal 61 Posted August 22, 2014 Share Posted August 22, 2014 Hello Stephen, For me it is the only answer and it works perfectly (so far). Anyway,I suppose it is the same problem that we all have from one computer to another with behaviours so different from one setup to the other. Regards, JP Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.