Compatibilité Dsx Flarm

[Bert]

Commentaire du pilote du DG : on ne peut pas se fier à un système qui ne répond à aucune certification, dont les antennes sont montées n’importe comment par n’importe qui, sans aucune certification ni vérification de fonctionnement.

 

Je suis en parfait accord avec ce commentaire.

Une grosse partie du problème est là. Les Flarm (terme générique) sont montés par les clubs ou les propriétaires dans le meilleur des cas selon les recommandations de montage éditées par les constructeurs et/ou par les fournisseurs des antennes.

 

J'en ai fait l'expérience que le montage de l'antenne est crucial, surtout dans un fuselage carbone et avec la petite antenne fourni avec l'appareil (pour moi, la solution finale était l'antenne souple lambda/2, sur le conseil d'Urs d'après mes photos du cockpit).

 

Les commentaires que "je n'ai pas eu d'alerte dans telle ou telle situation" n'apportent aucune information sans connaissance des montages impliqués.

 

Par contre, avec un système bien monté j'avais l'impression qu'il donne des bonnes indications dans des paquets de planeurs en spirale avant le depart lors du CMVVM...

[AFox]

... le Flarm ne fonctionne pas en spirale ni lors d’un étagement vertical. D’après cet accident, il ne fonctionne pas non plus lorsque les trajectoires sont exactement face à face...

Les lacunes de la détection en spirale du Flarm sont connues mais ne sont pas préoccupantes car la règle en spirale, en présence d'autres planeurs, est de regarder dehors plutôt que son tableau de bord... par contre ce qui semble beaucoup plus préoccupant, à te lire, si cela était avéré, c'est la non détection lorsque les 2 trajectoires sont exactement face à face, qui pour moi était la raison d'être première et majeure d'un dispositif anti-collision!

 

Je le dis car j'ai moi-même été victime d'une quasi collision en sept. 2006 dans la région de Briançon avec un planeur en vol rigoureusement de face... notre étagement vertical n'a pas été supérieur à 2m. C'est un 'miracle' si la dérive n'a pas accroché! Bien sûr j'ai mis cela sur l'absence (probable) de Flarm à bord de l'autre planeur, mais maintenant j'ai comme un doute...

 

Ce serait bien que Flarm réponde aussi à ces interrogations ?

[jp PETIT]

Moi aussi, je peux parler d'une touchette ou les 2 planeurs avaient des flarms MAIS un des flarms n'était pas allumé ........

 

La chaine sera optimum si :

il y a compatibilité

s'il n'est pas en panne

s'il est branché

si l'antenne est installé correctement

....

un élément manquant et la chaine est rompue.

 

Il y a un système extraordinaire pour éviter ou plutôt diminuer les collisions, pas trop cher, perfectible mais qui sauvera certainement quelques vies dans les prochaines années

Alors faisons en sorte que tous les maillons soient bons en diffusant les erreurs a ne pas faire, les circonstances ou le système est moins bon plutôt que des remarques négatives qui ne feront pas avancer la sécurité

Le système est perfectible puisque des gens continuent à l'améliorer mais je trouve bien qu'il en soit conscient et le fasse

sans supplément de prix

Je ne vois aucun reproche a faire sur la mise à niveau ; on l'installe et au jour dit, la nouvelle version se met en marche ; les numéros de téléphone à 10 chiffres ont fonctionné de la même façon

 

Quand à la compatibilité flarm dsx actuelle , cela doit pas être des essais à 100 millions d'euros pour savoir c'est compatible : oui ou non

idem pour la version 4

 

salutations

[Godzilla]

Le risque de mettre dans la boucle les autorités de tutelle (DGAC ) est énorme.

Le premier truc qu'il feraient, c'est d'exiger un LSA pour le Flarm (ou assimilé), avec contrôle par un atelier radio homologué tous les 4 ans, sur le planeur. Ceci représenterait une tracasserie bien trop importante pour les clubs, qui vireront le bazar : fin du problème.

 

Mais c'est peut être le but recherché ...

[Robert Ehrlich]

...

Si tel est le cas, alors il suffit de l'écrire et de le signer à l'appui d'un relevé de tests assez simples à réaliser. ...

Malheureusement, un test est éventuellement capable de prouver et mettre en évidence une incompatibilité, mais jamais une compatibilité, tout ce qu'il peut dire c'est qu'il n'a pas mis en évidence d'incompatibilité, comme le test n'est jamais exhaustif, ça ne veut pas dire qu'il n'y en a pas. C'est pourquoi on peut comprendre l'attitude de FLARM qui dit en gros "c'est compatible parce que c'est la même chose". C'est bestial, mais ça marche.

Merci Robert, d'exprimer, avec ta précision habituelle, le fond du problème.

Car, en appliquant ta définition à ce que Jean-Marie a très bien dit, les T-Adviors et les Flarm volant depuis plusieurs années dans les Alpes, à ce jour jamais une incompatibilité n'a été mise en évidence !

 

Que ce soit dans les dictionnaires de la langues française, ou dans les vocabulaires courants de domaines tels que la télécommunication, l'informatique, l'électronique, et... l'aéronautique, le mot compatible veut dire "susceptible de s'accorder, pouvant être utilisé avec un autre dispositif, ou appareil, malgré leur origine différente".

Autrement, il faudrait utiliser le terme "identique". Une signification qui est loin d'être identique à la précédente...

Je ne sais pas si j'ai exprimé le fond du problème, mais j'ai l'impression de ne pas avoir été compris. Je suis bien d'accord "compatible" et "identique" n'ont pas la même signification, mais "identique" est le plus simple et le plus sûr moyen d'avoir du "compatible". On peut critiquer FLARM d'avoir choisi cette seule façon d'assurer la compatibilité, mais les accuser de faire cela pour des raisons bassement commerciales me semble d'une part être un procès d'intention et d'autre part sous estimer grandement la difficulté d'assurer la compatibilité par une autre moyen.

Au risque de me répéter je réaffirme que la vérification "opérationnelle" ne prouve rien, sauf quand elle prouve que ça ne marche pas. En tant qu'ex-enseignant d'informatique je peux dire que j'ai vu nombre de programmes d'étudiants dûment "testés", donnant le bon résultat, et pourtant faux.

Rien de plus simple, lit-on dans ce forum, il suffit que FLARM publie leur protocole et que ceux qui ne font pas "identique" s'y conforment. Vision naïve me semble-t-il, à laquelle je crois me souvenir au hasard de mes lectures sur le WEB que FLARM avait plus ou moins répondu qu'il avaient essayé, qu'un premier jet s'était révélé ne pas coller correctement avec la réalité et qu'ils avaient renoncé devant l'ampleur de la tache. Pour avoir travaillé pendant une bonne partie de ma vie professionnelle avec des protocoles normalisés (Ethernet, SCSI...) destiné à assurer de la compatibilité, je peux affirmer que ce n'est pas une petite affaire, les comités de normalisation qui rédigent ces protocoles sont plus nombreux que le personnel de FLARM et le temps qu'il mettent à sortir une spécification est supérieur à la durée d'existence de l'entreprise FLARM. Donc le "yaka plublier ..." est un peu simpliste, ça représente un boulot énorme si on veut le faire bien et si on le fait mal on risque de se faire accuser de diffuser de l'information fausse et de mettre en jeu la sécurité. En plus malgré tous les efforts dans ces domaines (Ethernet et SCSI) j'ai eu plus d'une fois l'expérience d'incompatibiltés involontaires, et ce de la part d'entreprises bien plus importantes que FLARM.

Et donc je réitère : vouloir obtenir la "compatibilité" par l'"identité", quand on est une toute petite entreprise avec un marché réduit me semble une démarche tout à fait défendable. Dois-je préciser que je n'ai aucun intérêt dans l'entreprise FLARM ?

[Régis]

Au risque de me répéter je réaffirme que la vérification "opérationnelle" ne prouve rien, sauf quand elle prouve que ça ne marche pas.

S'agissant de la sécurité anti-collision, C'est déjà pas si mal, non ?

Personnellement, j'ai d'autres préoccupations que de jouer sur les définitions des mots

Modifié le 23 février 2008 par Régis

[Robert Ehrlich]

Au risque de me répéter je réaffirme que la vérification "opérationnelle" ne prouve rien, sauf quand elle prouve que ça ne marche pas.

S'agissant de la sécurité anti-collision, C'est déjà pas si mal, non ?

Le plus simple serait que tu nous expliques, Robert, comment tu procèdes avec les Flarm de Beynes depuis deux ans ?

Je ne procède à rien du tout avec les Flarm de Beynes, on se contente de les installer et de faire confiance au constructeur. Ma conviction personnelle est que, comme dans tout système (partiellement) informatique, il y reste des erreurs non (encore) détectées, mais c'est également ma conviction que si on a deux réalisations indépendantes. on a aussi deux sources d'erreurs indépendantes.

Le "déjà pas si mal", d'accord, c'est mieux que rien, à condition de ne pas en conclure ce que ça ne prouve pas. Ne pas avoir montré d'incomptibilité n'est pas avoir montré la compatibilité. C'est comme la rubrique cinéma du Canard Enchainé : les films qu'on peut ne pas voir, ce ne sont pas des films qu'on ne peut pas voir.

[Yurek]

Je ne procède à rien du tout avec les Flarm de Beynes, on se contente de les installer et de faire confiance au constructeur. Ma conviction personnelle est que, comme dans tout système (partiellement) informatique, il y reste des erreurs non (encore) détectées, mais c'est également ma conviction que si on a deux réalisations indépendantes. on a aussi deux sources d'erreurs indépendantes. Le "déjà pas si mal", d'accord, c'est mieux que rien, à condition de ne pas en conclure ce que ça ne prouve pas. Ne pas avoir montré d'incomptibilité n'est pas avoir montré la compatibilité. C'est comme la rubrique cinéma du Canard Enchainé : les films qu'on peut ne pas voir, ce ne sont pas des films qu'on ne peut pas voir.

Te voilà bien imprudent, Robert...

On ne peut pas dire, en effet, que ton attitude soit "bestiale", envers ce dispositif !

Pour être sérieux : si j'ai rappelé les définitions des dictionnaires, c'était juste pour éviter les erreurs sémantiques. Comme toi, je pense qu'il n'est pas indifférent comment l'on dit, ce que l'on veut dire. Comme toi, je crois que la langue est un instrument précis, dont il est bien de profiter de la précision. Mais il ne s'agit pas non plus d'une discussion purement théorique et abstraite. Il s'agit d'un problème bien concret et d'un impact plutôt réel sur notre activité et même sur nos vies.

 

Concrètement donc - et non "dans l'absolu" - compatibilité, dont nous parlons ici, c'est la capacité des différents systèmes, avec certaines fonctions différentes, d'envoyer et de recevoir mutuellement des données "objectives" : les coordonnées GPS, l'altitude, et l'identification de l'aéronef. C'est tout !

C'est tout, en effet, ce qu'il faut à un Flarm, à un T-Advisor et à d'autres dispositifs qui apparaîtront peut-être un jour, pour se "voir" mutuellement.

Les autres données "propriétaires" qui servent à des fonctions spécifiques pour chaque fabricant, peuvent être envoyées également, afin d'être utilisées par chaque système à sa guise. Il n'y a aucune contradiction.

 

Si l'on veut compliquer les choses, on peut (tiens !) le faire et créer une usine à gaz, mais est-ce vraiment nécessaire ?

Par contre, si l'on veut rester simple et efficace, on peut faire communiquer les systèmes différents, sans aucun problème. Sinon, avec tous les fabricants et toutes les technologies qui existent et qui sont en concurrence permanente, la téléphonie mobile n'aurait pas fait un seul pas.

Modifié le 23 février 2008 par Yurek

[DT38]

...

Si tel est le cas, alors il suffit de l'écrire et de le signer à l'appui d'un relevé de tests assez simples à réaliser. ...

Malheureusement, un test est éventuellement capable de prouver et mettre en évidence une incompatibilité, mais jamais une compatibilité, tout ce qu'il peut dire c'est qu'il n'a pas mis en évidence d'incompatibilité, comme le test n'est jamais exhaustif, ça ne veut pas dire qu'il n'y en a pas. C'est pourquoi on peut comprendre l'attitude de FLARM qui dit en gros "c'est compatible parce que c'est la même chose". C'est bestial, mais ça marche.

Merci Robert, d'exprimer, avec ta précision habituelle, le fond du problème.

Car, en appliquant ta définition à ce que Jean-Marie a très bien dit, les T-Adviors et les Flarm volant depuis plusieurs années dans les Alpes, à ce jour jamais une incompatibilité n'a été mise en évidence !

 

Que ce soit dans les dictionnaires de la langues française, ou dans les vocabulaires courants de domaines tels que la télécommunication, l'informatique, l'électronique, et... l'aéronautique, le mot compatible veut dire "susceptible de s'accorder, pouvant être utilisé avec un autre dispositif, ou appareil, malgré leur origine différente".

Autrement, il faudrait utiliser le terme "identique". Une signification qui est loin d'être identique à la précédente...

Je ne sais pas si j'ai exprimé le fond du problème, mais j'ai l'impression de ne pas avoir été compris. Je suis bien d'accord "compatible" et "identique" n'ont pas la même signification, mais "identique" est le plus simple et le plus sûr moyen d'avoir du "compatible". On peut critiquer FLARM d'avoir choisi cette seule façon d'assurer la compatibilité, mais les accuser de faire cela pour des raisons bassement commerciales me semble d'une part être un procès d'intention et d'autre part sous estimer grandement la difficulté d'assurer la compatibilité par une autre moyen.

Au risque de me répéter je réaffirme que la vérification "opérationnelle" ne prouve rien, sauf quand elle prouve que ça ne marche pas. En tant qu'ex-enseignant d'informatique je peux dire que j'ai vu nombre de programmes d'étudiants dûment "testés", donnant le bon résultat, et pourtant faux.

Rien de plus simple, lit-on dans ce forum, il suffit que FLARM publie leur protocole et que ceux qui ne font pas "identique" s'y conforment. Vision naïve me semble-t-il, à laquelle je crois me souvenir au hasard de mes lectures sur le WEB que FLARM avait plus ou moins répondu qu'il avaient essayé, qu'un premier jet s'était révélé ne pas coller correctement avec la réalité et qu'ils avaient renoncé devant l'ampleur de la tache. Pour avoir travaillé pendant une bonne partie de ma vie professionnelle avec des protocoles normalisés (Ethernet, SCSI...) destiné à assurer de la compatibilité, je peux affirmer que ce n'est pas une petite affaire, les comités de normalisation qui rédigent ces protocoles sont plus nombreux que le personnel de FLARM et le temps qu'il mettent à sortir une spécification est supérieur à la durée d'existence de l'entreprise FLARM. Donc le "yaka plublier ..." est un peu simpliste, ça représente un boulot énorme si on veut le faire bien et si on le fait mal on risque de se faire accuser de diffuser de l'information fausse et de mettre en jeu la sécurité. En plus malgré tous les efforts dans ces domaines (Ethernet et SCSI) j'ai eu plus d'une fois l'expérience d'incompatibiltés involontaires, et ce de la part d'entreprises bien plus importantes que FLARM.

Et donc je réitère : vouloir obtenir la "compatibilité" par l'"identité", quand on est une toute petite entreprise avec un marché réduit me semble une démarche tout à fait défendable. Dois-je préciser que je n'ai aucun intérêt dans l'entreprise FLARM ?

 

Bravo Robert

 

Je crois que tu résumes exactement la situation!

 

Les "yaqua publier" sont un peu léger en la matière et je crois que ce n'est pas idiot en l'état de l'évolution du Flarm de le laisser vivre...C'est déjà bien assez compliqué comme ça!

 

Pour l'instant, même si ça fait un peu "soviétique" je préfère avoir un système "monopolistique" mais a peu près sur et bien suivi qu'un système ou tout le monde joue avec...

 

je n'ai également aucun intérêt avec l'entreprise flarn sinon que d'avoir la satisfaction d'avoir participer à son lancement!

[5 X]

En pratique, les deux questions fondamentales que se posent les utilisateurs de T-advisor (ou acquéreurs potentiels) sont:

 

1/ quels tests precis (procédure détaillée, durée, resultats) fait DSX sur chaque version du protocole de FLARM pour prétendre à la compatibilité ? C'est fondamental pour lever les réticences légitimes exprimées plus haut à intégrer le produit dans un parc Français constitué a 99.9% de FLARM et produits licenciés FLARM.

 

2/ à quelle date DSX va-t-il fournir a sa base installé une version de code dûment testée (cf point 1/) pour T-Advisor, compatible avec FLARM 4.xx ?

 

Yurek,

une réponse précise (pas de bla-bla, une date ferme et des infos techniques complètes et précises) à ces deux points permettrait d'y voir plus clair sur la viabilité de la strategie de DSX qui est de ne pas acquérir auprès de FLARM ses élements de HW et SW, mais de décoder le protocole de FLARM pour ensuite le coder dans le HW propriétaire DSX. Ce choix de stratégie leur appartient, les pb induits entre DSX et FLARM aussi, mais les utilisateurs (ou potentiels) doivent avoir une réponse satisfaisante et précise a ces deux questions, faute de quoi ce produit risque fort de voir sa pénétration dans le marché Francais sérieusement limitée.

[Yurek]

Yurek,

une réponse précise (pas de bla-bla, une date ferme et des infos techniques complètes et précises) à ces deux points permettrait d'y voir plus clair sur la viabilité de la strategie de DSX qui est de ne pas acquérir auprès de FLARM ses élements de HW et SW, mais de décoder le protocole de FLARM pour ensuite le coder dans le HW propriétaire DSX. Ce choix de stratégie leur appartient, les pb induits entre DSX et FLARM aussi, mais les utilisateurs (ou potentiels) doivent avoir une réponse satisfaisante et précise a ces deux questions, faute de quoi ce produit risque fort de voir sa pénétration dans le marché Francais sérieusement limitée.

Daniel,

M'as-tu déjà vu faire quelque part du bla-bla ?

Et si tu penses que oui, pourrais-tu en donner un exemple ?

Comme tout un chacun, je fais des erreurs, je me trompe parfois, mais je ne pratique jamais une langue de bois. Aussi, je répondrai à tes questions de façon précise et claire le plus vite possible. Pour être très précis, j'apporterai donc très vite une réponse du fabriquant.

 

Quant au risque que nous supportons, DSX et moi-même, sur le marché français, eh bien, cela fait partie de la vie. En présentant un produit nouveau, nous savions que les clients peuvent aussi bien l'accepter que le rejeter. Nous en tenions compte, et nous sommes prêts à en assumer toutes les conséquences : aussi bien le succès que l'échec. Personnellement, ayant introduit en France des remorques, des parachutes, des treuils, des câbles, et j'en passe, des marques inconnues ici auparavant, j'ai ramé plusieurs fois, et parfois très longtemps, avant de réussir à convaincre les premiers clients. C'est normal ! Et il n'y a aucune "sécu" qui pourrait me garantir quoi que ce soit. Pour être clair et précis : les réticences des clients, justifiées ou pas, sont toujours légitimes, quelque soit la position des concurrents, dominante ou pas...

 

Comme il est légitime le choix de F-T de développer cet argument de compatibilité, et de jouer de tout poids de son monopole de fait, pour éviter de discuter de vrais problèmes technologiques. Ils ont droit d'utiliser tous les moyens, n'est-ce pas ?

Je sais bien (puisque Robert nous l'a rappelé) que je n'arriverai jamais à prouver que je ne suis pas un chameau, mais restons plus terre-à-terre. Comme j'ai déjà expliqué deux contributions plus haut, il n'y a aucune contradiction entre un protocole de transmission des données de base (coordonnées, altitude, identification), et des données propriétaire nécessaires à des fonctions propriétaire. Un protocole de communication public, simple et stable, qui ne gêne en rien des fonctions particulières des différents fabricants est parfaitement possible.

En te sachant spécialiste en matière de télécommunication, je te serais gré de confirmer, ou d'infirmer ce constat.

 

Je te remercie d'avoir pointé ton doigt sur un constat pour moi essentiel, que le problème n'est pas vraiment technologique, mais commercial.

Comme tu le suggères, le choix des consommateurs peut effectivement se faire, non pas sur les avantages techniques réelles des uns et des autres, mais sur une question de "l'impossible compatibilité". Comme tu l'as justement rappelé, DSX n'envisage pas d'utiliser ni le matériel, ni le logiciel de Flarm-Technology. Dans le domaine d'avertissement de proximité, il n'est pourtant pas possible que plusieurs protocoles existent en même temps et en parallèle. Un nouveau intervenant est donc bien obligé d'accepter le protocole du fabricant dominant le marché. Toute tentative d'introduire un protocole différent serait non seulement suicidaire pour l'entreprise, mais surtout criminelle envers les utilisateurs !

 

En attendant la réponse de DSX à tes deux questions, disons clairement : DSX s'est adapté au choix de Flarm-Technology en ce qui concerne le protocole de communication (et il continue à le faire). Tout changement de ce protocole ne peut être qu'un fait de prince de Flarm-Technology, destiné uniquement à évincer son concurrent.

Si les tests de compatibilité, dont tu parles, doivent porter sur le protocole de communication, autrement dit, sur la compatibilité au sens propre (ou, pour utiliser un synonyme : inter-opérabilité), ils sont faisables et je n'y vois pas de problème (que Robert me pardonne !). Si une instance vélivole (Commission Sécurité fédérale, CNVV, ou autres) voulait le faire, DSX mettra des appareils à sa disposition. Je pense qu'il faut pour cela un organisme indépendant.

Si ces tests devaient prouver la "compatibilité" au sens utilisé par F-T, c'est à dire vérifier, si le T-Advisor est identique au Flarm, je ne vois pas d'intérêt à y procéder, car par définition, ce n'est pas le cas. DSX ne fera pas de Flarm dans une boîte estampillée DSX.

Après, il reste toujours la question, est-ce que les consommateurs veulent ou non, avoir un choix ? Ou préfèrent-ils, comme DT38, un monopole (le qualificatif "soviétique" est inutile : un monopole est un monopole, c'est tout) ?

 

Bons vols, quel que soit votre avertisseur !

[AFox]

Je ne sais pas si j'ai exprimé le fond du problème, mais j'ai l'impression de ne pas avoir été compris. Je suis bien d'accord "compatible" et "identique" n'ont pas la même signification, mais "identique" est le plus simple et le plus sûr moyen d'avoir du "compatible".

Mon cher Robert,

Je suis spectateur de ce débat, n'ayant pas plus d'intérêt que toi ni chez FLARM Tech. ni chez DSX, mais je ne puis te suivre dans la sémantique de ton dernier message. C'est d'abord une lapalissade d'écrire que identique est mieux que compatible qui me fait penser aux défenseurs du fameux 'principe de précaution'! Ton intervention n'apporte rien de concret car tu 'planes' au dessus de la réalité du sujet précis en emboîtant la réponse (commerciale) de Urs (FLARM) de ne plus vouloir publier de protocole de communication des nouvelles versions au motif que FLARM avait déjà dépensé beaucoup trop de temps et d'argent pour faire émerger l'appareil et que vu la complexité du système cela lui coûterait trop à présent de mettre par écrit un document fiable contradictoire et que le risque d'incompatibilité entre appareils serait trop grand. Un autre intervenant a même écrit: je fais confiance au constructeur (FLARM). Vous avez tord tous les 2, désolé, car aucun progrès n'est durablement possible dans une situation de monopole (cf. IBM qui s'est enrichi honteusement pendant 30 ans). Il est vrai que si 10.000 FLARM ont été vendus cela représente un CA de 5 millions d'€ de nature à faire oublier les engagements vertueux de la petite équipe du début de l'opération...

Chacun se souvient des problèmes de fiabilité de l'électronique de FLARM et personne n'a eu jusqu'à présent, à ma connaissance, l'opportunité de 'tester' professionnellement les qualités de détection du matériel (au sens d'une certification, càd quelque chose de sérieux). Le dispositif anti-collision n'a de valeur que si sa fiabilité est sans reproche. Si un doute subsiste c'est pire que de ne pas avoir ce dispositif à bord! Certes il faut continuer à regarder dehors, mais si un dispositif nous y aide avec assurance ce serait tellement mieux. Bref, ce ne serait pas si mal que des concurrents, non inféodés, apportent un souffle d'air frais autour de ce dispositif en vue notamment d'en assurer la relève si besoin le moment venu et les Autorités du VV au niveau mondial devraient faire pression pour clarifier la situation monopolistique dans laquelle elles se sont apparemment et pour l'instant fait emprisonner par FLARM Tech.

[Jean-Philippe Chenu]

AFox, 24 février: " Le dispositif anti-collision n'a de valeur que si sa fiabilité est sans reproche. Si un doute subsiste c'est pire que de ne pas avoir ce dispositif à bord! Certes il faut continuer à regarder dehors, mais si un dispositif nous y aide avec assurance ce serait tellement mieux. "

 

Personnellement, ce nest pas mon expérience avec le Flarm: si je pourrais avoir des doutes sur la fiabilité avec tout ce qui précède dans ces échanges, je constate qu'utilisateur du Flarm depuis 2 ans, je regarde plus attentivement à l'extérieur car vexé que Flarm me signale un autre planeur non aperçu. C'est d'ailleurs un des premiers arguments en faveur d'un tel dispositif. Et je trouve regrettable qu'il est encore trop de pilotes (et clubs) "attendant pour voir". Acheter aujourd'hui un dispositif anti-collisions comme Flarm ou DSX (compatible...) est bien un plus à la sécurité malgré tout ce qui précède (et j'ai aussi,rapidemment, installé l'antenne de 5X poiur améliorer les choses). Ce n'est donc pas pire que de ne pas en avoir!

 

J'irai plus loin: c'est un excellent dispositif pédagogique pour la formation de nouveaux pilotes pour la raison citée ci-dessus. Ah j'imagine l'élève et l'instructeur en K13 qui n'ont pas vu un autre planeur!!

 

Donc, si le Flarm ne fonctionnerait pas dans certains cas, c'est effectivement comme si je n'en avais pas, j'ai à regarder dehors. Et si le Flarm fonctionne, la conclusion est la même: j'ai à regarder dehors!

Quant à l'aspect commercial et le désaccord actuel je lis les échanges avec beaucoup d'intérêt

[JMG]

Bonjour

 

Voici une communication d'URS de chez FLARM.

 

Il y a le texte original en Anglais, je vous ai aussi fait une traduction en Français.

 

JMG

 

Salut Jean Marcel,

Si tu pouvais traduire le texte ci-dessous et le poster sur « planeur.net » avec l'original anglais...

J'espère que cela expliquera mieux notre position.

 

Remerciements

Urs

 

----------------------------------------------------------------------------

 

Dans la situation actuelle, comme nous le voyons :

- Nous ne pouvons pas garantir le comportement de FLARM quand d'autres systèmes "imitent" des signaux FLARM

- Sans action de notre part, bientôt nous allons avoir 10 + fabricants avec "des systèmes compatibles", plus d’incalculables unités faites artisanalement à la maison.

- De ma part, déclarer la pleine compatibilité avec le système de quelqu'un d'autre est, comme, correctement observé dans cette discussion, logiquement impossible.

- Si néanmoins nous essayons, il est impossible d'évaluer la conception d’un dispositif exotique contre un autre dispositif, dans toutes les situations (50 planeurs + le remorqueur à chaque compétitions ?)

- La structure de compatibilité appliquée est aujourd'hui très maigre et fortement efficace tant dans la technologie que dans la direction.

- Nous avons désigné les choses que l’on doit considérer pour la pleine compatibilité dans notre document :

http://www.flarm.com/product/Compatibility...rations_1_1.pdf

- C'est non seulement le vol à voile et ses exigences, c’est aussi des flottes entières d'hélicoptères commerciaux et militaires qui ont aussi été équipé. FLARM doit satisfaire rapidement des demandes croissantes.

- Comme toujours, méfiez vous des solutions qui sont présentés comme "simples".

 

À moins qu'une solution supérieure soit trouvée (voir Regis post, ci-dessus) nous nous mettons en situation pour tenir en fonctionnement sûr, les plus de 10000 FLARM existant.

Nous sommes bien conscients que de nous battant pour une solution efficace et sérieusement réfléchie, est une mauvaise solution, à court terme pour notre image de marque, contre quelques personnes qui ont poursuivi des chemins qui sont, de notre point de vue, à courte vue.

Néanmoins nous sommes convaincus que nous agissons dans le meilleur intérêt de la communauté d'aéronautique.

 

--------------------------

 

La plupart des problèmes rencontrés actuellement sont causés par des installations qui n'observent pas les directives données dans les manuels d'installation.

Nous avons offert l'analyse 3D de la gamme de transmission (en soumettant les fichiers de vol via l'email) depuis l'Été ' 07. Voir l'échantillon à :

http://www.flarm.com/support/785T2961.pdf

Avec le prochain V4.0 chaque utilisateur de FLARM sera capable de vérifier leur installation et ses performances via une interface web simple

(disponible vers le 08 mars).

 

--------------------------

 

Je voudrais faire des excuses du ton du dernier post sous mon nom, dans « planeur .net », c’était une conversation privée entre JM Gau et moi. Suite à une mauvaise communication entre nous, cela a été mis en ligne.

 

Bons vols !

 

Urs

 

 

The current situation, as we see it:

- We cannot guarantee the behavior of FLARM when other systems "emulate" FLARM signals

- With no action from us, soon we have 10+ manufacturers with "compatible systems", plus uncountable homemade units

- A self declaration of full compatibility to someone else's system is, as correctly observed in this discussion, logically

impossible

- If tried nevertheless, it is unworkable to test everybody's design against everybody's in all situations (50+ aircraft at

competitions?)

- The compatibility framework applied today is very lean and highly efficient in both technology and governance

- We have pointed out things that must be considered for full compatibility in our document at:

http://www.flarm.com/product/Compatibility...rations_1_1.pdf

- This is not only about gliding and its requirements, entire fleets of commercial helicopters and military training aircraft have

been equipped. FLARM must satisfy rapidly expanding demands.

- As always, be wary of simple solutions

 

Unless a superior solution is found (see Regis posting, above) we *will* put ourselves into the line of fire to keep the over 10000

existing FLARM operate safely.

We are well aware that fighting for an efficient and well thought out solution is bad for our short term reputation as it will upset

a few people who have pursued paths that are, in our view, short sighted.

Nevertheless we are convinced that we act in the best interest of the aviation community.

 

--------------------------

 

Most problems are caused by installations that do not comply with the guidelines given in the installation manuals.

We have offered 3D analysis of the transmission range (by submitting flight logs via email) since Summer '07. See sample at:

http://www.flarm.com/support/785T2961.pdf

With the upcoming v4.0 release all FLARM users will be able to check their installation and performance via a simple web interface

(available mid March 08).

 

--------------------------

 

I would like to apologize for the tone of the last posting, which was meant to be a private conversation to JM Gau but got online by

my miscommunication.

 

Enjoy gliding!

Urs

Modifié le 26 février 2008 par JMG

[Bert]

Comme j'ai déjà expliqué deux contributions plus haut, il n'y a aucune contradiction entre un protocole de transmission des données de base (coordonnées, altitude, identification), et des données propriétaire nécessaires à des fonctions propriétaire. Un protocole de communication public, simple et stable, qui ne gêne en rien des fonctions particulières des différents fabricants est parfaitement possible.

 

Sans avoir une position de préférence pour FT ou DSX, il faudrait quand même mentionner que le protocol de transmission contient également la trajectoire future estimée de l'émetteur, ce qui est un élement un peu plus que "basique" (car fonction de plein de calculs spécifiques), et que le Flarm compare les trajectoires des autre émetteurs avec la sienne pour en décider d'un danger potentiel.

Je peux sans autre imaginer que la comparaison entre deux trajectoires estimées sur deux bases de calcul/model différents, ça peut causer des problèmes de compatibilité assez subtils.

[Yurek]

Bonsoir,

Voici la réponse de DSX aux questions de Daniel :

"DSX ne "prétend" pas à une compatibilité, mais l'applique. Aujourd'hui, la compatibilité signifie que chaque système transmet des données utilisables par d'autres, travaillant "à sa manière", qu’il soit ou non en présence d'autres systèmes. Comme indiqué ci-après, ce serait sans aucune importance au cas, où les données "objectives" étaient les seules employées pour exécuter les calculs.

 

1) Les tests effectués.

Après une longue conception assistée par ordinateur et une analyse approfondie, des centaines d'heures d'essais en vol ont été effectuées, avec différents nombres des aéronefs équipés des T-Advisors et de Flarms. Depuis des cas simples d'un aéronef équipé d'un système et d'un autre avec l'autre système, aux cas de nombreux aéronefs avec des T-Advisors et Flarms, volant ensemble. Après des campagnes initiales d'essai, les tests en continu sont toujours régulièrement effectués par les pilotes choisis et indépendants, volant avec des T-Advisors et Flarms dans de conditions variées.

Les conditions testées incluent : le vol thermique en spirale, où on a constaté qu'aucun des systèmes ne garantit la détection correcte des menaces (comme cela a déjà été remarqué dans de différents forum par des pilotes de différentes régions), le vol en circuit, vol de pente, recherche des thermiques, ainsi que vol avec des trajectoires aléatoires.

Les membres de DSX ont réalisé les simulateurs de vol certifiés par la FAA, et le simulateur du modèle de vol d'un fabricant renommé d'avions d'entraînement militaire - nous invitons tout le monde à consulter la présentation de compagnie sur le nouveau site Web : DSX).

Avec cette forte compétence que DSX possède dans le domaine de simulation de vol, il a développé un simulateur temps réel (HIL) pour tester le système d'avertissement du trafic "à la maison". Ce simulateur peut générer n'importe quel type des conditions de vol et enregistrer toutes les données pour le re-traitement et le référencement. C'est un outil avancé qui permet de générer bien davantage de cas des conditions de vol que les vrais essais en vol. Naturellement, les essais en vol réels ont été et restent indispensables.

L'interaction correcte entre les deux systèmes a été démontrée en vol.

 

2) DSX est clairement opposé tout changement [du protocole] qui impliquerait une incompatibilité arrière des systèmes d'avertissement du trafic, ou tenterait d'empêcher la concurrence dans un secteur qui en bénéficierait beaucoup. Si un système a besoin d'une telle solution, cela signifie une erreur lourde à la base de sa philosophie de conception, comme expliqué ci-après.

En toute logique, nous sommes bien obligés à suivre la décision de l'autre constructeur [au sujet des changements], comme nous l'avons fait jusqu'ici, et comme nous ferons à l'avenir, mais nous disons clairement et fermement que c'est une mauvaise façon de procéder, et nous pensons que toute la communauté [vélivole] devrait s’y opposer.

 

Commentaires :

Les questions posées impliquent une certaine façon de voir, qui est restrictive et concentrée seulement sur la façon dont fonctionne le système Flarm. Nous proposons de regarder les systèmes d'avertissement du trafic, comme ils ont été étudiés et mis en application dans les décennies passées pour différentes applications, en se libérant des limitations qui sont aujourd'hui imposées par ce choix de conception.

La voie la plus facile pour réaliser un système d'avertissement du trafic est d'avoir la transmission des données de base brutes, comme les coordonnées, l'altitude, la vitesse et une identification. Ces données, à part l'identification, peuvent provenir d'un GPS. Certains indicateurs, peu nombreux, comme la définition du type d'aéronef et de conditions de vol, peuvent être facultatifs, et ils ne sont pas essentiels pour exécuter correctement l'avertissement du trafic.

Ces paramètres permettent à l'unité de réception :

- savoir, où l'(es) autre(s) se trouve(nt)

- comparer les deux (ou davantage de) positions

- si quelqu'un (constructeur) le souhaite, il peut mettre en application tous les algorithmes qu'il veut (pour faire de la prédiction de position ou toute autre chose), faire exécuter tous les calculs à l'unité de réception, et avertir le pilote selon toute procédure spéciale voulue.

Avec cette démarche, le problème de compatibilité n'existera plus, soudainement disparu !

Il n'y a aucun problème avec les anciens, actuels et futurs systèmes d'avertissement du trafic de n'importe quel constructeur : les données échangées sont des "vraies" données (coordonnées, altitude, vitesse et identification) et le niveau du traitement de ces données est laissé à chaque constructeur. Chaque produit pourra alors offrir des fonctions selon ses calculs internes, et chaque pilote pourra choisir le produit qui lui convient le mieux.

Chaque système avertit alors son pilote, selon les critères programmés (prévision de trajectoire, vitesse d'approche ou autre).

Si une performance minimum est exigée, afin de s'assurer que chaque système exécute vraiment la fonction de l'avertissement du trafic, alors une règle de base (une norme) doit être définie. Ce n'est en rien difficile à faire, et cela peut être maintenu à un niveau minimum, disons par exemple que tous les systèmes doivent avertir des pilotes, quand un temps calculé avant l'impact, basé simplement sur la vitesse d'approche divisée par la distance, est au-dessous d'une certaine valeur. Ceci garantit que tous les systèmes ont un niveau de performance minimale requis. Les fonctions et performances supplémentaires sont "des plus" qui différencient les systèmes.

 

Il n'y a nul besoin de transmettre davantage, pour avoir un système d'avertissement du trafic.

Le T-Advisor fournit au pilote des indications basées seulement sur les données minimales énumérées ci-dessus : tous les calculs sont exécutés intérieurement et sont par conséquent indépendants des calculs exécutés par d'autres dispositifs. Ceci garantit que n'importe quelle version de T-Advisor peut fonctionner avec tout autre et avec n'importe quel dispositif qui transmet ses coordonnées, altitude et identification : l'ensemble minimum de données pour identifier la position de l'autre aéronef.

Avec cette solution, tous les problèmes dérivant de la "compatibilité" disparaissent ; il n'y a aucun besoin d'exécuter une mise à jour synchronisée des micrologiciels et il n'y a aucun problème de compatibilité parmi différents systèmes : des nouveaux systèmes offriront des algorithmes probablement plus raffinés et des nouvelles fonctions, mais ceci n'aura aucun impact sur des unités plus anciennes qui pourront continuer à travailler sans limitations. Ceci garantirait que chaque unité fournie exécuterait son travail de sécurité n'importe quand, tout le temps et partout.

 

La conclusion :

Le problème entier de la "compatibilité" dérive du choix de transmettre des données calculées au lieu de données "brutes", c'est à dire des données minimales et objectives : coordonnées, altitude et identification. À notre avis, c'est une erreur fondamentale dans la conception d'un système d'avertissement du trafic.

Lucas Marchesini / DSX"

 

Le texte original en anglais est disponible à la demande.

[AFox]

... la trajectoire future estimée de l'émetteur,...

Sans vouloir entrer dans la polémique, n'étant pas impliqué de surcroît dans le développement du dispositif, on peut penser d'un point de vue théorique que la trajectoire peut être:

- soit une droite, définie par 2 points, points correspondant à 2 enregistrements (successifs ou non, question de précision) émanent du GPS. Les paramètres de géométrie analytique définissant la droite dans l'espace sont basiques,

- soit une courbe, définie par une succession de 3 ou 4 ou + de points. Là encore, le polynôme de cette courbe est défini de manière basique.

La précision de rapprochement des trajectoires, et donc la validité de prédiction de collision (propre à chaque appareil), repose trés étroitement sur la justesse de position des points GPS, surtout s'ils sont rapprochés (calcul d'erreur), et des paramètres de trajectoire qui en découlent, mais cela n'a rien à voir, a priori, avec le choix du protocole de communication!

 

L'utilisation du FLARM depuis le début m'a montré que le 'faisceau' de prédiction devait être plutôt calé 'large', car lorsque les planeurs sont encore à 1 km de distance, le FLARM voit un danger même lorsque le croisement prévisible se fait à 200m voire plus ce qui mobilise l'attention inutilement, n'ayant pas d'information affichée sur la distance du danger potentiel (ce qui manque) et nuit à son efficacité. La release 4.0 apportera-t-elle une amélioration?.

'Faire confiance au constructeur' maintient l'utilisateur dans l'ignorance des réelles caractéristiques des appareils!

 

C'est là, je me répète, qu'une émulation entre constructeurs serait bénéfique, selon moi.

[lexupol]

Comme j'ai déjà expliqué deux contributions plus haut, il n'y a aucune contradiction entre un protocole de transmission des données de base (coordonnées, altitude, identification), et des données propriétaire nécessaires à des fonctions propriétaire. Un protocole de communication public, simple et stable, qui ne gêne en rien des fonctions particulières des différents fabricants est parfaitement possible.

 

Sans avoir une position de préférence pour FT ou DSX, il faudrait quand même mentionner que le protocol de transmission contient également la trajectoire future estimée de l'émetteur, ce qui est un élement un peu plus que "basique" (car fonction de plein de calculs spécifiques), et que le Flarm compare les trajectoires des autre émetteurs avec la sienne pour en décider d'un danger potentiel.

Je peux sans autre imaginer que la comparaison entre deux trajectoires estimées sur deux bases de calcul/model différents, ça peut causer des problèmes de compatibilité assez subtils.

 

Questions de néophyte, pour les transpondeurs existe-t-il qu'un seul fabriquant ? Ou plusieur fabriquants utilisant les mêmes composants ? ou plusieurs fabriquants utilisant un même protocole ?

Ils ont bien dû trouver un moyen de tester pour savoir s'ils étaient compatibles ?

 

Paul

[EricP]

Ils ont bien dû trouver un moyen de tester pour savoir s'ils étaient compatibles ?

 

Bien sur, mais comme cela à déjà été dit plus haut, il a fallu pour cela éditer une spécification extremement précise et rigoureuse (ce qui coute très cher, plus que les 5 millions d'euros déja évoqué 10_000*500 euros)

auxquels if faudrait ajouter plusieurs millions d'euros de tests de certification ... et dans ce cas on réinvente le transpondeur mais pas un systeme à 500 euros ... il faut choisir ...

[Yurek]

et dans ce cas on réinvente le transpondeur mais pas un systeme à 500 euros ... il faut choisir ...

Justement ! Tu as raison, Eric : ce n'est pas la peine de compliquer.

Une sophistication inutile rend d'ailleurs l'ensemble non seulement plus cher, mais aussi davantage exposé aux bogues et aux pannes...

Il faut rester simple : coordonnées, altitude, identification. Point.

[Philoo]

Il faut rester simple : coordonnées, altitude, identification. Point.

 

Tout à fait d'accord. La vitesse, le cap et trajectoire probable de l'aéronef sont des calculs hasardeux qui dépendent principalement de la précision et de la fréquence de localisation du GPS. De plus on ne peut pas tenir compte des intentions du pilote.

 

Par contre une question me turlupine: au niveau des transmissions des infos, cela se fait par radio, sur une même fréquence obligatoirement, mais à partir de combien de Flams (ou compatibles) dans le même périmètre risque-t-il d'y avoir des brouillages?? Quel est l'intervalle de temps entre deux transmission de données d'un même émetteur??

[5 X]

Bonsoir,

Voici la réponse de DSX aux questions de Daniel :

"DSX ne "prétend" pas à une compatibilité, mais l'applique. Aujourd'hui, la compatibilité signifie que chaque système transmet des données utilisables par d'autres, travaillant "à sa manière", qu’il soit ou non en présence d'autres systèmes. Comme indiqué ci-après, ce serait sans aucune importance au cas, où les données "objectives" étaient les seules employées pour exécuter les calculs.

 

1) Les tests effectués.

Après une longue conception assistée par ordinateur et une analyse approfondie, des centaines d'heures d'essais en vol ont été effectuées, avec différents nombres des aéronefs équipés des T-Advisors et de Flarms. Depuis des cas simples d'un aéronef équipé d'un système et d'un autre avec l'autre système, aux cas de nombreux aéronefs avec des T-Advisors et Flarms, volant ensemble. Après des campagnes initiales d'essai, les tests en continu sont toujours régulièrement effectués par les pilotes choisis et indépendants, volant avec des T-Advisors et Flarms dans de conditions variées.

Les conditions testées incluent : le vol thermique en spirale, où on a constaté qu'aucun des systèmes ne garantit la détection correcte des menaces (comme cela a déjà été remarqué dans de différents forum par des pilotes de différentes régions), le vol en circuit, vol de pente, recherche des thermiques, ainsi que vol avec des trajectoires aléatoires.

Les membres de DSX ont réalisé les simulateurs de vol certifiés par la FAA, et le simulateur du modèle de vol d'un fabricant renommé d'avions d'entraînement militaire - nous invitons tout le monde à consulter la présentation de compagnie sur le nouveau site Web : DSX).

Avec cette forte compétence que DSX possède dans le domaine de simulation de vol, il a développé un simulateur temps réel (HIL) pour tester le système d'avertissement du trafic "à la maison". Ce simulateur peut générer n'importe quel type des conditions de vol et enregistrer toutes les données pour le re-traitement et le référencement. C'est un outil avancé qui permet de générer bien davantage de cas des conditions de vol que les vrais essais en vol. Naturellement, les essais en vol réels ont été et restent indispensables.

L'interaction correcte entre les deux systèmes a été démontrée en vol.

 

2) DSX est clairement opposé tout changement [du protocole] qui impliquerait une incompatibilité arrière des systèmes d'avertissement du trafic, ou tenterait d'empêcher la concurrence dans un secteur qui en bénéficierait beaucoup. Si un système a besoin d'une telle solution, cela signifie une erreur lourde à la base de sa philosophie de conception, comme expliqué ci-après.

En toute logique, nous sommes bien obligés à suivre la décision de l'autre constructeur [au sujet des changements], comme nous l'avons fait jusqu'ici, et comme nous ferons à l'avenir, mais nous disons clairement et fermement que c'est une mauvaise façon de procéder, et nous pensons que toute la communauté [vélivole] devrait s’y opposer.

 

Commentaires :

Les questions posées impliquent une certaine façon de voir, qui est restrictive et concentrée seulement sur la façon dont fonctionne le système Flarm. Nous proposons de regarder les systèmes d'avertissement du trafic, comme ils ont été étudiés et mis en application dans les décennies passées pour différentes applications, en se libérant des limitations qui sont aujourd'hui imposées par ce choix de conception.

La voie la plus facile pour réaliser un système d'avertissement du trafic est d'avoir la transmission des données de base brutes, comme les coordonnées, l'altitude, la vitesse et une identification. Ces données, à part l'identification, peuvent provenir d'un GPS. Certains indicateurs, peu nombreux, comme la définition du type d'aéronef et de conditions de vol, peuvent être facultatifs, et ils ne sont pas essentiels pour exécuter correctement l'avertissement du trafic.

Ces paramètres permettent à l'unité de réception :

- savoir, où l'(es) autre(s) se trouve(nt)

- comparer les deux (ou davantage de) positions

- si quelqu'un (constructeur) le souhaite, il peut mettre en application tous les algorithmes qu'il veut (pour faire de la prédiction de position ou toute autre chose), faire exécuter tous les calculs à l'unité de réception, et avertir le pilote selon toute procédure spéciale voulue.

Avec cette démarche, le problème de compatibilité n'existera plus, soudainement disparu !

Il n'y a aucun problème avec les anciens, actuels et futurs systèmes d'avertissement du trafic de n'importe quel constructeur : les données échangées sont des "vraies" données (coordonnées, altitude, vitesse et identification) et le niveau du traitement de ces données est laissé à chaque constructeur. Chaque produit pourra alors offrir des fonctions selon ses calculs internes, et chaque pilote pourra choisir le produit qui lui convient le mieux.

Chaque système avertit alors son pilote, selon les critères programmés (prévision de trajectoire, vitesse d'approche ou autre).

Si une performance minimum est exigée, afin de s'assurer que chaque système exécute vraiment la fonction de l'avertissement du trafic, alors une règle de base (une norme) doit être définie. Ce n'est en rien difficile à faire, et cela peut être maintenu à un niveau minimum, disons par exemple que tous les systèmes doivent avertir des pilotes, quand un temps calculé avant l'impact, basé simplement sur la vitesse d'approche divisée par la distance, est au-dessous d'une certaine valeur. Ceci garantit que tous les systèmes ont un niveau de performance minimale requis. Les fonctions et performances supplémentaires sont "des plus" qui différencient les systèmes.

 

Il n'y a nul besoin de transmettre davantage, pour avoir un système d'avertissement du trafic.

Le T-Advisor fournit au pilote des indications basées seulement sur les données minimales énumérées ci-dessus : tous les calculs sont exécutés intérieurement et sont par conséquent indépendants des calculs exécutés par d'autres dispositifs. Ceci garantit que n'importe quelle version de T-Advisor peut fonctionner avec tout autre et avec n'importe quel dispositif qui transmet ses coordonnées, altitude et identification : l'ensemble minimum de données pour identifier la position de l'autre aéronef.

Avec cette solution, tous les problèmes dérivant de la "compatibilité" disparaissent ; il n'y a aucun besoin d'exécuter une mise à jour synchronisée des micrologiciels et il n'y a aucun problème de compatibilité parmi différents systèmes : des nouveaux systèmes offriront des algorithmes probablement plus raffinés et des nouvelles fonctions, mais ceci n'aura aucun impact sur des unités plus anciennes qui pourront continuer à travailler sans limitations. Ceci garantirait que chaque unité fournie exécuterait son travail de sécurité n'importe quand, tout le temps et partout.

 

La conclusion :

Le problème entier de la "compatibilité" dérive du choix de transmettre des données calculées au lieu de données "brutes", c'est à dire des données minimales et objectives : coordonnées, altitude et identification. À notre avis, c'est une erreur fondamentale dans la conception d'un système d'avertissement du trafic.

Lucas Marchesini / DSX"

 

Le texte original en anglais est disponible à la demande.

 

Bravo Yurek pour le boulot de trad.

 

(heureusement que j'avais demandé d'éviter de faire du bla-bla :lol: )

 

Pour resumer les reponses aux questions posées:

Q1: tests précis faits par DSX pour s'assurer de la compatibilté avec FLARM ?

Reponse DSX: on est balaises en tests et on en a fait plein

Mon commentaire: un peu court (si je puis dire ), non?

 

Q2: quand DSX va-t-il fournir à ses clients un code à installer sur les T-advisor pour qu'ils soient compatibles FLARM 4.0 ?

Reponse DSX: pas de date, et aussi : nous sommes opposés au changement de protocole, et aussi: ce n'est pas une bonne solution que de transmettre des positions et trajectoires calculées comme FLARM le fait (et comme DSX aussi, j'imagine, puisqu'il est compatible )

Mon commentaire: là, si je suis proprietaire d'un T-Advisor qu'on m'a vendu compatible FLARM, je commence a m'inquiéter, car une seule chose est sure, c'est que si DSX ne fait rien, mon T-Advisor ne sera plus compatible FLARM au 1er Mai :rolleyes:

 

Je comprends parfaitement que DSX ne soit pas enchanté a l'idée de devoir re-décoder le protocole, re-developper le code pour le T-Advisor, et re-le tester.

Mais dès le début FLARM a adopté une strategie de mises a jour sans compatibilité arrière et de transmission de valeurs calculées. Ce n'est pas une surprise qui arrive aujourd'hui, c'était en place et public lorsque DSX a decidé de ne pas adopter le HW/SW de FLARM préférant developper ses propres codes et HW. J'imagine qu'ils ont alors bien compris les conséquences de cette decision. Wait and see au 1er Mai.

Modifié le 26 février 2008 par 5 X

[Yurek]

Bravo Yurek pour le boulot de trad.

Merci, en toute modestie, j'accepte.

(heureusement que j'avais demandé d'éviter de faire du bla-bla )

C'est une traduction, pas un résumé.

D'un résumé tu t'es chargé toi-même... à chacun son boulot.

Mon commentaire: là, si je suis proprietaire d'un T-Advisor qu'on m'a vendu compatible FLARM, je commence a m'inquiéter, car une seule chose est sure, c'est que si DSX ne fait rien, mon T-Advisor ne sera plus compatible FLARM au 1er Mai

J'ai pour toi une surprise : aucun vent de panique n'a été observé chez les propriétaires du T-Advisor. Et puis, qui t'a dit que DSX ne fera rien ?

En tant que propriétaire d'un Flarm, tu peux dormir tranquillement ! :lol: J'en connais tout même quelques uns qui ont - tout récemment - troqué leurs Flarms contre des T-Advisors tout neufs... :rolleyes:

Je comprends parfaitement que DSX ne soit pas enchanté a l'idée de devoir re-décoder le protocole, re-developper le code pour le T-Advisor, et re-le tester.

Erreur d'interprétation : DSX n'a pas du tout peur du boulot, lui. Et - à mon humble avis - cette équipe ne se laissera pas décourager par le premier obstacle venu, comme elle n'a pas été découragée auparavant.

DSX trouve simplement que l'idée d'un protocole variable, excluant une compatibilité arrière, n'est pas bonne.

(Si cette opinion t'a échappé, ce que le texte était effectivement trop long. )

Malheureusement, à la base du conflit, il y a la volonté de l'équipe de Flarm-Technology d'exclure toute concurrence, quelques en soient les moyens (y compris un chantage à "l'incompatibilité"), et de garder un monopole. Ce qui n'est pas vraiment dans l'intérêt des consommateurs. C'est en tout cas, ce que certains consommateurs me disent.

[5 X]

Bravo Yurek pour le boulot de trad.

Merci, en toute modestie, j'accepte.

(heureusement que j'avais demandé d'éviter de faire du bla-bla )

C'est une traduction, pas un résumé.

D'un résumé tu t'es chargé toi-même... à chacun son boulot.

Mon commentaire: là, si je suis proprietaire d'un T-Advisor qu'on m'a vendu compatible FLARM, je commence a m'inquiéter, car une seule chose est sure, c'est que si DSX ne fait rien, mon T-Advisor ne sera plus compatible FLARM au 1er Mai

J'ai pour toi une surprise : aucun vent de panique n'a été observé chez les propriétaires du T-Advisor. Et puis, qui t'a dit que DSX ne fera rien ?

En tant que propriétaire d'un Flarm, tu peux dormir tranquillement ! :lol: J'en connais tout même quelques uns qui ont - tout récemment - troqué leurs Flarms contre des T-Advisors tout neufs...

Je comprends parfaitement que DSX ne soit pas enchanté a l'idée de devoir re-décoder le protocole, re-developper le code pour le T-Advisor, et re-le tester.

Erreur d'interprétation : DSX n'a pas du tout peur du boulot, lui. Et - à mon humble avis - cette équipe ne se laissera pas décourager par le premier obstacle venu, comme elle n'a pas été découragée auparavant.

DSX trouve simplement que l'idée d'un protocole variable, excluant une compatibilité arrière, n'est pas bonne.

(Si cette opinion t'a échappé, ce que le texte était effectivement trop long. :lol: )

Malheureusement, à la base du conflit, il y a la volonté de l'équipe de Flarm-Technology d'exclure toute concurrence, quelques en soient les moyens (y compris un chantage à "l'incompatibilité"), et de garder un monopole. Ce qui n'est pas vraiment dans l'intérêt des consommateurs. C'est en tout cas, ce que certains consommateurs me disent.

 

 

Le débat que DSX tente de placer sur un terrain pseudo technique ne me parait pas les servir. Par exemple: selon eux il faudrait transmettre les données brutes de position, et non des infos de trajectoire. Cela reviendrait a dire que chaque recepteur devrait calculer la trajectoire de tous les planeurs (jusqu'à 50...) qu'il recoit, ce qui ferait une belle puissance de calcul necessaire dans chaque planeur, parfaitement incompatible avec les objectifs de consommation electrique de ce type de produit...et ce qui reviendrait donc à faire N-2 fois en trop le calcul de trajectoire de chaque planeur si N planeurs sont en communications.

 

Espérons que le poids du marché fera sa loi, et que dans l'interet et la securité de tous une voie de compatibilité sera trouvée.

 

 

 

PS: tu as raison, à Chartres il n'y a que des FLARMS ou licenciés, pour l'instant.

[Yurek]

Excellent exemple !

Seulement, le conditionnel est tout à fait inutile... "calculer la trajectoire de tous les planeurs qu'il reçoit (jusqu'à 50...)", c'est précisément ce que fait le T-Advisor... actuellement. Cela veut dire que cette "belle puissance de calcul" est déjà disponible.

Pis, sa consommation électrique est presque vertigineuse : elle atteint en effet... 40 mA !

Mais je suis sûr que l'on peut faire encore mieux. Si tu fabriquais par exemple pour le T-Advisor une belle antenne (comme celle qui a permis à Flarm de presque doubler sa performance), on pourrait atteindre un rayon d'action de... 12 km !

 

Si vous êtes parvenu à avoir tous les planeurs à Chartres équipés de Flarm je vous en félicite : quoi en fait de plus encourageant que l'exemple d'un club qui prête attention à la prévention d'abordage. Et si tous ces appareils sont des Flarms, je m'en réjouis aussi : c'est nettement mieux que lorsqu'il n'y a aucun dispositif. :lol:

 

Ne soit pas surpris, Daniel : DSX n'a jamais souhaité la disparition du Flarm. Je dirais que c'est plutôt le cas inverse...

Nous espérons pourtant aussi que, pour l'intérêt de tous, une voie de compatibilité sera trouvée.