[Important] info concernant le Décodeur SBus/CPPM vers PWM

C'est exactement ce problème qui a été corrigé. Tu peux facilement planté un modèle avec ce genre de "blagouille"...

ça n'arrivait que lorsque l'on forçait les servo a plus que 100%

djsyl a écrit:ça n'arrivait que lorsque l'on forfait les servo a plus que 100%

Les servos déclaraient alors forfait....

non ils repassent juste a l'autre extrémité

allez bon je corrige


bon je confirme que le timing est toujours a 9ms même après mise a jour du firmware !

C'est bien d'avoir vérifié.

Genial merci pour cette info.
Ca fais plusieurs mois que je me demandais comment resoudre un pb de pan-tilt avec pour HD19 qui faisait un jitter max et s'embalais.
J'utilise un X8R, en D16, mode binding '4' (9-16).

Je pense avoir trouvé grace a toi LapinFou !  

Je vais tester avec d'autres servo dessus et donnerais la suite ici.

> pour info les servo testé et qui 'grinch' sont :
- TGY-9025MG
- servo d'origine HD19 Boscam
-

Salut à tous,
je me permets de revenir sur ce sujet car le dernier message date de 2016 et peut-être que certaines choses ont évoluées depuis...
Voici ce que je désire faire: J'ai un ancien planeur (donc ancien servos analogiques) qui demande 10 voies. Mon souhait est d'utiliser un récepteur G-RX8 avec en plus un décodeur S-BUS PWM 4 voies qui me permettrait d'avoir 12 voies au maximum. J'ai lu dans la doc du G-RX8 que je peux le passer en mode FS. Si je le passe ce récepteur en mode FS pour mes servos analogiques et que je branche mon décodeur avec 4 voies supplémentaires sur le SBUS IN de ce dernier, est-ce que ces 4 voies supplémentaires seront aussi en mode FS ?
Merci beaucoup pour votre aide! :-)

Alors je vais compléter ma propre question et y répondre si ça peut aider un jour qqun.
J'ai donc connecté mon décodeur Sbus PWM de 4 voies sur le récepteur G-RX8 ce qui me donne 12 voies. Dans mon cas, je l'ai mis en mode FS en raison de mes anciens servos. Mon décodeur de 4 voies est a brancher bien entendu sur le SBUS OUT (et non le SBUS IN). J'ai tenté de connecter un vieux servo sur les 4 voies supplémentaires qui sont en SBUS et il chauffe malgré que le récepteur soit en FS. C'est peut-être logique pour les connaisseurs :-).

Je voudrais aussi utiliser ce décodeur 4 voies derrière un S8R pour exploiter les voies 13 à 16 avec des servos analogiques (Hitec HS82 MG).
J'ai toutefois quelques interrogations :

1) Compte tenu des infos fournies par LapinFou, je voudrais savoir si c'est confirmé que sur un SBus d'un récepteur EU-LBT la trame PWM est bien à 15ms. Si c'est confirmé, quelqu'un a-t-il pu constater un dysfonctionnement des servos car j'avoue qu'entre 15 et 18 ms je ne sais pas si le servo y voit vraiment une différence. C'est vrai qu'avec 9ms de période, c'est du simple au double. Je comprend que le servo "grogne".

2) est-il possible (avec un SCC) d'affecter aux 4 voies de ce décodeur les valeurs 13 à 16. Je suppose que de construction ce sont les voies 1 à 4 qui sont affectées.

