J-Log.eu - Forum

Hallo,
eigentlich hab ich nicht unbedingt ein Problem mit dem S32 aber vielleicht hat ja trotzdem jemand eine Idee:

Habe ein S32 am Kosmik hängen und per X-Bus am AR8010T. Der Emfänger ist per SRXL am Spirit angeschlossen. S32 ist neueste Firmware und Bootloader (1.9) und Kosmik ebenso (4.10). -> Wenn ich alles ganz normal verbunden habe und den Akku anstecke dann kommen keine Daten vom S32 im Sender an, das S32 funktioniert aber und loggt auf die SD-Karte und auch alles andere funktioniert normal. Stecke ich das Spirit nun ab dann funktioniert die Telemetrie so wie sie soll, auch wenn ich danach das Spirit wieder anstecke läuft die Telemetrie weiterhin, also eigentlich alles so wie es soll. Kann mir grad keinen Reim drauf machen.

SPEKTRUM's SRXL ist ja eigentlich kein SRXL. Sie haben sich den Namen "SRXL" unter den Nagel gerissen, machten es unabgesprochen bidirektional (k.A., ob auch bei diesem Empfänger), und sie senden die Kanaldaten nicht als SRXL, sondern als Remote Receiver, als deren Sat Protokoll.
http://j-log.eu/s32/s32-de/telemetrie-spektrum-srxl
http://j-log.eu/s32/s32-de/telemetrie-spektrum

Das schnuppert einfach nach einem Bug in der Firmware des Empfängers. Das Spirit hat vielleicht einen Pullup auf der Signalleitung, und das hält den Rx davon ab, den X-Bus zu bedienen, solange er nicht mal Low sah auf seiner Sendeleitung. Sehr komisch.., sehr typisch SPEKTRUM...

Mal einen Serienwiderstand von 1..5kOhm in die Signalleitung von SRXL, einfach mal probieren.

Wenn dieser Rx auch deren bidirektionales "SRXL" bedienen sollte wie der 4649T, dann könntest Du alternativ auf X-Bus pfeifen, S32 via SRXL Telemetrie machen lassen.
Das Spirit hinge an S32, bekommt den unidirektionalen Teil des SRXL (Kanaldaten), - oder man hängt es parallel mit S32 an den SRXL Port des Rx, sofern das Spirit keine Krise kriegt durch die in der Rückrichtung gesendeten Daten, wenn es die sieht. Das müsste man probieren. 3Digi kann es ab, beim Spirit weiß ich es nicht.
Allerdings, wie gesagt, keine Ahnung, ob dieses sogenannte "SRXL" auch bidirektional ist wie beim 4649T. Theoretisch dächte ich das nicht. Aber bei SPEKTRUM kann man sich nie sicher sein...

_________________
Tom

der 8010t ist Baugleich zum 9030t
ich hab beide im Einsatz und funktioniert bestens (den 9030t von mir hattest du zum testen von Markus damals)

mfg Sascha

Danke schon mal für die Tips - eigentlich sollte der 8010T nicht bidirektional können aber man weiß ja wirklich nie bei Spektrum...

Dachte eigentlich auch es liegt evtl. am SRXL von Spektrum aber ich kann das auch folgendermaßen produzieren:
SRXL-Kabel abstecken und Spirit vom Slaveport des Kosmik mit ausgepinnter Signalleitung versorgen, also Quasi nur Strom für´s Spirit vom ESC sonst keine Verbindung zum Empfänger. -> Selbes Fehlerbild. Versorge ich das Spirit beim Starten gar nicht mit Strom sondern erst hinterher -> kein Problem. Ist es möglich das ich irgendwo eine Masseschleife über das BEC habe wenn das Spirit läuft? Komisch komisch...

Weiter auf Fehlersuche - könnte es auch an der Initalisierung des Kosmik-BEC´s liegen?

Folgendes:
Verwende ich einen externen Versorgungsakku um das ganze System zu initalisieren funktioniert es! Am Kosmik ist dann das Pluskabel ausgepinnt so das nur Gas vom Sender kommt. Völlig egal ob ich erst den Akku an den Regler stecke und dann den Versorgungsakku an den Rest oder umgekehrt... alles OK inkl. Telemetrie

Update: Lösung gefunden (Problem versteh ich immer noch nicht ganz), hatte noch ein Optipower BEC-Guard hier liegen - einfach mal zwischen ESC und Spirit gehängt und siehe da, alles funktioniert wie es soll. Also entweder kommt der 8010T mit der Initalisierung des Kosmik BECs nicht klar, der Kosmik startet soweit ich weiß immer mit ca.5V und erst nachdem er ein Signal vom Empfänger hat erhöht er die Spannung auf den eingestellten Wert. Möglich wäre auch das die Servos Rückströme produzieren die ein Problem für den Empfänger sind....

Das ist der bekannte Design Flaw um den BEC im KOSMIK und JIVE Pro, ein klassisches Henne-Ei-Problem.
Dieser BEC muss eigentlich lastfrei starten, sonst kann Mist passieren um seine Ausgangspannung (bricht wieder, kann sogar endlos als Sägezahn schwingen).

Deshalb gaben wir dem BEC Guard eine kleine Zusatzfunktion, die bewirkt, dass der BEC verzögert die Last sieht. Das hilft hier.
Die ersten 10ms sind kritisch, obwohl erst nach 100ms der Prozessor die Sollspannung an den BEC liefert.
Dabei bläst man sich erfolglos selbst in die Segel, weil der Prozzi auch aus der BEC-Spg. versorgt wird.

Kommt ein weiterer, typischer RC-Pfusch hinzu, von SPEKTRUM: Unnötig früh startet der Rx seinen Scan nach Sensoren auf dem X-Bus. Der wird unterbrochen nach POR (Power-On-Reset), weil seine Betriebsspannung wieder einknackte.
Der BEC Guard verhindert es, weil er die Mimose die ersten 10ms vor Last beschützt.

_________________
Tom