<![CDATA[OpenTx]]>

<![CDATA[OpenTx]]> https://opentx-doc.fr (C) 2005-2026 PHPBoost fr PHPBoost <![CDATA[Tableau récepteurs/protocoles]]> https://opentx-doc.fr/wiki/tableau-recepteursprotocoles https://opentx-doc.fr/wiki/tableau-recepteursprotocoles Article écrit par Ceeb182 / MaJ 04-2022

L'objectif de ce tableau est double :

connaitre rapidement les protocoles possibles pour un récepteur donné
connaître l'ancienneté d'un récepteur

Ce tableau est volontairement simplifié^**.
^** les récepteurs ACCST 900MHz anciennes générations, les récepteurs V8 et D8 ne sont volontairement pas listés ici car largement suplantés par de nouveaux produits. Seuls les récepteurs officiels de la marque FrSky sont listés.

Pour en savoir plus sur les protocoles FrSky, plusieurs articles sont à votre disposition ici.

Année de commercialisation	Famille ou Série	Nom du récepteur	ACCST D16 v1 2.4GHz	ACCST D16 v2 2.4GHz	ACCESS 2.4Ghz	ACCESS 900MHz	TANDEM 2.4GHz + 900Mhz	TWINI 2 x 2.4GHz
2015	X	X4R	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2015	X	X4R-SB	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2015	X	X6R	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2015	X	X8R	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2018	X	RX4R	Oui⁽¹⁾	Oui⁽¹⁾	Oui⁽¹⁾⁽²⁾	/	/	/
2018	X	RX6R	Oui⁽¹⁾	Oui⁽¹⁾	Oui⁽¹⁾⁽²⁾	/	/	/
2017	X	RX8R	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2018	X	RX8R Pro	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2017	X	R-XSR	Oui⁽¹⁾	Oui⁽¹⁾	Oui⁽¹⁾⁽²⁾	/	/	/
2017	X	G-RX6	Oui⁽¹⁾	Oui⁽¹⁾	Oui⁽¹⁾⁽²⁾	/	/	/
2018	X	G-RX8	Oui⁽¹⁾	Oui⁽¹⁾	Oui⁽¹⁾⁽²⁾	/	/	/
2016	X	XSR	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2017	X	XSR-M	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2017	S	S6R	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2017	S	S8R	Oui⁽¹⁾	Oui⁽¹⁾	/	/	/	/
2016	XM	XM	Oui	/	/	/	/	/
2016	XM	XM+	Oui	/	/	/	/	/
2017	XM	XMR	Oui	/	/	/	/	/
2019	R9	R9 STAB OTA	/	/	/	Oui	/	/
2019	R9	R9 Slim+ OTA	/	/	/	Oui	/	/
2019	R9	R9 MM OTA	/	/	/	Oui	/	/
2019	R9	R9 Mini OTA	/	/	/	Oui	/	/
2020	R9	R9 MX	/	/	/	Oui	/	/
2020	R9	R9 SX	/	/	/	Oui	/	/
2020	Archer	M+	/	/	Oui	/	/	/
2020	Archer	RS	/	/	Oui	/	/	/
2019	Archer	GR8	/	/	Oui	/	/	/
2020	Archer	GR6	/	/	Oui	/	/	/
2020	Archer	R6	/	/	Oui	/	/	/
2020	Archer	R8 Pro	/	/	Oui	/	/	/
2020	Archer	R10 Pro	/	/	Oui	/	/	/
2020	Archer	SR6	/	/	Oui	/	/	/
2020	Archer	SR8 Pro	/	/	Oui	/	/	/
2020	Archer	SR10 Pro	/	/	Oui	/	/	/
2021	Tandem	TD-MX	/	/	/	/	Oui	/
2022	Tandem	TD-R10	/	/	/	/	Oui	/
2022	Tandem	TD-R18	/	/	/	/	Oui	/

Note :

⁽¹⁾ signifie que le protocole dépend du firmware injecté dans le récepteur
⁽²⁾ ces récepteurs ne connaitrons plus de mise à jour du protocole ACCESS. Ces récepteurs ont permis, en leur temps, de faire la transition entre l'ACCST et l'ACCESS lorsque la gamme Archer n'existait pas encore.

]]> Mon, 25 Apr 2022 17:57:25 +0200 <![CDATA[Normes ETSI: FCC Vs. (EU-)LBT]]> https://opentx-doc.fr/wiki/normes-etsi-fcc-vs-eu-lbt https://opentx-doc.fr/wiki/normes-etsi-fcc-vs-eu-lbt Citation :

J'ai eu des échanges par email avec Mr Lacroix (Microtechnics) qui confirme l’exactitude de ces information en ce mois de Juin 2016. Pour info, Microtechnics est un revendeur 'Premium Dealer' par FrSky.

Pour ceux qui seraient perdus, voici une explication sur les normes actuelles.
Cela concerne également les autres marques, mais ici nous sommes sur un site dédié à OpenTx, donc je ne parlerai que de nos Taranis.
Il est important de comprendre que la date d'application des normes dépend de la date d' importation par le revendeur (qui est la référence des textes) et non de la date d'achat par l'utilisateur.

IMPORTANT: ne pas confondre firmware de la carte RF de la radio et le firmware OpenTX. Ce sont 2 choses qui fonctionnent ensemble, mais qui sont différentes.
- Le module RF (RF = Radio Fréquence) interne, c'est la partie qui établit le lien 2.4GHz entre le TX (la Taranis) et le récepteur (ce qui est dans le modèle volant et qui contrôle les servos). C'est de cela que l'on parle dans cet article. Cela concerne aussi les modules XJT FrSky externe.
- OpenTX, c'est l'OS du TX (la Taranis). C'est la partie qui permet de tout gérer. C'est le chef d'orchestre qui vérifie la positions des manches, des boutons, le retour de télémétrie, qui contrôle le module RF, l'écran, le vibreur, etc..
Chacun a sa propre version de firmware, et même s'ils travaillent en symbiose, la mise à jour de l'un n’impacte pas le fonctionnement de l'autre.