Merci à ceux qui ont ces infos de m'aiguiller sur mon choix car mis à part ce décodeur ou mettre 4 SD1 (solution + chère), je n'ai pas vraiment trouvé d'autre solution outre quelques produits chinois qui ne m'inspirent pas réellement confiance (pas beaucoup d'infos sur la période de la trame, du jitter..).

Guy

1. Si ton servo analogique (les numérique ne sont pas concernés) grogne beaucoup et chauffe, alors c'est pas bon. Pour les histoires de trames, j'avais lu cela sur le forum FrSky. Maintenant que j'ai un petit analyseur logique, je vais vérifier cela moi-même.

2. Bien sûr ! Le SCC est fait pour cela.

@LF
Je ne sais pas encore s'il va grogner ou chauffer car pour l'instant j'hésite à acheter ce décodeur.

Ce serait sympa si tu pouvais tester la trame avec ton analyseur (veinard ! j'aurais bien voulu en avoir un depuis longtemps mais je fais avec mon oscillo) pour confirmer cette histoire de 15ms.

Si en plus tu avais un décodeur de ce type, et si tu pouvais me dire si un servo analogique se comporte normalement, ce serait le Top !

Si tu n'en a pas et que tu confirmes la trame à 15ms, je pense que j'en achèterai un et ferais les essais. Bien sûr je vous communiquerais les résultats sur le forum.

Guy

Ce décodeur sort a la vitesse de celle du SBUS. Si un SxR c'est toute les 9ms, donc ils sort toute les 9ms.

Après, ca n'est ni bon ni mauvais, ca demande juste des servos qui acceptent ce type de signal (ca fait très qu'on a du PWM rapide pour les hélicos par exemple). Il y a des servos analogique que ca ne gène pas du tout, d'autres qui aime moins, ca dépend du modèle. M'enfin faudrais peut être penser a passer aux servos numériques !!!!

3djc

Faut-il alors laisser l'info sur le site documentaire ?

Breizh29 a écrit:Faut-il alors laisser l'info sur le site documentaire ?

Je ne comprend pas ce que tu veux dire.
L'info est tout à fait pertinente, si tu balance du PWM à 9ms sur un vieux servo analogique, il ne va pas résister longtemps.
Pour la différence de rafraichissement du SBus entre la norme FCC et EU-LBT, je vais essayer de regarder cela demain.

C'est bien de cette dernière info dont je parlais. Si sa trame SBus est tjs à 9ms, alors il ne faut pas parler de 15ms

Guy

OK. C'est le truc que je dois vérifier, car j'avais lu sur le forum FrSky que les RXs tournant avec un firmware EU-LBT envoyait une trame toute les 15ms au lieu de 9ms.
Je vais vérifier cela moi-même et mettre à jour l'article Wiki en conséquence.

Mystère résolu !!
L'article Wiki "Décodeur SBus vers PWM" est maintenant à jour (capture de l’analyseur logique inclus).
Que ce soit FCC ou LBT, le S.Bus fonctionne toujours à 9ms. Donc le décodeur fonctionne également à 9ms quelque soit la norme de votre radio. Les vieux servos analogiques savent à quoi s'en tenir.

Je dirais que cette histoire de 15ms doit dater de l'époque du 1ère firmware EU tout foireux.

Merci pour tes recherches.
J'avoue que je m'y attendais un peu car je ne voyais pas pourquoi ils auraient augmenté la trame PWM sachant que les servos SBus sont par nature numériques et que la trame de 9ms leur permet une réactivité plus grande.

Je vais quand même utiliser ce décodeur car pour 2 voies qui rentrent sur un micro-contrôleur de ma réalisation je vais pouvoir prendre en compte ces 9ms et pour les deux autres voies qui vont vers des servos analogiques, j'envisage de me faire un montage pour diviser le trame par 2 (à l'aide d'une simple bascule D et d'un circuit NAND).

Guy

@LapinFou
Merci pour tes captures d'écran. C'est très clair maintenant et dans le fond, assez logique.

Dommage que FrSky n'a pas développé un module avec 4 SD1 sur un même circuit, car cela aurait eu l'avantage de pouvoir être configuré avec le script Lua et la sortie aurait été à 18ms.
On peut aussi soi-même assembler 4 SD1 mais cela revient à nettement + cher.

Sujet clos pour moi.
A+
Guy

Le SD1 fonctionne peut-être de la même manière que le décodeur SBus ?!?
A vérifier.

Non, d'après la doc FrSky, il est fait pour cela.

La trame PWM est bien notée 18ms/55Hz et il est précisé que le changement de la voie de sortie peut se faire de plusieurs manières dont une à l'aide d'un script Lua.

Guy

Super. C'est bon à savoir.

@ LapinFou

Bonjour Seb

