J-Log.eu - Forum

Hallo Tom,

nachträglich schönen Ostern, habe mit meinem Bericht gewartet, bis die Feieretage vorüber sind, wir alle brauchen ja immer mal wieder eine gewisse Auszeit, damit sich der Blick klärt für das wirklich Wichtige.

Leider hat sich herausgestellt, dass S32 manchmal, bei vermutlich Motor aus, einfriert und dummer weise auch damit den HoTT Daten-BUS lahm legt. Es sind dabei nur die am Empfänger extern angeschlossenen Sensoren betroffen, die Empfänger-Telemetriewerte sind davon nicht betroffen, sie kommen ja auch alle 10 ms und nicht reihum abwechselnd wie die extern angeschlossenen Sensoren. Mein Problem stellt sich genau so dar, wie hier viewtopic.php?f=31&t=908 beschrieben, nur dauert es etwas länger und ist im Trockenbetrieb so nicht nachvollziehbar. Im referenzierten Bericht wurde auch nach der BEC-Strom-Ausgabe des Jive Pro gefragt, bei mir zeigt sich auch kein BEC-Strom. BEC-Strom könnte zu niedrig sein (?), auch der Motor-Strom wird erst geschrieben und angezeigt, wenn er 1 A überschreitet. Im Fehlerfall leuchtet die orange LED konstant, nach Beschreibung ist ein konfigurierter Alarm aufgetreten, ich sehe aber keinen im Log. Die blaue/grüne LED leuchtet nicht mehr, was darauf hindeutet, dass es auf dem Datenbus keine Aktivität, ausgehend vom S32, mehr gibt. Extern:RPM wird bis auf ein paar Spikes überhaupt nicht angezeigt, obwohl die RPM-Sensor LED leuchtet wenn der Motor dreht. Alarm:SpannungBat geht von 0 auf -999, gerade entgegengesetzt dem Erreichen der SpannungBat. SpannungBEC kommt mir seltsam glatt konstant vor.

Extern angeschlossen habe ich ein GAM zur Empfänger Spannung und Strom Überwachung. An der Empfänger-Versorgung hängt aber nun mal das Modellleben, deshalb ist es mir wichtig. Weiterhin ist ein GPS angeschlossen. Das S32 stellt ein ESC im Sinne der HoTT Telemetrie dar.

S/N R2F011D6 hardware version 3.0.4
(device marked as QC and functional tests passed)
Saturday 04/15/2017 14:31:33 (mmdd20yy-24h RTC) S32T language: English
S32 (JLog3) R2prototyping You think of it, we make it. http://r2prototyping.ch http://j-log.eu
Support: http://support.r2ag.ch http://www.helifreak.com/forumdisplay.php?f=257 http://j-log.eu/forum
devID:00556609 enabling:F firmware bootloader:1.9 app:1.43 | BOR3 wu|sb|pvd|brr|VOS Vs/3/1:6.73V (3=6.73V 4=3.12V 8=0.19V)
SETUP name:"" esc:<JIVE Pro> tel:<Graupner HoTT v4> box:<none> poles:14 ratiotype:0 (ratio:1:1.0 pinion:0 maingear:0) l/s:0/0 shunt:4
Sensor Fusion HV2BEC:0/0 CVS16:0/0/0 BID:0 C200:0 Temp:0 Volt1:0 Volt2:0 Pulse1:0 Pulse2:0 RPM:R11 Pspeed:0 Gspeed:0 Aline:0/0 Morse
Alarm Thresholds cap:10 capPl:0/capPh:0 capR:0 ubat:135 ubec:1 tfet:70 tbec:0 imot:600 t1M:0/0 t2M:0/0 t3M:0/0 erpmm:0 erpmM:0 spdm:0 spdM:0
Enjoy your Hobby!

$1;1;0.00;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0
$1;1;1.89;67;0;0;0;166;0;0;0;0;0;0;0;0;0;19;0;20;0;0;0;0;0;0;0;0;0;0;0;0;0;0;-999;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0 JIVEpro fw version: 1.10

Ich habe versucht das Problem im Trockenbetrieb mit verschiedenen Konfigurationen nachzustellen. Den Ext:RPM habe ich nicht weiter beachtet und aus der Konfiguration herausgenommen und nicht mehr angesteckt. Wegen der bekannten BEC-Probleme des Jive Pro stecke ich immer zuerst einen 2S LiFe Akku an, der im Falle eines BEC-Problems die Spannungsversorgung sichert. Initiale Spannung des BEC deshalb 6,8 Volt, die im Problemfall schnell auf 6,5 Volt zurück geht und mir durch einen Alarm aus dem GAM oder Empfänger angesagt wird.

