Einstellungen 16CH SBUS zu PWM Decoder

fa223

Erfahrener Benutzer
#1
Hallo,

wie im Titel beschrieben, geht es um den „16CH SBUS TO PWM DECODER“. (oder alternativ auch hier)

Die Idee:
Nachdem ich für ein Modell mehr als 8 Kanäle benötige und damit der vorhande X8R bzw. R-X8R zu wenig Anschlüsse hat und zwei zu groß sind, kam ich auf die Idee, einen R-XSR zusammen mit einem 16CH-Decoder zu verwenden.

Vorarbeit:
Der R-XSR hat die neueste Firmware (LBT, Vers.171103) drauf, bindet mit der X9D+ problemlos und liefert z. B. die RSSI-Werte als Telemetriedaten.
Zu dem „16CH SBUS TO PWM DECODER“ gabs hier schon mal eine Produktvorstellung. Auch der Decoder arbeitet an einem X4R problemlos. An SBUS angesteckt, können über die Ausgänge des Decoders Servos bewegt werden.

Problem:
Nun zu meinem „Problem“. Verbinde ich den R-XSR mit dem Decoder, leuchten beide jeweils grün (R-XSR auch blau, weil auf SBUS eingestellt). Aber an den Ausgängen des Decoders kommt offenbar kein Signal für die Servos.
Nachdem offenbar beide Einzelteile funktionieren, gehe ich davon aus, dass es an irgendeiner Einstellung hapert. Am Sender (X9D+ mit V2.2.1, LBT) fällt mir da nur die Einstellung „internes HF-Modul“ - „FrSky XJT (D16)“ > „CH1“ bis „16“ ein. Ich hatte da auch schon bis „8“ stehen, ohne Änderung.

Sehe ich den Wald vor lauter Bäumen nicht? Momentan bin ich etwas ratlos. :???:

Auf der Seite von RC-Terminal (siehe Link oben) gibt es eine Software mit der man die Zuordnung der Kanäle des Decoders ändern könnte (was ja in meinem Fall eigentlich nicht notwendig ist). Mit dem STK kann man den Decoder nicht ansprechen, was bräuchte man da für einen Verbindungsstecker?

Grüße,
Klaus
 

r41065

Erfahrener Benutzer
#2
Mess mal bitte mit einem Oszilloskope den Signalpegel vom SBus des R-XSR:

SBUS-Ausgang der X4/6/8R Empfänger ist 3.3V

SBUS-Ausgang der RB10 ist jedoch nur 2.8V.

Ich habe auch einen Sbus Konverter ( RMilec) der mindestens 3V Signalpegel benötigt und an den Empfängern direkt einwandfrei funktioniert, an der RB10 jedoch nichts ausgibt.

Ralf
 
Zuletzt bearbeitet:
#3
Guck sicherheitshalber nochmal auf die Pinbelegung des R-XSR, die ist leicht unlogisch, finde ich:

GND
5V
SPort
SBus out
SBus in
 

fa223

Erfahrener Benutzer
#4
Guck sicherheitshalber nochmal auf die Pinbelegung des R-XSR, die ist leicht unlogisch, finde ich:

SPort
SBus out
Ohhhhhh, ist das peinlich! :eek:
Ich habe das gestern ein paar mal kontrolliert, aber genau das verwechselt!
Das werde ich heute abend nochmal ändern und gebe dann Bescheid.

DANKE Carbonator!

Danke auch Ralf, für deine Antwort. Das was du schreibst ist sehr interessant. Dass der Decoder da so empfindlich reagiert, hätte ich nicht gedacht. Werde die Signalspannung messen, was beim R-XSR raus kommt.

Grüße,
Klaus
 

fa223

Erfahrener Benutzer
#6
CARBONATOR DU BIST MEIN HELD DES TAGES! :D :D
Es ist unglaublich, welche Resultate erzielt werden können, wenn man statt des S.Ports den SBUS verwendet. :p

Das würde mir -hüstel- nie -hüstel- passieren :D :D
Hmm, das zerknirscht mich um so mehr, dass nur mir sowas passiert... :cool:
Dennoch, ohne deinen dezenten Hinweis würde ich vermutlich am nächsten Wochenende immer noch nach möglichen Fehlern suchen.

Wünsche allseits einen schönen Abend,
Klaus.
 
#7
Hallo,

wie im Titel beschrieben, geht es um den „16CH SBUS TO PWM DECODER“. (oder alternativ auch hier)

Die Idee:
Nachdem ich für ein Modell mehr als 8 Kanäle benötige und damit der vorhande X8R bzw. R-X8R zu wenig Anschlüsse hat und zwei zu groß sind, kam ich auf die Idee, einen R-XSR zusammen mit einem 16CH-Decoder zu verwenden.

