Le forum des pilotes privés

lbleriot a écrit:D'un autre cote une "RNP APCH  avec RMG/API en RNP0.3" (EGNOS obligatoire? CDI a +/-0.3nm en API?), reste mieux qu'une RNP AR...

Beaucoup de noeuds au cerveau, quand même...

Pas besoin de SBAS pour RNP APCH ou ce que tu appelles RNP 0.3. La différence entre RNP APCH avec et sans SBAS est que dans un cas le guidage latéral dans le segment final est angulaire, et dans l'autre il est linéaire. En SBAS, en API tu restes à la sensibilité minimale (dans la pointe du triangle) jusqu'à ce que tu appuies sur SUSP (unsuspend), où tu repasses en RNP 0.3. En non-SBAS tu es en RNP 0.3 pendant tout le segment final ainsi qu'en API.

Si tu avais pris la peine d'aller regarder l'AIP comme suggéré, tu aurais peut-être noté les différences entre ces deux approches:





Dans le premier cas tu restes en RNP APCH jusqu'à MOPAR. Dans le second seulement jusqu'à PT407, avant le CF leg vers l'attente où tu repasses en RNAV 1.

Tout cela sont vraiment des détails dont on aurait volontiers pu se passer. C'est déjà assez compliqué comme ça. Ca illustre cependant ce que l'on dit sur la différence entre la navigation conventionnelle et PBN: En conventionnel la préparation était facile, mais l'exécution difficile, tandis qu'en PBN la préparation est difficile (et nécessite plus de connaissances système d'où la formation PBN obligatoire), mais l'exécution est simple.

Aviathor a écrit:Si tu avais pris la peine d'aller regarder l'AIP comme suggéré, tu aurais peut-être noté les différences entre ces deux approches:

Bien sure que j’ai pris la peine de regarder, j’ai bien mentione avant que RNP05X VEXAV est "backward compatible" avec TSO129 (Garmin ou Proline21 non-WAAS)
Ce n’est pas ca la question ici: c’est ce segment RNP0.3 jusqu’a MOPAR en Y/Z qui nous interesse !

lbleriot a écrit:Sur la nouvelle AIRAC, les RNP05 (Y et Z) ont a été forcée avec  API RNP0.3 jusqu'a l'attente RNAV1, c'est possible de faire ces segments de remise de gas avec un TSO129 (GPS sans WAAS)?
Normalement, RNP05X par VEXAV (API05 RNAV1) doit être disponible sur un GPS non-WAAS. Une API RNP APCH se fait en RNAV1 apres MATF qui permet de supporter les TSO129 (GPS non-WAAS)

Je suis 100% sure que Garmin ignorent le segment RNP0.3->MOPAR: ils vont le remplacer avec RNAV1, je te paie une tournee s'il est code en RNP APCH !
Je vais tester cette remise de gas avec G430W pour voir si MATF->MOPAR affiche TERM (RNAV1) ou APR/MAPR (RNP APCH)

Soit c’est une erreur de frappe par DGAC/SIA? ou erreur code par Jeppsen/Garmin? soit c’est un choix concepteur procedure?  

Si c’est un choix concepteur, la question de RMG en RNP0.3 jusqu’a l’attente MOPAR reste problematique en degradation EGNOS/GNSS
Je ne sais pas si tu vois la subtilite d'un degradation RNP APCH -> RNAV1? meme DME/DME et RADAR ne suffisent pas !

Tu as aussi un tas de questions,
*Si tu peux faire RNP0.3 en segment FNA avec virages pourquoi tu aura besoin de RFs?
*Si tu peux faire RNP0.3 en segment RMG avec virages pourquoi tu aura besoin de RNP1+RF?

Pour les erreurs de frappe DGAC/SIA, il y a toujours un paquet, la fiche ILS n'est pas publiee pour Pontoise...
Mais il y a encore le coding RNAV->ILS (PRECODING MOPAR ILS Y CAT 1 LOC Y RWY 05) dans l'AIP_AD2_LFPT_DATA

J'imagine Jeppesen et Garmin peuvent décider de coder un segment API en RNP0.3 comme segment RNAV1? ou un arc DME comme segment RNAV1? car c'est peut etre ok en standard US mais bon...

lbleriot a écrit:Si c’est un choix concepteur, la question de RMG en RNP0.3 jusqu’a l’attente MOPAR reste problematique en degradation EGNOS/GNSS

Si cela est le cas, tu as procédure d'extraction que tu n'auras pas manqué de prévoir dans ton briefing d'approche pour remonter à une altitude de sécurité sur une trajectoire adaptée.

Le G1000 SBAS passe effectivement en RNAV 1 après PT407.



Pour la compatibilité, qu'il soit SBAS ou pas, les deux supportent RNP APCH.

Mais franchement, on s'en fout car nous avons obligation d'exécuter la procédure tel qu'elle est codée dans la base, et nous n'avons pas d'autre choix. Est-ce que c'est parce que Garmin ne supporte qu'un seul segment MAPR, parce que c'est codé comme ça par Jeppesen... J'ai passé suffisamment de temps sur des trucs qui au final n'ont aucune importance et qui ne font qu'épaissir le brouillard.

Oui, on a une marge pour "API alternative" dans ENR1.5.5.6.3 (mais parfois il faut negocier a l'avance, regardes Le Bourget)

Maintenat, il faut convaincre Garmin d'afficher toutes les procedures (exclure un segment non supporte, faire en overlay RNAV1..)

Les RMG CONV, etaient simples et flexibles:
* La classique: "montee sur l'axe (compas) a 3000ft (altimetre)" puis "virage/guidage en dme/radar"
* Parfois il y a une "RMG alternative" (sans DME, sans VOR...), parfois meme 3*APIs publiees

Les RMG RNP, sont complexes et rigides:
* RMG RNP avec RNAV1 est le seul choix plausible en degradation RNP->RNAV (ou assitance RADAR/DME)
* RMG RNP "montee sur l'axe a 3000ft puis virage" ne sont pas supportees en RNAV1 (il faut etre RNP1 avec BARO/SBAS + compensation)
* Il y a une seule RMG en RNP (pas de "RMG RNP alternative") et la sequence SUSP/MAPT est obligatoire

Mais, "les boss du LEGO PBN" veulent rajouter l'API en "Advanced RNP": segments TA, TRF, RF en RNP1, RNP0.3, RNP0.1

Personellement, je ne vois pas l'utilite: bruit? terrain? espace? c'est hyper rare de faire une remise de gas !
Et en cas de degradation RNP, bah tu vas revenir au fameux "dans l'axe, altitude, virage..."

A LFST, je peux monter DEP OMNI, SID RNAV1, SID CONV, RMG CONV sans problem !
Ce n'est pas l'arc RF en API RNP qui va me tuer ou sauver?

Meme commentaire sur API RNP0.3 de Toussus, LeBourget, Pontoise...je ne savais meme pas qu'ils etaient "re-codee" RNAV1

Reglementairement, c'est simple:
* "RNP AR" en haut droit de la fiche, c'est interdit
* "RNP APCH" en haut droit de la fiche, c'est autorise

Pour l'equipement, il faut voir ce que Jeppesen, Garmin, Avydine, Proline decident d'afficher ou non?

Après une lecture, l’utilisation du RNP APCH hors du segment final fait partie du “A-RNP” (Advanced RNP), c’est un peu plus que “RNP APCH” avec GNSS (sans DME, INS, IRU) mais ce n’est pas encore une “RNP AR”.

“scalable RNP” avec “RF/RNP legs outside the Final Approach Segment (FAS) of the RNP APCH procedure”

https://www.faa.gov/about/office_org/headquarters_offices/avs/offices/afx/afs/afs400/afs420/order_ac_memo/%20A-RNP-Letter.pdf

https://www.faa.gov/documentLibrary/med ... date_2.pdf

Au US, c’est aussi très récent comme développement et la bonne nouvelle pas d’autorisation aux Part91 pour A-RNP mais il faut un équipement (par contre en extraction lors d’une perte de GNSS/SBAS, il faut être convaincu qu’on a moins de 1/1000 de mourir en final et 1/100 en remise de gas)

https://aerospace.honeywell.com/us/en/about-us/news/2022/07/understanding-advanced-rnp

Garmin donne la liste des equipments qui supportent ce A-RNP,
https://support.garmin.com/en-IE/aviation/faq/OhOmf8eu9v7ldhYxAsgea6/
Garmin permet de bouger son CDI à hors du segment final pour maintenir +/-0.3

Le choix de RNP0.3 partout hors segment final semble être plutôt un standard pour pour les hélicoptères en zone urbaine (et avions lents)…
https://www.eurocontrol.int/archive_download/all/node/11320
https://www.icao.int/APAC/Meetings/meet ... 0Specs.pdf

Effectivement, comme le disait Aviator, un G1000 même avec GDU >=13.0 soit ne sais pas voler de segments RF, soit ce n'est pas certifié sur le Cessna. En tout cas, les approches RNP de Strasbourg ne sont pas proposées.

Claude

F-CLS a écrit:Effectivement, comme le disait Aviator, un G1000 même avec GDU >=13.0 soit ne sais pas voler de segments RF, soit ce n'est pas certifié sur le Cessna

Le G1000 c'est compliqué à modifier car il figure dans le certificat de navigabilité du "C172-G1000", c'est possible que c'est un "manque de travail" par le constructeur

Les Cirrus, Pipers et Daher (SR22, PA46, TBM) sont au taquet pour "travailler", ahem "forcer", Garmin à supporter un cockpit intégré avec toutes les fonctionnalités sur terre, regardes pour "smart-glide" et "auto-land" (les Cessna, Bonanza, Mooney, Diamonds...ne sont pas au top sur ce côté)

Le GTN (XI) reste le seul choix fiable pour PBN en aviation générale, il est très capable et modulaire (3D pbn/overlay, RF leg...) et son code est facilement modifiable par Garmin. A ma connaissance, c'est le seul choix par défaut pour les Hélicos qui veulent faire des RNP tordues. Même les PC12s mettent un GTN (à côté du G1000) au lieu de passer aux autres Gx0000

Un C172 avec GTN+2×G5 peut faire RF à LFST mais je pense il faut activer cette fonction (pareil pour VNAV baro). Sur un avion Foxtrot, je pense le pilote est bien légalement bien couvert, ça reste une RNP APCH autorisée par l'AFMS et la doc Garmin suffira pour justifier la capability RF.

Sur un avion November, il faut demander à la FAA, même s'ils n'exigent pas des qualifications PBN, ni autorisations opérationnelle en P91, ils sont hyper strictes que ces choses soit noir/blanc dans l'AFM. Par exemple, KLN sur TB20 November n'est pas autorisé SID RNAV1 ou STAR RNAV1 alors qu'il est autorisé RNP APCH (ça ne m'étonne pas si FAA demande un PA digital capable de faire l'approche finale et interompue en mode couplé avec sequence LPV, TOGA, API pour faire la procédure à LFST)