problème simulateur télémétrie companion 2.3.4

Bonsoir,
Je viens de migrer ma X7Q en v2.3.4, sans soucis, j'ai volé avec Samedi: Nickel.
Je voulais tester sur simulateur, avant de migrer ma X9E en v2.3.4, car elle sert aux grands planeurs, c'est plus prudent!
Je rencontre un problème avec le simulateur companion 2.3.4 sur mon profil X9E et sur mon profil X7Q:
Les différents inters et voie proportionnelles fonctionnent, mais quand je veux simuler en télémétrie je n'ai aucun résultat.
Je m'en suis pourtant servi avec succès il y a quelque mois quand j'étais en version 2.3.2?
Normalement j'avais bien le vario et l'annonce de l'altitude, mais là c'est le silence complet.
Par contre j'ai des annonces sur position d'inters, qui fonctionnent correctement.
Je vois aussi les inters logiques bouger...
Pouvez-vous me donner un petit tuyau SVP?
Jeep

Je crois qu'il y a des petits soucis avec le simulateur de Companion.
Si tu veux tester, il faut lancer un fichier .log d'un vrai vol. Là, cela devrait fonctionner.

Merci LapinFou,
Malheureusement, je n'en ai pas encore réalisé.
C'est une fonction que je n'ai pas encore exploitée...y en a tellement!
Je viens de tester sur companion 2.3.2 (installé dans un dossier séparé, sans désinstaller la version 2.3.4):
pareil! çà indique NO DATA dans la page écran télémétrie, en bas.
Penses-tu qu'une réinstallation complète de Companion 2.3.4 apporterait un mieux?

Non, cela ne changera rien au problème. Ceci dit, si la télémétrie fonctionnait correctement sur ta X9E, il n'y pas de raison connue que cela change avec un passage en 2.3.4.

La télémétrie fonctionne bien entre radio et récepteur, je viens de vérifier. ouf!
C'est seulement le simulateur companion qui ne fonctionne pas en télémétrie (no data)

Je viens de tout désinstaller du PC ce qui concerne Companion, nettoyage des registre et boot du PC.
Réinstallation de Companion 2.3.4, et j'ai re-paramétré les 3 profils que j'utilisais. (j'ai refusé la récupération proposée au premier démarrage).
Donc:
profil X9E :firmware, opentx-x9e-eu-horussticks-lua-noheli-fr-2.3.4
profil X9D :firmware, opentx-x9d-lua-noheli-fr-2.3.4, (celle du copain en non EU)
profil X7Q: firmware, opentx-x7-eu-lua-noheli-fr-2.3.4
même problème du simulateur Companion, partout!

Par contre, en remettant à jour les préférences pour chaque profil radio, j'ai constaté quelque chose au niveau de l'onglet "paramètres de l'application":
dossier de sauvegarde automatique se complète tout seul, systématiquement avec le dernier path que j'avais saisi précédemment sous un profil différent.
bizarre...
Alors que c'est bon dans l'onglet "profil radio", les path écrits pour la SD et la sauvegarde automatique sont bien conservés
exemple:
D:/Mes Programmes/OPEN_TX/Taranis X9E/SDcard-X9E
D:/Mes Programmes/OPEN_TX/Taranis X9E/X9E-SavAuto
et
D:/Mes Programmes/OPEN_TX/Taranis X7Q/SDcard-X7Q
D:/Mes Programmes/OPEN_TX/Taranis X7Q/X7Q-SavAuto
Gérer 3 profils de radios différentes nécessite un grande vigilance et une bonne organisation des dossiers!

Autre constatation, résumé de mes tests:
1/ Lancement du simulateur companion par l'icone "simuler radio en haut de la feuille "modèles ....":
On a bien la X9E, mais l’écran affiche, après un bip: SD Card Warning: expexted version: 2.3V0025
Ce n'est pas le cas sur la radio réelle:(Je n'ai pas encore migré la X9E par précaution (toujours en 2.3.2))

2/ Lancement avec l'icone Firmware Simulateur 2.3 de démarrage Windows:
Pareil!

3/ Lancement "simulation" en bas de la page édition d'un modèle:
On a bien la bonne présentation d'écran de la X9E, pas d'alarme SD, et si on va chercher un écran télémétrie on à No DATA en bas