Vorarbeit:
Der R-XSR hat die neueste Firmware (LBT, Vers.171103) drauf, bindet mit der X9D+ problemlos und liefert z. B. die RSSI-Werte als Telemetriedaten.
Zu dem „16CH SBUS TO PWM DECODER“ gabs hier schon mal eine Produktvorstellung. Auch der Decoder arbeitet an einem X4R problemlos. An SBUS angesteckt, können über die Ausgänge des Decoders Servos bewegt werden.

Problem:
Nun zu meinem „Problem“. Verbinde ich den R-XSR mit dem Decoder, leuchten beide jeweils grün (R-XSR auch blau, weil auf SBUS eingestellt). Aber an den Ausgängen des Decoders kommt offenbar kein Signal für die Servos.
Nachdem offenbar beide Einzelteile funktionieren, gehe ich davon aus, dass es an irgendeiner Einstellung hapert. Am Sender (X9D+ mit V2.2.1, LBT) fällt mir da nur die Einstellung „internes HF-Modul“ - „FrSky XJT (D16)“ > „CH1“ bis „16“ ein. Ich hatte da auch schon bis „8“ stehen, ohne Änderung.

Sehe ich den Wald vor lauter Bäumen nicht? Momentan bin ich etwas ratlos. :???:

Auf der Seite von RC-Terminal (siehe Link oben) gibt es eine Software mit der man die Zuordnung der Kanäle des Decoders ändern könnte (was ja in meinem Fall eigentlich nicht notwendig ist). Mit dem STK kann man den Decoder nicht ansprechen, was bräuchte man da für einen Verbindungsstecker?

Grüße,
Klaus
Hallo Klaus,

schau mal banggod, da ist er biliger und da gibt es eine Anleitung.

Gruß
Elmar
 

kreidler

Erfahrener Benutzer
#8
Der Decoder ist bei BG zweimal im Angebot. Einmal mit dem Download-Link wie bei rc-terminal.de für das Config-Programm in Englisch. Eine Anleitung dazu habe ich beim Chinesen noch nicht gesehen.

Ich habe den Decoder im Original ein Arduino mal ein wenig umprogrammiert, so dass man auch Relais oder sonstige Sachen, die schwarz/weiß brauchen ansteuern kann. Leider habe ich noch kein Video gemacht (kommt diese Woche) und auch den China-Klon noch nicht zum Arbeiten mit der neuen Firmware überreden können:confused:. Ansonsten hätte ich das Ganze auch schon mal hier vorgestellt. Es gibt auch eine deutsche Beschreibung:). Wer also Lust auf ein wenig löten hat, kann den Decoder auch für 5€ selber bauen.

Das Projekt ist hier: https://github.com/kreidler/SBus_Decoder

Gruß Matthias
 
Erhaltene "Gefällt mir": Bussard

fa223

Erfahrener Benutzer
#9
Hallo

@ Elmar, ganz oben im Eingangspost (...alternativ auch hier) hatte ich den Link zum Angebot des fernöstlichen Händlers bereits angegeben. Aber eine Beschreibung habe ich bisher auf dessen Seite nicht gefunden. Vielleicht kannst du den Link zur Beschreibung posten?

@ kreidler: Dein Projekt finde ich sehr spannend! Hätte ich das eher erfahren, hätte ich drauf gewartet. Nimmst du für die Verbindung USB > SBUS so ein Teil? Ist das dann selbsterklärend, welche der Pins die Signalleitung ist?

Grüße,
Klaus
 

kreidler

Erfahrener Benutzer
#10
@fa223: Jupp, so ein Konverter ist es. Nur halt in einfacher Ausführung als sog. FTDI-Adapter in CN für weniger als 2€ oder bei ebay und amazon ab 3€ erhältlich.

Pinbelegung ist im China-Prog als auch in meiner Abwandlung auf der linken Seite dauerhaft eingeblendet. In dem Projekt habe ich auch Bild dazu. Pin PC_EN muss auf GND gelegt werden um in den Konfiguriermodus zu kommen (Lila Kabel bei mir). Rx und Tx Kabel nach "Gefühl" da manchmal die Beschriftungen auf den Adaptern nicht stimmen. Als letztes Vcc und GND, damit der Decoder gleich im Konfig-Modus startet. Es ist egal, ob 3V3 oder 5V angeschlossen werden. Der Decoder ist abgesichert. Danach einfach auf "Read" klicken. Falls das Programm hängt, Kabel tauschen:). Bei der Selbstbaulösung muss noch die Sbus-Leitung gekappt werden (JP von Inverter auf Config Mode).

Gruß Matthias
 
#11
Der Decoder ist bei BG zweimal im Angebot. Einmal mit dem Download-Link wie bei rc-terminal.de für das Config-Programm in Englisch. Eine Anleitung dazu habe ich beim Chinesen noch nicht gesehen.

