bug sur simulateur opentx + precision de capteur sur configuration smart port / converter / px4

Bonjour à tous,
J'ai remarqué qu'il semble manquer le paramètre permettant d'ajuster la précision des capteurs dans le cas d'une configuration smart port / converter / px4. Par exemple dans le cas d'un GPS connecté sur PX4 puis relayé sur le smart port d'un récepteur frsky, la vitesse "Gspd" de celui-ci apparaîtra toujours avec un maximum de precision 1kts (0.51m/s), même bien sur en corrigeant sur opentx "0.00" . De même le cap "Hdg" aura une précision maximum du degré.
Cela semble venir de la configuration du PX4 (serialX_protocol = 4: FRsky S port) qui ne permet pas, il me semble, le contrôle ni l'ajustement du flux renvoyé sur le smart port frsky, car j'ai testé avec des GPS différents, des câbles de conversion différents et des télécommandes différentes avec toujours le même résultat. Bref pour avoir une mesure de faible vitesse en smart port, seul le classique GPS de frsky semble convenir.
Je précise que pour le débogage, j'utilise souvent le simulateur de télémesure qui ne permet pas de rentrer un capteur non déclaré dans la liste classique. Je ne trouve pas très pratique ce mic-mac ID / instance : par exemple prenons un capteur de température Tmp2 découvert directement par la télécommande, puis réimporter sur opentx, identifié par ID = 4 sous l’écran principal, ID= 410 5 sous l’écran édit, impossible à simuler il me semble. Ou bien presque ce même capteur découvert par le simulateur de la télécommande en ID = 228 sous l’écran principal, ID = 410 5 sous l’écran édit, qu'il est possible de simuler en utilisant l'instance 5. Est-ce un bug du simulateur ? Bon pour les scripts lua, je suis passé définitivement au "getValue("Tmp2")" qui simplifie.
Je rajoute encore une question, si jamais quelqu'un avait une idée, mais est il possible de gérer la fréquence d’acquisition de ces capteurs. Par exemple, dans le cas des coordonnées données par un GPS passant par la PX4 + converter + smart port, la fréquence parait aléatoire, et surtout jamais supérieur au Hz. Quelle est la limitation, matériel ou logiciel ?

Merci pour votre aide

- Pour le GPS FrSky sa vitesse de mise à jour ne dépasse pas 1Hz.
- Pour la précision des capteurs, elle est définie de part la technologie utilisée et ne peut pas se paramétrer manuellement.
- Pour le "0.00", il s'agit simplement de l'affichage des chiffres significatifs, mais si la précision du capteur est inférieure au format d'affichage, cela ne change rien.
- Pour le simulateur des télémesures de Companion, c'est vrai qu'il mériterait un lifting. Cependant les ressources humaines allouées à OpenTx ne sont pas extensibles et la priorité est donnée à l'OS de la radio et non au logiciel "Companion".

Merci pour la réponse.
    - Concernant les fréquence de mise à jour, je me permet de douter. La plupart des GPS permettent de monter sans problème à 5Hz, notamment la gamme ublox et le GPS v2 Frsky. Dans le cas du GPS Frsky sur smart/port, j'ai devant moi des relevés en 3.3Hz ou l'on arrive à trouver des blocs de ligne ou la vitesse varie sur 4 points continue. Donc mathématiquement au moins 2.5Hz de mise à jour.
   - Concernant les chiffres significatifs, je confirme qu'ils définissent en partie la précision des capteurs sous opentx. Pour confirmer, un test simple : si l'on simule une vitesse de 0.1m/s et que l'on règle ensuite les chiffres significatifs à 0.-- sous opentx. Si l'on récupère ensuite "Gspd" avec un script avec une résolution de 0.00, la vitesse sera quand même de 0m/s.
Bon ensuite la précision des vitesses de GPS sont à ma connaissance souvent supérieur à 1kt/s. Dans mon cas, le GPS mesure en mm/s, donc un facteur 100 sans problème.
   - Lors de la programmation d'un logiciel, trouver les bogs est aussi un gros travail. Mais les utilisateurs peuvent parfois en faire une partie. Mes remarques ne sont à prendre que dans un sens constructif, car il est souvent possible à notre échelle de feinter les problèmes.

Sur le problème noté de companion, j'ai identifié un peu plus loin. Si l'on prend un capteur en instance 25 déclaré, le simuler le passe en 24 sous l’écran télémétrie simulé de la télécommande, le simulateur de télémesure le propose en 24, la simul de l'édition le garde en 25. L'échange se fait en ID 248.

- Pour la fréquence de mise à jour du GPS, je me suis tout simplement basé sur le post de 3djc. 3djc est un des développeurs d'OpenTx très actif (bsongis, 3djc, kilrah et bien d'autres...).
- Pour contribuer au débogage ou à l’amélioration d'OpenTx/Companion, il faut aller sur le dépôt GitHub du projet, puis aller dans Issues, appuyer sur le bouton vert "New Issue" et expliquer avec le plus de détail possible le bug ou l'amélioration. Si vous êtes développeur, vous pouvez contribuer directement au projet.

Merci pour la réponse, j'avais noté d'autres points, notamment le transfert des modèles vers le pc puis retour direct sur la télécommande avec des capteurs qui change d'ID, sur la dernière version 2.3.5. J'ai donc ouvert un post dans le github avec mon superbe anglais