4/ ces symptômes sont exactement les même avec la X7Q et la X9D, toutes les 2 migrées en v2.3.4

bonsoir,
je reviens vers vous après quelques essais.
Sur le conseil de LapinFou, j'ai enregistrer un LOG sur la X9E, en baladant le fuselage dans le séjour et de haut en bas!
J'ai aussi bougé les manches et inters.
Je confirme le bon fonctionnement de la télémétrie en réel, affichage correct des données dans les écrans.
L’émetteur a bien enregistré le LOG, que j'ai récupéré sur le PC.
Je visualise bien les données sur Companion 2.3.4, par Fichier/Ouvrir un Log.
1/ Ouverture du modèle pour lancer Simulation: Toujours pareil, toutes les fonctions actives (inters, manches, sorties, mixeurs,etc), sauf la télémétrie qui semble ne rien transmettre (Simule coché), d'ailleurs le simu affiche NODATA sur les pages affichage télémétrie.
Dans ce test j'ai rempli moi-même les cases Alt et Vspd ce qui faisait bien réagir le simu en V2.2.4 (bruit vario, annonce altitude atteinte) lorsque je l'ai programmé en septembre. En V2.3.4, rien ne réagit plus.
2/ Comme indiqué par LapinFou j'ai ouvert le LOG, la lecture se fait, remplissant les cases du tableau Télémétrie du simu, on voit bien évoluer Alt et Vspd entre autre. Malheureusement toujours rien n'arrive, aucune réaction, NODATA sur les pages affichage télémétrie.
3/ La X7Q et la X9D souffrent du même problème, j'ai fait aussi le test, sous version 2.3.4 et sous version 2.3.5
4/ Testé sur un autre PC, sous windows10, mêmes conditions, même problème.
5/ est-il possible de refaire le test avec Companion 2.2.4, sans rétrograder les radios?
N'y aurait-il pas un bug qui se serait glissé là au cours des dernières évolutions?
Nos amis développeurs sont-ils informés du soucis?

Je trouvais tellement pratique ce simulateur Companion lors du paramétrage d'un nouveau planeur.
Jeep1656

je me réponds tout seul: pas besoin de rétrograder les radios pou tester le Simulateur de Companion 2.2.4: il faut par contre utiliser un modèles sauvegardé en V2.2.x.
Donc, désinstallation complète de Companion 2.3.5 (en fait le soucis existe depuis 2.3.0, où le simulateur a évolué dans son aspect actuel)
Installation de 2.2.4, création du profil radio et récupération d'un fichier modèle d'époque compatible. (sinon çà plante!).
ET là! miracle, la télémétrie est bien transmise au simulateur, on a les valeurs dans les pages affichage télémétrie.

