Presentation de la telemetrie OpenTX 2.1- Traduction de "OpenTX 2.1 telemetry system preview"

CoyotteDundee a écrit: Hello Murphy, penses-tu réellement qu'elle est compliquée à programmer la Taranis ?

Tout est d'une logique simple et implacable.
- Si tu as compris comment fonctionne un mixage, c'est valable pour tous les mixages.
- Si tu as compris comment fonctionne un interrupteur logique, c'est valable pour tous les interrupteurs logiques de tous tes modèles.
- ...

Le modèle de base n'est pas plus compliqué à programmer qu'une autre radio. Et de plus quand je fait une mise à jour des nouvelles radios reçues au club j'installe le SCRIPT LUA pour la création des nouveaux modèles. Donc avec cet assistant 90% des utilisateurs s'en sortent et c'est suffisant pour eux.

Sinon très peu utilisent des sensors vario, GPS ou FLVSS. En fait sur une vingtaine que je connais nous ne sommes que deux ou trois. Car en définitive sur une liste de 22 possesseurs de Taranis dans ma région, je suis le seul à participer à ce forum. Donc cela veut dire que les autres ignorent totalement ce qui se passe. C'est moi qui passe un mail à tous mes correspondant quand il y a de gros changements sur le soft.

J'ai aussi deux forums de club auxquels je participent et sur lesquels j'entretient une rubrique sur la Taranis.

Merci quand même aux développeurs pour le boulot qu'ils font.

Bonjour,

Après avoir basculé ma radio en 2.1, voici quelques remarques qui font peut-être partie des corrections apportées dans la future version.
1- Pour la plupart des modèles, il m'a fallu reprogrammer le système de déclenchement des chronos
2- Quand on demande une lecture audio de ces chronos dans les fonctions spéciales, la voie ajoute le terme " tension" au lieu de mn et sec après les chiffres.
3- Dans les inters logiques, pour certains modèles, je ne peux pas accéder à un certain nombre de champs dont RSSI, ou alt qui ne sont pas dans le menu déroulant.
4- Dans la plupart des modèles, plusieurs lignes de fonctions spéciales vides ont été générées, et il m'a fallu les supprimer pour améliorer la lisibilité.
A qui peut-on faire remonter ces informations ?
Merci des précisions que vous pourrez me communiquer
Cdlt
Paul

pat31 a écrit:...

Sare 100 a écrit:Ah ben non, c'est utile pour les capteurs s.port, si tu as deux vario, il te faudra changer l'ID physique d'un des deux et indiquer l'ID que tu as choisi pour les données du deuxième vario.

Ok pour ce qui est de l'ID, mais là il s'agit de la case d'à coté qui est "INSTANCE".
Apparement, c'est 2 choses distinctes . Me gourge ? ...

Il y a un problème de terminologie. Il y a deux numérotations :
- le numéro qui identifie le capteur (GPS, vario, capteur de courant, etc...)
- le numéro qui identifie la donnée (longitude, latitude, vitesse GPS, cap GPS, altitude, vitesse verticale, courant, volt, etc...)

Le numéro qui identifie est appelé "instance" dans la nouvelle télémétrie. Le numéro qui identifie la donnée est appelé ID.

La terminologie de Frsky est :
- Physical ID (PhyId) pour identifier les capteurs, cela correspond à "instance" dans OpenTx.
- Data ID pour identifier la donnée, cela correspond à "ID" dans OpenTx.

Re,

Je l'aurais un jour...je l'aurais

Merci pour cette explication.
Je résume :
INSTANCE correspond à PhyId
ID  correspond à identifiant des données

Pour compléter ce que je dis au sujet des ID, voici la liste des Data ID (ID) issus des sources d'openTx :

Code:


ALT (altitude vario)             100
VARIO (vitesse verticale vario)  110
CURR (courant)                   200
VFAS (???)                       210
CELLS (???)                      300
T1 (température 1)               400
T2 (température 2)               410
RPM (tour par minute)            500
FUEL (carburant)                 600
ACCX (accélération X)            700
ACCY (accélération Y)            710
ACCZ (accélération Z)            720
GPS_LONG_LATI (longitude ou latitude GPS) 800
GPS_ALT (altitude GPS)           820
GPS_SPEED (vitesse GPS)          830
GPS_COURS (cap GPS)              840
GPS_TIME_DATE (heure ou date GPS) 850
A3                               900
A4                               910
AIR_SPEED (vitesse air)          A00
RSSI (RSSI Rx)                   F101
ADC1                             F102
ADC2                             F103
SP2UART_A                        FD00
SP2UART_B                        FD01
BATT (Batterie Tx)                F104        (confirmé par Murphy)
SWR (SWR Tx)                     F105
XJT_VERSION                      F106
FUEL_QTY (quantité de carburant) 0A10


La liste des Physical ID (INSTANCE) est la suivante :

Code:


VARIO            1
FLVSS            2
FAS              3
GPS              4
RPM              5
SP2UH            6 (je ne sais pas ce que c'est !!!)
SP2UR            7 (je ne sais pas ce que c'est !!!)
AirSpeed        10 (je ne suis pas sûr, à confirmer)
Rx (récepteur)  25
Tx interne      25
Tx externe     ??? (y'a-t-il un PhyID spécifique, je ne sais pas)


C'est un premier jet, tous ces identifiants doivent être confirmer lors des tests.

CoyotteDundee a écrit:Il n'est écrit nulle part que cette nouvelle version est obligatoire. Ceux qui trouveraient l'ancienne version plus adaptée à leurs besoins peuvent rester en 2.0.17 ou autre. C'est ça aussi la force d'OpenTx

on peut lire en conclusion de OpenTX 2.1 released! sur http://openrcforums.com/forum/viewtopic.php?f=45&t=7239

Kilrah a écrit:En raison des différences majeures et pour éviter de créer de la confusion chez les utilisateurs, les versions majeures de ce genre ne sont plus offertes comme une « mise à niveau », elles sont en paquet séparé que vous installez indépendamment des versions précédentes. Vous pouvez donc installer et utiliser Companion 2.0 et 2.1 simultanément sur votre PC, et par exemple gérer une radio sur 2.0 et un autre sur 2.1 sans problème. 2.0 restera disponible et même, être maintenu pendant un certain temps (corrections de bugs seulement) pour les utilisateurs qui ne veulent pas faire le saut, mais préfèrent profiter d'une version stable.

L'équipe OpenTx a bien conscience de la marche, mais à la différence d'une entreprise qui cherche à vendre ses produits, elle met en œuvre ce que l'informatique a de + performant pour gérer la complexité que représente la gestion de systèmes télémétriques de marques et de protocoles différents depuis une seul radio.

@Sacre100: A propos de la liste des numéros d'instance, merci pour ta cette découverte . Dans quelle partie du code as tu trouvé ce début de liste de physical ID ?

En fait j'ai trouvé dans opentx/radio/src/telemetry/frsky.h en utilisant le mot clés Physical ID au lieu d'instance qui ne me menait à rien dans github.

pp340 a écrit:A qui peut-on faire remonter ces informations ?

https://github.com/opentx/opentx/issues/

Il faut créer un compte avec le bouton vert sign up

dev.fred a écrit:@Sacre100: A propos de la liste des numéros d'instance, merci pour ta découverte . Dans quelle partie du code as tu trouvé ce début de liste de physical ID ?

En fait j'ai trouvé dans opentx/radio/src/telemetry/frsky.h en utilisant le mot clés Physical ID au lieu d'instance qui ne me menait à rien dans github.

Ca n'est pas une découverte pour moi, ça fait pratiquement une année que je sais que ça se trouve là.

Ca serait bien si on pouvait sélectionner l'Id de la donnée par son nom et non par son numéro, ça rendrait la chose un peu plus conviviale. C'est comme si dans les mixages on sélecionnait une source par son numéro au lieu de son nom, tu vois comme ça serait sympa de programmer un modèle.

J'ai trois questions :

1. Quand tu détectes automatiquement les capteurs, les données découvertes sont-elle nommées automatiquement ou faut-il le faire manuellement en connaissant quel DataId correspond à quellle donnée ?
   
2. Quand OpenTx détecte qu'un capteur n'est plus présent, que se passe-t-il, la données est-elle supprimée automatiquement de la liste ? Et quid des valeurs calculées avec celles-ci, sont-elles aussi supprimés en cascade ?
   
3. Est-on vraiment limité à 3 écrans de télémétrie ? Si c'est le cas, ça fait peu et  ça serait dommage.
   

Le point 2 me concerne vraiment car je déplace mes capteurs (vario, GPS, IMU) d'une machine à l'autre alors si je perds les données et les calculs lors que je vole temporairement sans capteurs, ce sera ennuyeux.

Le points 3 me concernent aussi car j'ai toujours 3 écrans de télémétrie et j'en concote un 4ème alors si c'est vraiment le cas, je vais laisser tomber.

Sacre100 a écrit:
J'ai trois questions :

1) Y'a un nom par défaut que tu peux ensuite changer si tu veux.
2) Il reste jusqu'à ce que tu décides de le virer.
3) 4. Suffit d'installer companion 2.1 pour le voir

furynick a écrit:Moi ce que je ne comprends pas c'est comment le Rx peut gérer plusieurs capteurs sachant qu'il fait du polling (interrogation) sur un nombre limité et défini d'ID.

Aurais-je raté quelque chose ?

Le RX interroge les Physical ID, donc chaque capteur "matériel". A chaque interrogation c'est le capteur correspondant qui décide s'il le souhaite de transmettre une donnée, qui peut être n'importe quoi. Les capteurs qui retournent plusieurs valeurs alternent entre elles, et généralement ne répondent qu'à une fraction des interrogations pour laisser de la place aux autres.

pp340 a écrit:
1- Pour la plupart des modèles, il m'a fallu reprogrammer le système de déclenchement des chronos

