ACCST D16 2.1.0 et ACCESS v2.1.0

olivierpo a écrit:les firmwares 2.1 pour les SxR sont ici :

https://github.com/FrSkyRC/Firmware-Test

je testerai demain si ça fonctionne avec la telemetrie et le LUA de config.


En fait j'ai fait le 1er test tout de suite,

config : x9d+ en 2.3.5 et xjt en 2.1 - s6r en lbt v2.1et capteur altitude "high precision" frsky

- La télémétrie a l'air de fonctionner sans bug, le capteur d'altitude n'a pas donné une valeur erronée en 30 min (contre une fausse toutes les 15s avec la 2.01) - par contre j'ai un phénomène que j'avais déjà sur ma x9 lite (mais pas avec la x9d+ et les firmware du pack 2.3.5): l'altitude s’incrémente tout doucement - en 20 minutes de 6/7 mètres environ (bien évidemment sans bouger le modèle)
- Le script lua de config à l'air de fonctionner aussi. il marche 2 fois sur 3, mais ça n'a jamais été mieux que ça avec les firmware v1 (contre 1 fois sur 20 avec la 2.01)
- Pour l'immunité au bug du freeze de servos liées aux pertes de trames, je n'ai pas les outils pour le tester.


A+

Si tu utilises un vario FrSky, il fonctionne avec la pression atmosphérique.
Donc, ce n'est pas anormal d'avoir une imprécision de plusieurs mètres.

Sur un moto planeur (ou avion), l’altitude peut changer rien qu'avec la variation de vitesse de l'hélice...

Pour le script LUA, il faut débrancher les capteurs Sport. Si tu as encore le problème avec aucun capteur de brancher sur le S.Port, alors là ce n'est pas normal.

En plus je ne suis pas sûr du tout que le capteur soit compensé en température.

Ceeb182 a écrit:En plus je ne suis pas sûr du tout que le capteur soit compensé en température.

Exact. Effectivement, je ne pense pas non plus qu'il y ait une compensation en température.

J'avance sur mon bug , alors j'ai eu la surprise de constater qu'il y a 2 modèles de BOX qui se ressemble beaucoup , le R.B 20 qui est une 15 voies et la REDUNDANCY BUS qui est une 16 voies et qui n'est plus produite , comme j'avais imprimer la notice en Francais sur le site je vous laisse deviner laquelle j'avais ......
Apres avoir corrigé le tir , j'ai continué mes essaies , donc sur certaine voies , pas toutes , le frétillement apparait au bout d'un temps X , pas forcement sur les voies ou il y a ds Y , elle m'a encore cramé 2 servos branchés seul en voies 8 et 10 , ceux des trappes de trains d'atterrissages principal , et j'arrive pas à savoir si c'est la BOX qui déconne ou si c'est la liaison S-Bus de l'émetteur .

La télémétrie de la BOX ne veux pas fonctionner aussi .

Ça y est la version 2.1.0 est en ligne sur le site frsky. Par contre pas pour le S8R.

doit on mettre à jour avec version 2.1.0 ?
Puisque j’ai installé mon module ISRM je ne devrais pas être concerné ?

Zeblade64 a écrit:Ça y est la version 2.1.0 est en ligne sur le site frsky. Par contre pas pour le S8R.

Peut-être que FrSky va corriger ce bus ? → #3 S8R quickmode startup time too long

LapinFou a écrit:

Ceeb182 a écrit:En plus je ne suis pas sûr du tout que le capteur soit compensé en température.

Exact. Effectivement, je ne pense pas non plus qu'il y ait une compensation en température.