Pour faire une analogie informaticienne:
OpenTX = windows XP/7/8/10 de la radiocommande (dans notre cas la Taranis)
Firmware radio = driver/pilote d'un périphérique (dans notre cas le module RF interne/externe)

Mode de fonctionnement des récepteurs:

- Série V sans télémétrie → mode V8
- Série V-II sans télémétrie (notez bien le II) → mode D8
- Série D avec télémétrie analogique→ mode D8
- Série X avec télémétrie Smart Port (ou S.Port) → mode D16
Les différentes versions des firmwares:
non-EU (aussi nommée FCC): version distribuée partout dans le monde sauf en Europe depuis le 01/01/2015. Supporte les modes D8, D16 et LR12
EU: 1ère version diffusée pour l'Europe début 2015. Il est très vivement recommandé (comprendre par :"obligatoire si toi pas vouloir planter ton modèle") de ne plus l'utiliser. Cette toute première version EU n'était pas conforme et aussi illégale en raison de l'absence d'une Déclaration de Conformité. De plus, elle contenait un bug technique. La Déclaration de Conformité n'a été rédigée que fin Janvier 2015 et la version EU a été corrigée avant de céder la place à EU-LBT. Supporte uniquement le mode D16-EU
EU-LBT ou LBT: c'est la version officielle pour toute l'Europe depuis fin 2015. Supporte les modes D16-EU-LBT et LR12

Radios vendues à la norme ETSI EN 300 328 v1.8.1 (obligatoire depuis le 01/01/2015):
- la RF peut être flashée en version non-EU, mais c'est illégal si la radio a été importée après le 01/01/2015.
- Les 1ère radios vendues début 2015 étaient en version EU. Il est très vivement recommandé de les flasher en version EU-LBT (d'ailleurs, tous les RXs vendus aujourd'hui sont en version EU-LBT et non compatible avec la version EU). De plus, certains utilisateurs ont eu des problèmes de portée avec cette 1ère version EU intermédiaire (ce qui n'est, heureusement, plus le cas avec la version finale EU-LBT). Vous êtes prévenus...
- On peut réactiver le mode D8 en décochant la case EU sous Companion, mais c'est illégal si la radio a été importée après le 01/01/2015. Il est en effet illégal d'émettre en mode D8 avec un émetteur importé après le 01/01/2015, mais c'est autorisé si on utilise un module externe DJT ou XJT importé avant cette date.
- Si vous votre radio a été importée avant le 01/01/2015, vous pouvez la passer en mode EU-LBT et activer le mode D8. C'est légal (comme Spektrum avec son mode DSM2 et DSMX avant 2015, puis uniquement du DSMX à partir de 2015).
- Retour du mode LR12 avec le firmware EU-LBT (ce n'est pas le cas avec le firmware EU qui supporte uniquement le mode D16-EU).

A noter:
- FrSky recommande à ceux qui ont achetés une Taranis avant le 01/01/2015 de mettre à jour tous leurs équipements FrSky à la norme 1.8.1 (EU-LBT). Attention, il faut refaire l'appairage après avoir fait la mise à jour ! Sinon votre RX peut se comporter de façon bizarre (le plus souvent on voit les servos frétiller de façon erratique).
- Le mode D8 est le même dans le monde entier, mais n'est plus légal pour les équipements neufs vendus après le 01/01/2015.
- Le mode LR12 est le même dans le monde entier.
- L'importation et la vente des récepteurs série D en Europe sont illégales, sauf pour anciens stocks importés avant le 01/01/2015. Pour les récepteurs de la série V c'est différent du fait qu'ils n'émettent pas. Ceci dit, il faut bien noter l'absence de Déclaration de Conformité pour la série V...

Pour résumer:

Avant le 01/01/2015 → version non-EU (aussi nommée FCC) (mode D8, D16 et LR12) partout pareil dans le monde.

Après le 01/01/2015 → version EU-LBT (mode D16-EU-LBT et LR12) en Europe et version non-EU (mode D8, D16 et LR12) pour le reste du monde. Même si on peut le réactiver, le Mode D8 n'est plus légal en Europe pour les radio achetées à partir de 2015.
On oublie la version EU pas LBT, car c'était une version intermédiaire avec des problèmes de portée. Si votre Taranis a été achetée entre janvier 2015 et novembre 2015 et que vous avez des problèmes d'appairages avec les RXs EU-LBT, alors vous êtes très certainement en version EU "moisie" (la fameuse EU non-LBT à éviter à tout prix)

]]> Sun, 12 Dec 2021 17:44:43 +0100 <![CDATA[D8 vs. D16 vs. R9M vs. LR12]]> https://opentx-doc.fr/wiki/d8-vs-d16-vs-r9m-vs-lr12 https://opentx-doc.fr/wiki/d8-vs-d16-vs-r9m-vs-lr12 Article écrit par LapinFou en Mars 2019.

Pour les nouveaux dans le monde FrSky, voici un résumé sur les modes D8, D16, R9M et LR12.

A noter:

Le mode D8 est le même partout dans le monde.
Sur les radios Européennes, ce mode est caché par défaut car il ne respecte pas les normes pour les radios vendues à ce jour. Par contre on peut démasquer (et ainsi accéder) au mode D8 en flashant la radio sans cocher l'option EU. Il faut savoir que ce n'est pas légal de faire cela.
Le mode LR12 (Long Range) est le même partout dans le monde.
Il est légal en Europe, car pas de télémétrie.
Le mode D16 est différent entre l'Europe et le reste du monde.
Il existe le mode D16 non-Eu (aussi nommé mode FCC) et le mode D16 EU-LBT (LBT = Listen Before Talk). Les RXs doivent être dans la même norme que la radio.
Le mode R9 est différent entre l'Europe et le reste du monde.
C'est le nouveau protocole "Longue Portée". Il nécessite un module d'émission spécifique : le R9M (au format baie JR) et le R9M-Lite (au format spécifique de la baie de la Taranis X-Lite et qui bénéficie d'une latence bien plus faible que le R9M grâce à l'utilisation d'une UART dédié). Ce même module fonctionne soit sur la bande des 900MHz pour la zone non-européenne (version FCC, 16 voies), soir sur la bande des 868MHz pour la version Européenne (version EU, 8 voies en 25mW, sinon 16 voies). La portée indicative est de 10km. Ce mode supporte la télémétrie (en EU et en FCC). Les récepteurs que l'on peut associer sont ceux de la série R9.

Plus d'info ici → Le point sur les normes ETSI

En résumé nos Taranis émettent en mode D8 (non dispo par défaut en Europe), mode D16 et mode LR12.
Par contre, elles ne supportent pas le mode V8. Pour cela il faut un module externe FrSky DJT.
Pour le "long range" R9, il faut un module externe FrSky R9M/R9M-Lite.

Mode	Récepteur	Description
V8	Série V sans télémétrie	8 voies
D8	Série V-II sans télémétrie (notez bien le II)	8 voies
D8	Série D avec télémétrie analogique (besoin d'un hub si plusieurs capteurs) et failsafe programmable uniquement sur le RX	8 voies + télémétrie analogique d'où la nécessité d'un hub. En effet, on ne peut pas chaîner les capteurs car sinon cela ferait des conflits électriques.
D16	Série S, X et XM avec télémétrie numérique Smart Port (ou S.Port) et failsafe programmable depuis la radio	16 voies + S.Bus (sauf le X4R et XMR) + Smart port qui est le port numérique de télémétrie. On peut chaîner les capteurs.
LR12	Série L sans télémétrie et failsafe programmable depuis la radio	12 voies + S.Bus (12voies + 4 voies toujours à 0%) + pas de télémétrie.
R9M	Série R9 avec télémétrie et failsafe programmable depuis la radio	8 ou 16 voies + S.Bus + télémétrie numérique S.port (la disponibilité de la télémétrie dépend du protocole et de la puissance d'émission choisis).

Pour faire simple: tout RX avec port S.Bus sort 16 voies sur celui-ci s'il est appairé/bindé en mode D16, R9M ou LR12 (série S, X, XM, R9 et L).

Le S.bus est un lien série numérique (un peu comme un cordon USB). C'est une trame de donnée numérique qui est beaucoup moins sensible aux perturbations magnétiques (comparée au PWM). Dans cette trame, il y a l'information de position pour 16 voies différentes. Par exemple, un petit X4R-SB a 3 sorties classiques (PWM) et 1 sortie S.Bus. Sur cette sortie S.Bus, les 16 voies sont envoyées !! Petit, mais costaud.

La grande majorité des servos sont des servos PWM. Qu'ils soient analogiques ou numériques cela ne change rien.

Maintenant, la grande question est: comment utiliser le SBus ?
2 solutions: soit on utilise des servos S.Bus (capable de comprendre et décoder la trame S.bus), soit on utilise un convertisseur S.Bus vers PWM pour utiliser des servos classiques.
On doit assigner au servo S.bus un numéro (pareil pour un convertisseur S.Bus vers PWM).
Évidemment ce numéro est compris entre 1 et 16. En faisant cela on programme le servo S.bus pour réagir uniquement aux ordres de position qui le concerne. Bien évidemment, si besoin, on peut programmer plusieurs servos S.bus sur le même numéro (ex: 2 servos pour la profondeur). En général on fait cela soit parce que l'on a plus de 16 servos dans un modèle, soit pour utiliser uniquement 8 voies afin de rester en mode 9ms (voir explication plus loin pour la différence 9ms/18ms en mode D16).
Chez FrSky on utilise un SCC pour faire cette programmation.
Une fois programmé (par exemple le numéro 10), on branche sur le port S.Bus le servo S.Bus.
Il va décoder toute la trame, mais il va réagir uniquement à la position de la voie 10.

Le gros avantage est que cela fait moins de fils, puisque l'on peut brancher les servos en série (comme une guirlande) au lieux d'avoir plein de fils qui partent du RX.
Pour plus d'info voir Futaba S.Bus System ou La technologie Futaba S-Bus

Par contre il faut faire attention a 2 choses très importantes:

La sortie S.bus des RX FrSky est uniquement conçue pour envoyer la trame numérique. Il ne faut pas faire passer de puissance par cette sortie. Concrètement, cela veut dire que le fil rouge qui alimente tous les servos ne doit pas venir directement depuis le port S.Bus du RX.
Le S.bus est beaucoup plus rapide que le classique PWM (ce qui est un autre avantage). Par contre si l'on branche un servo analogique PWM derrière un convertisseur S.Bus → PWM, il ne va pas apprécier. Il va chauffer, voir cramer. En effet, le taux de rafraîchissement de la position est trop rapide pour lui.

En conclusion, si on pilote des servos avec du S.Bus comme source, il faut utiliser uniquement des servos numériques (beaucoup plus rapides).

Comment choisir le nombre de voies sur le mode D16 ?

En toute logique, envoyer 16 voies prend 2x plus de temps (18ms) qu'envoyer 8 voies (9ms).
Du coup, la position des servos est bêtement rafraîchie 2x moins souvent même si on n'utilise que 8 voies.
Mais comme FrSky fait bien les choses, la radio envoie les informations par paquet de 8 voies en alternant ([1-8], [9-16], [1-8], [9-16], [1-8], etc...).
Donc, on peut choisir d'envoyer seulement 8 voies si cela suffit à notre modèle.

C'est pour cela que lorsque l'on fait le Bind, on peut choisir les voies "de 1 à 8 (9ms)" ou "de 1 à 16 (18ms)".
Mode 9ms = [1-8], [1-8], [1-8], [1-8], [1-8], etc...
Mode 18ms = [1-8], [9-16], [1-8], [9-16], [1-8], etc...
NB sur le taux de rafraichissement des sorties du RX:

Même si les trames sont envoyées toutes les 9ms, cela ne veut pas dire que les sorties PWM sont rafraîchies toutes les 9 ms (sinon pschitt les servos analogiques !!). Sur les RX FrSky, le taux de rafraîchissement des sorties PWM est de 18ms quelque soit le mode.
Par contre, la trame S.Bus est bien générée toutes les 9ms. D'où la mise en garde lorsque l'on utilise un convertisseur S.Bus → FrSky Décodeur SBus vers PWM.
Note sur le mode D16: Même si on envoie que 8 voies (9ms), la sortie S.Bus génère quand même une trame de 16 voies. Par contre seules les 8 premières sont rafraîchies. Les 8 dernières voies sont forcées en permanence sur la position milieu (au neutre).
Note sur le mode LR12: On peut utiliser uniquement 12 voies max pour le mode LR12. Cependant, la sortie S.Bus génère quand même une trame de 16 voies. Par contre seules les 12 premières sont mises à jour. Les 4 dernières voies sont forcées en permanence sur la position milieu (au neutre).

Plus d'infos sur les différents acronymes → PWM, CPPM, S.Bus... Késako ??
]]> Sun, 10 Jan 2021 18:08:10 +0100 <![CDATA[PWM, CPPM, S.Bus... Késako ??]]> https://opentx-doc.fr/wiki/pwm-cppm-s-bus-kesako-ee https://opentx-doc.fr/wiki/pwm-cppm-s-bus-kesako-ee Article écrit par LapinFou en Avril 2019.

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:

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.
]]> Tue, 01 Dec 2020 15:44:59 +0100 <![CDATA[ACCST D16 v1 - Le bug]]> https://opentx-doc.fr/wiki/accst-d16-v1-le-bug https://opentx-doc.fr/wiki/accst-d16-v1-le-bug Article écrit par LapinFou en Janvier 2020 et modifié en Août 2020.

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.

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

]]> Wed, 05 Aug 2020 11:28:07 +0200 <![CDATA[Les radios ACCESS]]> https://opentx-doc.fr/wiki/les-radios-access https://opentx-doc.fr/wiki/les-radios-access Article écrit par Ceeb182 (transféré par Lapinfou).