Genau diesen Download Link meinte ich, mit disem Programm die Einstellungen des Decoder Kontrollieren.

Und die Kanäle die nicht Gebraucht werden Ausschalten, mit den Zeiten der Benutzten Kanäle mal Ausprobieren was der Empfänger braucht.
Die Werkeinstellung ist 20my, Versuch mal zuerst 27my, dann wenn es immer noch nicht Funktioniert 9my wenn das auch nicht Funktioniert
liegt der Fehler nicht am Decoder.

Gruß
Elmar
 

kreidler

Erfahrener Benutzer
#12
Ich glaube zwar, dass fa223's Problem gelöst ist: Es war Anschlusskabelsalat;) aber

Und die Kanäle die nicht Gebraucht werden Ausschalten, mit den Zeiten der Benutzten Kanäle mal Ausprobieren was der Empfänger braucht. Die Werkeinstellung ist 20my, Versuch mal zuerst 27my, dann wenn es immer noch nicht Funktioniert 9my wenn das auch nicht Funktioniert liegt der Fehler nicht am Decoder.
Der Empfänger sendet 'nur' den seriellen SBus-Datenstrom nach der entsprechenden Spezifikation (100000 Baud / 25 Byte / 16+2 Kanäle) zum Decoder. Der Decoder nimmt das Signal auf und wandelt es je nach Frame-Einstellung in entsprechend getaktete PWM-Signale um. Eine Änderung der Frame-Einstellung hilft nicht, um zu sehen, was der Empfänger "braucht", sondern nur, wenn Du prüfen möchtest, was deine Servos "vertragen".
 

fa223

Erfahrener Benutzer
#13
Ja, genau. Mein Fehler war das Vertauschen des S.Port-Pins mit dem SBUS-Pin. Mit einem neuen "Y-Kabel" (natürlich nur "+" und "-") geht nun beides und damit auch der Decoder.

So wie ich das verstanden habe, ist die Standardeinstellung des Decoders 20 ms, womit eigentlich auch alle analogen Servos zurecht kommen sollten? Werde aber am Wochenende nochmal probieren, ob ich zwischen dem PC-Programm und dem Decoder einen Kontakt herstellen kann.

@ kreidler: Werden eigentlich beim Decoder die Signale alle gleichzeitig auf alle 16 Kanäle verteilt oder erfolgt das innerhalb der Framezeit gestaffelt? Wenn alle Servos gleichzeitg angesteuert werden und auch mehrere gleichzeitig arbeiten sollen, könnte das zum Problem werden, oder? Andererseits wünscht man sich ja gerade z. B. bei der Taumelscheibenansteuerung von Helis, dass zwischen den Servos kein Delay ist...?

Grüße,
Klaus
 

kreidler

Erfahrener Benutzer
#14
Es werden natürlich alle Signale "gleichzeitig" verteilt;). D.h. nach Erhalt eines kompletten SBus-Datensatzes wird aktualisiert. Die Angelegenheit dauert nur ein "paar" Takte eines Arduino und wird nacheinander für Bank 1 (Steckplätze 1-8) und dann Bank 2 (Steckplätze 9-16) ausgeführt.

Ein SBus-Satz kommt laut den Infos, die mir vorliegen, meist mit 14/15ms bzw. 6.3/7ms Abstand. Das PWM-Signal muss sich aber an die Frame-Taktzeiten halten, da es sonst diese interessanten Phänomene wie z.B. bei der Ansteuerung von älteren Servos mit kleinen Frames geben kann. Der Decoder kann übrigends minimal nur 16ms (= 7 Kanäle).

Wenn Du das jetzt anders herum berechnest, ergibt sich theoretisch irgendwann immer ein Informationsverlust von ein bis zwei SBus-Datensätzen am PWM-Ausgang. Ich kann aber nicht wirklich sagen, ob dem so ist, da ich nicht nachmessen kann. Wir reden hier aber immer noch über eine Informationsänderung von maximal alle 0.02 Sekunden.

Gruß Matthias
 
Zuletzt bearbeitet:

fa223

Erfahrener Benutzer
#15
Hallo Matthias,

DANKE für die Erklärung.
Das heißt aber dann doch auch (soweit ich das Thema mit meinem eingeschränkten Verständnis für Elektronik verstehe), dass es letztlich ziemlich egal ist, ob im schlimmsten Fall alle Servos gleichzeitig oder nacheinander den Befehl zur Bewegung bekommen, weil die Trägheit der Motoren eh deutlich größer ist, als die Frames. Oder sehe ich das falsch?
Hintergrund der Frage ist, dass auf Seite 586 von Helles Anleitung (zum FrSky PWM-Decoder) steht "alle 4 Kanäle kommen gleichzeitig somit Stromspitzen". Das ließe sich aber auch nicht vermeiden, wenn die Signale "nacheinander" kämen?