Ils étaient configurés comment avant la migration?

pp340 a écrit:
2- Quand on demande une lecture audio de ces chronos dans les fonctions spéciales, la voie ajoute le terme " tension" au lieu de mn et sec après les chiffres.

Tu as oublié de changer ton pack d'annonces vocales avec une version compatible 2.1.

pp340 a écrit:
3- Dans les inters logiques, pour certains modèles, je ne peux pas accéder à un certain nombre de champs dont RSSI, ou alt qui ne sont pas dans le menu déroulant.

Tous les réglages de télémétrie sont supprimés lors de la migration, il faut passer par l'étape "découverte des capteurs" avant de pouvoir reconfigurer.

pp340 a écrit:
4- Dans la plupart des modèles, plusieurs lignes de fonctions spéciales vides ont été générées, et il m'a fallu les supprimer pour améliorer la lisibilité.

C'était probablement des fonctions qui étaient liées à tes annonces de télémétrie... qui ont perdu leurs sources et nécessitent aussi d'être reconfigurées.

Kilrah a écrit:

Sacre100 a écrit:
J'ai trois questions :

1) Y'a un nom par défaut que tu peux ensuite changer si tu veux.
2) Il reste jusqu'à ce que tu décides de le virer.
3) 4. Suffit d'installer companion 2.1 pour le voir

La 2.1 est installée, tu as raison 4, j'avais mal vu. Faut dire que c'est caché tout en bas et qu'au début, je me suis même demandé où c'était.

Quand tu vires une variable, les données calculées qui l'utilise sont-elles supprimées en cascade ?

Et les telemetry-scripts peuvent-ils recevoir des paramètres en entrée comme les model-scripts ou doit-on toujours passer via des variables globales entre model-script et telemetry-script ?

Merci pour vos réponses.
A Kilrah: Le chrono 1 était déclenché par le manche des Gaz, et le chrono 2 par un interrupteur.
Après la migration, je les ai retrouvés associés à des inter logiques.
Ou puis-je trouver un pack d'annonces vocales en français compatibles 2.1 ?

ici
http://voices-21.open-tx.org/

Le départ est dans companion après appui sur la flèche bleu télécharger puis télécharger les fichiers son:

OK merci

Sacre100 a écrit:Eh, ayant développé un capteur pour mon horizon artificiel, tu crois que je me sens dérouté par cette nouvelle télémétrie, c'est mal me connaitre. N'empêche que je trouve ça pas aussi bien pensé que le reste d'OpenTx et que ça va générer beaucoup de question sur les forums, pas de la part de ceux qui ont déjà mis les mains dans le cambouis et qui savent fouiner tous seuls, mais pense à tous les autres.

Eula !! Je le sais bien ! C'est juste une pointe d'humour et non d'humeur !

C'est clair qu'il faudra faire un bon tuto.

Merci à tous pour ces débuts d'explications détaillées sur la nouvelle télémétrie, j'y vois déjà plus clair.
Cela ne parait pas simple au 1er abord mais je suis certain que d'ici quelques temps on se dira que c'est bien mieux qu'avant !

En tout cas avec cette radio on ne s'ennuie jamais, même quand la météo ne permet pas de profiter de notre loisir favori on peut toujours apprendre et améliorer la programmation de nos modèles (en tout cas pour ceux qui sont aussi passionnés par l'informatique comme moi)

Sacre100 a écrit:SP2UH            6 (je ne sais pas ce que c'est !!!)
SP2UR            7 (je ne sais pas ce que c'est !!!)

Il s'agit de SP2UART:


Curieux le décalage de -1  

Re,
Afin de me coucher moins bête ce soir, pouvez vous me dire à quel capteur correspond SP2UART_H et _R ?

http://www.alofthobbies.com/frsky-sp2uart-2.html

C'est un port série accompagné de 2 ports de convertisseur connectable sur le S-Port qui peut s'utiliser en 2 modes High et Normal!
Un super produit surement indispensable mais un peu compliqué à expliquer de l'aveu du site alofthobbies : The SP2UART is a little hard to explain.  

Sacre100 a écrit:
Quand tu vires une variable, les données calculées qui l'utilise sont-elles supprimées en cascade ?

Et les telemetry-scripts peuvent-ils recevoir des paramètres en entrée comme les model-scripts ou doit-on toujours passer via des variables globales entre model-script et telemetry-script ?

Sauf erreur rien n'est viré automatiquement, les fonctions qui utilisaient le capteur sont toujours là mais avec "rien" en entrée.

Pour ce qui est de lua aucune idée, j'ai rien suivi.

pp340 a écrit:A Kilrah: Le chrono 1 était déclenché par le manche des Gaz, et le chrono 2 par un interrupteur.
Après la migration, je les ai retrouvés associés à des inter logiques.

Migration faite dans la radio ou dans companion? Avec la version finale ou une préversion? Parce que personne d'autre n'a reporté ce problème, et mes modèles sont OK...

Bonsoir,
Migration faite à partir de companion 2.1 donc la version finale.
PF