J-Log.eu - Forum

Hallo,

ich hatte am Mittwoch ein merkwürdiges Erlebnis. Morgens noch schnell was im Stabi eingestellt, und
zum Platz gefahren. Dort den Logo wie immer scharf gemacht, und los geflogen. Plötzlich machte meine
DX8 ab und an einen Piep. Bin sofort gelandet. Auf der Suche nach der Ursache bemerkte ich, das mir
eine Drehzahl von 15000 angezeigt wurde. Durch Zufall hatte ich auch mein Notebook dabei, sodass ich
mal auf die micro SD vom Jlog2 schauen konnte. Dort fiehl mir auf, das die Config.txt komplett leer war.
Der Ordner mit den Telemetriedateien war noch vorhanden, und es wurde auch weiter geloggt.

Möchte dies gerne in Zukunft vermeiden, daher die Frage, wie das passieren kann?? Wodurch wurde
die Config.txt gelöscht? Nehme an, das die gelöscht, und leer neu erzeugt wurde. Aber wodurch?

Grüße Andre

André, das Filesystem der SD wird angeschlagen sein.
Mal neu formatieren, am besten mit dem SDformatter von sdcard.org.

Das kann immer passieren, wenn JLog der Saft abgedreht wird, während er schreibt. Daher gibt es ja den LogStop.
Am besten den Heli 5 Sekunden ruhig stehen lassen, bevor man den Akku abklemmt.

LogStop, sofern im JLC enabled, stoppt das Log Recording, sobald Imot unter 0,1A und Ibec unter 2,9 gehen.
Das Filesystem wird eh ständig gesynct.

-------
Allerdings dann ohne Logs Recording for Forensik: Die neuen Firmwares starten und laufen, laufen weiter, auch ohne SD.
Da es dann keine Config zu lesen gibt, nimmt JLog eben die zuletzt gelernte Config aus dem EEPROM seines Prozessors.

Ohne SD geht nun alles andere trotzdem, Data Processing, Telemetrien und Alarming.

Und, nein , das Aufzeichnen im Sender kann kein Ersatz sein für das Logging von JLog.

_________________
Tom

Hallo,

so etwas hatte ich mir schon gedahct, danke.



Den Satz verstehe ich zwar nicht, aber o.k. Im Sender wird eh nix Aufgezeichnet.

Grüße Andre

Weil schon solche Töne kamen wie JLog nur noch als Telemetrie-Gateway und Logging im Sender, wenn geht.

_________________
Tom

Moin,

nene, ich machen loggen nur im Jlog, und Gateway zum Sender als Anzeige. Kapazitätswarnung im Sender.
Mehr brauche ich nicht.

Grüße Andre

Okay.

Ich würde aber trotzdem on top Alarme für Ubat, tFET(!) und UbecDip (Checkbox) setzen.
Ubat: Zellenzahl *3,2...3,3V
tFET: 85°C

_________________
Tom

Jetzt hat es meine Config.txt auch erwischt: ratzeputz leer.

Auffallend war auch dass der JLog erst beim zweiten Anstöpseln startete.


version.txt: 4.0.0J_H4-N-62.12
JIVEinfo.txt:12 N.A.

Was empfiehlt denn Windoofs beim Mount? Überprüfen?

_________________
Tom

Nöscht.

Habe die SD aber nochmal langsam formatiert: FS im Hintern; einige alte Files sind auch hinüber.

Wo war noch dieses SD-Format-Tool?

https://www.sdcard.org/downloads/formatter_3

Ich antworte mal hier, für die Allgemeinheit.
Klaus per Email:

Die Firmware hat keinen Bug.
Der Zugriff auf CONFIG.txt erfolgt nur unmittelbat nach dem Start, nach Ablauf der 5-sekündigen Warteschleife mit dem Kino mit allen 3 LEDs. Wenn man genau hinguckt, sieht man für den Bruchteil einer Sekunde die orange LED aufblitzen.

Er liest die letzten gelernten Einstellungen aus dem EEPROM des Microcontrollers.
Er liest und verarbeitet CONFIG.txt. Dabei führt er Konsistenzchecks der Parameter durch. Die habe ich aber bereits vor geraumer Zeit teilweise zurückgenommen, um ROM zu sparen. Da editiert ja kaum jemand drin herum (außer mir ), somit reicht es aus, wenn JLC es richtig machte.
Dann überschreibt er die Zellen im EEPROM, deren Werte sich änderten.
Dann nimmt er notwendige Einstellungen an der Hardware vor (Pins etc.).
Dann erst befasst er sich mit dem vakanten Logfile, ermittelt die nächste laufende Filenummer, speichert die im EEPROM, erzeugt ein evtl. erforderliches [weiteres] Unterverzeichnis, bestimmt den Filehandler usw.

Während des Laufs gibt es keinerlei Zugriff auf CONFIG.txt, es sei denn, ungewollt:
- Durch ein defektes Filesystem (Cluster vermischt).
- Durch Brownout des Microcontrollers wg. einbrechender Betriebsspannung.

Brownout: Wenn nicht das Filesystem schon vorher schwer angeschlagen war, kann es nur durch Brownout zu so einem Effekt kommen. Der Prozessor wird ohnmächtig, und wenn er wieder kommt, ist der RAM leer, und damit sein Status im Nirvana. Ein Zombie.
Die in einem Mikrocontroller einstellbaren Brownout-Schwellen sind diskret, wodurch sie manchmal nicht zu zulässiger Minimalspg. eines gesteuerten Geräts passen können. Das ist hier der Fall: Eine mSD geht spannungsmäßig in die Binsen (deren Controller), bevor der schützende Brownout des JLog zuschlägt.

Die Leute hatten es massenhaft geschafft, das Filesystem zu killen, damit meist CONFIG.txt geleert oder den File komplett weggeputzt. Grund sind Antiblitzwiderstand, und insbesondere in Kombination mit Caps am BEC-Ausgang eines JIVE.
Der BEC erkennt multible Kurzschlüsse beim Startup, die BEC-Spannung spielt total verrückt. Um das zu kompensiren, habe ich diese 5-sekündige Warteschleife gegen Crazy Voltage eingeführt (LED-Kino). In Unterspannungsversuchen hatte ich dann nur noch ein Issue auf 300 Unterspannungsereignisse.

Das ist aber keine Garantie! Leider sind die lieben Anwender ja i.Allg. superschlau, meinen, so ein Antiblitzwiderstand wäre problemlos, und fette Caps am Ausgang ohne Ladestrombegrenzung dazu ebenfalls. Tja, was soll ich machen, rede mir den Mund fusselig.

In Deinem Fall, Klaus, tippe ich auf so ein Spannungsproblem. Dass in CONFIG.txt plötzlich was anderes steht, der Content aber immer noch konsistent und sinnig ist, deutig sehr stark darauf hin, dass JLog zwischendurch mal in den Brownout ging. Er startete quasi irgendwo mittendrin, ohne ein sauberes Reset (POR Power-On-Reset) erfahren zu haben.
Nun ist es an Dir, über mögliche Quellen dafür nachzudenken.

_________________
Tom