Je ne pense pas non plus qu'il soit compensé mais deux choses me font penser qu'il y a aussi un léger pb de calcul sur la x9D+
- avec le même récepteur et capteur (mais pas le même firmware tx forcement) l'information d'altitude est parfaitement stable avec ma x9 lite en accst d16. (la dérive se fait de quelques cm autour du point zéro et ce sur 2 heures)
- sur la x9D+ l’incrémentation est constante et linéaire (20 M à l'heure _testé sur 3 heures), ce qui ne ressemble pas à une courbe de montée en température d'un composant.

Apres avoir refait plusieurs test en vérifiant les paramètres suivants :
- tension alim capteur,
-température et pression local
-mesure altitude toutes les secondes pendant 1h30 avec et sans offset auto
on constate que la courbe d’erreur de l’attitude est bien logarithmique (donc certainement liée à l’élévation de température du capteur). l'allure est la même avec un fmw v1 ou v2 et quelque soit l’émetteur. La seule seule chose c'est que selon le moment ou on fait le test (j'ai pourtant respecté toujours un temps de refroidissement d'1h30 du capteur) la vitesse de dérive n'est pas la même et semble aléatoire (de 11 à 26 m /heure).
je vais refaire le meme genre de test avec mon capteur unisens pour lequel je n'ai pas constaté ce phénomène jusqu’à présent.

A+

Étrange

@olivierpo & Ceeb182 : Un altimètre atmosphérique se base sur la pression de son environnement (pression statique) pour calculer l'altitude. Si la pression atmosphérique varie, alors l'altitude le fera également (à raison d'environ un dixième de mètre par hPa de plus ou moins à l'altitude zéro) -> tout changement météorologique fait varier l'altitude calculée. De même un changement de température (donc de pression statique) fait également varier l'altitude calculée. Ces deux phénomènes naturels peuvent donc provoquer des petites variations d'altitude bien que le capteur (modèle) ne bouge pas.

Je ne vois pas trop pourquoi l'émetteur pourrait être responsable de la variation de l'altitude. OpenTx est le logiciel qui calcule la valeur d'altitude en fonction de la valeur transmise par le récepteur. Seul le capteur peut provoquer ces variations. ACCST, le protocole de communication, devrait être "transparent" entre la version 1 et 2

Bonjour,
les premiers firmwares ACCESS en version 2.1.0 ont été postés hier :

https://github.com/FrSkyRC/Firmware-Test

Pascal

Yep !
Ici pour être exact → https://github.com/FrSkyRC/Firmware-Test/tree/master/ACCESS%20firmwares%20v2.1.0

LapinFou a écrit:Yep !
Ici pour être exact → https://github.com/FrSkyRC/Firmware-Test/tree/master/ACCESS%20firmwares%20v2.1.0

oui super...
le personnel FrSky recommence le travail on dirait ?
qui saurait si on peut flasher le module ISRM pour ma X12 ? avec ce soft ...
1.3.07 with iXJT v2.1.0 update
le précédent que j'ai installé : ISRM_S_X10S_191113.frsk

j'ai déjà mis à jour 2 récepteurs G-RX8 en ACCESS
mais j'ai eu un peu de mal à les binder
la procédure ne me parait pas simple, à moins que je ne pratique pas bien ?

Il faut attendre que le firmware du module ISRM soit proposé au téléchargement avant de réaliser l'upgrade des récepteurs et du module que ce soit les récepteurs ACCESS ou les récepteurs ACCST car tout doit être migré en 2.1.0 en même temps.

Pascal.

Pour info, une mise à jour du module multi supportant la version 2.1.0 du protocole ACCST est disponible, ainsi que dès demain le support OpenTX correspondant dans les nightlies

Bonjour,
merci 3djc je viens e tester sur ma X12S avec multimodule mis à jour et test de la version nightlies du jour et cela semble parfaitement fonctionner avec la version 2.1.0 sur un X6R => bind et tests sur table OK.

Pascal.

filduch a écrit:@olivierpo & Ceeb182 : Un altimètre atmosphérique se base sur la pression de son environnement (pression statique) pour calculer l'altitude. Si la pression atmosphérique varie, alors l'altitude le fera également (à raison d'environ un dixième de mètre par hPa de plus ou moins à l'altitude zéro) -> tout changement météorologique fait varier l'altitude calculée. De même un changement de température (donc de pression statique) fait également varier l'altitude calculée. Ces deux phénomènes naturels peuvent donc provoquer des petites variations d'altitude bien que le capteur (modèle) ne bouge pas.

Je ne vois pas trop pourquoi l'émetteur pourrait être responsable de la variation de l'altitude. OpenTx est le logiciel qui calcule la valeur d'altitude en fonction de la valeur transmise par le récepteur. Seul le capteur peut provoquer ces variations. ACCST, le protocole de communication, devrait être "transparent" entre la version 1 et 2

C'est plutot 10m par hPa (en aero on compte 1hPa/30ft)

En principe on estime la densité de l'air de moitié par tranche de 5'500m. Au niveau de la mer, la référence est de 1013 hpa. A 5'500 on aura donc approximativement 506 hpa. 506 hpa / 5'500m = environ 0,1 mètre par hpa.

Oui environ 500hPa de pression atmo à 5000m, donc on perd bien 1hPa tous les 10m, et non 0,1m ;-)

Tu as tout à fait raison

Un changement de météo peut donc provoquer une assez grande différence d'altitude même au cours d'une seule journée.

apparemment l'access v2.1 n'est pas encore dispo pour la x9 lite.
donc je suppose que les recepteurs rx4r et rx6r pour ma part ne peuvent pas etre updates en v2.1 ?

Effectivement, les protocoles ACCST et ACCESS version 2 ne sont pas supportés par la X9 lite. Les Rx4R et Rx6R supportent ACCST en version 2 et ACCESS en version 1. Les deux éléments (émetteur & récepteur) doivent être de la même version pour communiquer.

olivierpo a écrit:apparemment l'access v2.1 n'est pas encore dispo pour la x9 lite.
donc je suppose que les recepteurs rx4r et rx6r pour ma part ne peuvent pas etre updates en v2.1 ?

Ca y est :  
https://www.frsky-rc.com/access-2-x-x-important-firmware-update/
https://www.frsky-rc.com/taranis-x9-lite/

Merci Alain,,
J'ai vu et mis à jour la radio et les rx
Quelqu'un sait à quoi servent les nouvelles options de bindage sur les récepteurs en access 2.1 (télémétrie 25mw et f port?)