Grüße,
Klaus
 

bendh

Erfahrener Benutzer
#16
wenn die Servoimpulse alle gleichzeitig ausgegeben werden, laufen auch alle Servos gleichzeitig an und die eine entstehende Stromspitze ist höher als wenn die Servos nacheinander anlaufen und sich die Stromspitzen auf mehrere kleine verteilen.
Um ein zu knapp bemessenes BEC zu überlasten, kann das entscheidend sein, auch wenn es sich im ms Bereich abspielt. Einem Empfängerakku ist das egal.
 

kreidler

Erfahrener Benutzer
#17
@fa223: Bitte das Ganze zitieren;):
Nur für Digitalservos, da 9ms Framezeit, alle 4 Kanäle kommen gleichzeitig somit Stromspitzen!
Die Angabe bezieht sich nur auf den 4 Kanal FrSky SBUS to PWM Decoder.
bendh Post passt schon. Dazu kommt, dass das Teil anscheinend jeden empfangenen SBus-Datensatz "sofort" auf alle 4 Servos "verteilt". Bei dem DIY Decoder gilt aber die eingestelle Framerate. Somit ist die Spannungsversorgung weniger anfällig (aufgrund eigener Erfahrungen: Trotzdem Elko auch bei Akkubetrieb:)).

Ich hoffe, dass ich am Wochenende dazu komme einen neuen Thread aufzumachen:eek:.

Gruß Matthias
 

fa223

Erfahrener Benutzer
#18
Danke für eure Klarstellung.

@fa223: Bitte das Ganze zitieren;):
Das sind doch zwei getrennte Themen, oder? :confused:

1) Einige, insbesonders ältere Analogservos haben Probleme mit den 9 ms. Sei es dass sie gar nicht arbeiten, nicht korrekt arbeiten oder nach kürzerer Zeit den Dienst quittieren. Mit den 18 ms (oder 20 ms oder 22 ms ... je nach Hersteller) bewegt man sich im Bereich der 50 Hz, für die auch die alten Analogservos ausgelegt wurden.
2) Dass die Signale gleichzeitig kommen und dadurch Stromspitzen entstehen, hat ja grundsätzlich mit der Framezeit nichts zu tun? Das Problem tritt sowohl bei Digital-, als auch bei Analogservos auf.

Grüße,
Klaus
 

kreidler

Erfahrener Benutzer
#19
1) Einige, insbesonders ältere Analogservos haben Probleme mit den 9 ms. Sei es dass sie gar nicht arbeiten, nicht korrekt arbeiten oder nach kürzerer Zeit den Dienst quittieren. Mit den 18 ms (oder 20 ms oder 22 ms ... je nach Hersteller) bewegt man sich im Bereich der 50 Hz, für die auch die alten Analogservos ausgelegt wurden.
Korrekt:)

2) Dass die Signale gleichzeitig kommen und dadurch Stromspitzen entstehen, hat ja grundsätzlich mit der Framezeit nichts zu tun? Das Problem tritt sowohl bei Digital-, als auch bei Analogservos auf.
Klares Jein.
Ja: Es ist egal, ob A oder D-Servos. (ich hatte nur komplett zititert:D)
Nein: Dieser FrSky-Adapter im speziellen soll wohl alle 9ms (Framezeit) alle Servos ansteuern. Ich hatte schon einiges gelesen, mir ist aber nicht klar, woher diieser Wert stammt, da Futaba empfängerintern mit 7ms ("Highspeed Mode") bzw. 14ms arbeitet und diese Taktung auf den SBus weitergibt. Technisch sind es für den Datensatz 25byte à 12bit bei 100kBaud = 3ms plus eine Pause mit entsprechender Länge. Die 9ms "riechen" sehr nach einem 4Kanal-PxM (ohne Sync) auch wenn das im Gegensatz zu allem steht, was ich gelesen hatte. Vielleicht hatte ja schon jemand das Teil an einem Mehrkanal-Oszi hängen und kann mehr dazu sagen.

Gruß Matthias
 

fa223

Erfahrener Benutzer
#20
... Dieser FrSky-Adapter im speziellen soll wohl alle 9ms (Framezeit) alle Servos ansteuern.
(Wieder nicht komplett zitiert...):D

Nun, interessant wäre das auf alle Fälle.
Denn während bei dem damals "brandneuen" G-RX8 Analogservos einfach nicht mochten oder brummten (weil der ab Werk auf 9 ms eingestellt war), funktionieren die gleichen analogen Servos an dem FrSky-Decoder einwandfrei...

Grüße,
Klaus
 
RCLogger

FPV1

Banggood

Banggood

Oben