Oh, si ergo, il y a quelques infos publiques sur le web.
On est d'accord sur une chose : Largement pas assez pour implémenter le système sur un simu pointu. Mais toutefois suffisamment pour décrire le concept général.
En toutes lettres :
Depuis plusieurs années, le Centre d’Expérimentations Aériennes Militaires (CEAM) teste le téléaffichage qui permet d’envoyer les ordres d’interception sur un dispositif récepteur placé sur le tableau de bord du chasseur. Pour la petite histoire, après de nombreux essais et des budgets très conséquents, ce dispositif n’a jamais fonctionné correctement, mais il est cependant l’ancêtre de la liaison 16.
Source :
http://www.anatc-tnb.fr/memoire/111121P ... DeLaDA.pdf
NB : ce paragraphe parle de 1969 ; on est donc à l'époque du Mirage III, pas du Mirage 2000 ; on peut imaginer que les problèmes de fiabilité évoqués ont peu à peu été résolus.
En revanche, cette date donne une indication de plus sur l'origine et le "concept" du système : à l'époque, l'ennemi à intercepter c'était le bombardier stratégique (nucléaire) volant en HA/MA et globalement "tout droit". Un dispositif permettant d'envoyer à l'intercepteur la position, l'altitude, la route de l'ennemi, de manière à ce qu'il puisse se placer efficacement pour un tir (avec des fenêtre fort réduites !) avait donc du sens. De même d'ailleurs pour les systèmes permettant au pilote d'entrer lui même des éléments de repérage du vilain bombardier, avant de demander aux calculos de son avion de "faire les maths" à sa place.
Souci : Dès que l'ennemi arrête de jouer le jeu (il n'est plus en HA, donc plus repérable de loin, ou encore il ne vole plus en ligne droite, car ses propres systèmes de nav ou son autonomie lui permettent d'adopter des tactiques de diversion), alors le système devient un gadget assez inutile. Sans doute l'une des raisons de son abandon
La mise en place sur tous les intercepteurs de systèmes automatisés de téléaffichage des ordres d'interception. Un tel système, qui permet de se passer de la voix du contrôleur d'interception, susceptible d'être brouillée, en la remplaçant par des messages très comprimés (...)
Source : Rapport du Sénat de 1983.
A cette époque, il est bien question de Mirage 2000.
= = = = = = = = = = =
Bacab a écrit :Que l'on soit d'accord: j'apprécie le travail de Razbam et je trouve que globalement ils ont fait un bon travail.
Cependant il y a certain parti pris concernant le radar qui me dérangent et notamment le fait qu'il affiche des faux contacts sur des cibles dont le brouilleur est allumé. Aucun autre radar ne fait ça dans DCS et je trouve que cet ajout est de trop. La remarque à déjà été faite, par ggtharos notamment, sur le forum officiel. Pour le coup ça mériterait qu'ils se calent sur le comportement des autres radar.
No soucy
Il s'agit effectivement d'un parti pris ; mais comme le soulignait jojo, ce n'est pas foncièrement différent des autres appareils de DCS, plutôt l'inverse. Alors à moins d'avoir une donnée publique indiquant que c'est différent sur RDI, ça ne me choque pas (pour être complet, on peut aussi préciser qu'il reste quelques bugs à régler sur l'implémentation).
Bacab a écrit :Par ailleurs je trouve que le radar décroche beaucoup. Zeus reconnaît le bug mais renvoie la balle à ED. Vu le temps que ça dure j'aimerais bien qu'ils trouvent un palliatif en interne.
Après il y a d'autres choses qui me dérangent mais qui sont de toutes façons absentes de tous les radars simulés dans DCS donc on va dire que c'est moins grave.
Le bug "reconnu", c'est bibi qui l'a qualifié, je peux donc en causer précisément : il ne concerne pas le PSIC (STT), mais uniquement les modes "scans" (y compris le PSID). Le constat fait, c'est que le pointage de l'antenne (donc du faisceau radar) rencontre une sorte de limitation (vitesse de déplacement) ; cette limitation n'impacte pas l'ensemble des déplacements => ce qui permet de dire que c'est un bug. Conséquence : lorsque l'avion porteur manœuvre franchement, le radar ne parvient pas à "compenser" assez vite dans certains cas, donc l'antenne se met à regarder "ailleurs que là où elle devrait" donc elle perd le lock PSID.
On est d'accord que ça fait longtemps. Je doute en revanche qu'il soit techniquement possible pour Razbam de développer un palliatif (sans recoder l'ensemble du radar par eux-même hors de tout SDK ED, et là j'imagine qu'on se heurte à des délais eux aussi fort longs, et à un impact négatif en matière de rentabilité pour Razbam).
Les autres cas de décrochage du radar (il y en a !) sont,
jusqu'à preuve du contraire, "légitimes" : Je veux dire par là que, malgré mon intérêt pour la question, je ne suis pas encore tombé sur un exemple documenté (track...) montrant un autre problème que celui évoqué plus haut. En revanche, il m'est arrivé (plus d'une fois) d'étudier la "plainte" d'un utilisateur qui liait ses pertes de lock au "bug" évoqué, pour découvrir qu'en fait c'était l'utilisateur/pilote qui s'y prenait mal, par exemple en laissant un ennemi le
beamer.
++
Az'
