News:

Precision Simulator update 10.164 (17 December 2022) is now available.
Navburo update 13 (23 November 2022) is now available.
NG FMC and More is released.

Main Menu

Route turn direction problem on ND

Started by MRFarhadi, Tue, 29 Nov 2022 00:23

MRFarhadi

Dear Hardy,

I made an observation the other day and posted my question regarding the matter on Aerosoft's forum about how DME arcs that have multiple radial fixes in the middle of them sometimes don't get coded correctly into the database.
Aerosoft Forum Post - DME Arcs

Do you believe the issue lies with the original ARINC 424 file? Cause I wasn't convinced how the root of the problem doesn't lie with Aerosoft while other flight simulator community addons do not have to deal with this issue, and PSX "does" depict other arcs and RF legs correctly.

p.s. the note about how the issue is "rather normal" doesn't seem right to me and is not consistent with my experience.
Mohammadreza Farhadi

Hardy Heinlin

#1
Dear Mohammadreza,

if other database interpreters depict this path code correctly, it's most likely a problem in PSX. Sometimes there is a dilemma with database typos regarding the left/right-turn characters R and L. Applying the typo strictly may display a turn in the opposite direction; on the other hand, ignoring the typo and calculating the nearest course change direction sometimes leads to errors as well.

I'll look into it when I have the time.


|-|ardy


I'm splitting this discussion from the Navburo thread as I think it's not related to Navburo.

MRFarhadi

Dear Hardy,

I also checked with the Navigraph database I still had in hand and their depiction is exactly like the Aerosoft in all the cases I previously brought forward. I also managed to get similar results for some other STARs e.g. ALMOB1U into OIKK VOR DME 1 RW16R and MOBON1S for VOR DME 2 RW03R for OIKB. In addition to wrong turn directions, the legend of dd.d DME ARC L/R in the legs page is missing and discontinuity is generated instead.

Thanks for your continued support.


Best,
Reza
Mohammadreza Farhadi

Markus Vitzethum

Hi Hardy,

I had a brief look into this issue and the report is puzzling me, I haven't figured out yet  what is going on.

Quick summary so far:
the ASNI1P at OISS has an AF leg as the last leg of the STAR procedure, going to SADIA. For some reason, Navburo converts this last leg not to a DME arc leg terminating at SADIA, but it creates a direct course to a waypoint named D064Y.
However, in the raw ARINC424 data there is no data related to a R-064 radial or a 25 DME (=Y) distance. When I change the leg type to TF, the waypoint is correctly shown as SADIA.

Markus

MRFarhadi

#4
Dear Markus,

I believe the ARINC424 file you're referring to is correct. According to the LIDO m/Pilot screenshot I upload to the Aerosoft Forum, which can be found here, ASNIT1P is a continuous 17 DME arc from 339 Radial to 075 Radial (SADIA fix).
Is it possible for you to confirm that other AF legs are also decoded the same way?
Mohammadreza Farhadi

Markus Vitzethum

Hello Mohammadreza,

I also (briefly) check the RIBU1P arrival at OIMM. For this procedure, there are two AF legs coded into the raw ARINC424 data, the first leg goes to D203P, the second one to D134P.

Here, the first AF leg seems to be shown correctly by PSX, however the second (last) AF leg is again shown incorrectly. So, basically AF legs are correctly shown as DME Arcs but not in your examples (reason to be determined).

Markus

Markus Vitzethum

A few observations, based on modified raw ARINC424 data and checking what happened in PSX.

When I add more AF legs to the procedure (e.g. contine the 17 DME arc on ASNI1P from SADIA to HAFEZ), the first DME arc shows up in PSX. (Not correctly, though, see below).

Conclusion 1 (preliminary) - is it possible that a DME Arc (created by the AF leg) does not show up in PSX when the AF leg is the last leg in the procedure?


