Crash avec Horus X12 en FrTX V1.5.05

Bonjour Phillipe.
Je n'ai pas complètement éliminé la RB20 de la liste des "suspects" car je sais bien qu'avec le pilote et le codage des données dans l’émetteur, ce sont les 3 seuls éléments qui ne sont pas doublés.
Par ailleurs, si, les pompes nouvelle génération sont brushless. Sur la mienne, c'est marqué dessus : "Digital brushless fuel pomp".
Et puis voici encore 2 autres éléments accréditant la thèse du reboot émetteur :
- je n'ai eu à aucun moment d'alerte vocale concernant la qualité de la réception. Quand l'alim de réception a été déconnectée dans le crash, j'aurai au moins dû avoir "télémetrie perdue". A moins que ma mémoire me fasse défaut, ce qui est malgré tout possible vu les circonstances. Mais franchement , c'est peu probable.
- les logs s'arrêtent au moment de la perte de contrôle, alors que sans pb sur l'emetteur, les enregistrements continuent, même après que la reception ait cessé de fonctionner (je viens de refaire un enregistrement test : quand j'arrète le Rx, le RSSI passe à 0 et l’enregistrement continu jusqu' à extinction de l'emetteur). Or dans mes logs, à la dernière ligne, le RSSI est à 54, alors que j'avais éteint l’émetteur plusieurs minutes après le crash. Et là, c'est enregistré, c'est indiscutable.

Bonjour Michel79,

Ce que je ne comprends pas c'est, si un reboot a eu lieu, alors la réception aurait du se mettre en failsafe. D'après ce que j'ai compris, tu en doutes fortement. Un émetteur qui "fait le fou" et qui envoie toujours les mêmes signaux (bloqué aux dernières valeurs), je n'ai jamais entendu parler (ça sera peut-être une première).

Sur mon jet, j'ai paramétré le failsafe : commandes de vol hold, gaz réduit et trains sortis. Ce dernier point me permet, si le cas se présente, de savoir si le failsafe s'est activé.

Bonne journée.

Cdt.

Philippe

filduch a écrit:si un reboot a eu lieu, alors la réception aurait du se mettre en failsafe.

Oui, bonne remarque.
Peut-être que ce n'était pas un reboot, mais simplement un blocage de la partie traitement et codage des ordres, mais avec la partie émission active, et simplement la perte de l'image du modèle de l'affichage de l'écran.
Ou alors, le reboot est intervenu dans un second temps, après l'impact, et avant que je baisse les yeux sur l'écran,... là je ne sais pas.
Ce qui est sûr, c'est que l'enregistrement s'est arrêté prématurément, et ça, ça se passe uniquement sur l’émetteur.

Souvenez vous que le module travaille seul, FrTX (ou OpenTx) ne fait que lui donner les valeurs a envoyer, mais tant qu'il est sous tension , il émet

3djc

Je ne connais pas en détail l'architecture de l'implémentation des émetteurs FrSky. Certain est que les modules (interne et externe) reçoivent les consignes à transmettre. C'est le travail des modules de gérer la transmission. Il serait intéressant de comprendre ce qui se passe si une panne logiciel (FrTx ou OpenTX) survient. Apparemment rien d'après ce que j'ai lu mais je garde un petit doute sur ce point.

Philippe

Bonjour, j ai moi aussi fait cette mise a jour sur ma Horus 12 je suis passé de la version 1.05.0 4 suite au passage a la version 1.5.05 mon funcub sur module extérieur fr sky DGT était dérèglé Ailerons et commande ne correspondait plus par chance lors du contrôle avant vol la position des éléments de commande étaient clairement identifiable je suis repasse a la version 1.05.04 et tout est revenu en ordre si cela peu aider bonne journée