Position des commandes principales sur les sorties récepteur

Bonjour à tous

Je suis en train d’équiper un modèle avec un récepteur X8R à la place d'un Futaba 6014
L'ordre de sortie des voies est inversé d'un récepteur à l'autre
Comme le câblage est propre sous gaine spirale avec colliers autobloquants je ne souhaite pas le modifier
En conséquence mes commandes de vol principales se retrouvent sur les sorties 5, 6 et 7 au lieu de 1, 2 et 3

Il s'agit d'un jet à réacteur, y a t il un inconvénient (temps de réponse ou autre) à faire ainsi ?

Est ce que toutes les sorties du récepteur sont équivalentes ?

Ca fonctionne parfaitement au sol, c'est surtout pour me rassurer

Merci

Hello,

Sauf erreur de ma part, il n'y a pas de temps de réponse différent entre les voies. Elles sont toutes transmises dans la même trame. (Kilrah pourra peut-être confirmer ?)
Et comme c'est une Taranis avec OpenTx, tu es libre d'organiser tes voies comme bon te semble :-)

Bons vols !

Coyotte

Au niveau de la latence, il me semble qu'il y ait une légère différence (en mode D16), si tu choisies voie 1 à 8 ou voie 1 à 16. Mais je ne suis pas sûr du tout. A confirmer par Kilrah s'il passe dans le coin.

Moi aussi je suis d'accord. Si on choisi voie 1-8 au lieu de voie 1-16 le taux de transmissions est plus court.

Quand au voies en sortie il suffit de les organiser dans les mixages dans l'ordre que l'on veut.

Murphy a écrit:Si on choisi voie 1-8 au lieu de voie 1-16 le taux de transmissions est plus court.

La différence ne peut se voir qu'en SBUS, donc avec des servos branchés sur les sorties standard on s'en fiche pas mal

Merci Kilrah !!!
Il me semblait bien, que j'avais zappé un truc.
Par contre tu confirmes qu'il y a 2 tailles de trame en S.Bus. 1 avec 8 voies (ou moins, mais cela ne changera pas la taille de la trame) et 1 autre taille avec 16 voies ?
En plus il me semble que le taux de rafraichissement du S.Bus est de 9ms en version non-EU et 18ms en version EU. Du coup, si on utiliser un convertisseur S.Bus → PWM avec un RX non-EU et des servos analogiques, il faut faire attention qu'ils ne surchauffent pas.
Après confirmation , il faudra absoluement que je note ce quelque part.

LapinFou a écrit:...
Par contre tu confirmes qu'il y a 2 tailles de trame en S.Bus. 1 avec 8 voies (ou moins, mais cela ne changera pas la taille de la trame) et 1 autre taille avec 16 voies ?
...

