J-Log.eu - Forum

Ok, dann sollte meine Seite zumindest von der Stromversorgung sauber sein:
- kein Antiblitzdings
- Linus Caps V2

Beim Anstöppeln kommt doch normalerweise bischen LED-Kino und dann "Grün"-Geflacker, wenn der Jive was sendet. Dann ist doch keine orange LED an? Das habe ich eigentlich nie groß beachtet, weil alles immer ok war.

Aber kann es sein, dass das Updatefile der FW aus dem Root der SD nach Update-Erfolg nicht gelöscht wird?


PS: Passt das in das Thema, sonst kannst du es gerne verschieben.

Automatisch gelöscht wird da nix.
Der Bootloader fasst so einen File bei jedem Startup an, flasht aber nur, wenn was anderes drin ist, als aktuell geflasht.
Daher nie mehr als einen Updatefile rumliegen haben, er reflasht sich sonst bei jedem Start.

Flashen im Bootloader:
- Filename/Extension egal.
- Der BL durchsucht die Cluster nach einem File passender Länge.
- Wurde einer gefunden, wird der gelesen und ein Trailer in dem ausgewertet:
-- Für welche Hardware?
-- Welches Release, anders als mein aktuell geflashtes?

_________________
Tom

Hm...

Nehmen wa mal an dass das FS meiner SD nen Hau weg hat.
Der Akku wurde angestöppelt.
Das Update der FW war noch im Root der SD, wurde also verglichen und für gut befunden.
Das FS macht Ärger.
JLog wird nicht Grün.
... auch nicht nach ~15sek
Der Sender erkennt zwar TM vom Empfänger, aber nix vom JLog.
Akku wird abgestöppelt und auch die Caps entladen. Alles stromlos.
Der Hott-Sender mault rum.

Akku wieder dran.
JLog wird Grün und flackert. (Ich weiss jetzt nicht ob da noch was Orange dabei war.)
Sender-TM meldet die Akku-Spannung, die via JLog kommt.
Fliegen bis der Arzt kommt. Leider zu lange. Kein Alarm wegen Kapazitätsschranke.
Akku verreckt (Ist jetzt nur noch ein 10S )

Wieso kam der Alarm nicht? Weil Config.txt im Arsch war?

Der war aber schon hin beim Start.

Wieso da irgendwas wie nicht blinkte.. who knows..

Ich sagte ja, die orange bei ganz genauem Hingucken für den Bruchteil einer Sekunde. Ich sage gar nichts mehr, wenn Ihr nicht genau lest.

Und? Willst Du jetzt 'n neuen Akku von mir, Jupp?

_________________
Tom

Moin!

Noch mal nachgedacht nach etwas Schlaf, nunja, 5h..

Schon auffällig, dass es immer die HoTT Firmware ist..
Ich werde noch mal gucken. Wenn ich mich nicht irre, is das die "vollste", hat den höchsten RAM-Bedarf.

Es könnte nämlich auch an der Ecke was sein, stochastisch..

_________________
Tom

Klar nen neuen Akku, du hast wegen JLog die Verantwortung der ganzen Welt übernommen. Als Ausgleich entwickelst du jetzt zur Strafe ein Mittel gegen Krebs und für den Weltfrieden.

Ich bin nur irritiert, weil die ganze Geschichte bisher ohne irgendeinen Mucks lief. Erst nach meinem Versuch mit HoTT MX20 V1.128 und wieder zurück auf V1.126 hatte ich jetzt zum ersten Mal Probleme. Mein Ziel ist es den "Bug" in meiner Anstöpselphase zu finden oder einfach nur sagen zu können, dass FS der SD hatte nen Hau wech.

... und diesem Lipo trauer ich wahrlich nicht nach.

Hallo zusammen,

ich habe gerade diesen Thread gefunden, weil ich das selbe Problem hatte.

Mein config.txt war heute auch leer. Die TM lief im Flug tadellos, aber der Alarm für die Kapazität wurde nicht ausgelöst. Ist natürlich etwas gefährlich, wenn man sich drauf verlässt, dass die TM sich im Sender meldet, wenn der Akku leer ist. Gottseidank habe ich parallel noch einen Timer laufen.

Jlog 2.6 mit 26-K_S-45.6 (heute upgedatet auf .8)
Kosmik 200
Spektrum TM1000
GreenCap Buffer (3x50F)

Hab nun die SD-Karte formatiert und hoffe, dass es zukünftig hält.
Bei einer Testeinstellung des Kapazitätsalarms auf 100mAh hat sich der Sender nun brav bemerkbar gemacht.

Grüße
Rolf

Ja, das kann passieren.

Das Filesystem wird ja zwangsläufig ständig auf Kante gefahren, kann jederzeit inkonsistent werden beim Abschalten, und FAT ist nicht gerade besonders resistent gegen so was.

LogStop ist die einzige mögliche Methode, das Risiko zu lindern. Es funktioniert aber nur, wenn 5s vor Saftweg die beiden Ströme Imot und Ibec tatsächlich unter Limit waren. Außerdem wird LogStop automatisch ausgehebelt, wenn bestimmte JLog-eigene Sensoren konfiguriert sind, die ständiges Recording erfordern.

Wenn man nicht häufig die SD in den PC bringt, dann auch ein angeschlagenes Filesystem repariert (oder neu formatiert mit dem SDformatter), dann besteht die Gefahr latent.

----------------
Was passierte hier im Besonderen?

Siehe hier http://j-log.eu/jlog-in-funktion/konfigurator-jlc, wie JLog und JLC via CONFIG.txt kommunizieren, wie JLog das Setup sieht und speichert:


JLog schreibt zumindest seine Duftmarke in CONFIG.txt, wenn die nicht vorhanden ist, wenn es ein 2.6 ist, der seinen Enabling Status darin verewigt. Ist das FS nun schwer angeschlagen, kann dabei ein Configfile rauskommen, der Null lang ist.
Beim nächsten Start liest er diesen leeren File. Vor dem Einlesen stellt JLog auf Defaultwerte, aktualisiert die dann anhand des Inhalts vom Configfile (also gar nicht), stellt dann fest, dass anders als die letzte Config, die er lernte (in seinem nichtflüchtigen Speicher im Prozessor), korrigiert das daraufhin, - und zwar zum Falschen.

Wenn man den Fehler sucht, so vorgehen:
1. CONFIG.txt von der SD löschen.
2. JLog mit der SD starten, laufen lassen bis LED Blinkkino vorbei. Er erstellt CONFIG.txt neu aus seinem Gedächtnis.
3. SD in den PC und Config in JLC einlesen (Man sollte immer - Einlesen, Modifizieren, Zurückschreiben, - nicht von der grünen Wiese aus in JLC konfigurieren!). -- Dann kommt das große Staunen, was JLog da gelernt hat. Warum? Siehe oben.

_________________
Tom