I also notice that in this procedure, the termination waypoint of the DME arc is a 'properly' named waypoint with a five letter name. In PSX, the termination waypoints always follow the radial/distance naming convention of DrrrX, e.g. D064Y. In particular, for the DME arc terminating at SADIA, I cannot get PSX to show SADIA waypoint. Instead, D064Y is shown at the correct 17 DME arc but at the wrong radial.

Conclusion 2 (preliminary) - is it possible that PSX expects a DrrrX waypoint in an AF leg and cannot handle five letter waypoint names?

I guess we need Hardy to look into this further.

Markus


Hardy Heinlin

This is simply a side effect of a safety filter I implemented 9 years ago (in a late beta). The filter sits in the route reader in PSX where route injections are read from situ files and from the network every few seconds. There was a nav database problem somewhere that caused two discos in a row in certain route combinations with fly-over waypoints. The filter then changes the last leg to a TF path. This is one of those safety modifications whose side effects may be discovered years later.

Well, I just added a line that inhibits the filter for AF paths. Those missing arc legs appear now.
The wrong turn direction is herewith automatically corrected as well.

Will be available in PSX update 10.160.


|-|ardy


(Navburo doesn't alter or remove any data of what PSX will read. Navburo just converts from text to binary.)

MRFarhadi

#8
Dear Hardy and Markus,

Thanks for troubleshooting and addressing the issue.
My initial suspicion regarding Navburo was due to the PSX's lack of problems dealing with back to back RF legs and I thought to myself that AF legs issue might have to do something with the Navburo as Aerosoft uses it.
Honestly, It's been great feeling that the customers' thoughts and ideas are being heard and the project is still going on and still being improved.

Best,
Reza
Mohammadreza Farhadi

Jeroen Hoppenbrouwers

Quote from: MRFarhadi on Sat,  3 Dec 2022 22:24... and the project is still going on and still being improved.

Where improved does not mean "new big features being added daily under market pressure, so that small continuous improvement moves to the bottom of the manager's list."

It's a precision simulator after all...

Hoppie

MRFarhadi

Quote from: Jeroen Hoppenbrouwers on Sat,  3 Dec 2022 23:01Where improved does not mean "new big features being added daily under market pressure, so that small continuous improvement moves to the bottom of the manager's list."

It's a precision simulator after all...

Hoppie


TBH, that's exactly what drew me to PSX, after years of dealing with mainstream simulators.
Mohammadreza Farhadi

Hardy Heinlin


MRFarhadi

Quote from: Hardy Heinlin on Mon,  5 Dec 2022 19:38The above correction is now available in PSX update 10.160:

https://aerowinx.com/board/index.php/topic,4191.0.html


|-|ardy

Thanks Hardy! Your time and effort is appreciated  ;D
Mohammadreza Farhadi

Markus Vitzethum

Hardy,

I checked the ASNI1P arrival at OISS with the latest PSX update and I still see one issue, previously mentioned above.

According to the ARINC424 raw data and according to the charts, the AF arc should end at a waypoint SADIA, located at R-075, 17 DME. In PSX 10.162, the arc ends at waypoint D064Y (which translates to R-064, 25 DME), actually being located at R-064, 17 DME (correct DME distance, with a discrepancy to the waypoint name).

The D064Y waypoint does NOT appear in the ARINC424 data and it is does not appear on the charts - and it is not located at the correct position (R-064, R-075 should be correct).
The expectation is that the arc should end at the SADIA waypoint.

Markus

Hardy Heinlin

10.160 fixed the omission issue only, not the radial shift which is probably another safety function of the fly-by turn anticipation in PSX -- and which makes no sense here because this special arc here has to have an open end. I will check that issue in the next update.


|-|ardy

Hardy Heinlin

The last leg of an arc is now a fly-by instead of a fly-over -- in PSX update 10.163:

https://aerowinx.com/board/index.php/topic,4191.0.html


Regards,

|-|ardy

MRFarhadi

Dear Hardy,

It's working perfectly now.
Thanks for the update.
Mohammadreza Farhadi