Ah non, la trame SBUS entre le récepteur et les servos fait toujours la même longueur (16 voies proportionnelles + deux voies tout ou rien soit 25 byte toutes les 14ms (analog mode) ou 7ms (highspeed mode).

C'est la communication en OpenTx et le module d'émission (protocol PXX pour les modules XJT) qui me semble-t-il (mais sans certitude), envoie 2 * 8 canaux plus des informations de contrôle.

Le SBUS sort du récepteur avec 16 canaux proportionnels toutes les 9ms (les canaux tout ou rien ne sont pas utilisés).
Les signaux servo sortent du récepteurs toutes les 18ms.

La radio envoie un paquet de 8 canaux (1-8 ou 9-16) toutes les 9ms.

Donc il faut 2 paquets radio pour passer 16 canaux (18ms). Si on n'en passe que 8 on peut profiter de la pleine vitesse du SBUS, mais les 16 ont le temps de passer à la vitesse du signal servo.

Merci Kilrah.

Par contre j'avais lu cela sur le foprum Frky:

Hi, the version of eu sbus framerate is 15ms, the version of non eu sbus framerate is 9ms, please check it again.

X4R SBus framerate - SBUS to PWM converter

Du coup j'ai compris qu'il y avait une différence entre la version EU et non-EU.
Évidement, je pose la question uniquement sur la trame qui sort du RX (donc, qui n'a rien à voir avec OpenTX), pas sur la trame entre le TX et le RX.

Si je concatène ces 2 informations, je conclurais que sur le FW EU si on balance 16 voies, alors la trame S.Bus complète fait 30ms au lieu de 18ms en FW non-EU.
C'est louche cette histoire !!

LapinFou a écrit:...
Si je concatène ces 2 informations, je conclurais que sur le FW EU si on balance 16 voies, alors la trame S.Bus complète fait 30ms au lieu de 18ms en FW non-EU.
...

Mais non, la trame s.bus fait toujours 25 byte :
- 1 byte de contrôle (0x0F -> start byte)
- 22 bytes pour les 16 voies (16 * 11 bit -> 22 bits)
- 1 byte contenant :
-> 1 bit pour la voie 17 (tout ou rien)
-> 1 bit pour la voie 18 (tout ou rien)
-> 1 bit pour indiquer si le frame a été perdu entre l'émetteur et le récepteur
-> 1 bit pour indiquer si le failsafe est actif ou pas
- 1 dernier byte de contrôle (0x00 -> end byte)

La vitesse de transmission étant 100'000 bits/seconde, parity N, stop bit 2, il faut 2.5 millisecondes 25*(8+2)/100 pour transmettre cette trame de 25 byte. Autrement dit, vu qu'une trame est envoyée toutes les 9ms, la ligne entre le récepteur n'est pas complètement occupée, on pourrait envoyer facilement 32 voies (3.76ms) ou même 64 voies (7.28ms) sans grandes difficultés.

Par ailleurs, je ne pense pas que le récepteur se mette sur la même cadence qu'OpenTx pour envoyer ses trames s.bus, il doit les envoyer toutes les 9ms qu'il aie reçu de nouvelle infos de l'émetteur ou pas sauf s'il constate qu'il doit se mettre en failsafe.

Ca, c'est pour le S.Bus, ce qui circule entre le récepteur et les servos/décodeurs sur la ligne s.bus.

Ensuite, il y a ce qui circule entre openTx et le module d'émission, et peut-être aussi le module d'émission et le récepteur.

Entre OpenTx et le module XJT, le protocole, c'est le PXX qui est différent du s.bus, les bytes de contrôles et la structure du frame est différent (si j'ai bien compris d'après ce qu'il y a dans les sources) :
- 4 bits de préambule
- 1 byte de contrôle (0x7E -> start byte)
- 1 byte contenant plusieurs flags :
-> 1 bit indiquant qu'il faut faire le bind
-> 3 bits pour le code pays
-> 1 bit indiquant de mettre le récepteur en test de portée (puissance plus faible pour le range check)
-> 1 bit indiquant qu'OpenTx envoie les données du failsafe
- 1 byte de contrôle (0x00)
- 8 voies codées sur 12 bits (1 bit pour indiquer si c'est une voie entre 1 et 8, ou entre 9 et 16, plus 11 bits pour indiquer la valeur)
- 1 byte de contrôle (0x00)
- 2 byte pour le CRC
- 1 byte de contrôle (0x7E -> end byte)

Soit semble-t-il, une trame de 156 bits pour transmettre 8 voies au module d'émission pour le PXX, bits qui sont envoyée en plus avec une séquence de deux bits (01) pour un bit à 0 et trois bits (001) pour un bit à 1 toutes les 8uS (je te laisse calculer la vitesse de transmission, ça devient trop compliqué pour moi).

Quant à ce qui circule entre le module d'émission XJT et le récepteur, quelle est la structure de la trame, je n'en sais rien, il faudrait avoir les sources et ça, on ne les a pas.

Merci pour cette explication très claire et détaillé.
Par contre je ne sais plus qui parle de quoi ?!?
Kilrah parle des packets entre OpenTX et le module RF interne → 8voies toutes les 9ms, soit 18ms pour 16voies
Le gars de FrSky (dans le lien que j'ai donné plus haut) parle de la transmission entre la RF interne et le RX → 16 voies en 9ms pour les FW non-EU et 15ms pour les FW EU
Et toi, Sacre, tu parles de la trame sortant des RX → 16+2 voies toutes les 9ms

J'ai bon ??

LapinFou a écrit:Merci pour cette explication très claire et détaillé.
Par contre je ne sais plus qui parle de quoi ?!?
Kilrah parle des packets entre OpenTX et le module RF interne → 8voies toutes les 9ms, soit 18ms pour 16voies
Le gars de FrSky (dans le lien que j'ai donné plus haut) parle de la transmission entre la RF interne et le RX → 16 voies en 9ms pour les FW non-EU et 15ms pour les FW EU
Et toi, Sacre, tu parles de la trame sortant des RX → 16+2 voies toutes les 9ms

J'ai bon ??

Ce dont parle Kilrah, c'est le PXX dont je parle, c'est même lui qui m'avait fait comprendre que ce n'était pas la même chose que le s.bus.

Ce dont je parle, c'est bien de la sortie s.bus du récepteur, toutes les 9ms (ou 7ms tel qu'on peut le lire parfois) en high-speed mode, toutes les 15ms (on peut aussi lire 14ms par endroit) en normal mode.

Le gars de Frsky ne parle pas de la transmission entre le TX et le RX mais aussi de la sortie s.bus sur le récepteur (output from the SBUS), d'où peut-être ta confusion si tu avais compris qu'il parlait de la transmission en le TX et le RX.

Merci !! C'est plus clair.

Mais pourquoi le gars de FrSky fait un distingo entre le FW EU et non-EU ?? Very confusing....

LapinFou a écrit:Merci  !! C'est plus clair.

Mais pourquoi le gars de FrSky fait un distingo entre le FW EU et non-EU ?? Very confusing....

Parce-qu'il semble que le firmware EU pour les récepteurs sorte une trame s.bus toutes les 15ms alors que les récepteurs avec le firmware non-EU toutes les 9ms. Ca me parait est un peu couillon vu que le PXX ne semble être capable de sortir 16 voies que toutes les 18ms alors ça ne sert à rien d'avoir derrière une sortie s.bus haute-vitesse.

Merci pour vos réponses
En plus pleins d'infos sur le Sbus que j'utilise aussi sur d'autres modèles.

Je ne suis pas certain que mon niveau me permette de sentir la différence entre 9ms et 18ms
Je pense que si on n'utilise pas de plateau cyclique avec plusieurs servos ou des gouvernes avec plusieurs servos synchronisés cela ne doit pas être perceptible mais peut être que je me trompe

j'ai un pilotage plutôt coulé et orienté vol réaliste et je n'ai jamais senti de différence dans les temps de réponse.
Même si parfois je fais des modèles un peu délire avec des débattements "démentiels" genre 5 tonneaux/sec cela n'a pas d'importance que le servos atteigne la position demandée en 1/10 ou 1/100 de seconde. La précision du neutre et pour moi beaucoup plus importante
Pour info, je ne pose pas mes modeles avec se taux de roulis j'ai un bouton poussoir pour être sur que le mode démentiel est bien temporaire

LapinFou a écrit:
Par contre j'avais lu cela sur le foprum Frky:

Hi, the version of eu sbus framerate is 15ms, the version of non eu sbus framerate is 9ms, please check it again.

Vu que ça vient de FrSky ça doit être correct - mon post ne s'appliquant alors qu'au firmware non EU.
Je n'ai jamais regardé de près ni même vraiment essayé les FW EU.

Merci à tous !


Pour résumer:
-La trame PXX entre OpenTX et le module RF interne → 8voies toutes les 9ms, soit 18ms pour 16voies.
-Une nouvelle trame 16voies S.Bus (durant seulement quelques ms) sortant des RXs est générée → tout les 9ms pour les FW non-EU et tout les 15ms pour les FW EU.