Présentation des nouveautés d'OpenTX 2.1

Je regrette ce que j'ai écrit par égard aux dev. qui ont fait un travail remarquable surtout que je ne le pense pas vraiment.

C'est vrai que pour ceux qui n'évolue que dans le monde FRSKY, c'est régressif.le mot est trop fort, c'est juste un peu déroutant avec la détection automatique des capteurs mais une fois que c'est fait, c'est tellement puissant avec tous les modes calculés dérivés des infos des capteurs, un régal. Surtout que tous les os font çà, chez Windows c'est le plug and play. Mais là le mode manuel existe toujours, si ça bégaie, on peut corriger.
Dommage qu'il n'y ai pas une option "FRSKY only" dans Companion qui permettrait de rester compatible mais c'est surement trop tard et très compliqué à gérer (en fait cela inciterait à la paresse et le problème se reposerait en 2.2, et ça ferait du dev en + pour pas grand-chose )
Sinon il y a beaucoup de nouveautés en dehors de la télémétrie dont les menus qui regroupent les items par catégorie (télémétrie, entrée , manche, trim ..) quand on y a gouté, difficile de s'en passer.
Pour faire des tests, je suis repassé en 2.0.17 et franchement je n'ai rien regretté (là j'ai eu l'impression de régresser rien qu'à cause de l’ergonomie) quand je suis revenu en 2.1.1 . Il faut dire que cela fait déjà 1 mois que je suis en 2.1.0 et j'ai eu le temps de m'acclimater.
Je reprends doucement mes modèles mais vue la météo, je ne suis pas pressé et je n'ai pas eu de pb particulier.

Bonjour,

Moi aussi je suis repassé en 2.0.17 sur ma X9D. En fait j'ai deux avions et 3 planeurs qui utilisent la télémétrie vario et conso de courant. Et pour moi c'est suffisant.

Et puis je dois penser aux copain qui sont toujours en version 2.0.9 ou 2.017. Je dois rester compatible avec eux.

Et pour l'instant sur ma X9E j'ai installé le Cri-Cri, le Grob qui utilise un vario pour le train et mon Epsilon qui utilise aussi un vario. Bref pas vraiment de quoi changer le monde.

Pour moi aussi je trouve pas simple la nouvelle télémétrie mais j'ai fait l'effort de passer à la version 2.1.1 et tant pis je ne ferais plus marche arrière.
Il est vrai que j'ai peu de modèles concernés !

dev.fred a écrit:C'est vrai que pour ceux qui n'évolue que dans le monde FRSKY, c'est régressif.
Dommage qu'il n'y ai pas une option "FRSKY only" dans Companion qui permettrait de rester compatible mais c'est surement trop tard et très compliqué à gérer.

Pas seulement Frsky, toutes les marques fournissent pratiquement les mêmes données (RSSI, GPS, vario, etc...). La nouvelles télémétrie est très bien pour une minorité de capteurs ou de données calculées mais c'est tellement dommage que pour ces quelques cas, on doive toujours faire toutes ces manipulations. Il aurait été nettement préférable que la nouvelle télémétrie complète l'existante au lieu de la remplacer.

Justement j'ai un problème avec le vario qui m'affiche en initialisation 250,0m. Comprend pas pourquoi !

Autre problème sur la X9E, le règle le son par le potar S1 sur 2.0.17. Or en 2.1.1 je retrouve le son réglé par F1. Je croyais que F1 était l'une des deux portar linéaire. Or ce n'ai pas le cas, F1/F2 sont bien les deux potars de dessus et les potars linéaires sont devenu S1/S2.
Fallait quand même le savoir

Les potards sont différents entre les 2 radios, faut reconfigurer.

Kilrah a écrit:Les potards sont différents entre les 2 radios, faut reconfigurer.

Oui et non. Du moment que je sais que S1 s'appelle désormais F1 je laisse ainsi. Mais j'ai mis quelques jours à comprendre car je croyais à une erreur de mise à jour de l'EEPROM.

Sacre100 le Dim 9 Aoû 2015 - 13:09

dev.fred a écrit:
   C'est vrai que pour ceux qui n'évolue que dans le monde FRSKY, c'est régressif.
   Dommage qu'il n'y ai pas une option "FRSKY only" dans Companion qui permettrait de rester compatible mais c'est surement trop tard et très compliqué à gérer.

Pas seulement Frsky, toutes les marques fournissent pratiquement les mêmes données (RSSI, GPS, vario, etc...). La nouvelles télémétrie est très bien pour une minorité de capteurs ou de données calculées mais c'est tellement dommage que pour ces quelques cas, on doive toujours faire toutes ces manipulations. Il aurait été nettement préférable que la nouvelle télémétrie complète l'existante au lieu de la remplacer.