Log0006 aus dem Flugbetrieb, nach 54 Minuten und der 5.ten Motor-Laufzeit friert die Telemetrie HoTT weit ein, S32 Log stoppt, orange LED leuchtet konstant, alle anderen LEDs aus (HoTT Log nur als Bild angehängt, S32 Log als zip)
Das eigentliche Problem kann ich auf der Werkbank nicht nachvollziehen, man kann den Hauptakku abstecken und wieder anstecken, S32 loggt weiter, auch ohne blau/grüne LED. Ist Ubec-Dip konfiguriert leuchtet die orange LED konstant, wenn nicht flackert die Orange weiterhin. Als problematisch empfinde ich das einfrieren des HoTT BUS. Das S32 wird ja aus dem Kabel der HoTT-Telemetrie versorgt und das sieht man ja auch schön in wie die Spannung abfällt, wann der Hauptakku abgesteckt und angesteckt wird. Welches Signal aus dem Jive führt dazu, dass das S32 sich so verhält, ist es wieder die EMK-Bremse? Wieso kann der am S32 angeschlossene ESC das S32 so aus dem Tritt bringen? Aus dem oben referenzierten Forumseintrag hatte ich verstanden, dass alle Daten-Eingänge/Ausgänge entkoppelt sind, daraus schließe ich, dass die auf den jeweiligen Daten-Eingänge/Ausgänge werkelnden Prozesse unabhängig voneinander arbeiten. Alles deutet aus meiner Sicht wieder auf die "main-loop" hin? Als Verbindung zwischen S32 und Jive verwende ich das beiliegende Kabel ohne Modifikation.


Das Log passt nicht zu dem Angehängten S32 Log, dennoch zeigt es das Verhalten. Die Werte frieren nicht auf dem letzten Wert, so wie zu sehen ein, sondern nehmen einen Maximalwert im Wertebereich ein, diese werden aber heraus gefiltert deshalb bleibt es beim letzten gültigen Wert.

_________________
Gruß Winne

Winne, ich zieh's mir rein.

Wieso die blaue LED? Die blinkt nur für Datenbus-Aktivität, aber den verwendest Du ja nicht.

Unser Server war bis heute eh down. Der Provider mal wieder..
Rate mal, was ich Ostern machte. Nein, leider keine Zeit für RC, aber schlimmere Entwicklungssachen.

_________________
Tom

Hallo Tom,
wie Du geschrieben hattest ist Ostern dieses Jahr ausgefallen, bei mir eben auch.

Ich hoffe Du bist nicht genervt, wenn schon wieder jemand mit einer K-Kombi aufschlägt. Nicht vergessen, bei mir ist die Bremse aktiv.

PS: Randthema; Was mir bei der Datenauswertung nicht gefällt ist, dass wir immer mehrere Datensätze haben ($1; $2;...), mir persönlich ist alles auf einer Zeitachse immer lieber. Wenn es irgendwelche Zeitabhängigkeiten der verschiedenen Signale/Messwerte gibt sieht man es auf einen Blick.

_________________
Gruß Winne

Das sind wenigstens 4 Themen insgesamt. Eigentlich wollte ich heute antworten.. Sorry, ich versuche, dass morgen.
Mein Main Project steht gerade an einem Punkt, der kein Scheidepunkt werden darf. Übernächste Woche ist Messe, bis dahin muss was ticken.., sonst kacken die Investoren ab.

_________________
Tom

Hi Tom, keine Panik. Ich weiss, dass ich ganz schön viele Probleme aufgezählt habe. Bin aber der Meinung, das S32 ist so ein geiles Teil, das ist es Wert. Die Funktionalität über die vielen unterstützten ESCs und Telemetrie-Systeme ist so eine große Testmatrix, das kann kein Mensch alleine schaffen. Dann kommen ja noch die zusätzlichen Sensoren dazu, wow, das braucht seine Zeit, bis das alles zur Zufriedenheit läuft.

_________________
Gruß Winne