Voici le point sur diverses informations relatives à l'arrivée des nouveaux émetteurs FrSky supportant le protocole ACCESS.
Dans ce qui suit RF signifie Radio Fréquence.

Concernant les modules RF des radios ACCESS

Il existe 3 types de module RF pour les radios supportant le protocole ACCESS :
- le ISRM_P = Emetteur RF + Puissance mètre + Mesure précise du SWR*
- le ISRM_S = Emetteur RF + Ancienne mesure imprécise du SWR* renommé RAS* dans OpenTx
- le ISRM_N = Emetteur RF
SWR* et le RAS** : Pour en savoir plus cliquer ici

Il existe actuellement 3 variantes du ISRM de type S : le S, S_X9 et S_X10.
Il s'agit de la même famille que le S. La différence est principalement liée aux antennes et à une intégration différente à la radio.

Concernant la fonction Analyseur de spectre

La fonction Analyseur de Spectre n'est pas liée au hardware des modules ISRM.
La fonction Analyseur de Spectre est basée uniquement sur un calcul logiciel.
Autrement dit, toutes les radios ACCESS ont la fonction Analyseur de Spectre.
Il y a même un développement de l'Analyseur de Spectre pour le module multiprotocole

Concernant la législation FCC et Européenne

Rappel : il y a deux systèmes normatifs principaux pour le matériel RF dans le monde
- l'Union Européenne qui édicte les directives et les normes uniquement pour les 28 pays de l'Union Européenne
- la FCC (Federal Communications Commission) basée aux USA qui édicte les normes pour l’Amérique du nord

Ce paragraphe est valable pour tous les fabricants de matériel RF.
Je ne suis pas spécialiste en question juridique de radio-télécommunications. Cependant on trouve assez facilement des informations permettant de comprendre les impératifs auxquels doivent se conformer les fabricants, importateurs, distributeurs, consommateurs.
Voici quelques impératifs des réglementations FCC et Européenne (liste non-exhaustive) :

les critères de conformité technique de la partie RF sont différentes entre la FCC et l'Europe : fréquences parfois différentes, puissance différente, LBT en Europe, etc...

"Réglementations concernant la conformité technique de la partie RF" :
- En Europe : ETSI EN 300 328 (réglementation Européenne)
- Hors Europe : Code of Federal Regulations, Title 47, Part 15 (47 CFR 15) (réglementation de la FCC - Federal Communications Commission)
la modification du logiciel de la partie RF est très encadrée

"Réglementations concernant les radios définies par le logiciel utilisé" :

- En Europe : la directive RED - 2014/53/UE Chapitre I Article 3

Citation :
Exigences essentielles
Les équipements radioélectriques de certaines catégories ou classes sont construits de telle sorte qu'ils respectent les exigences essentielles suivantes:
(...)les équipements radioélectriques sont compatibles avec certaines caractéristiques visant à garantir qu'un logiciel ne peut être installé sur un équipement radioélectrique que lorsque la conformité de la combinaison de l'équipement radioélectrique avec le logiciel est avérée.

- Hors Europe : réglementation de la FCC Code of Federal Regulations, Title 47, Part 2