Je m’intéresse au décodeur SBus vers PWM pour l'intégrer dans un montage électronique de ma conception.
J'ai regardé tes chronogrammes réalisés à partir de ton analyseur de signaux et une question me taraude l'esprit (un peu pompeux non ?).

Tu dis dans un article consacré aux sorties d'un Rx que les impulsions PWM arrivent les unes après les autres et ton analyseur le montre bien.
Mais comment font-ils pour faire tenir 16 voies (max 2ms) dans une trame de 18 ms ? Est-ce qu'ils ne transmettent pas les 8 premières voies dans une première trame et les 8 autres dans la suivante ?
Mais alors qu'en est-il en en mode HS (9ms) ou en sortie de décodeur SBus vers PWM ? les impulsions ne seraient-elles pas sorties en simultané ?

Je ne sais pas si tu as pu creuser la question mais si oui pourrais-tu me fournir quelques infos.
Merci

Guy

Très bonne question. Mais je n'ai pas creusé la question à fond.

Attention a ne pas confondre la trame entre le module RF et le RX, et la trame PWM sortant du RX. Elles sont évidemment synchronisées du certaine manière, mais ce n'est pas le même type de transmission.

Ce que je sais:
- En mode 8 voies classique en D16, si tu binds avec les voie de 01 à 08, le refresh entre la radio et le RX s'effectue toutes les 9ms par paquet de 8 voies. Après le RX met 18ms pour générer les 8 trames PWM. En mode "9ms" comme dispo sur certain RX HS, je ne sais pas ce que cela donne. Le jour où j'aurais un de ces RXs, je pourrais faire des captures. Je suppose qu'au lieu de générer les 8 sorties de façon séquentielle, le RX doit mettre à jour 2 voies en même temps. Ainsi, cela tient en 9ms au lieu de 18ms.
- En mode 16 voies en D16, si tu binds avec les voie de 01 à 16, le refresh entre la radio et le RX s'effectue toutes les 9ms toujours pas paquet de 8 voies. Donc, un coup c'est les voies 01-08 et un coup, c'est les voies 09-16. Ceci dit le module RF (c'est la tambouille à FrSky) est un peu plus intelligent que cela. Donc, si les voies 09-16 n'ont pas changé, le module RF peut envoyer plusieurs trames de 01-08 d'affiler et envoyer une trame 09-16 s'il y a eu un changement. Le RX fait un "Hold" sur les voies tant qu'elles ne sont pas rafraichies.

C'est pour cela que lorsque tu fais le bind, suivant le nombre de voies choisies, OpenTX affiche 9ms ou 18ms. Mais là on parle du taux de rafraichissement entre le module RF et le RX. Cela n'impacte pas les sorties du RX, car c'est le RX qui choisit comment traiter ces infos.

J'ai expliqué cela (avec moins de détails techniques) ici: https://opentx-doc.fr/wiki/d8-vs-d16-vs-r9m-vs-lr12

J'espère avoir éclaire ta lanterne.

Petite anecdote: certaine marque ont dit que pour les hélicos, c'était important que les 3 voies du plateau cyclique bougent en même temps (et pas séquentiellement) pour améliorer la qualité de vol des hélico. Donc, je crois, de mémoire, que sur ces RXS, 4 voies étaient rafraichies en même temps. D'autre on dit que ce n'était pas bien, car cela faisait un gros appel de courant...
Dans tous les cas le problème ne se pose plus avec les hélico FBL. C'est le module FBL qui gère cela comme une grand.

Merci Seb.
Effectivement ce n'est pas toujours très clair et je n'ai pas trouvé beaucoup d'infos là-dessus autres que les tiennes.

Mon soucis est de pouvoir utiliser un décodeur SBus vers PWM avec des servos analogiques et donc d'éviter ce rafraichissement à 9ms.
Je vais m'acheter un décodeur et voir à l'oscillo comment sortent les impulsions sur chaque voie. J'aurais aimé avoir un analyseur de signaux, mais je n'ai qu'un oscillo monotrace.
Je communiquerai sur mes résultats si j'arrive à trouver quelque chose.

Encore merci pour tes infos

Guy