Perte de contrôle en vol

Oui, c'est tout a fait normal vu ton LS

3djc

Je viens de mettre en service le nouveau FW. Tout semble correct, merci. Je suppose que la Taranis tourne maintenant la 2.2.4 (avant j'étais en 2.2.3) ?

Retour case départ. Crash de la journée, même scénario : le problème reste entier.

Bref historique (d'après mémoire en partie)

 - Perte d'un Super Dimona juin 2018 suite à une transmission d'ordres incorrectes durant une quinzaine de secondes. Le fichier de log indique bien des valeurs totalement absurdes jusqu'à la disparition de l'appareil. J'utilisais une Taranis X9D+ qui me donnait entièrement satisfaction depuis environ deux ans. OpenTx était en version 2.2.2
 - Suite à l'achat d'une Horus X12S d'occasion (janvier 2019) j'ai eu à peu près le même scénario qui se produisait sur différents modèles et le manche de droite a été changé (profondeur + aileron). OpenTx était en version 2.2.3
 - Ne trouvant pas le problème sur la X12S d'occasion, je décide d'en commander une nouvelle X12S neuve et vole en attendant avec la Taranis
 - Juin 2019, perte d'un aéronef suite au même scénario. OpenTX était en version 2.2.3. J'arrête de voler jusqu'à l'arrivée de la nouvelle X12S
 - Juillet 2019, mise en service de la nouvelle X12S et début des vols. Environ 250 vols effectués sans problème
 - le 7 novembre j'upgrade OpenTX à la version 2.3.1 puis rapidement passe à la 2.3.2 (emergency)
 - Aujourd'hui, crash d'un aéronef toujours selon le même scénario. Je vois dans les logs des valeurs complètement éronnées des commandes durant un laps de temps d'environ 4 secondes. Aucune annonce durant le vol Quelques secondes après le crash, la X12S m'annonce "télémétrie perdue" (aéronef explosé !) Rien à signaler au niveau du RSSI

Je me retrouve à nouveau sans possibilité de voler et cette fois je vais rester au sol jusqu'à que je trouve la raison du problème. Je suis plutôt assidue à ma passion en faisant voler un peu tout ce qui peut l'être. Je vole plus que la moyenne (environ 6 à 700 vols par année et ça pourrait expliquer en partie pourquoi je me sens si seul avec cette épée de Damoclès qui n'est certainement pas présente juste pour moi. C'est une question de temps / vols pour que le problème arrive (une fois par année pour ma Taranis et ??? pour la Horus X12S).

Rien n'est à chercher au niveau de la réception (elle a bien suivit les ordres reçus). Pilote Ok :-) Tout est dans la/les boîte/s HW et SW (X12S / Taranis). Ca va pas être facile et peut-être que par recoupement une piste émergera. Certaines X12S ont des problèmes de manches / calibration. A un moment j'avais pensé à un problème indirectement lié à la calibration.

J'aurai une petite question concernant la correctif apporté à OpenTX 2.3.0/1 : est-ce qu'une trace (audible ou dans des logs) peut se retrouver ?

Zut alors !!

Si je résumé en quelques mots, tu as eu le même problème avec des radios et des RXs différents. Correct ?

Si oui, alors c'est peut-être une cause dans ton environnement de vol ?
- Est-ce que cela s'est produit plus ou moins au même endroit ?
- Une base militaire dans le coin ?
- Un radar météo ?
- Est-ce que d'autres membres de ton club ont eu le même souci avec une autre marque de radio ?
- Pas de téléphone portable sur toi lorsque tu voles ?

Il y a forcément un dénominateur commun qui pourrait expliquer tes problèmes...
Je compatis sincèrement avec toi.

Bonjour
Pour moi "télémétrie perdue" n'est pas un critère important seul le RSSI prouve quelque chose; Lorsque je vole sur mon propre terrain avec des parkflyer j'ai fréquemment cette annonce et pratiquement toujours dans la même zone!
Je soupçonne des ondes WIFI provenant d'émetteurs situés entre 8 et 3 km ... par contre lors de ces annonces je n'ai pas de perturbation radio rssi normal.
Dans le cas de Filduch je pense à un perturbateur matériel aléatoire comme disent les spécialistes de l'adsl!
pierre

Hello LapinFou pas si fou que ça

Le profil du problème est le même lors de tous les incidents avec :

 - des émetteurs différents (Taranis X9D+ et Horus X12S (deux émetteurs))
 - récepteurs hétérogènes (X4R, X8R, R-X8R Pro)
 - OS OpenTX avec des versions différentes (2.2.2 à 2.3.2). Rien à signaler jusqu'à la 2.1.9
 - Je vole pratiquement exclusivement au même endroit
 - Je suis le seul à rencontrer ce problème
 - Tous ceux qui volent très occasionnellement au terrain avec des Taranis (X9D et X9E) n'ont pas de problème (OpenTX <= 2.1.9)
 - Pas d'environnement hostile (base militaire,radar, ...)
 - Portable : non

La source du problème est l'émetteur. Il envoie occasionnellement (1 x pour les 2 à 300 derniers vols), une séquence de commandes qui cause la perte du modèle qui se trouve dans les airs à ce moment là. Trois émetteurs différents (1 x Taranis X9D+ et 2 x Horus X12S) sont impliqués. Je cherche à comprendre et le seul dénominateur commun est l'OS qui gère le matériel, matériel qui pourrait occasionnellement induire l'OS à la faute s'il a lui même un problème. Le fait de voler beaucoup augmente ma malchance de rencontrer le problème.

Le log du crash : https://1drv.ms/u/s!AvtsYZCNc6p6ixmQAtaSzePnVW8u?e=wVyE8o : troisième vol, début de la séquence : 17:04::35:500

Séquence : Sitôt que je m'aperçoit du problème je coupe les gazs (Gaz -1024), la direction se met à bouger (je ne l'utilise pas en vol) et la profondeur se met à "plein piqué" (Prof -1024). Pour le reste des commandes, difficile à dire qui fait quoi. A 17:04:39.720 (soit environ 4 secondes après le début de l'incident), tout redevient normal et l'avion est en morceaux.

C'est à rien n'y comprendre...
Je suppose que tes failsafes sont correctement configurés et que la batterie de ta radio est suffisamment chargée (avec les bonnes valeurs d'alarmes) ?

D'après le log on voit que quelque chose "se bloque", car les BtRx, Brx, RSSII restent figé aux mêmes valeurs.
Pour exclure un problème d'OS, il faudrait passer ta Horus sous FrOS...
Ou repasser une Taranis sous OpenTX 2.1

Dans tous les cas, ce n'est clairement pas des solutions "sympas".

Hello Filduch,

Désolé pour la triste nouvelle...
Comme tu voles beaucoup, et que tu loggues tout, as-tu vérifié si ta carte SD n'était pas pleine, ou proche de la saturation ?
A priori, cela ne devrait pas interférer mais comme on ne sait pas ce que l'on cherche, il faut bien chercher partout...

Coyotte

Désolé aussi pour toi, c'est quand même un phénomène très particulier au vu des circonstances et du nombre d'essais de configurations différentes effectués.
Tu sembles mettre en cause OpenTX, je suppose que tu as épluché les issues du repo GitHub qui feraient état d'un bug correspondant à ta description ? Il y a sans doute d'autres utilisateurs qui volent aussi beaucoup et qui pourraient avoir signalé ce genre de chose ?

@LapinFou :

- Il n'a a aucune raison que le récepteur se soit mis en failsafe car l'émetteur a émis continuellement des informations pourries mais cohérentes. Les failsafes sont néanmoins configurés et testés correctement.
- Batteries réception et émission correctement chargées (attesté dans le log)
- seuils signal faible et signal critique correctement configurés (le log atteste les bonnes valeurs de RSSI
- "BtRx, Brx, RSSII restent figé aux mêmes valeurs", comme toutes les autres valeurs car je pense que l'enregistrement continue à reporter les dernières valeurs reçues tant que l'émetteur n'est pas coupé
- repasser la X12S à FrTx, j'y ai déjà songé mais cela ne prouvera rien jusqu'au prochain accident (ou pas). Voler dans l'incertitude, j'ai assez donné et ne veux pas être dans l'attente du prochain crash qui pourrait (ou non) se passer d'ici à plusieurs mois. Trois modèles détruits ça suffit.
- remettre en activité ma Taranis en 2.1.9, j'y ai également déjà songé. Mais pourquoi ? Je vole maintenant avec des modèles qui demandent des versions d'OpenTX supérieures. Ce sont ces modèles (et les futures) que je souhaite ressortir de ma cave. Si je revole avec ma Taranis en 2.1.9 sur de petits modèles, soit ça crash ou soit ça ne crash pas. Un crash peut ne pas se reproduire avant un certain temps. Je ne saurai vraisemblablement jamais quand dire : OpenTX jusqu'à la version 2.1.9 sur Taranis X9D+ était pour moi fiable. Et quand bien même, est-ce que cela me permettra de revoler en toute confiance mes beaux modèles ?
- j'ai fait un test "natel" intensif pour voir si je pouvais reproduire quelque-chose. Dans toutes les configurations possibles (y compris natel collé sur l'antenne d'émission), rien à signaler.

@Mipel :

- Je ne met pas directement en cause OpenTX. Je le trouve plus que top et souhaite plus que tout continuer à l'utiliser. Il est néanmoins vrai c'est le seul point commun que j'ai trouvé et qui pourrait provoquer les différents crashs. Je dois comprendre ce qui amène l'émetteur à envoyer des commandes erronées. Le HW semble hors de cause car plusieurs (3x) plateformes provoquent la même séquences, mais j'aurai plutôt tendance à penser qu'il pourrait quand même être la cause du problème mal géré par OpenTX. A ce stade je n'en sais rien, j'essaye d'investiguer toutes les pistes en étant conscient qu'aussi bien au niveau du matériel (FrSky) que l'OS (OpenTX), je ne trouverai certainement rien si j'ai pas une aide de ce côté là. Je pense que j'ai plus de chance de trouver en passant par OpenTX car le logiciel peu permettre de trouver également des dysfonctionnements matériel.
- Je passe énormément de temps à scruter le web et j'aimerai bien passer plus de temps à construire. Coté FrSky, c'est plutôt bien étanche et rien (ou presque) ne filtr. J'ai trouvé quelques informations au niveau des utilisateurs grâce aux différents forums dédiés ou non à FrSky/OpenTX

Je ne peux malheureusement pas t'aider, c'est pas faute de le vouloir pourtant. La durée du vol avant crash est-elle semblable sur tes relevés ?

Je suis comme tout le monde, je suis à court d'idée...
En ce qui concerne la tension de la batterie, je suppose que tu utilises une LiPo 4S et pas la NiMh d'origine ?

Les crash se sont passés systématiquement sur le même terrain ou sur des lieux différents ?

Afin d'éliminer des pistes possibles :
Les personnes présentes lors du crash étaient elles les mêmes ou différentes à chaque fois ?

Question aux plus calés que moi : cela ne pourrait pas être le résultat d'un brouilleur à proximité (d'où mes 2 questions précédentes) ?

Quelle nouvelle navrante...
Franchement c'est vraiment pas de chance.  

Je suis les échanges de ce sujet depuis le début en espérant que quelqu'un trouve l'élément défaillant.
Après avoir émis des hypothèses sur tout le reste, peut-être faut-il envisager un effet de bord de quelque chose d'illogique. Concernant ta carte SD, étant donné que tu logues en permanence et que tu voles énormément, quelle est la taille du log le plus important ? Y-aurait-il par hasard un dépassement d'un pointeur qui aurait un effet de bord inattendu ? Utilises-tu des scripts LUA ? Comme, Coyotte, je regarderai aussi si la carte SD n'est pas pleine, bien que la probabilité d'un tel évènement n'a sans doute pas de répercussion.

Désolé pour toi filduch

Peux-tu me dire ta fréquence d'enregistrement des logs ?

J'avais par le passé constaté une perte des commandes temporaires si la fréquence des logs était trop importantes car j'avais mis la valeur la plus basse soit 0.1 s (mais peut être simple coïncidence)

Depuis je ne descend jamais en dessous de 0.5 s

Ce n'est qu'une idée de plus, j'étais dans une config particulière avec 2 récepteurs (1 FrSky et 1 Spektrum), je n'utilise plus cette configuration.

Merci pour vos réponses. J'ai perdu mes ailes et je ne me sens pas trop à l'aise ces temps.

@LapinFou : Je n'ai pas (encore) changé la solution d'origine (NiMh 2'000). Il me semble qu'elle donne totalement satisfaction et que seule la capacité peu poser problème (ce point ne me dérange pas pour le moment car je n'ai pas volé mes planeurs depuis pas mal de temps).

@Thierry94 : Je vole très majoritairement (mais pas uniquement) sur le même terrain et suis le seul à vivre ces incidents. J'y vole depuis plusieurs décennies en commençant par le 27 puis le 40 Mhz. Arrivée du 2.4 Ghz (WFLY) durant presque 5 ans pour "enfin" baigner avec la Taranis qui m'a posé aucun problème également pendant environ 2 ans et demi. Très honnêtement si il est légitime de penser que l'environnement pourrait avoir quelque-chose à faire avec ce qui m'arrive, cela me parait très peu probable.

@Ceeb182 : J'en suis à ma troisième carte SD. Celle que j'utilise actuellement à une capacité de 16GB (utilisé 140 MB) - Fat32. La fréquence d'enregistrement des informations dans le log est de 0.5 seconde et le plus grand log fait environ 2MB. Aucun LUA ne tournait lors du dernier crash.

@Eric84AMC :  La fréquence d'enregistrement des informations dans le log est de 0.5 seconde

Afin de lever le doute, comme je l'avais déjà suggéré précédemment, il serait une bonne idée d'implémenter dans OpenTX, la possibilité d'enregistrer non seulement les valeurs des positions des commandes (-1024 / + 1024) mais également les valeurs analogiques retournées par les manches. 3djc m'avait fait une version d'OpenTX spéciale à cet effet pour la version 2.2.4 (de mémoire). Cette fonctionnalité n'a pas été implémentée en standard. Si elle l'avait été, il aurait été plus "facile" de différencier un dysfonctionnement HW s'un bug SW. Peut-être que cette idée fera un jour son chemin ?

Je me pose toujours beaucoup de questions sur le basculement en mode emergency (trace, durée, ce qui le déclenche)

... et beaucoup d'autres chose encore !

Merci pour toutes ces infos.
Mea-culpa sur la batterie. J'ai confondu Brx et TxBat...

Perso, je suis un peu comme tout le monde. Je suis à court d'idées.

A force de lire un peu tout ce qui peut se trouver sur le web, je me rends compte qu'un monde idéale n'existe pas même pour une superbe Horus X12S.

Apparemment pour une raison inconnue, elle ne se fabrique plus depuis juin 2019 et elle pourra peut-être être remplacée par une nouvelle version "PRO". La X10S pourrait en prendre également le chemin. J'ai également lu que quelques soucis de sécurité sont à résoudre au niveau de ACCESS. Toutes ces informations ne sont pas 100% fiables car le principale intéressé (FrSky) est assez avare en informations "publique".
J'ai également trouvé plusieurs postes concernant des pilotes ayant connus des similitudes avec mon problème (ex : tonneau non sollicité, X12S en version OpenTX 2.3.1, ça je l'ai vécu avec ma X12S d'occasion) mais qui ne sont pas allé jusqu'au bout des choses et également pas vraiment compris ce qui c'était passé. Certainement que ces pilotes ne volent pas autant que moi, ils ont "simplement" continué à voler en pensant avoir trouvé et corrigé le problème. Ils se sont construit une sécurité relative.
Le module R9M, lorsqu'il délivre sa pleine puissance (1W), peut également perturber la X12S (FrSky n'est pas très fiable en ce qui concerne le blindage de ces circuits).

Contrairement à ce que j'avais écrit, un script LUA était bien actif au niveau d'un widget (BatCheck).

N'hésitez pas à reporter tout incidents plus ou moins en relation avec le sujet. Je vous en remercie par avance.

Bonjour,

votre perte de contrôle n'est 'elle pas due à un brouillage externe?

au vu de vos investigations, on peut supprimer les problèmes de manches à effet hall, l'installation de vos modèles et openTX (en tout cas pour moi)
- vous semblez voler en moyenne 200j/an (si je rapporte cela aux nombre de vols : 600/an).
- vous semblez être le seul concerné par ce problème
si je compile ces données, il ressort pour moi que :
un brouillage externe par une borne installée près de votre terrain pourrait en être la cause qui émettrait à intervalles réguliers. (relevés compteurs...)
pourquoi êtes vous le seul concerné? : les autres marques en 2.4GHz ont une bande légèrement décalées. vos collègues en frsky volent peu et ne sont jamais sur la période d'émission de la balise

autre point : je suis parti du postulat que tous les crashs ont eu lieu au même endroit.
pour étayer ma théorie, vos déboires ont elles eu lieu à la même période, dans un endroit précis du terrain?

je vous plains car cet un problème difficile à résoudre.
bon courage

Cordialement

Quelques retours d'informations de mes investigations :

D'après : https://www.rcgroups.com/forums/showthread.php?3393419-sporadic-failsafes-or-uncontrolled-rudder-deflection-in-several-cases#post42600903, il est reporté l'apparition de situations de failsafe ainsi  que des déplacements de gouvernes inopinés :

 - ceci affecterait du matériel FrSky conjointement avec OpenTX, principalement avec des Horus X10 et X12
 - ces situations sont majoritairement observées lors des approches (phase atterrissage) ou à proximité du pilote (donc de l'émetteur)
 - un problème n'arrive que très peu fréquemment et ce n'est qu'avec le temps (quelques dizaines d'heures) qu'il est mis en évidence
 - le problème arrive également quand le RSSI est bon
 - dans un cas, il a été relevé une valeur de positionnement d'une commande qui dépassait de ce que peux en principe être transmis par OpenTX (?)
 - FCC semble plus robuste que LBT (enfin telle qu'implémenté par FrSky qui est invité à revoir sa copie)
 
Peut-être rien à voir avec mes soucis et peut-être que tout n'est pas correct, n'empêche que certains d'entre nous (dont moi) rentrent dans ce profil" correspondant aux points mentionnés ci-dessus.

J'ai également trouvé un autre "moi" qui a reporté le même profil que mes logs. Je me sens un peu moins seul mais ça ne ma'aide pas vraiment.

je pense que dans la majorité des cas, l'effet du problème n'est pas toujours très visible et ne dure que quelque instant. Il est donc vite oublié et sans gravité dans la plupart des cas.

Dans mon cas, je ne pense pas que le mode "Emergency" ce soit déclenché. Je penche toujours pour un problème qui a pour origine le matériel (X12S), problème qui n'est pas forcément spécifique avec mon émetteur qui, géré par OpenTX, produit l'effet de l'envoie des commandes erronées. Il me parait toujours aussi intéressant de connaître le comportement d'OpenTX lorsqu'il reçoit des valeurs de positionnement des commandes erronées (problème de calibration ou autre). Egalement afin de faciliter la "debuging", il serait bien de pouvoir loger les valeurs des commandes des manches.

Bonne journée à tous

@Jed :

Merci pour ton message. Pas de problème de brouillage entre l'émetteur et le récepteur. Le problème est dans l'émetteur car il envoie des valeurs erronées. Si je suis le seul sur ce forum, je ne suis pas le seul dans le monde qui rencontre cette situation.

Cordialement

Question: es-tu passé à un moment ou un autre de FCC à LBT ??

Bonjour,
D'après ton lien, il est précisé aussi:
- avec l'utilisation d'une RB
- souvent sur des récepteurs se série G-Rx
- après une utilisation de la radio supérieur à 10-12h
- un vol en l'air  de 20 à 30 mn
Cela rajoute des facteurs supplémentaires et permettra donc, peut-être de mieux cerner le problème.

EDIT:
je possède une X10
ma radio à plus de 10h de vol
je n'ai pas de RB
je n'ai pas de Rx: G-Rx
je vole très rarement plus de 20mn

Pour l'instant aucun problème, mais je vais quand même surveiller les logs, si çà devait arriver.

filduch a écrit:
Il me parait toujours aussi intéressant de connaître le comportement d'OpenTX lorsqu'il reçoit des valeurs de positionnement des commandes erronées (problème de calibration ou autre). Egalement afin de faciliter la "debuging", il serait bien de pouvoir loger les valeurs des commandes des manches.

Les valeurs sont bornées, donc ca prend forcement une valeur valide (autrement dit, aucun moyen de sortir de -1024 +1024, même si le HW du manche voudrait -3000 par exemple, ça sera -1024 qui est utilisé)