Citation :
§2.944 Radio définie par le logiciel utilisé
Les fabricants doivent prendre des mesures pour s'assurer que seuls les logiciels approuvés avec une radio définie par logiciel peuvent être chargés dans la radio. Le logiciel ne doit pas permettre à l'utilisateur de faire fonctionner l'émetteur avec des fréquences de fonctionnement, une puissance de sortie, des types de modulation ou d'autres paramètres de fréquence radio en dehors de ceux qui ont été approuvés.
toute modification du logiciel de la partie RF incompatible avec la certification RF FCC ou Européenne rend caduque la certification du matériel.
(certification caduque = matériel illégal = usage interdit sur le territoire concerné)

"Réglementations concernant la validité de la certification de la partie RF" :

- En Europe : le marquage CE des équipements radioélectriques est valide uniquement si le matériel associé aux normes/directives EU ont été vérifiées par un bureau de contrôle accrédité. Il est clairement indiqué sur le certificat du bureau de contrôle "Aucune configuration autre que celle décrite dans le certificat n'a été prise en compte et n'est donc pas incluse dans le certificat". Autrement dit toute modification du matériel rend caduque la certification CE.
- Hors Europe : réglementation de la FCC Code of Federal Regulations, Title 47, Part 15

Citation :
§15.21 Information donné à l'utilisateur.
Le manuel de l'utilisateur ou le mode d'emploi d'un émetteur, intentionnel ou non, doit avertir l'utilisateur que des modifications ou des changements non expressément approuvés par la partie responsable de la conformité pourraient annuler le droit de l'utilisateur d'utiliser l'appareil.
l'évolution actuelle des réglementations vont vers une plus grande responsabilisation des fabricants. Le fabricant doit mettre en place un mécanisme pour empêcher que certaines modifications logicielles puisse rendre la partie RF illégale vis à vis des réglementations locales.

"Réglementations concernant les mécanismes visant à empêcher la modification logicielle de la partie RF d'un matériel" :

- En Europe : la directive RED - 2014/53/UE Chapitre I Article 3

Citation :
(...)les équipements radioélectriques sont compatibles avec certaines caractéristiques visant à garantir qu'un logiciel ne peut être installé sur un équipement radioélectrique que lorsque la conformité de la combinaison de l'équipement radioélectrique avec le logiciel est avérée.

Norme ETSI EN 300 328 v2.2.2 paragraphe 4.3.1.13.3

Citation :
L'emplacement géographique déterminé par l'équipement FHSS** tel que défini à la clause 4.3.1.13.2 ne doit pas être accessible à l'utilisateur d'une manière qui lui permettrait de le modifier.
**FHSS = "Frequency-Hopping Spread Spectrum" ou en français "étalement de spectre par saut de fréquence". C'est sur ce principe que fonctionnent nos radios.

- Hors Europe : réglementation de la FCC Code of Federal Regulations, Title 47, Part 2

Citation :
Les fabricants peuvent utiliser des moyens, y compris, mais sans s'y limiter, l'utilisation d'un réseau privé qui ne permet qu'aux utilisateurs authentifiés de télécharger des logiciels, l'utilisation de signatures électroniques à l'intérieur des logiciels ou codées à l'intérieur du matériel permettant de vérifier que les nouveaux firmwares peuvent être légalement téléchargés sur un dispositif pour satisfaire les exigences RF. Le fabricants doivent décrire les mesures prises à cet effet dans leur demande d'accréditation de leurs équipements.

Tout ceci oblige le fabricant à ne pas laisser l'utilisateur final faire n'importe quoi sur la partie RF de son matériel.

En bref, pour le respect des réglementations RF et pour ne pas exposer le fabricant à des sanctions, une mesure simple consiste à ce que l'utilisateur final ne puisse pas modifier le logiciel de la partie RF de son matériel.

Concernant la version LBT ou FCC des radios FrSky supportant le protocole ACCESS

Rappel : en radiocommande, les deux types de transmission RF les plus utilisés dans le monde sont
- le type EU-LBT aussi appelé LBT (Listen Before Talk) en vigueur dans l'Union Européenne. Il a pour particularité de vérifier que le canal RF est inoccupé avant d'émettre.
- le type Non-EU aussi appelé FCC (Federal Communications Commission) en vigueur en Amérique du nord
Le module RF d'un émetteur possède son propre logiciel qui est totalement indépendant de la version d'OpenTx. Pour simplifier, OpenTx envoie des ordres en clair au module RF de l'émetteur qui les formate au bon protocole pour les transmettre au récepteur. Le récepteur et le module RF de l'émetteur doivent converser dans la même langue pour se comprendre. Chaque protocole (ACCESS, ACCST_D16) est décliné en deux types : FCC ou EU-LBT.

Actuellement, le module ISRM des radios supportant ACCESS contient simultanément les versions LBT et FCC.
Autrement dit, le module ISRM contient les protocoles suivants : ACCESS_FCC et ACCST_D16_FCC, ACCESS_LBT et ACCST_D16_LBT (voir ici).

Théoriquement, c'est à la commande de l'émetteur radio que l'utilisateur final doit faire le choix LBT ou FCC.
Quant aux récepteurs ACCESS, ils s'adaptent automatiquement à la norme FCC ou LBT (un seul et unique firmware quelle que soit la norme FCC ou EU-LBT).

Pour les nouveaux émetteurs FrSky, un centre technique FrSky ou un opérateur habilité par FrSky (comme par exemple un vendeur premium) a le droit et peut techniquement effectuer l'opération de sélection des versions LBT ou FCC des protocoles.

