J-Log.eu - Forum

Hallo zusammen und Danke für die Freischaltung hier!

Ich hoffe man kann mit dem Titel was anfangen, war mir nicht sicher wie ich das bezeichnen soll

Nach dem Umstieg von der Futaba T14SG auf die T18SZ, kommen die Telemetriedaten oft erst ca. 2 Minuten nach einschalten der Elektronik.

Zustand vorher:
ESC: Hobbywing 160a V4 (aktuellste Firmware Version)
T14SG-Version: 7.0
S32-Version: 1.52
Sofort nach einschalten Telemetriedaten, also alles super. Sensoren angemeldet als Roxxy.

Zustand ist:
ESC: Hobbywing 160a V4 (aktuellste Firmware Version)
T18SZ-Version: 2.1
S32-Version: 1.53 (im Zuge des Umstiegs auf 1.53 aktualisiert)

Nach einschalten erhalte ich manchmal sofort Telemetriedaten. Beim z.B. zweiten Flug, dauert es auch schon mal ca. 2 Minuten nach einschalten bis Daten angezeigt werden.
Dies passiert willkürlich, also ich kann es nicht auf die Anzahl des einschaltens der elektronik eingrenzen.
Angemeldet habe ich den S32 mit 10 Senoren wegen dem Roxxy BUG der T18SZ.
Beobachtet habe ich auch, dass die grüne LED nach einschalten manchmal direkt blinkt und manchmal erst ne Weile die blaue (springt dann irgendwann auf die grüne LED und blinkt).

Nun bin ich mir nicht sicher an was es liegen kann, am Update auf die 1.53 oder an der T18SZ.
Bei einem anderen Heli ohne S32, aber mit Futaba Sensoren, habe ich immer direkt nach einschalten die Daten auf der T18SZ.
Würde man das evtl. sehen können wenn ich eine SD-Karte in das S32 einlegen würde? Bin leider noch nicht so firm in Sachen JLog, weiß nur das es einfach klasse ist.

Danke und Beste Grüße,
Martin

Hi Martin!

"Keine Daten" heißt alles Null oder "-----"?

Wenn alles Null, dann bitte mal loggen lassen, und zwar ohne LogStop, also unabhängig von fließendem Motorstrom.

Blau ON heißt: Ich sehe keine s.bus2 Daten vom Empfänger. (Der Rx sendet erst dann Daten, wenn er 1x nach PowerUp den Sender sah.)
Die grüne muss immer blinken, heißt, ich habe einen Datenstrom vom ESC.

_________________
Tom

Hi,

ja genau, wenn es dauert, dann "----".
Hab den Empfänger (ist ein R7008SB) einfach an der T18SZ neu verlinkt, mehr kann man glaube ich ja nicht machen wenn man neue Funke verwedet.

Also müsste ich dann eine SD in S32 einlegen und mit dem Terminal einstellen zum Dauerlog?

So ich hab mal loggen lassen. Wohin soll ich die Logs schicken?

Dann ist mir noch etwas aufgefallen:
Ich habe einen 4700µF Kondensator zusätzlich am FBL dran, diesen hab ich nun mal abgesteckt und hatte plötzlich nach jedem starten der Elektronik die Daten auf dem Schirm. Bei der T14SG war der Kondensator aber auch schon immer im Heli angesteckt. Könnte es sein, dass es am Kondensator liegt und der S32 nicht komplett runterfahren kann wenn dieser angesteckt ist. Würde evtl. erklären warum es beim ersten Start immer funktioniert (Entladung Kondensator). Nur warum es dann bei der T14SG funktionierte verwundert mich dann.

Log einfach hier anhängen. Aber Du hast es ja gefunden.

Ja, könnte sein. So ein ARM (Microcontroller) funktioniert noch bei 1.8V einwandfrei.
Habe aber eher den Eindruck, als ob die (Rest-)Spannung vom Elko irgendwie den Signalpegel verschiebt, - via GND.

Wo genau hängt das Ding, wo an Plus connected?

_________________
Tom

Hi Tom,

also der Kondensator hängt am BeastX am AUX Eingang. BEC-Spannung ist auf 8 Volt eingestellt.
Was ich halt nur merkwürdig finde ist, dass es bei der T14 immer funktioniert hat. Da war der Elko ja auch schon dran.

In den Empfänger geht das BEC von der ESC und in das Beast ein Optiguard, Empfänger ist mit dem Beast via SBUS verbunden.

Tja... Den UltraGuard sieht man, natürlich, - Log Channel 2 "Vs", - S32 Betriebsspannung via Port4, siehe Attachment.

Das mit dem Elko verstehe ich nicht, weil mir "AUX" am Beast nichts sagt.

Was natürlich passieren kann:
Eine Elektronik, wie so ein komplexes Ding von Millionen Transistoren wie ein ARM, ist spannungslos eine "elektrische Kartoffel", - ein undefininierter, nichtlinerarer Widerstand.
Eine Spannung an irgendeinem Pin kann somit durch ihn hindurch auf den Ausgang des ebenfalls noch toten internen Spannungsreglers kriechen, die C's an dessen Ausgang aufladen. (Das ist ein Buck, ein "SBEC", wie der Volksmund diesen erfundenen Begriff so gern annahm.)
Das könnte nun ein sauberes Power-On-Reset (POR) verhindern, wenn dann Betriebsspannung kommt an den Eingang des Regulators, damit von dessen Ausgang an den Prozessor.
Wir haben verschiedene Maßnahmen dagegen bereits implementiert. Elektrisch so was komplett tot zu machen, geht nicht. Es gibt aber Maßnahmen im Bootloader, die bewirken aber nur wenige Sekunden evtl. Verzögerung.

Woher und in welches Pin diese Spannung im Aus-Zustand in S32 gelangt, das kann ich mir auf Basis Deines Inputs noch nicht vorstellen.

Der UG erscheint zunächst für 5 Sekunden mit ca. 5V, sobald er was von der Quelle (BEC) sah, dann erst misst er die BEC-Spg. für sein Step-In 0.5V darunter.

_________________
Tom

Nicht, dass der Buck im S32 erst überlastet wird...

Der <+> Pin an Port 4 ist beides, Ausgang (ca. 3.2V) und Eingang (theoretisch (und praktisch getestet ) bis 4..6S).
Allerdings müsste dazu S32 via einen anderen Port Betriebsspannung bekommen. Die Log File Header und die Logs sagen aber: Nö, da kommt nur via Port 4 etwas.
Nur der USB Port wäre eine Quelle, die Big Brother nicht watcht seitens der Betriebsspannung.

_________________
Tom

Ok vielen Dank erstmal für deine Analyse und die schnellen Antworten!

Ich werd jetzt einfach mal ein paar Flüge ohne den Elko machen und dann mal andere Steckmöglichkeiten am Empfänger und Beast ausprobieren (Log kann ich ja laufen lassen).
Wobei ich den Elko wohl nicht wirklich brauche. Werde mich dann bis ende nächster Woche aber melden wie es verlaufen ist.

Also nochmals Danke

So

endlich gutes Wetter im Allgäu, so konnte ich nun endlich mal testen und kann berichten.
Ich habe nun den Elko statt am FBL, am Empfänger eingesteckt. Nun läuft alles wie es soll, Daten kommen sofort an. Ich vermute, dass der Empfänger (dort ist der JLog ja auch angeschlossen) den Elko einfach schneller leer saugt und somit das s32 dann gescheit starten kann.

Grüße,
Martin