Je regrette d'avoir écrit ça (d'ailleurs j'ai corrigé mon commentaire), ce n'est pas régressif mais simplement déroutant, et ce n'est rien d'autre que du plug and play (en + c'est vraiment ce que l'on fait!) avec la possibilité d'intervenir manuellement quand le système bug ou que les capteurs ne sont pas connus.
Quand tu branches un périphe sur ton ordi, tu ne passes plus par une liste de tous les drivers possibles pour le mettre en route sauf quand ça bug où là tu cherches, parfois désespérément, sur le net, le driver qui va bien.
Par contre il y a beaucoup de nouvelles fonctionnalités qui demandent du temps pour être assimilées si l'on veut les utiliser ce qui n'est pas obligatoire sauf cas particulier.

En même temps, je trouvais aussi horrible d'avoir accès a des capteurs que l'on avais pas vraiment, et donc avant, il fallait se souvenir ce qu'il y a vraiment dans l'avions. Maintenant, tu as ce que tu as, perso, je préfère nettement comme ça, ça a considérablement simplifié les choses pour moi

G

dev.fred a écrit:... Je regrette d'avoir écrit ça (d'ailleurs j'ai corrigé mon commentaire), ce n'est pas régressif mais simplement déroutant, et ce n'est rien d'autre que du plug and play (en + c'est vraiment ce que l'on fait!) avec la possibilité d'intervenir manuellement quand le système bug ou que les capteurs ne sont pas connus. ...

Il serait quand même souhaitable que la conversion des modèles de la 2.0.x vers 2.1.x tienne compte des capteurs déjà utilisés dans une programmation car c'est laborieux de remettre tout en place.

Par ailleurs, je n'ai pas retrouvé où indiquer les valeurs pour l'alarme indiquant quand la tension du récepteur est basse ou critique. Ca n'est peut-être plus disponible je ne sais pas. Si c'est le cas, on peut le faire par quatre lignes de programmation (2 interrupteurs logiques et 2 fonctions spéciale).

Sacre100 a écrit:Il serait quand même souhaitable que la conversion des modèles de la 2.0.x vers 2.1.x tienne compte des capteurs déjà utilisés dans une programmation

Si c'est pas fait c'est simplement parce que c'est impossible, trop différent. Un exemple, des capteurs qui sont maintenant différenciés étaient auparavant "tous dans le même panier", donc on ne peut pas savoir lequel tu avais avant pour créer son équivalent. Et plus simplement, on ne sait pas quels capteurs tu avais tout court dans la liste de tous les possibles.

Kilrah a écrit:

Sacre100 a écrit:Il serait quand même souhaitable que la conversion des modèles de la 2.0.x vers 2.1.x tienne compte des capteurs déjà utilisés dans une programmation

Si c'est pas fait c'est simplement parce que c'est impossible, trop différent. Un exemple, des capteurs qui sont maintenant différenciés étaient auparavant "tous dans le même panier", donc on ne peut pas savoir lequel tu avais avant pour créer son équivalent. Et plus simplement, on ne sait pas quels capteurs tu avais tout court dans la liste de tous les possibles.

Pour savoir quels capteurs sont utilisés dans une programmation, il suffit de regarder là où ils peuvent être utilisés, soit dans les entrées, les interrupteurs logiques et les fonctions spéciales. Une fois un capteur repéré, il peut être créé avec le Physical ID habituel. Si c'est une configuration spécial (openXsensor ou autre), l'utilisateur le sait et pourra facilement changer l'ID physique dans la nouvelle télémétrie mais au moins, il ne perd pas sa programmation existante.

Pour les capteurs qui ne sont pas utilisés dans la programmation, même pour ceux utilisé dans LUA, cela ne pose aucun problème car ils sont détectés automatiquement par la suite.

Avec cette approche, on minimise le travail que doit faire l'utilisateur après la conversion et surtout il ne devra faire des corrections que dans la télémétrie sans devoir contrôler et corriger ses entrées, ses interrupteurs logiques et ses fonctions spéciales.

J'insiste bien sur le fait que cela ne concerne que les capteurs utilisés dans les entrées, les interrupteurs logiques et les fonctions spéciales, les autres, ce n'est pas un problème.

Sacre100 a écrit:Une fois un capteur repéré, il est créé s'il n'existe pas, avec le Physical ID habituel

