ACCST D16 v1 - Le bug

A ceux qui se poserait la question, je n'ai pas mis à jour mes packs SD pour la simple et bonne raison que les nouveaux firmware ACCST D16 v2 ne sont pas stables.
Lorsque la v2 sera stable, je mettrais alors à jour mes packs SD.
Ce qu'il faut savoir:

• Le protocole D8 n'est pas concerné par ce bug. Seul les protocoles D16 FCC & LBT sont concernés.
• Le protocole LBT est plus sensible à ce problème que le protocole FCC.
• Il faut des conditions particulières pour que ce bug se produise (fort brouillage RF).
• Suivant l'environnement radio dans lequel vous volez, ce bug peut ne jamais se produire pendant des années ou se produire plusieurs fois dans la même journée.
• Ce bug existe sur toutes les radios et RX ACCST D16.
• Ce bug n'avait pas encore été identifié, car difficile à reproduire.
• Avec le nombre grandissant d'utilisateurs FrSky, "les petits cas" isolés sont devenus un vrai et unique problème commun à un groupe.
• Grace au travail d'une équipe Allemande, un environnement sous contrôle a permis de reproduire, analyser et comprendre l'origine du problème.
• Lorsque ce bug se produit, un mouvement incontrôlé se produit sur un servo pendant environ une petite seconde.

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.

Petite parenthèse, c'est ici que le FCC et le LBT diffère.
Le FCC va sauter sur la prochaine fréquence prédéterminée sans se poser de question.
Le LBT (Listen Before Talk) va écouter (Listen) avant (Before) d'envoyer (Talk). En clair, le LBT ne va pas transmettre sur une fréquence déjà occupée pour éviter de parasiter le popotte qu'il l'utilise.
Je ne rentrerais pas plus dans les détails, car ce n'est pas le sujet de cet article.
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.

NB: seulement 8 voies sont transmises dans un paquet; un coup les VOIE01-08, un coup les VOIE09-16.
Sauf si vous avez choisi au moment du bind le mode "9ms VOIE01-08". Dans ce cas, seules les VOIE01-08 sont transmises à tous les coups.
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).

Cependant si un paquet est déclaré comme OK alors qu'il est corrompu, là il y a un problème. Plus grave, le RX ne va pas écouter sur la bonne fréquence pour recevoir le prochain paquet. Du coup, il passe dans un genre de failsafe (qui dure 0.9s) avant de raccrocher les wagons avec la radio.
C'est là l'origine de ce fameux bug.
Là ou c'est encore plus embêtant, c'est lorsqu'il y a une erreur ET sur la prochaine fréquence ET sur la position des servos. Le modèle reçoit un ordre non voulu et reste "bloqué" pendant 0.9s.
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.