WARNING : plage de variation des servos en SBUS

Ce message s'adresse à ceux qui utilisent la communication SBUS pour augmenter leur nombre de voies servos.
En raison d'une communication sur 11 bits de la valeur de commande de chaque voie servo, sur le SBUS, 2048 valeurs différentes (de 0 à 2047) sont disponibles pour couvrir toute la plage de variation de chaque servo.
Les développeurs de notre logiciel émetteur ont utilisé "au mieux" cette plage de valeurs disponibles pour avoir la meilleure précision, et lui ont attribué une plage de commande de 880us à 2160us, avec une résolution de 0.625us.

J'arrête là la théorie, et voyons ce que cela donne en pratique.
Si votre commande servo est inférieure à 880us, la transmission SBUS enverra une valeur de 880 us, jamais moins (le logiciel émetteur "clampe" correctement cette valeur).
Mais, suite à un bug (ou un test oublié dans le logiciel de l'émetteur), si la commande servo est supérieure à 2160 us, la valeur envoyée en SBUS n'est pas saturée à 2160us, mais elle repasse à 880us !!! En effet, dans ce cas, le 12ème bit de la valeur correspondante est à '1' mais ne puet pas être transmis, et est donc perdu.

Donc attention si vous utilisez des servos en SBUS ou des convertisseurs SBUS -> PPM : la valeur de commande de chaque servo doit être limitée à la plage 880 <> 2160 microsecondes.
NB : cette plage correspond à un neutre PPM de 1520us, avec une variation de + ou - 640 us (c'est à dire + ou - 125 %).

As-tu signalé ce bug à l'équipe d'OpenTx sur Github ?

Juste un complément et un méa culpa.
Ce n'est pas l'émetteur qui génère le SBUS, mais le récepteur !!!, et je ne sais pas si tous les logiciels récepteurs ont le même défaut : je n'ai testé pour l'instant que sur des XR4 et XR4SB.
En conséquence je ne peux que m'excuser auprès de nos développeurs qui font un travail remarquable, et mon erreur me vaudra une nouvelle contribution à leurs efforts.

Alors ce dont tu parles est-ce ce qui est corrigé par les firmware disponibles ici : http://www.frsky-rc.com/download/index.php?sort=Firmware&cate_id=0&pro_id=0

Pourras-tu nous dire si ces firmware corrigent bien le bug que tu as identifié.

J'ai acheté mes derniers récepteurs, avec lesquels j'ai fait les tests, il y a un mois à l'autre bout du monde : je les ais reçus il y a une semaine. Comme mon émetteur est toujours à l'ancienne norme, il ne m'est même pas passé par la tête de vérifier leur version logiciel ! et la plus récente est novembre 2014.
Donc j'ai du boulot : 4 récepteurs à aligner avec la version logiciel "SBUS data overflow fixed" (X4R modifié SBUS, X4RSB, X6R et X8R), puis contrôle de leur transmission SBUS.
Je m'y attèle dès demain.

Je n'ai pas pu attendre jusqu'à demain ! Et le test est déjà fait.
Résultat : le problème que j'ai soulevé est déjà résolu par FrSKY.

J'ai reprogrammé mes 4 récepteurs cités plus haut avec le logiciel SBUS data overflow fixed, en version non EU pour rester compatible avec mon émetteur.
Puis test de la transmission SBUS de chacun de ces récepteurs : il n'y a plus le problème du passage brutal de 2160us à 880us : la valeur transmise par l'émetteur, supérieure à 2160 us, est désormais bien saturée à cette valeur.

Donc cette mise à jour est indispensable pour ceux qui utilisent le SBUS !!!

Le seul "warning" qui reste est la saturation de la commande transmise par SBUS qui limite la plage de commande à 880 us <> 2160us, un peu en dessous de la plage étendue maximale.

Je confirme ça a été corrigé je l'avait signaler et vue au scope sur des anciennes versions ...

skysun a écrit:...
Le seul "warning" qui reste est la saturation de la commande transmise par SBUS qui limite la plage de commande à 880 us <> 2160us, un peu en dessous de la plage étendue maximale.

C'est quand même étonnant ce bug car OpenTx transmet les données au module XJT sur 11 bits, j'imagine que le module envoie aussi les données aux récepteurs X sur 11 bits alors que peut-il bien se passer lors de la génération des données SBUS qui elles aussi sont sur 11bits.

Mistère, mistère ...

salut 
je suis une bille dans le domaine 
mais j utilise des récepteurs xr8 avec le sbus 
et d autre xr8 sans le sbus je me suis mis à la norme etsi300
je voudrais savoir si faut que je fasse l ensemble de mes récepteurs des fois  qu'un jour je leur installeraient un sbus 
ou que les récepteurs equippés sbus 
j'ai cramé il y a quelque temps des servo analogique sur le 
sbus il chauffait enormement après cet mise à jour est ce que je pourrai brancher de nouveau des servo analogique sans les cramer  ?

Je n'ai pas analysé la transmission au module XJT, mais si elle est également sur 11 bits, OpenTx doit certainement utiliser une autre résolution pour obtenir une plage plus importante : pourquoi deux résolutions différentes ? il y a effectivement un mystère.

Aerobig : pour la mise à jour de tes récepteurs, si tu es passé à la nouvelle norme, peut-être as tu aussi fait la mise à jour du bug en même temps si tu as flashé la version http://www.frsky-rc.com/download/view.php?sort=Firmware&down=188&file=X8R/%20X6R-%20EU-%20SBUS%20Bug%20Fixed
En tout cas je ne peux que conseiller de faire ce que j'aurais dû faire moi-même : mettre à jour les récepteurs dès leur réception. Sinon, pense à repérer les récepteurs non mis à jour, pour ne pas te faire avoir plus tard.

skysun a écrit:Je n'ai pas analysé la transmission au module XJT, mais si elle est également sur 11 bits, OpenTx doit certainement utiliser une autre résolution pour obtenir une plage plus importante : pourquoi deux résolutions différentes ? il y a effectivement un mystère.

Si tu veux analyser ça, c'est ici : https://github.com/opentx/opentx/blob/9886dede7335de823e1dcb434626ccfa46049fdc/radio/src/pulses/pxx_arm.cpp

Ca serait intéressant de comprendre le pourquoi du comment.

En analysant rapidement le source pxx_arm.cpp, il apparait que la transmission du PPM subit une mise à l'échelle et une saturation afin de transmettre une valeur comprise entre 1 et 2046 (donc bien sur 11 bits).

La valeur du neutre est 1024, et la variation de la commande autour de ce neutre est les 3/4 de la valeur à transmettre (valeur * 512 / 682) : cette valeur étant saturée à 1 ou 2046. La plage étendue transmise semble donc être de + ou - 133% (et non 150% comme accessible dans Companion, ou 125% sur le SBUS)

Attention toutefois : il me manque pas mal de données, et une analyse beaucoup plus poussée du logiciel est nécessaire. En effet :
- je ne connais pas la résolution de la valeur à transmettre (on peut imaginer qu'il s'agit de 0.5 microseconde, mais il n'y a aucune certitude)
- je ne connais pas non plus la résolution du timer utilisé pour la génération des pulses, ni les transformations que subit la valeur transmise (ne serait-ce que l'offset ajouté pour recaler le neutre du signal).

Il faudrait récupérer l'ensemble des sources et les éplucher en détail pour y retrouver ses petits : si quelqu'un veut se pencher sur le problème, moi je ne pense pas pouvoir dégager assez de temps pour cela dans l'immédiat.

Sauf erreur, les données sont envoyées toutes les 11 milisecondes.