Même si vous savez que "isrm_mode.lua" et "region.lua" permettent de changer entre LBT et FCC (c'est devenu un secret de polichinelle !), l'utilisateur final est dans l'illégalité s'il tente de le modifier lui-même. Ces scripts ont été communiqués sous le sceau du secret et n'aurait pas dû circuler.
Pour donner un parallèle avec des logiciels commerciaux pour ordinateur : même si avez accès à un "Crack", c'est à dire un programme visant à contourner l'obtention d'une licence officielle d'un logiciel commercial, il est illégal de l'utiliser.

De plus il faut savoir qu'à partir d'OpenTx 2.3.x conjugué au nouveau matériel FrSky, il est désormais possible de voir si votre radio est FCC ou LBT (ce qui n'était pas le cas auparavant). Le contrôle de conformité vis à vis de la réglementation RF locale est alors possible et aisé.

Des fabricants de matériel RF entre le marteau et l'enclume

Est-ce que le fabricant doit supprimer la souplesse de mise à jour du logiciel de la partie RF pour être parfaitement dans la légalité ? Non, mais il y a des gardes fous réglementaires ! (voir le paragraphe "Législation FCC et Européenne")
Les fabricants sont tiraillés entre le fait de se conformer aux réglementations locales en vigueur, et, satisfaire le besoin du client final à adapter rapidement le matériel à son usage.
Il n'y a pas que FrSky qui est dans ce cas là : tous les fabricants proposant du matériel RF à l'international sont impactés.
Si demain le contrôle venait à s'exercer de façon plus prononcé et avec des sanctions effectives à la clef, le fabricant n'aura d'autre choix que de rendre impossible la modification logicielle des parties RF. Il préservera ainsi sa certification RF et pourra continuer à vendre son matériel RF sur les marchés qu'il occupe.

]]> Fri, 06 Dec 2019 09:39:23 +0100 <![CDATA[Le protocole ACCESS]]> https://opentx-doc.fr/wiki/le-protocole-access https://opentx-doc.fr/wiki/le-protocole-access gaston-icone-h25

Article écrit par Ceeb182.

access-01

Traduction de l'annonce officielle présente sur le site FrSky datée du 23 mars 2019, mis à jour en juin 2019

Introduction

FrSky cherche constamment à améliorer les performances et la fiabilité de ses transmissions RC. Le protocole ACCESS de FrSky est le plus avancé à ce jour étant donné qu'il offre bien plus de fonctionnalités que les protocoles traditionnels.

FrSky a développé de nouvelles idées innovantes qui enrichissent le rôle qu'un protocole traditionnel est censé jouer. Conçu à partir de notre très populaire protocole ACCST , ACCESS apporte des fonctionnalités visionnaires comme le Smart Share™, le Smart Match™ et le Trio Control™. Une fois qu'un récepteur a été appairé à une radio, il peut être ré-appairé n'importe quand sans devoir utiliser le bouton d'appairage (ou bouton "Bind") du récepteur. Le partage de vos modèles n'a jamais été si facile, et la mise à jour a aussi été simplifiée. Désormais vous n'avez plus besoin d'avoir une connexion physique à vos récepteurs pour effectuer leurs mises à jour. De plus, de nouveaux outils comme "l'Analyseur de spectre" et le "Puissance mètre" sont maintenant disponibles sur votre émetteur.

Souhaitant être toujours à la pointe de la technologie, nous avons développé ACCESS pour améliorer votre expérience de vol en vous permettant, avec votre ensemble émetteur/récepteur, de faire plus que jamais auparavant.

Fonctions et caractéristiques principales

Performances accrues grâce à un débit en bauds plus rapide et une latence plus faible

	● Prise en charge de 24 voies Certains modèles nécessitent plus que les 16 voies disponibles avec l'ancien protocole. Pour les utilisateurs de ces modèles, ACCESS gère jusqu'à 24 voies sur une seule liaison radio.
	● Débit en bauds plus rapide et latence plus faible ACCESS permet de transmettre des consignes de positions à des vitesses plus importantes et avec une meilleure précision. Il est extrêmement important pour nous de garder une longueur d'avance sur la concurrence. Moins de latence se traduit par un temps de réponse plus rapide.

Technologie M2M (Multi to Multi) plus pratique

	● Appairage, mises à jour et configuration sans fil Il n'est plus nécessaire d'accéder au récepteur pour l'appairage, les mises à jour et la configuration car ces procédures sont désormais réalisées avec une connexion sans fil. Grâce à l'appairage sans fil, il n'a jamais été plus facile de partager ses modèles avec d'autres utilisateurs FrSky. (Smart Share™)
	● Appairage automatique (Smart Match™) L'appairage de votre modèle est plus sûre que jamais. Vous pouvez facilement appairer vos modèles avec une connexion sans fil sans avoir besoin d'accéder à votre récepteur. De plus, la double authentification de l'émetteur et du récepteur rend le processus d'appairage plus sûr qu'auparavant.
	● Re-direction des voies (ou Remapping) Avez-vous déjà branché et installé un récepteur juste pour découvrir que tout était branché sur les mauvaises prises ? Vous pouvez maintenant simplement re-diriger l'ordre des voies à partir de votre émetteur.
	● Télémétrie administrable (Trio Control™) Vous pouvez administrer la télémétrie jusqu'à 3 récepteurs simultanément via la radio. Vous n'avez plus besoin d'utiliser l'outil STK. De plus le Smart Port permet l'utilisation de périphériques tiers d'entrée/sortie grâce au mode "transfert" (ou mode "pass-through").

Fiabilité et sécurité améliorée - Système anti-interférence et anti-détournement

	● Utilisation de la radio comme "Analyseur de Spectre" Vous pouvez maintenant utiliser votre émetteur pour surveiller les ondes radios, ce qui vous permet de mesurer l'intensité de votre signal et d'autres signaux présents à votre emplacement. L'analyseur de spectre permet à l'utilisateur de mesurer la puissance, le bruit et le brouillage des fréquences environnantes.
	● Utilisation de la radio comme "Puissance mètre" La puissance RF en dBm provenant d'autres appareils peut être mesurée grâce à cette nouvelle fonctionnalité.
	● Algorithme de cryptage avancé Un cryptage plus élevé signifie une plus grande tranquillité d'esprit car le signal de votre modèle ne pourra pas être perturbé.