Hallo Tom,
Graupner hat für seine HoTT Normal-Empfänger, also ohne Gyro, die Firmware aktualisiert. Die Einstellerei über den Sender klappt jetzt verzögerungsfrei und im Log gibt es keine Werte-Ausreißer mehr. Warum schreibe ich das; In dem Flieger in dem das S32 sitzt habe ich ein LinkVario von WStech. Bei mir kamen immer noch Werte-Ausreißer von den Sensor-Modulen, GPS und GAM, die durch das LinkVario dargestellt werden. Habe dann kurzer Hand das LinkVario durch GPS-Logger2 und UniLog2 ersetzt. Mit diesen Sensor-Modulen bekomme ich Telemetrie-Daten ohne jeglichen Ausreißer.

Mit den beschriebenen Komponenten kann ich ohne Aussetzer oder einfrieren bis zu 1,5 Stunden mit dem S32 aufzeichnen. Allerdings hatte ich auch mal einen Flug ohne Fehler in dem Sender-Log aber keine Datei vom S32.

Mir war es wichtig diesen Hinweis zu geben, es kann ja sein, dass bei Datensalat auf dem "Telemetrie-BUS", alle Sensoren werden ja parallel angeschlossen, das S32 beeinflusst wird und das zu den beschriebenen Problemen führt. Der Thread, der vergleichbare Probleme für das Jeti-System beschreibt zeigt für mich auch in diese Richtung.

_________________
Gruß Winne

Winne!

Mann, hab ich ein schlechtes Gewissen, dass ich nicht gleich antwortete. Meine Analyse war bereits fertig, - jetzt kann ich mich nicht mehr erinnern, und die Daten sind auch weg (Viewer Sessions), weil mein Server ungewollt abkackte bei seinen vielen Reisen zw. DE und CH.

S32 hat damit eigentlich kein Problem. Allerdings haben die Koreaner es nie geschnallt seit 2011, was ich denen via Ralf von Graupner DE erzähle:
Sie haben kein Idle Line Protocol. Damit ist es möglich, dass ein Sensor ein Datum eines anderen Sensors (Binär!) als seine Adressierung ansieht und dazwischenballert.

Wenn S32 mal kein Log aufzeichnete, dann hatte die SD beim Start oder zwischendurch ein Problem (Wackelkontakt, Filesystem?). Dann schlägt ein Watchdog zu in der Firmware, der weiteres Benutzen der SD in dieser Session abschaltet, um die Main Loop nicht aufzuhängen.

_________________
Tom

Ich gehe davon aus, dass Du die Beeinflussung des S32 von aussen durch den Telemetrie-Anschluss meinst. OK, ich versuche das LinkVario nochmal und schaue, ob ich das Verhalten reproduzieren kann. Mit dem JLog2.6 hatte ich das beschriebene Problem in der Form nie, es wurde von Anfang an mit dem LinkVario in der identischen Sensor-Kombi benutzt.


Wenn ich den Akku anstecke, sah ich immer grüne und orangene LEDs flackern, dachte das wäre das Zeichen für Schreibaktivitäten. Wenn ich eine Teildatei gesehen hätte könnte ich Deiner Argumentation eher folgen. ChkDsk hatte ich laufen lassen, dachte die Schreibsession wäre nicht ordnungsgemäß geschlossen. Ich hatte die SD-Karte weder bewegt, noch gibt es Vibrationen oder Stöße, die sich als Wackelkontakt auswirken könnten.

_________________
Gruß Winne

S32 ist da nicht anders als JLog2.x am HoTT Tele Interface. Er reagiert nur auf die Adressen, für die er konfiguriert ist (HoTT Sensoren).
Irgendeinen Effekt per Hardwareunterschied kann man natürlich nie ganz ausschließen.

Log: Er hat keinen neuen Logfile erzeugt? Sieht man ja auch an den Timestamps der Files und am Header im Logfile wegen der RTC, die S32 hat.

"WD" == Watchdog. Sprich, wenn die orange LED blinkt, muss er eigentlich auch aufzeichnen..

_________________
Tom

Hallo Tom,

heute habe ich einen 2 Stunden Flug hingelegt, die HoTT Telemetrie hat einwandfrei funktioniert, leider hat S32 mal wieder nicht aufgezeichnet. Schade, das wäre so eine fette Datei geworden. Ich sichere die Daten der SD, formatiere sie, schreibe die Daten zurück und versuche es erneut.
Das Einfrieren der HoTT Telemetrie konnte ich auch mit zurück getauschten Komponenten nicht wieder beobachten, also Entwarnung.

_________________
Gruß Winne