Hello,
There is a new RNP field in the nav data for MSFS 2024. I’m using it to filter out any procedures that my GPS unit does not support and it looks quite plausible with the default navigation data. However, when using Navigraph, all RNP values are 0. For example, this is EDDF RNAV 7C X, which goes down to 0.3NM in the default data but is all 0 for Navigraph:
Hello! Thank you for the feedback!
These values have been correctly included in the next cycle. Let us know if you are still having issues after the next update!
Kind Regards,
Malte
Thank you very much, great news! I won’t even have to wait for long 
Thanks Malte,
I see the RNP for approaches now, but it does not look like they are available for SIDs and STARs. For example KJFK PARCH 3. The charts state, that this requires RNAV 1, but in the sim, RNP is 0 for the whole procedure. The same goes for KJFK DEEZZ 5.
Hi,
Thank you very much for the report. I will check it … Thanks for the example!
Cheers
Richard
Hi again,
I have checked the RNP values in the SIDs/STARs, and the values are there (i.e., DFFD the ANIX1N departure). My main question is, where do you see the RNP1 in the KJFK SIDs/STARs? I can´t find it on the charts:
… the sample DFFD:
But I don´t see this somewhere on the charts for KJFK, and I have not found any RNPs in the source for SIDs/STARs at KJFK.
So, please, can you provide a hint at where you see this RNP you mentioned in your initial posting?
Thank you very much,
Richard
PS: RNAV 1 <> RNP 1 … RNP is a subset of RNAV with additional requirements
Interesting. I do not see an RNP in your example DFFD ANIX1N:
I guess KJFK was a bad example. I must have remembered it wrong, because it is coded with 0 everywhere even in the default dataset. A better example is EDDF. There are RNP STARs and RNAV STARs. Both are coded with an RNP of 1 in the default dataset and 0 in the Navigraph dataset.
I had a quick chat with Working Title on how the RNP value from the dataset should be interpreted:
My motivation here is that I simulate a KLN-90B which is only certified for B-RNAV. Its database does not include any procedures that it would not be allowed to fly, so I’m using the RNP field to filter out those procedures.
I will check it in the next few days and inform you when it´s fixed. When needed, I will release a new revision of this cycle.
Thank you,
Richard
Hi again,
I can confirm that we have identified an issue with the data conversion of the RNP value. We have started to work on a fix. We will release a 2nd revision for this cycle as soon as this is done. Thank you very much for your input … I will keep you informed here when it´s released/online …
I hope that helps,
Richard
Hi,
I have released a second revision for MSFS2024, which correct the RNP values … Please can you confirm, that this is solved now 
Thank you very much,
Richard
The RNP values now look very much as expected. Thank you very much!
I have now noticed that many procedures are twice in the data. For example this is KDAL, where I do not have any custom scenery:
Hi,
Yes, thank you. We saw this too yesterday evening, and we will fix it. It’s a wrong test code that splits the procedures into segments. It was my fault, sorry. We will correct this and will upload a new version.
Sorry and thanks for your hint
Richard
Hi,
revision 3 is out and should fix the issue with the double procedures.
Thank you,
Richard
Thanks from my end as well for being so responsive to this issue.
Kirk
Thank you. I can confirm, the double procedures have been fixed.
The RNP now looks different again from Rev 2. In Rev 2, I saw that EDDF DIXAT 1A (RNP 1) and DEBHI 1A (RNAV 1) both had an RNP of 1NM in the data. In Rev 3, now only DIXAT 1A has an RNP coded and not DEBHI 1A.
You mentioned, that RNP 1 and RNAV 1 are different requirements and this is technically correct. However, is it actually intended that you only fill the RNP for true RNP procedures? You have taken the response from Working Title and my use case into account? The data in the Navigraph dataset now fills this field differently than the default dataset, which makes things a bit more complicated for addon authors.
Hi,
Please mark where you see an RNP 1 at the DEBHI1A arrival. The DEBHI1A is “only” an RNAV arrival but not, like the DIXAT1A, an RNP arrival; therefore, there are no RNP values in it.
Again, RNAV1 is not the same as RNP1 … RNAV doesn’t automatically mean that this includes RNP. As I have written, it’s a sub from RNAV. That’s precisely why RNP isn’t a route_type as RNAV in the ARINC424 rules.
I have checked the AIP Germany, too, and I can’t see any RNP for DEBHI1A. Possible I missed something or I have overseen something.
Cheers
Richard
Likewise, I too can confirm that the double approach issue is resolved.
Thank you. I hope I made it clear, that I understand that RNP 1 and RNAV 1 are not the same and that the field was intended to be used differently by the sim and thus is filled und used differently in the default dataset vs the Navigraph dataset.
Anyway, I guess this is a design decision by Navigraph and works as intended. I consider this matter closed then. Thank you for all your help!
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
