PWM, CPPM, S.Bus... Késako ??
Table des matières
Un petit résumé des différents acronymes dans notre merveilleux monde du modélisme.
Pour info, cliquez sur les images pour zoomer.
Il y a plein de protocoles différents qui ne sont pas compatibles entre eux (sinon il faut utiliser un convertisseur).
Dans le monde RC, voici les principaux protocoles que l'on rencontre :
PWM (Pulse Width Modulation)
ou MLI (Modulation de Largeur d'Impulsion)
C'est une sortie classique sur le RX pour piloter un servo. Une seule voie est transmise. Un signal carré est envoyé en permanence au servo. La largeur de l'état haut donne la position (largeur de 1500µs = neutre, largeur de 1000µs = servo au mini, etc..). Un nouveau signal PWM est envoyé tout les 20ms.
Petite note pour les RXs Spektrum, c'est ici que l'on comprend la différence entre le mode 11ms et 22ms.
Par contre, attention ! certains vieux servos analogique n'aiment pas recevoir une commande trop rapide. Ils grognent et chauffent...
Ci-dessous une capture réalisée sur un X4R-SB (mode D16/16voies, firmware non-EU).
Les signaux PWM sont envoyés toutes les 18ms.
Sur la voie 1, 0.988ms (ou 988µs) correspondant à -100%
Sur la voie 2, 1.5ms (ou 1500µs) correspondant à 0%
Sur la voie 3, 2.012ms (ou 2012µs) correspondant à +100%
D'ailleurs, c'est ici que l'on comprend comment fonctionnent les servos digitaux narrow band (ou servos à bande étroite).
Chez Futaba, le neutre est à 1520µs +/-500µs. Certains servos (souvent utilisés sur l'AC des hélicos) sont des 760µs (+/-250µs).
Qu'est ce que cela veut dire "un servo 760us" ? Et bien, tout simplement que la largeur d'impulsion est 2x moins large qu'un servo classique (analogique ou digital).
Quelle utilité ? Et bien, comme l'impulsion est 2x moins large, alors on peut l'envoyer 2x plus souvent. Donc la latence est réduite de moitié: rafraîchissement du servo toutes les 10ms au lieu de 20ms.
PPM ou CPPM (Pulse Position Modulation)
ou MPI (Modulation en Position d'Impulsions)
C'est utilisé par de nombreux contrôleurs (type Naza ou autre) et aussi utilisé pour l'écolage. Là, on transmet 8 voies (voire 12 dans certains cas) avec un seul signal (= un seul fil). Ce protocole est assez lent.
Pour ceux que cela intéresse, on voit que chaque voie peut faire 2ms (2000µs, voir explication sur le PWM) de largeur au max (temps entre 2 impulsions). Avec 8 voies, cela fait 8 x 2ms = 16ms. Donc cela fait une pause de 4ms (période de 20ms - 16ms) entre 2 trames, si la période de la trame est 20ms (comme sur l'image ci-dessus).
Avez-vous déjà entendu parler du "firmware 27ms" sur le RX D4R-II afin d'utiliser jusqu'à 12 voies en PPM ? Mais qu'il faut aussi utiliser cette version de firmware pour éviter un problème en utilisant 8 voies ?
En fait FrSky utilisait une trame de 18ms au lieu de 20ms dans le firmware original. Du coup, c'est le drame et cela ne fonctionne pas. En effet avec 18ms, cela laisse seulement 2ms de pause → 18ms - (8 x 2ms) = 2ms. Hors, 2ms correspond à une largeur d'impulsion valide pour une 9ème voie (qui serait en position max, soit 2ms). Du coup, l'appareil recevant cette trame va comprendre qu'il y a 9 voies, au lieu de comprendre que ces dernières 2ms est une pause entre 2 trames...
Là où c'est encore plus vicieux, c'est que si les 6 premières voies sont au max et que les 7 & 8ème voies sont aux neutres, cela donne 6 x 2ms + 2x 1.5ms = 15ms et là, ça passe, car il y a 3ms (18ms - 15ms) de pause. Au final, ça marche jusqu'au moment où les 8 voies approchent le max et boum, le modèle est crashé.
Avec le firmware 27ms, cela donne 12 x 2ms = 24ms. Soit 3ms de pause entre 2 trames. Dans ce cas là tout marche normalement.
Vous conclurez aussi que plus on transmet de voies, plus longue est la trame. Ce qui ajoute une latence et ça, c'est mal.
Quand vous avez le choix, privilégiez toujours le S.Bus.
Quelques captures d'écran réalisées avec un X4R-SB couplé avec un convertisseur FrSky S.Bus vers CPPM:
On voit que la trame PPM dure 21ms. La 1ère trame correspond aux 8 voies au max et la 2ème trame aux 8 voies au minimum.
On notera qu'avec du PPM 8 voies, on obtient une nouvelle position toutes les 21ms (à comparer au 18ms sur une sortie PWM classique chez FrSky).
Sur cette capture, on voit que la trame dure 28ms lorsque l'on met le jumper sur le convertisseur afin de générer 12 voies (le taux de rafraîchissement est encore plus lent).
S.Bus (Serial Bus)
C'est Futaba qui l'a inventé. Là, on transmet 16 voies proportionnelles (sur 11bits, soit une résolution de 2048) + 2 voies digitales avec une trame digitale sur un seul fil. Le protocole est rapide.
NB: ces 2 dernières voies digitales ne peuvent prendre que la valeur min ou max (résolution de 2) et ne sont pas utilisées chez FrSky.
Comme indiqué dans la section PPM, lorsque vous avez le choix, privilégiez toujours le S.Bus. Ci-dessous une capture d'écran qui devrait vous convaincre.
Le taux de rafraîchissement est de 9ms (firmware non-EU) seulement (à comparer aux 21, 27 ou 28ms du PPM) et en plus on transmet 16 voies proportionnelles à chaque fois (au lieu des 8 ou 12 voies) !
Voici à quoi ressemble une trame S.Bus en détail:
Pour ceux qui veulent en savoir encore plus:
Citation :
c'est une connexion UART avec un baud composé de 1 start bit + 8 data bit + 1 even parity bit + 2 stop bit (8E2).
Le baudrate est de 100 000 bit/s
Le bit de poids fort (MSB) est envoyé en 1er. La logique est inversé (état haut = '0', état bas = '1').
En clair, 12 bit envoyé physiquement (en vrai) sur le port S.Bus correspond a 1 byte (ou octet) de donnée utilisable.
Une trame complète est composée de 25 bytes de données.
La trame est composée comme cela:
[startbyte] [data1] [data2] [data3] .... [data22] [flags] [endbyte]
startbyte
C'est toujours 8'b11110000 (0xF0).
Cela indique le début d'une transmission.
[data1] [data2] [data3] .... [data22]
Cette concaténation de data correspond aux 16 voies proportionnelles
[ch1, 11bit][ch2, 11bit] .... [ch16, 11bit]
La voie/channel 1 utilise 8bits du byte [b]data1 [/b]et 3bits du byte [b]data2[/b]
La voie/channel 2 utilise 5bits du byte [b]data2 [/b]et 6bits du byte [b]data3[/b]
etc...
22 bytes de data = 22 x 8bits = 176bits
16 voies de 11bits = 16 x 11bits = 176bits
Le compte est bon !!
Ça donne cela:
flags
bit7 = voie/channel 17 = voie digital uniquement (0x80)
bit6 = voie/channel 18 = voie digital uniquement (0x40)
bit5 = trame perdue, équivalent à 1 clignotement de la LED rouge sur le récepteur (0x20)
bit4 = failsafe activé (0x10)
bit3 = n/a
bit2 = n/a
bit1 = n/a
bit0 = n/a
endbyte
C'est toujours 8'b00000000 (0x00).
Cela indique la fin de transmission de la trame S.Bus.
Le baudrate est de 100 000 bit/s
Le bit de poids fort (MSB) est envoyé en 1er. La logique est inversé (état haut = '0', état bas = '1').
En clair, 12 bit envoyé physiquement (en vrai) sur le port S.Bus correspond a 1 byte (ou octet) de donnée utilisable.
Une trame complète est composée de 25 bytes de données.
La trame est composée comme cela:
[startbyte] [data1] [data2] [data3] .... [data22] [flags] [endbyte]
startbyte
C'est toujours 8'b11110000 (0xF0).
Cela indique le début d'une transmission.
[data1] [data2] [data3] .... [data22]
Cette concaténation de data correspond aux 16 voies proportionnelles
[ch1, 11bit][ch2, 11bit] .... [ch16, 11bit]
La voie/channel 1 utilise 8bits du byte [b]data1 [/b]et 3bits du byte [b]data2[/b]
La voie/channel 2 utilise 5bits du byte [b]data2 [/b]et 6bits du byte [b]data3[/b]
etc...
22 bytes de data = 22 x 8bits = 176bits
16 voies de 11bits = 16 x 11bits = 176bits
Le compte est bon !!
Ça donne cela:
Code :
channels[0] = ((buffer[1] | buffer[2]<<8) & 0x07FF);
channels[1] = ((buffer[2]>>3 | buffer[3]<<5) & 0x07FF);
channels[2] = ((buffer[3]>>6 | buffer[4]<<2 | buffer[5]<<10) & 0x07FF);
channels[3] = ((buffer[5]>>1 | buffer[6]<<7) & 0x07FF);
flags
bit7 = voie/channel 17 = voie digital uniquement (0x80)
bit6 = voie/channel 18 = voie digital uniquement (0x40)
bit5 = trame perdue, équivalent à 1 clignotement de la LED rouge sur le récepteur (0x20)
bit4 = failsafe activé (0x10)
bit3 = n/a
bit2 = n/a
bit1 = n/a
bit0 = n/a
endbyte
C'est toujours 8'b00000000 (0x00).
Cela indique la fin de transmission de la trame S.Bus.
Chaque voie est donc codée sur 11bits. Si vous avez le servo (ou carte de vol) qui va bien en face, c'est plus précis et rapide que le PPM.
S.Bus2 (Serial Bus 2)
C'est le bus série de télémétrie Futaba. Tous les capteurs parlent sur le même fil.
S.Port (ou Smart Port ou Sport)
C'est le bus série de télémétrie FrSky. Tous les capteurs parlent sur le même fil.
F.Port
C'est le nouveau bus série FrSky surtout dédié aux drones. Pour faire simple c'est du S.Port et du S.Bus sur un seul et même fil.
Autres protocoles
CCPM:
A ne pas confondre avec CPPM, c'est un type de mixage utilisé pour les hélicoptères avec barre de Bell. qui n'a donc rien à voir avec les protocoles ci-dessus. Programmer un hélico avec barres de Bell sous OpenTX 2.1
DSM2/DSMX (Digital System Multiplexer):
Protocole de Spektrum moins sensible aux bruits et interférences. DSMX est la nouvelle version du protocole.
ACCST (Advanced Continuous Channel Shifting Technology):
C'est le protocole FrSky avec télémétrie utilisé sur les Taranis, Horus et module XJT.
ACCESS (Advanced Communication Control Elevated Spread Spectrum):
C'est le dernier protocole FrSky avec télémétrie sorti en 2019.
Plus d'info dans l'article suivant: Le protocole ACCESS
FASST (Futaba Advanced Spread Spectrum Technology):
C'est le protocole haut de gamme de chez Futaba. C'est aussi le 1er protocole 2.4GHz utilisé chez Futaba.
FASSTest:
Évolution du FASST avec l'ajout de la télémétrie et du S.Bus2.
S-FHSS (Frequency Hopping Spread Spectrum):
Protocole récent chez Futaba (incompatible avec le FASST) pour ses radios moins haut de gamme.
T-FHSS:
Évolution du S-FHSS avec l'ajout de la télémétrie et du S.Bus2.
HoTT (HOpping Telemetry Transmission):
Protocole avec télémétrie de chez Graupner.
Duplex 2.4 GHz:
Protocole avec télémétrie de chez Jeti.
A noter que chez Jeti (uniquement pour les radios DC-24 et DS-24) avec l'ajout d'un satellite RSAT 900MHz Duplex EX ont obtient une double connexion en 2.4GHz et en 900MHz. La connexion 900MHz servant alors de liaison de secours.