Questions & Réponses

Qu'est-ce que le Smart Match™ ?

Maintenant, vous bénéficiez d'une sécurité supplémentaire avant de voler. Le Smart Match™ obtient la double authentification de votre récepteur et de votre émetteur, et vous procure ainsi une protection double.

Qu'est-ce que le Smart Share™ ?

Vous pouvez maintenant appairer plusieurs émetteurs à un même récepteur et dans ce cas le Smart Share™ vous assure d'avoir une authentification unique pour chaque émetteur. Si vous volez en compétition, vous pouvez configurer deux émetteurs de façon identique et ainsi en avoir un de rechange prêt à l'emploi au cas où vous en auriez besoin. Il n'y a pas besoin d'accéder physiquement au bouton d'appairage du récepteur. Tout est prêt à l'emploi. De nombreux clubs ont des avions d'entraînement pour former les nouveaux aéromodélistes. Il est maintenant facile de permettre à plusieurs émetteurs autorisés de s'appairer avec le récepteur de l'avion d'entraînement.

Qu'est-ce que le Trio Control™ ?

ACCESS permet à un émetteur de contrôler le signal et/ou la télémétrie jusqu'à 3 récepteurs au maximum par modèle. La redondance du récepteur offre une couche de sécurité supplémentaire notamment pour les vols des modèles de grande taille.

Quelles sont les améliorations du protocole ACCESS par rapport au protocole ACCST ?

Le protocole ACCESS peut gérer jusqu'à 24 voies avec une vitesse de transmission accrue et une latence réduite (latence totale mesurée entre la prise de position effectuée par les manches de l'émetteur et le signal de sortie de commande généré par le récepteur) et bénéficie aussi de performances internes élevées.

mode 8 voies : latence fixe de 11ms / Débit montant de la télémétrie amélioré de 40% / Débit descendant de la télémétrie amélioré de 60%
mode 16 voies : latence 14 ~ 23ms / Débit montant de la télémétrie amélioré de 40% / Débit descendant de la télémétrie amélioré de 60%
mode 24 voies : latence 14 ~ 23ms / Débit descendant de la télémétrie amélioré de 60%

Y a-t-il des différences entre les anciens et les nouveaux produits si j'utilise le protocole ACCESS ?

Oui. Certaines nouvelles fonctionnalités comme le "Puissance Mètre" ont été développées et optimisées avec les nouveaux émetteurs FrSky (comme par exemple la "Taranis X-Lite Pro"). En ce qui concerne les performances sans fil, le nouveau module RF amélioré est spécialement conçu pour utiliser le nouveau protocole ACCESS. La qualité du lien radio obtenu grâce au nouveau module RF amélioré est supérieure à celui d'un module standard.

Quelles seront les bandes de fréquences prises en charge par le nouveau protocole ACCESS ?

Le protocole FrSky ACCESS prendra en charge les bandes de fréquences 900 MHz et 2,4 GHz avec des performances différentes. Les nouveaux produits à double fréquence comme les émetteurs, les modules d'émission et les récepteurs qui seront lancés dés cette année fonctionneront en parfaite symbiose.

Quels sont les scénarios pour lesquels je peux utiliser la fonction Smart Share™ ?

Un utilisateur dispose de 3 radios FrSky différentes pour chaque type d'aéromodèle, puis finalement il souhaite les faire voler tous avec un seule et même radio. Étant donné que l'utilisateur a déjà appairé précédemment ses récepteurs, l’accès physique au bouton d'appairage (ou bouton "bind") est désormais inutile pour changer d'émetteur.
Les compétiteurs RC transportent souvent une radio de secours au cas où quelque chose arriverait à la radio principale. Dans ce cas, le pilote peut passer sur la 2^ème radio sans avoir besoin d'accéder physiquement au bouton d'appairage du récepteur de son modèle.
Les clubs qui possèdent et utilisent des avions communautaires à usage spécial, comme les avions qui remorquent les planeurs pour la mise en altitude, n'auront plus besoin d'avoir une seule et même radio dédiée à cet avion. Chaque pilote autorisé pourra utiliser son propre émetteur FrSky grâce à son numéro d'identification unique.
Un utilisateur qui souhaite partager un modèle avec un ami peut maintenant l'autoriser à s'appairer au modèle sans avoir besoin d'accéder physiquement au bouton d'appairage. De même, lorsque le modèle est rendu à son propriétaire, il peut être simplement ré-appairé sans avoir besoin d'accéder physiquement au bouton d'appairage.

Quels récepteurs supporteront le protocole ACCESS ?

Edition du 26/06/2019
Le 1er lot de mises à jour comprend le RX4R, le RX6R, le G-RX6 et le G-RX8.
Le second lot de mises à jour comprend le RXSR, le XM, le XM+ et le RX8R Pro.

Y aura-t-il différentes versions d'ACCESS pour les récepteurs et émetteurs dépendant de la région d'utilisation du matériel ?

Edition du 26/06/2019
Pour les récepteurs il n'y aura qu'une seule version d'ACCESS. Cependant les émetteurs disposeront au choix de l'un des deux modes : mode LBT et mode Non-LBT.
Le récepteur ACCESS reconnaîtra et s'adaptera automatiquement au mode de fonctionnement utilisé par l'émetteur dés qu'ils seront en communication. Le mode LBT est le seul mode autorisé en Europe. Les utilisateurs US ou du reste du monde peuvent choisir le mode qu'ils souhaitent utiliser.

