ACCST D16 2.1.0 et ACCESS v2.1.0

Merci beaucoup pour ces précisions. Il faudra certainement  s'attendre à un certain retard pour les correctifs car je redoute une forte réduction des capacités à traiter ces multiples demandes compte tenu des problèmes de santé qui règnent dans le monde ces temps. Cldt

Ou que la V2 corrigée soit infectée par le corona....

Zeblade64 a écrit:Ou que la V2 corrigée soit infectée par le corona....

bien fraiche la corona !




avec moderation bien sur ! lol

Bonjour
Une marque à éviter dans vos modèles

Hi hi, j'adore votre humour les mecs

je confirme (merci encore une fois à lapinFou pour son aide inestimable) les soucis rencontrés sur un s6r avec l'accst d16 2.0.0 :

-Télémétrie fantaisiste : le capteur d'latitude remonte régulièrement ( toutes les 4 ou 5 secondes!!) des valeurs erronées (du style 78600 m)
-quasi impossibilité d’utiliser le script lua de réglage du s6r avec la x9d+ ; il lit une valeur sur 3 ou 4;(par contre il marche parfaitement avec la x9 lite en accst - je n'ai pas d'explication à cela).

j'ai repassé le s6r avec la version de fmw du dernier pack(ainsi que la x9d+ et tout refonctionne correctement..

Bonjour,
pour ceux qui veulent tester les nouveaux firmware 2.1.0 pendant le confinement

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

Les premiers retours semblent bons.

Pascal

Merci pour l'info.

Merci pour l'info.

Heeeeeu , juste une question , j'ai été absent de France 2 mois et je découvre ce soucis en lisant le forum , est ce que ce bug n'expliquerai pas les mouvement incontrôlé des servos au bout d'un certain temps d'utilisation que j'ai décris avec les box RB 10 et RB 20 que j'ai testé en double réception connecté en S-Bus avec un X8R et un R9MM que je décris ici ?

https://frskytaranis.forumactif.org/t9420-redundancy-box-frsky-vos-avis

Non je ne pense pas que cela ait un rapport avec ton problème.
Là il s'agit d'un problème statistiquement rare dont le détail est décrit ici (l'article initial de l'équipe Allemande ayant prouvé le bug est à la fin de l'article).

Pourtant les symptômes sont très proches : mouvement erratiques des servos dans certaine conditions c'est vraiment ce que j'avais .

En plus , d'après se que je comprend en lisant le report , le bug était présent quand on utilisait la sorties S-Bus c'est ça ?

Et la seule fois ou j'utilise le S-Bus pour commander les voies c'est quand je connecte la Box au 2 récepteurs , autrement dans mes autres configuration , les servos sont directement connecté aux sorties de chaque récepteur ....  ....

Je cite :

Connected to the SBUS is a Teensy (Arduino) that reviews the expected result on the SBUS that would be connected to the flight controller.

Traduction

Connecté au SBUS est un Teensy (Arduino) qui examine le résultat attendu sur le SBUS qui serait connecté au contrôleur de vol

https://github.com/FrSkyRC/Firmware-Test/issues/1#issuecomment-600151327

Le bug, dans le cas le plus défavorable, gèle les sorties servos pendant 0,9s avec une des voies dont la position est erronée. L'apparition du bug est statistiquement rare (une des raisons pour laquelle il n'a pas pu être reproduit pendant des années). On est donc loin de tes symptômes.
Lire l'article initial de l'équipe Allemande ayant prouvé le bug à la fin de l'article de LapinFou.

De toutes façon , dans le doute j'ai démonté les 2 box des avions et ça tombe bien je vais avoir du temps pour faire des tests ......

Pour reproduire le bug, il faut un environnement HF dégradé, envoyer des ordres évolutifs sur toutes les voies et surveiller les trames S.BUS pendant plusieurs heures à l'aide d'un fichier journal puis décortiquer le tout. Ce n'est vraiment pas un bug systématique.

De mémoire tu utilisais un RB10 ou 20 avec un S8R et un R9 avec des servos analogiques et ton problème était quasi-systématique.

Ceeb182 a écrit:Pour reproduire le bug, il faut un environnement HF dégradé, envoyer des ordres évolutifs sur toutes les voies et surveiller les trames S.BUS pendant plusieurs heures à l'aide d'un fichier journal puis décortiquer le tout. Ce n'est vraiment pas un bug systématique.

De mémoire tu utilisais un RB10 ou 20 avec un S8R et un R9 avec des servos analogiques et ton problème était quasi-systématique.

Heeeu , non , c'étais l’apparition au bout d'un temps X de frétillement sur des servos analogique et/ou numérique ( A vérifier en test ) quelques soit les voies quand j'utilisai une RB 10 ou une RB 20 avec un récepteur de la série S, X , ou meme RX couplé ou pas en S-Bus sur la Box avec un récepteur de la série R .

@cri.cri : Je confirme ce qui a déjà été dit, ACCST version une ne devrait pas produire ce que tu as rencontré

Volant passablement, je remarque le bug de la version une de temps à autre en observant le comportant de mes aéronefs en vol. Il s'agit d’absence de commandes et / ou d'une commande non sollicitée (principalement pour moi au niveau de la profondeur) de courte durée ne laissant pas de trace au niveau du log (je note le moment quand ça arrive et j'épluche les logs).

Donc je vais me faire mon petit protocole de test :

Une radio X9D avec récepteur de la série S ou X et R en FCC avec l'ancien fireware branché en S-Bus sur la Box RB 10 avec servos numérique et/ou analogique .

Une radio X12S avec récepteur de la série S ou X et R en FCC  flashé avec la mise à jour branché en S-Bus sur la Box RB 10 avec servos numérique et/ou analogique .

Honnêtement , je pense que peux de personne vole avec ma configuration , donc forcement peux de gens peuvent constaté se bug , comme je l'avait dit , je pense que ca vient soit d'un dysfonctionnement des Box et/ou du S-Bus dans certaine condition , reste a trouver les quelles ......

Juste avant de démonter les Box des avions , j'ai pu constater que ca réussi à me bloquer le fonctionnement d'un servos de volet qui a fini par cramer .....

Donc premier bug que je constate avec la X9D , si je met le S-Port de la Box , je perd d'une façon aléatoire l'affichage des fonctions du S8R , c'est a dire que j'ai 3 traits à la place de l'état de la fonction quand je vais dans le menu Outils et que j’exécute le LUA du S8R .

Tu as trouvé une version 2.1 pour SxR ?

3djc a écrit:Tu as trouvé une version 2.1 pour SxR ?

Pour l'instant , j'ai pas flashé le correctif , je fais les test avec l'ancienne version pour reproduire le bug .

C’est pratiquement impossible de reproduire ce bug dans des conditions standard. Pour y arriver, les allemands ont du utiliser un signal très faible et inonder le récepteur de plusieurs réseaux wifi avec du streaming vidéo a fond

L'ensemble des firmware de test sur github est la :

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

rien sur les SxR pour l'instant

3djc a écrit:C’est pratiquement impossible de reproduire ce bug dans des conditions standard. Pour y arriver, les allemands ont du utiliser un signal très faible et inonder le récepteur de plusieurs réseaux wifi avec du streaming vidéo a fond

Je parle de mon bug , celui qui fait frétiller mes servos avec la Box , le plus pénible est que sur le banc j'y arrive pas .......

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+