Il y aurait donc bien un truc cassé au changement de branche:
Cela pourrait venir des deux cases à cocher ajoutée "pause.." et RAZ RSSI..." qui n'y étaient pas dans la branche 2.2.
(c'est le bon vieux jeu des 7 différences...)

ON va attendre l'analyse des pros...
bonne nuit
Jeep1656

Bonsoir, j'ai refais l'essai de revenir avec Companion en v2.2.4, X9E ou X9D, avec des modèles enregistrés sous cette version d'openTX: il n'y a aucun problème avec la télémétrie du simulateur Companion 2.2.4.
Je confirme aussi que sous cette ancienne version il y avait uniquement la case à cocher "Simule" en haut à gauche de la fenêtre de simulation Télémétrie.

J'ai ensuite testé la version 2.3.0 et le problème de NoData apparaît avec la télémétrie du simulateur 2.3.0.
C'est dans cette version qu'apparaissent les 2 nouvelles cases à cocher "pause.." et RAZ RSSI..." sous "Simule".
Serait-il possible de remettre le simulateur V2.2.4 dans la version 2.3.5 de Companion? une dll en particulier?  je délire peut-être là!

Y aurait-il un moyen de signaler cette anomalie aux développeurs, un lien, une adresse?
Jeep

Bonjour,

Tu peux le faire sur le site d'Open-Tx : https://www.open-tx.org/issues

Coyotte

merci Coyotte,
Je le ferai ce soir..
Jeep

Jeep1656 a écrit:merci Coyotte,
Je le ferai ce soir..
Jeep

20h23: C'est fait!
première fois, alors j'espère que je n'ai pas commis de boulette...
rédaction "In French"
Combien de temps pour que je retrouve ma prose en ligne?

Jeep

Oups!
me suis fait viré gentiment!
1/ no speak french!
2/ sujet déjà soumis et clos!
En effet, on nous explique (avec traduction google) que çà fonctionne ...sur Horus!

Euh! je dois acheter une Horus, là?

J'ai regardé l'issue que tu as posté.

La raison de la fermeture de ton issue est qu'elle a déjà été signalée par ailleurs : #6862 - Companion telemetry simulator not usable with "real" sensors on 2.3. Dans l'issue #6862, il est bien indiqué que le bug sur la simulation de la télémétrie dans Companion est valable pour toutes les radios depuis la version v2.3.0. Il est aussi indiqué par Kilrah que le bug est indirectement dû à un manque de ressource pour s’atteler à cette tâche et maintenir le code.

Pour la langue utilisée pour décrire le bug, il est demandé d'utiliser l'anglais qui permet à tous les utilisateurs/testeurs/développeurs de pouvoir suivre les échanges de façon internationale. Ce n'est pas parce que ton issue était rédigée en français qu'elle a été clôturée (en plus elle a été clôturée par un francophone !). Un outil très pratique pour traduire les échanges est l'utilisation de DeepL.

Il ne faut pas croire que l'équipe qui développe et entretien OpenTx/Companion est colossale.
Il suffit de suivre les modifications sur le dépôt GitHub du projet pour se faire une idée du nombre principal de contributeurs.
A mon avis, il y a donc des priorités au développement :
- assurer la qualité d'OpenTx (OpenTx ne donne jamais de date de sortie. La nouvelle version est disponible uniquement quand la qualité de l'OS est considérée comme très bonne et que l'OS a été suffisamment testé pour vérifier que le risque lié à son utilisation soit quasi-nul)
- permettre le support de nouvelles radios (FrSky, Jumper, Radiomaster, peut-être Flysky...)
- inclure les évolutions les plus pertinentes (proposées par les utilisateurs, les développeurs, les fabricants)
A mon avis, la priorité est donc donnée à OpenTx plutôt qu'au logiciel Companion.

Comme l'équipe d'OpenTx/Companion est sur tous les fronts, il ne faut pas s'offusquer quand parfois la réponse donnée lors d'un échange est laconique. Ils vont à l'essentiel pour être le plus efficace possible.

En tout cas, OpenTx/Companion est sans cesse en mouvement pour le plus grand plaisir de ses utilisateurs. Quel superbe projet collaboratif !
Le développement d'OpenTX est impressionnant tant sur le fond que sur sa forme. C'est un régal de pouvoir mettre en œuvre ses besoins d'aéromodéliste sur un système d'exploitation d'une si grande souplesse.
Un grand bravo et respect à tous les contributeurs d'OpenTx !

Merci beaucoup Ceeb pour ces eclaircissements.
J'approuve totalement tout ce que tu nous dis sur l'équipe "dev" d'openTX.
Pour ma part je suis converti!
pour ce qui est de la réponse, j'ai foncé directement verts la déclaration de probléme, même pas au bon endroit! J'ai en effet trouvé des réponses...Mon "vieil Anglais" est bien loin...merci pour le décodage!
Le mieux et pour moi de me désinscrire de GitHub, m'excuser!
Je resterai simple lecteur dans un premier temps...et je patiente, ce n'est pas une situation blocante, juste du confort...
Il me reste encore plein de chose à tester, notament un capteur pour contrôle des elts d'accus propulsion.
à Bientôt
jeep

Non, tu n'as pas besoin de te désinscrire et de t'excuser. Ton issue, même si elle n'était pas rédigée en Anglais, était courtoise et documentée.
J'ai vu des échanges sur le GitHub d'OpenTx bien plus condamnable car totalement inappropriés, dénué d'argument et peu courtois.

c'est sympa
en fait je suis juste désabonné du sujet que j'ai créé, lui-même fermé. .
j'ai tout de même mis un petit mot à 3djc.
Ainsi je suis...

allez rendez-vous à mes prochaines prospections dans OpenTX..
jeep

Bravo à toi pour cette attitude respectueuse et très cordiale que nous apprécions à sa juste valeur. Un exemple de savoir-vivre qui pourrait servir d'exemple...

Y en a tellement qui vivent sans ce savoir...
allez on devient hors sujet!
Jeep

Bonsoir,
Désolé de vous relancé mais je crois avoir trouvé quelque chose...
C'est en mettant en service un capteur FLVSS (1er experience!) que j'ai révisé le tuto Télémetrie de notre cher Rongeur-fou:
Je me mets à déclarer tout mon petit bazard, avec application...et je lance machinalement une simulation! oups!
Et, sans pouvoir vous dire porquoi, je remarque une anomalie dans les numéros d'instance des capteurs de télémétrie, y compris ceux du RX, côté simulateur.
Comparaison immédiate avec les instances réellement vues par la radio: euréka! je l'ai mon jeu des 7 différences!
...Et de remettre les bonnes valeurs dans le tableau du simulateur, et de retrouver de la vie au fur et à mesure que les instances sont corrigées!
Je vous ai mis une copie d'écran "avant/après", et j'ai vérifié que les valeurs prises au démarrage de la simulation sont toujours les mêmes.
Est-ce que cela pourra aider? je ne sais pas...
En tout cas, en attendant, je sais comment remettre le simulateur Companion235 en fonctionnement
Bonne nuit à tous, moi je vais dormir serein
...et une brouette de carottes pour le LapinFou (qu'est-ce-qu'on-ferait-sans-tes-tutos?)
Jeep1656

Merci pour les carottes !

Pour l'instant, il est vrai que le simulateur télémétrie sur la branche OpenTX 2.3 est un peu cassé.
Le seul truc qui marche bien est d’enregistrer un log en réel avec la radio et ton modèle et de rejouer ce log dans la simulateur.

salut LapinFou,
tu m'as déjà proposé le tuyau, et tu penses bien que je l'ai fait illico:
bin pour moi, çà ne donne rien, les données passes bien dans le tableau du simu, mais pas vers la radio (NO DATA)...maintenant que je sais pourquoi, je vais retenter l’expérience et voir si par la lecture du log, je remets ou non les instances de capteurs à jour. A priori non! mais en informatique ou en électronique "à priori" veut dire "à vérifier".
Je m'y colle DQP
à plus

Dès Que Possible: j'y suis!
donc re-test avec la X9E en lançant la lecture d'un log:
1/ déjà au démarrage dans le tableau télémétrie du similateur, on a des valeurs erronées dans presque toutes les instances, toujours les mêmes (voir copies précemment jointes).
2/ lecture du log: les variables évolues bien dans les cases correspondantes, alt, vspd rssi, (instances toujours fausses). No Data côté ecran simu-radio.
3/ correction des instances et les datas passent: valeurs affichées et annonces vocales.

Conclusion: avec ou sans log, toujours ce problème d'instances erronnées qui plantent l'affichage des datas.
Bonne cogitation...
Jeep1656

Bonsoir,
encore une précision (copie ecran jointe) : il semble que dans la version 2.3.x le problème du simulateur n'affecte que les capteurs découverts en ajoutant bizarrement la valeur 223 au numéro d'intance donné dans les paramétres radio.
Par exemple (v2.3.5) sur un modele avec vario, mais sans le capteur FLVSS, la case "Element" a son n° instance à 2 par défaut.
Si on prend un modèle où on ajoute par exemple le capteur FLVSS, la case "Element" a son n° instance à 2+223=225
Les cases "BtRx", "RSSI" (n° instance= 25+223=248), "Vitesse Verticale" et "Altitude"(n° instance= 1+223=224), sont aussi touchées
Lles autres valeurs (instances non utilisées) ont une valeur identique en comparant la v2.2.4 avec la v2.3.5.

Si quelqu'un a réussi a comprendre mon charabia, merci de le ffaire suivre à nos développeurs:
j'aurai bien du mal à le rendre compréhensible "in ingliche". Chu (C)harentais, Mouai!
Là-dessus je laisse LapinFou à ses carottes, moi je suis dans les choux!
bonne nuit

jeep

Le problème est connu depuis Septembre. Il faut maintenant attendre qu'un dev est du temps libre pour corriger ce bug en particulier → #6862

Merci,
je viens aussi d'en informer par mail.
En effet Gastolectric a posté un remède paliatif identique au mien, ->#6862
je ne suis pas très doué sur GitHub pour l'avoir trouver tout seul. pardon!
je n'en rajoute plus promis...
Jeep