Est-il possible d'utiliser mes récepteurs ACCST avec les nouveaux émetteurs ACCESS ?

Edition du 26/06/2019
Si les utilisateurs disposent d'un émetteur FrSky supplémentaire et de récepteurs ACCST ne disposant pas encore de mise à jour ACCESS, ils peuvent pour le moment rester au protocole ACCST et remettre à plus tard la migration vers le protocole ACCESS. FrSky conseille les utilisateurs de mettre à niveau leurs émetteurs et récepteurs pour profiter des nouvelles fonctionnalités du protocole ACCESS uniquement lorsque leurs produits disposeront des mises à jour adéquates.

A propos du module externe des radios FrSky à venir

Edition du 26/06/2019
FrSky adoptera principalement l'interface 8 broches (version Lite) pour le module externe des nouvelles radios à venir. Pour les fabricants de modules externes tiers qui respectent les exigences ci-dessous, FrSky offrira tout le support logiciel et matériel nécessaires incluant la documentation technique du matériel, les schémas de l'interface, etc.
1. Les modules externes tiers doivent être vérifiés par des tests de compatibilité FrSky;
2. Le fabricant n'enfreint pas les droits de propriété intellectuelle d'autrui (individu, organisation et entreprise).
L'utilisation d'un module externe non vérifié peut entraîner une dégradation de l'émetteur. Le fabricant tiers n'ayant pas fait l'objet de vérification est responsable de tout dommage qui pourrait survenir, et la garantie FrSky des utilisateurs sera alors caduque.

Caché :

Mise à jour du 26/06/2019 - Autre changement observé
La question suivante a été supprimée :
Q: Puis-je mettre à jour les produits FrSky existants pour les doter du nouveau firmware intégrant le protocole ACCESS ?
R: Tous les émetteurs FrSky précédents et actuels peuvent être mis à jour pour bénéficier du protocole ACCESS. Progressivement FrSky proposera les nouveaux firmwares correspondants pour les récepteurs des séries X, XM, RX, GX et S.

]]> Tue, 27 Aug 2019 10:23:32 +0200 <![CDATA[Modification majeure de la gamme FrSky (Août 2019)]]> https://opentx-doc.fr/wiki/modification-majeure-de-la-gamme-frsky-aout-2019 https://opentx-doc.fr/wiki/modification-majeure-de-la-gamme-frsky-aout-2019 Article écrit par Ceeb182 (transféré par Lapinfou).

FrSky a mis son site officiel à jour indiquant l'arrêt de production de certains de ses produits. Ils sont étiquetés "Discontinued".

Vous trouverez ci-après les produits dont la production est arrêtée.
J'ai aussi ajouté une suggestion de remplacement quand cela est possible.

Émetteurs

Produit	Date Arrêt prod	Remplacé par
Horus X10	08/2019	Horus X10 Express
Horus X10S	08/2019	Horus X10S Express
Taranis X9D Plus	08/2019	Taranis X9D Plus 2019
Taranis X9D Plus SE	08/2019	Taranis X9D Plus SE 2019

Module d'émission radio

Produit	Date Arrêt prod	Remplacé par
R9M	08/2019	R9M 2019
DFT	08/2019	non-remplacé
DHT	08/2019	non-remplacé

Récepteurs

Produit	Date Arrêt prod	Remplacé par
R9 Slim	08/2019	R9 Slim+
XSR-M	08/2019	R-XSR
XSR	08/2019	R-XSR
RX8R	08/2019	RX8R Pro
X4RSB	08/2019	RX4R
X4R	08/2019	RX4R
X6R	08/2019	RX6R
TFR4	08/2019	non-remplacé
TFR8SB	08/2019	non-remplacé
TFR4SB	08/2019	non-remplacé
D4R	08/2019	non-remplacé
V8R4-II	08/2019	non-remplacé

Contrôleur de vol

Produit	Date Arrêt prod	Remplacé par
XSRF3PO	08/2019	RXSR-FC
XSRF4PO	08/2019	RXSR-FC
XSRF4O	08/2019	RXSR-FC
XSRF3O	08/2019	RXSR-FC
XSRF3E	08/2019	RXSR-FC
XMPF3E	08/2019	RXSR-FC
XMF3E	08/2019	RXSR-FC

ESC

Produit	Date Arrêt prod	Remplacé par
FrESC32-35A	08/2019	Neuron 40
FrESC32-80A	08/2019	Neuron 80
FrBLS_30A	08/2019	Neuron 40

VTX

Produit	Date Arrêt prod	Remplacé par
VS600	08/2019	Scout VS600 Mini

Aéromodèle

Produit	Date Arrêt prod	Remplacé par
Vantac AR+ Wing	08/2019	non-remplacé

Accessoires

Produit	Date Arrêt prod	Remplacé par
Redundancy Bus (16 voies)	08/2019	RB-20
SPC (Smart Port Converter)	08/2019	STK
FSD (FrSky S.Port Dashboard)	08/2019	non-remplacé

Le mode D8 est considéré officiellement comme obsolète à partir 2019 par FrSky.
En 2019 apparaît le protocole ACCESS de FrSky ainsi que les nouvelles radios supportant ce protocole (Taranis X9D Plus 2019 et Horus X10 Express, Taranis X9-Lite, ainsi X-Lite PRO et X-Lite S). A ce jour les radios supportant ACCESS supporte aussi le protocole D16.
Les radios arrêtées en 2019 fonctionnent avec les protocoles D8 et D16 et le nombre de récepteurs commercialisés utilisables reste actuellement très important.
gaston-icone-h25

]]> Mon, 26 Aug 2019 16:17:14 +0200 <![CDATA[Normes & Protocoles]]> https://opentx-doc.fr/wiki/normes-protocoles https://opentx-doc.fr/wiki/normes-protocoles Thu, 07 Feb 2019 17:10:27 +0100