Ca marche pas. VFAS peut soit venir du système D, soit du système S-Port, soit avec le traitement "perso" openXsensor, avec des Data ID différents et des attributs différents.

Avant tout ça était mis dans la même variable VFAS, maintenant plus donc on sait pas quelle version créer. Tu passerais plus de temps à corriger les erreurs qu'à reconfigurer proprement, certaines ne pouvant d'ailleurs pas être corrigées sans virer le capteur et donc toutes ses assignations.

Concernant la Taranis, le s.port étant sorti en même temps qu'elle, j'ai le sentiment que la majorité des utilisateurs n'ont que des capteurs s.port. Pour la carte Sky9x et la 9XR PRO, l'utilisateur doit indiquer s'il utilise le système D ou s.port, ça permet déjà d'orienter la conversion des modèles vers le bon système. Les autres radios ne sont pas concernées par la nouvelle télémétrie, donc à priori, ce n'est pas à prendre en compte.

Bien sûr que tous les cas ne seront pas pris en compte correctement en particulier openXsensor et le mix de capteur D et s.port sur la même radio, mais combien sont dans ce cas, une majorité, j'en doute mais je n'en sais rien et c'est à prendre en compte.

Sacre100 a écrit:Concernant la Taranis, le s.port étant sorti en même temps qu'elle, j'ai le sentiment que la majorité des utilisateurs n'ont que des capteurs s.port.

C'est un peu ce qu'on pensait mais c'est très loin d'être le cas, beaucoup de monde avait déjà du matos FrSky avant et continue à l'utiliser, et même beaucoup de nouveaux utilisateurs prennent du D parce qu'un peu moins cher, pour certaines fonctions comme le PPM, et pour des capteurs tierce partie.

Bref au final c'est une décision qui a été prise de ne pas passer des jours sur un truc qui ne sera qu'à moitié... 2.0 reste disponible et supporté.

Kilrah a écrit:... 2.0 reste disponible et supporté.

Le passage à la 2.1 attendra l'hiver, c'est pas le moment de le faire, la saison n'est pas encore finie. Par contre, les nouveaux possesseurs de Taranis ont tout intérêt à passer à la 2.1 tout de suite ce qui leur évitera cette conversion laborieuse.

Bonsoir,

En parlant de conversion, j'ai voulu faire voler un de mes hélicos BdB cet après midi, et je n'avais plus du tout de cyclique. Le passage en 2.1 m'a supprimé toutes les infos de la page hélico.
Sur companion, j'ai réinitialisé la page en fonction des mixages, comme suit:
Plateau: 120
limite: 0
Cyc long: E2 (prf) limite 100
Cyc lat: E1 (ail) limite 100
Source pas collectif: voie 11 limite 100
En simu, j'ai bien le déplacement des servos, mais je ne sais pas si les valeurs de limites sont correctes.
Merci de vos lumières
Paul

Sacre100 a écrit:

Kilrah a écrit:... 2.0 reste disponible et supporté.

Le passage à la 2.1 attendra l'hiver, c'est pas le moment de le faire, la saison n'est pas encore finie. Par contre, les nouveaux possesseurs de Taranis ont tout intérêt à passer à la 2.1 tout de suite ce qui leur évitera cette conversion laborieuse.

Je suis d'accord avec toi!

Surtout si une version 2.0.18 risque de voir le jour qui reprendra les amélioration de 2.1.1 mais sans avoir à modifier l'EEPROM.

Bonjour,

J'ai retrouvé les fichiers de Murphy et Lapin Fou pour les réglages d'un TREX 500 en 2.1.
J'ai mis les limites à 100 pour le cyclique et la voie 11, -50 pour le longitudinal ( inversion du sens ) et 50 pour le latéral.
A priori tests OK sur l'hélico dans mon jardin.
Merci.

Cool !
Peux-être, pourrais-tu poster ton EEPE pour les futurs utilisateur d'OpenTX 2.1 ??

C'est idiot, mais je n'arrive pas à récupérer mon fichier hélico qui fait partie d'un fichier global .bin regroupant tous mes modèles enregistrés sur l'émetteur.
Comment puis-je faire ?

Dans Companion, Il faut charger le EEPE de la radio. Puis il faut ouvrir une nouvelle fenêtre. Ensuite tu fait un glisser/coller de la fenêtre une vers la deux. Tu enregistres la seconde fenêtre sous le nom de ton modèle. Tu peux alors le mettre à dispo sur le forum après l'avoir mis au format ZIP.

Merci Murphy, je me coucherai moins bête ce soir

J'ai testé, ça marche !