Pour la petite histoire, voici un résumé et une explication "avec les mains" pour comprendre ce bug.
Le ACCST est basé sur une technologie à sauts de fréquence. C'est à dire qu'autour du 2.4GHz, il y a plein de canaux plus ou moins autour de 2.4GHz. C'est la même chose avec vos box et le WiFi, il y a des canaux de 1 à 13.
Les changements de canaux (les fameux sauts de fréquence) ne se font pas au hasard.
Un algo permet de déterminer une séquence de sauts qui garantit au mieux qu'en cas de problème on arrivera bien à faire passer l'info sur une fréquence ou une autre.
Les paquets de données sont envoyées toutes les 9ms.
Dans ce paquet transmit au récepteur, on trouve l'information de position des servos ainsi que la prochaine fréquence où le prochain paquet sera transmis.
Bien évidemment la radio et le RX doivent être synchronisés afin d’émettre/recevoir sur la même fréquence.
La radio doit transmettre sur la bonne fréquence, de même, le RX doit écouter le prochain message sur la bonne fréquence.
La durée de transmission est très très courte (inférieure à 1ms), donc la chance de collision est très faible.
Dans un environnement très bruité d'un point de vue RF (Radio Fréquence), les données numériques entre l’émetteur (la radio) et le récepteur (le RX dans votre modèle) peuvent être corrompues (données non utilisables).
La correction apportée par FrSky est un algo plus robuste de détection/correction d'erreurs des paquets.
En clair le nouvel algo garantit que dans tous les cas de figures un paquet corrompu ne puisse plus être faussement déclaré comme valide.
Cependant, ils en ont profité pour ajouter une couche de cryptage des données (un peu comme le nouveau protocole ACCESS), pour "notre bien" et afin de "sécuriser encore mieux la connexion".
Bien sûr cela n'a rien à voir avec les radios Jumper et les modules Multi qui utilisent massivement le protocole FrSky (et d'autres) en toute illégalité...
Du coup, cela oblige à modifier le firmware du module d’émission ET le firmware des récepteurs.
Sinon, ils ne parlent plus la même langue.
C'est là où le protocole ACCST D16 v2 fait son entrée.
Vous l'aurez compris le protocole ACCST D16 v2 n'est pas retro-compatible avec le le protocole ACCST D16 v1.
Il faudra mettre à jour sa radio et tous ses récepteurs.
Voilà, vous savez tout.
Article initial du Bug ACCST D16 v1 réalisé par l'équipe Allemande daté du 6/12/2019 :
Historique et résumé des informations les plus importantes au sujet des "déviations soudaines des servocommandes".
6 décembre 2019, 00:04
Source : Forum frsky-forum.de
Modifications et compléments au résumé suivant
Ce résumé a été complété et modifié le 06.12.2019 dans la section "Ce qui se passe dans la pratique" parce que quelque chose a été présenté de manière trompeuse.
Ce présent rapport a pour but de donner une aperçu compréhensible du problème des "déviations soudaines des servocommandes".
Les télécommandes et systèmes d'émission FrSky sont disponibles depuis 2009 et depuis lors, les produits sont reconnus pour leur fiabilité et sont de plus en plus populaires en raison de leur excellent rapport qualité/prix. Au milieu de l'année 2019, nous avons reçu des informations sporadiques de la part de clients en Allemagne sur des "déviations soudaines des servos". Peu de temps après, les premiers incidents sont venus d'Autriche et de Suisse.
Dans le monde entier, il n'y a pratiquement pas eu d'autres incidents.
Nous avons effectué de nombreux essais à long terme dans toutes les conditions de fonctionnement possibles, mais nous n'avons pas été en mesure de reproduire le problème. Lorsque les rapports au sujet de ces déviations des servos sont devenus plus fréquents et lorsque nous avons eu l'opportunité d'avoir plus de combinaisons émetteur/récepteur pour tester où le problème aurait dû se produire, nous avons été en mesure de voir l'erreur "en direct" sur un servo. Ni nous ni FrSky n'avons pu reproduire l'erreur.
A l'automne de cette année, Ewald Möhring et moi nous sommes rentrés en contact par e-mail, et il s'est avéré qu'Ewald était et reste un spécialiste retraité des logiciels et des radiofréquences. Nous lui avons fourni divers émetteurs et récepteurs Frsky pour effectuer des mesures et il a pu mesurer et reproduire le problème pour la première fois. Grâce à la technologie de mesure de haute qualité dont il dispose, il a pu pour la première fois générer des fichiers journaux de ce problème. Grâce à ces informations, Dirk Weiler et Udo Nowakowski ont pu contribuer à la localisation du problème grâce à leurs connaissances approfondies. Dirk et Udo ont développé des outils qui leur ont permis, ainsi qu'à nous (Engel Modellbau), d'enregistrer les fichiers journaux et d'afficher les erreurs sans utiliser une technologie de mesure extrêmement coûteuse.
C'est à ce moment-là que FrSky a finalement reçu des informations d'Ewald et de moi-même, ce qui a également permis à FrSky de reproduire le problème. À partir de ce moment, la situation est devenue sérieuse et FrSky a reconnu le problème. Le propriétaire de l'entreprise FrSky a lui-même ordonné que le problème soit traité en priorité.
Quels sont les produits concernés ?
TOUS les récepteurs et émetteurs/modules HF de FrSky !
La LBT (UE) et la FCC (dans le monde entier) sont-elles également touchées ?
En gros, oui ! Toutefois, même dans les cas extrêmes, en FCC on n'a pas plus de quatre trames de données défectueuses consécutives (soit 0,036 seconde) et l'utilisateur ne remarque pas le problème. Cela explique aussi pourquoi, jusqu'à récemment, il n'y avait aucune indication du problème aux États-Unis.
Avec la LBT (UE), le problème est très rare, mais beaucoup plus fréquent qu'avec la FCC. La raison se trouve dans la nature du LBT et n'a rien à voir avec FrSky.
Le problème se produit-il plus souvent avec OpenTX ou FrSky OS ?
Puisque le firmware de l'OS (interface utilisateur OpenTx ou FrOS) n'a rien à voir avec le firmware du module d'émission RF, peu importe si vous utilisez OpenTX ou FrSky OS car la solution au problème se situe dans le firmware du module d'émission RF.
À quelle fréquence le problème se produit-il ?
On ne peut pas répondre à cette question de manière aussi générale parce qu'il n'y a pas de logique. Des clients ont indiqué de manière crédible qu'ils avaient eu ce problème plusieurs fois par jour, mais ils ont aussi évoqué ne pas en avoir pendant des semaines. Il existe également des informations crédibles provenant de clients qui ont effectué plusieurs centaines de vols sans aucun problème jusqu'à ce que ponctuellement le problème se produise. Et il y a encore un grand nombre de clients qui n'ont jamais eu ce problème auparavant.
Mais cela peut arriver à n'importe qui à n'importe quel moment !
Que se passe-t-il dans la pratique ?
A.) Si l'erreur se produit (typiquement 2-4 trames défectueuses), elle se manifeste généralement par un court "tressaillement du servo" sans mouvement servo notable. 2 images durent 18ms, c'est trop court pour percevoir une déflexion des servos. C'est à peine visible, seulement audible. Habituellement, il n'affecte qu'un seul des 16 canaux d'asservissement, rarement deux.
B.) Dans de rares cas sous mentionnés en A.), non seulement une seule valeur d'asservissement est défectueuse, mais aussi une courte erreur se produit dans la gestion de la trame par le récepteur. Cela s'explique probablement parce que, en plus d'une valeur de position des servos, certains bits de commande importants pour le programme ont également été transmis de manière incorrecte. Dans tous les tests effectués jusqu'à présent, il a toujours fallu 0,9 seconde pour que le récepteur se "rattrape" et se resynchronise avec l'émetteur. Dans ces 0,9 secondes, toutes les valeurs d'asservissement sont ensuite gelées au dernier état.
Malheureusement, il arrive souvent qu'une valeur de servo défectueuse de 0,9s soit gelée sur l'un des 16 canaux de servo. Si un servo est connecté à ce canal, une déviation claire et non contrôlée du servo se produira. 0,9s est également suffisant pour que les servos lents atteignent un positionnement complet. Si, dans ce cas, la position d'un servo sur les 16 canaux est défectueux mais n'est pas utilisé, le modèle ne sera pas contrôlable pendant 0,9s, mais aucune déviation de servo ne sera détectée.
Il en va de même si seuls les bits de contrôle de la trame sont défectueux malgré que les valeurs de position des servos soient correctes dans cette même trame.
Par rapport au bref "tressaillement du servo", ce cas est beaucoup moins fréquent et ne concerne que quelques pilotes dans la zone de l'UE (LBT). La différence statistique entre A.) et B.) est simplement basée sur le fait que beaucoup plus de données de position des servos que de bits de contrôle sont transmises de l'émetteur au récepteur.
La cause principale est ce qu'on appelle la "détection d'erreur/cryptage" dans le firmware. Celui-ci a été développé par FrSky lui-même afin de rester indépendant des fabricants de puces. Ce système permet la détection et le décryptage des erreurs. Ce système de détection/chiffrement d'erreurs développé par l'entreprise a dû bien fonctionner pendant des années, car sinon, FrSky n'aurait pas acquis la bonne réputation d'un système RC sûr et fiable.
Récemment, cependant, les conditions de fonctionnement ont été de plus en plus modifiées en raison d'une utilisation nettement plus importante de la bande des 2,4 GHz. Il existe une corrélation statistique directe entre les interférences et la qualité de la liaison radio dans la bande des 2,4 GHz et la probabilité que notre erreur se produise.
De plus, les puces de réception modernes sont plus sensibles et permettent donc une plus grande portée. Cependant, ils sont également plus sensibles aux plus petits écarts de fréquence. C'est pourquoi les récepteurs comme le GRX-8 sont plus souvent affectés que les anciens types. Si la dispersion des caractéristiques des composants (ce qui est assez courant dans l'électronique) conduit maintenant à une alignement de fréquence TX/RX parfois moins précis et si il y a aussi beaucoup d'interférences dans l'environnement, alors la probabilité est beaucoup plus élevée que le problème se produise.
Que fait FrSky maintenant ?
FrSky travaille très dur sur les mises à jour de la plupart des produits. Seuls quelques récepteurs ne peuvent pas être mis à jour en raison des composants électroniques utilisés. Avec ces mises à jour, la "détection/cryptage d'erreur" mentionnée ci-dessus est considérablement améliorée. D'autres petites mesures seront également intégrées, ce qui aura également un effet positif sur la qualité de la transmission.
Là où il y a des avantages, il y a aussi des inconvénients connus. En raison de la modification du cryptage, tous les récepteurs et les modules émetteurs/HF exploités par un client doivent recevoir une mise à jour en même temps.
Si l'on ne le fait pas, seuls les récepteurs qui ont reçu une mise à jour fonctionneront avec l'émetteur.
C'est aussi la raison pour laquelle les mises à jour ne seront disponibles que sous forme de paquets ou lots de firmwares. Il y aura un paquet pour les modules émetteurs/module HF et récepteurs ACCESS, et, un paquet pour les modules émetteurs/module HF et récepteurs ACCST (D16).
Grâce à une pression massive de notre part, FrSky a pu être convaincu de préférer les mises à jour ACCST. Le plan initial était de terminer les mises à jour d'ACCESS en décembre, puis les mises à jour d'ACCST en janvier/février. FrSky travaille maintenant en parallèle sur les mises à jour des deux protocoles.
Le 05.12.2019 les tests finaux des mises à jour ont commencé. Les participants sont Ewald Möhring (spécialiste logiciel et HF), Jan Urbánek RC Studio CZ (électronicien), Mike Delay (spécialiste logiciel), Adela (employée technique en développement chez FrSky) et moi-même.
Quelle est la prochaine étape ?
Pour d'autres questions techniques, je vous demande de poster sous le sujet (fil de discussion) "Déviations soudaines de servo". Nous mettrons ensuite régulièrement à jour cette page d'information avec des réponses résumées selon les besoins.
Andreas Engel
Engel Modellbau & Technik
6 décembre 2019, 00:04
Source : Forum frsky-forum.de
Modifications et compléments au résumé suivant
Ce résumé a été complété et modifié le 06.12.2019 dans la section "Ce qui se passe dans la pratique" parce que quelque chose a été présenté de manière trompeuse.
Ce présent rapport a pour but de donner une aperçu compréhensible du problème des "déviations soudaines des servocommandes".
Les télécommandes et systèmes d'émission FrSky sont disponibles depuis 2009 et depuis lors, les produits sont reconnus pour leur fiabilité et sont de plus en plus populaires en raison de leur excellent rapport qualité/prix. Au milieu de l'année 2019, nous avons reçu des informations sporadiques de la part de clients en Allemagne sur des "déviations soudaines des servos". Peu de temps après, les premiers incidents sont venus d'Autriche et de Suisse.
Dans le monde entier, il n'y a pratiquement pas eu d'autres incidents.
Nous avons effectué de nombreux essais à long terme dans toutes les conditions de fonctionnement possibles, mais nous n'avons pas été en mesure de reproduire le problème. Lorsque les rapports au sujet de ces déviations des servos sont devenus plus fréquents et lorsque nous avons eu l'opportunité d'avoir plus de combinaisons émetteur/récepteur pour tester où le problème aurait dû se produire, nous avons été en mesure de voir l'erreur "en direct" sur un servo. Ni nous ni FrSky n'avons pu reproduire l'erreur.
A l'automne de cette année, Ewald Möhring et moi nous sommes rentrés en contact par e-mail, et il s'est avéré qu'Ewald était et reste un spécialiste retraité des logiciels et des radiofréquences. Nous lui avons fourni divers émetteurs et récepteurs Frsky pour effectuer des mesures et il a pu mesurer et reproduire le problème pour la première fois. Grâce à la technologie de mesure de haute qualité dont il dispose, il a pu pour la première fois générer des fichiers journaux de ce problème. Grâce à ces informations, Dirk Weiler et Udo Nowakowski ont pu contribuer à la localisation du problème grâce à leurs connaissances approfondies. Dirk et Udo ont développé des outils qui leur ont permis, ainsi qu'à nous (Engel Modellbau), d'enregistrer les fichiers journaux et d'afficher les erreurs sans utiliser une technologie de mesure extrêmement coûteuse.
C'est à ce moment-là que FrSky a finalement reçu des informations d'Ewald et de moi-même, ce qui a également permis à FrSky de reproduire le problème. À partir de ce moment, la situation est devenue sérieuse et FrSky a reconnu le problème. Le propriétaire de l'entreprise FrSky a lui-même ordonné que le problème soit traité en priorité.
Quels sont les produits concernés ?
TOUS les récepteurs et émetteurs/modules HF de FrSky !
La LBT (UE) et la FCC (dans le monde entier) sont-elles également touchées ?
En gros, oui ! Toutefois, même dans les cas extrêmes, en FCC on n'a pas plus de quatre trames de données défectueuses consécutives (soit 0,036 seconde) et l'utilisateur ne remarque pas le problème. Cela explique aussi pourquoi, jusqu'à récemment, il n'y avait aucune indication du problème aux États-Unis.
Avec la LBT (UE), le problème est très rare, mais beaucoup plus fréquent qu'avec la FCC. La raison se trouve dans la nature du LBT et n'a rien à voir avec FrSky.
Le problème se produit-il plus souvent avec OpenTX ou FrSky OS ?
Puisque le firmware de l'OS (interface utilisateur OpenTx ou FrOS) n'a rien à voir avec le firmware du module d'émission RF, peu importe si vous utilisez OpenTX ou FrSky OS car la solution au problème se situe dans le firmware du module d'émission RF.
À quelle fréquence le problème se produit-il ?
On ne peut pas répondre à cette question de manière aussi générale parce qu'il n'y a pas de logique. Des clients ont indiqué de manière crédible qu'ils avaient eu ce problème plusieurs fois par jour, mais ils ont aussi évoqué ne pas en avoir pendant des semaines. Il existe également des informations crédibles provenant de clients qui ont effectué plusieurs centaines de vols sans aucun problème jusqu'à ce que ponctuellement le problème se produise. Et il y a encore un grand nombre de clients qui n'ont jamais eu ce problème auparavant.
Mais cela peut arriver à n'importe qui à n'importe quel moment !
Que se passe-t-il dans la pratique ?
A.) Si l'erreur se produit (typiquement 2-4 trames défectueuses), elle se manifeste généralement par un court "tressaillement du servo" sans mouvement servo notable. 2 images durent 18ms, c'est trop court pour percevoir une déflexion des servos. C'est à peine visible, seulement audible. Habituellement, il n'affecte qu'un seul des 16 canaux d'asservissement, rarement deux.
B.) Dans de rares cas sous mentionnés en A.), non seulement une seule valeur d'asservissement est défectueuse, mais aussi une courte erreur se produit dans la gestion de la trame par le récepteur. Cela s'explique probablement parce que, en plus d'une valeur de position des servos, certains bits de commande importants pour le programme ont également été transmis de manière incorrecte. Dans tous les tests effectués jusqu'à présent, il a toujours fallu 0,9 seconde pour que le récepteur se "rattrape" et se resynchronise avec l'émetteur. Dans ces 0,9 secondes, toutes les valeurs d'asservissement sont ensuite gelées au dernier état.
Malheureusement, il arrive souvent qu'une valeur de servo défectueuse de 0,9s soit gelée sur l'un des 16 canaux de servo. Si un servo est connecté à ce canal, une déviation claire et non contrôlée du servo se produira. 0,9s est également suffisant pour que les servos lents atteignent un positionnement complet. Si, dans ce cas, la position d'un servo sur les 16 canaux est défectueux mais n'est pas utilisé, le modèle ne sera pas contrôlable pendant 0,9s, mais aucune déviation de servo ne sera détectée.
Il en va de même si seuls les bits de contrôle de la trame sont défectueux malgré que les valeurs de position des servos soient correctes dans cette même trame.
Par rapport au bref "tressaillement du servo", ce cas est beaucoup moins fréquent et ne concerne que quelques pilotes dans la zone de l'UE (LBT). La différence statistique entre A.) et B.) est simplement basée sur le fait que beaucoup plus de données de position des servos que de bits de contrôle sont transmises de l'émetteur au récepteur.
La cause principale est ce qu'on appelle la "détection d'erreur/cryptage" dans le firmware. Celui-ci a été développé par FrSky lui-même afin de rester indépendant des fabricants de puces. Ce système permet la détection et le décryptage des erreurs. Ce système de détection/chiffrement d'erreurs développé par l'entreprise a dû bien fonctionner pendant des années, car sinon, FrSky n'aurait pas acquis la bonne réputation d'un système RC sûr et fiable.
Récemment, cependant, les conditions de fonctionnement ont été de plus en plus modifiées en raison d'une utilisation nettement plus importante de la bande des 2,4 GHz. Il existe une corrélation statistique directe entre les interférences et la qualité de la liaison radio dans la bande des 2,4 GHz et la probabilité que notre erreur se produise.
De plus, les puces de réception modernes sont plus sensibles et permettent donc une plus grande portée. Cependant, ils sont également plus sensibles aux plus petits écarts de fréquence. C'est pourquoi les récepteurs comme le GRX-8 sont plus souvent affectés que les anciens types. Si la dispersion des caractéristiques des composants (ce qui est assez courant dans l'électronique) conduit maintenant à une alignement de fréquence TX/RX parfois moins précis et si il y a aussi beaucoup d'interférences dans l'environnement, alors la probabilité est beaucoup plus élevée que le problème se produise.
Que fait FrSky maintenant ?
FrSky travaille très dur sur les mises à jour de la plupart des produits. Seuls quelques récepteurs ne peuvent pas être mis à jour en raison des composants électroniques utilisés. Avec ces mises à jour, la "détection/cryptage d'erreur" mentionnée ci-dessus est considérablement améliorée. D'autres petites mesures seront également intégrées, ce qui aura également un effet positif sur la qualité de la transmission.
Là où il y a des avantages, il y a aussi des inconvénients connus. En raison de la modification du cryptage, tous les récepteurs et les modules émetteurs/HF exploités par un client doivent recevoir une mise à jour en même temps.
Si l'on ne le fait pas, seuls les récepteurs qui ont reçu une mise à jour fonctionneront avec l'émetteur.
C'est aussi la raison pour laquelle les mises à jour ne seront disponibles que sous forme de paquets ou lots de firmwares. Il y aura un paquet pour les modules émetteurs/module HF et récepteurs ACCESS, et, un paquet pour les modules émetteurs/module HF et récepteurs ACCST (D16).
Grâce à une pression massive de notre part, FrSky a pu être convaincu de préférer les mises à jour ACCST. Le plan initial était de terminer les mises à jour d'ACCESS en décembre, puis les mises à jour d'ACCST en janvier/février. FrSky travaille maintenant en parallèle sur les mises à jour des deux protocoles.
Le 05.12.2019 les tests finaux des mises à jour ont commencé. Les participants sont Ewald Möhring (spécialiste logiciel et HF), Jan Urbánek RC Studio CZ (électronicien), Mike Delay (spécialiste logiciel), Adela (employée technique en développement chez FrSky) et moi-même.
Quelle est la prochaine étape ?
Pour d'autres questions techniques, je vous demande de poster sous le sujet (fil de discussion) "Déviations soudaines de servo". Nous mettrons ensuite régulièrement à jour cette page d'information avec des réponses résumées selon les besoins.
Andreas Engel
Engel Modellbau & Technik