J-Log-Rund um die Briefmarke für den Jive

[dynaudio79]

AW: J-Log-Rund um die Briefmarke für den Jive

... das tue ich sonst immer schon Uwe.

[dl7uae]

AW: J-Log-Rund um die Briefmarke für den Jive

Der Hersteller sieht das leider anders...
Am liebsten würde ich die Transcend meinem Seitenschneider überantworten...

[Linus]

AW: J-Log-Rund um die Briefmarke für den Jive

Der Hersteller sieht das leider anders...
Am liebsten würde ich die Transcend meinem Seitenschneider überantworten...

glaubst Du dass die mit halber Kapazität schneller werden

LG
Linus

[Uwe Caspart]

AW: J-Log-Rund um die Briefmarke für den Jive

[marndra]

AW: J-Log-Rund um die Briefmarke für den Jive

Hm, welcher Hersteller denn?

[dl7uae]

AW: J-Log-Rund um die Briefmarke für den Jive

Wer die Arbeit hat, braucht für den Spott nicht zu sorgen.

Ist jetzt geritzt soweit, ätsch, hat mich etwas mehr als 100 Bytes RAM gekostet.

Allerdings geht mir das Telemetriedisplay (JETIbox) für den Bruchteil einer Sekunde in den Timeout, wenn sich die Karte mal wieder zu lange an den Füßen spielt. Heilung dafür zu finden, wird noch etwas haarig, weil alles zeitkritisch ist, und der JETI-Kram mit nur 9600 Baud klingelt, das dauert...., bis ein Display rausgequält ist, zumal das JETI-Protokoll dabei auch noch mit einem neunten Bit bespielt werden will.

Man sollte beim Kauf einer SD darauf achten, wie die klassifiziert ist (Speicherklasse, Zahl in einem Kreis, geht momentan von 2..10 (MB/s).

Meine Panasonic ist eine 4, die fragliche Transcend hier ist lt. Aufdruck unklassifiziert.

[Schneipe]

AW: J-Log-Rund um die Briefmarke für den Jive

Die Kingston, die beim JLog dabei war ist eine Class 2. Hab mir eben eine solche beim großen C geordert.

Die Transcent werden überall als Class 2 angeboten (zumindest die 2GB Karte)

[dl7uae]

AW: J-Log-Rund um die Briefmarke für den Jive

Ich muss es auch leider aufgeben, die beiden Vorgänge, - unregelmäßiges Warten auf die Karte nach einem Schreibvorgang und regelmäßiges aber im Verhältnis langsames Rausquälen des Outputs an die Telemetrie (JETI), - sind nicht synchronisierbar. Die JETIbox will innerhalb einer bestimmten Zeit neue Daten sehen, sonst wechselt sie das Display (Timeout), sagt, sie sähe kein Device.

Habe eben versucht, das Display-Update mit einer zeitgesteuerten Routine zu machen (interruptgesteuert per Timer also), die muss sich natürlich mit dem dazu asynchron laufenden Code synchronisieren, der die Displays erzeugt, also vorbereitet (jeweils 32 Zeichen), - geht aber auch nicht, weil Wartezeit auf die Karte und Ausgabezeit der Timer-gesteuerten Ausgabe zusammen fallen können, - dann is Schulz.

Auch wenn der Hersteller hier einen hohen Anspruch hat, das ehrt ihn und passt irgendwie zu meiner Grundeinstellung, sprich, jeden Scheiß mit dem Gerät kompensieren will, so, dass es mit jeder Karte ohne Glitches kann, - es gibt da einfach Limits.. So sorry. Die Quadratur des Kreises hat noch keiner geschafft.

Ich muss also darauf bestehen, dass die SD wenigstens eine Klassifizierung hat. Class 2 (Minimum) sollte reichen, muss ich aber mal testen. Nach meinem "Gefühl" (ja.., ich war zu faul, aufwändige Timerspielchen zu machen, um es zu messen), ist meine Class 4 Panasonic etwa Faktor 10 mal schneller beim Schreiben als die unklassifizierte SD, die hier das Maß des Schrotts sein soll, den man auch noch bedienen können will.

Zumindest ist der Logger jetzt bzgl. solcher eigentlich ungeeigneten Karten soweit resistent, dass es weder sein Data Processing noch seine Aufzeichnungen beeinflussen kann. Was ich aber nicht weg kriege, ist, dass die JETIbox in unregelmäßigen Abständen mal "Zwinkern" kann, wenn die Karte da rummurmelt. Wenn man fliegt, ist das eh nicht zu bemerken, Einer, der starr raufstiert, sieht das aber dann irgendwann mal, eben immer nur ganz kurz, Sekundenbruchteil. Ich kenne die Specs von JETI für die Box nicht, mMn will die mindestens alle 200ms neue Daten empfangen, nominal gebe ich ihr alle 100ms neue.

Wer also unbedingt 3 Cents sparen will, indem er eine unklassifizierte SD nimmt, muss damit leben, falls er Telemetrie benutzt.
Es stört auch nicht wirklich, des Menschen Auge ist träge, es ist eben mMn nur so, dass ein Timeout-Display der Box, auch wenn es nur ganz kurz erscheint, normalerweise bedeuten wird, dass die ßbertragungsstrecke (2G4) mal kurz einen Hack hatte. Ich höre schon die aufgeregten Forumdiskussionen: Hilfe, mein JETI funkt wohl unzuverlässig, meine Box zuckt ab und zu mal kurz, auch wenn ich nur 5m vom Modell weg stehe....

[marndra]

AW: J-Log-Rund um die Briefmarke für den Jive

Wieso ist doch alles bene,

Telemetrie ist mit Class2 Zertifiziert, das ist doch schon mal was.
Und wenn einer jamert, dann ist's seine schuld, wenn er "Aussetzer" hat in der Anzeige.
Das ist doch alles sauber erklärbar.

Kannst Du nicht einen Interrupt Buffer machen, damit das Timing immer schön sync läuft, oder kostet das zuviel RAM?

[Schneipe]

AW: J-Log-Rund um die Briefmarke für den Jive

Mal was anderes....Tom, du hast mal gesagt, das sich der Jlog die letzte Config im RAM merkt. D.h. wenn ich eine leere SD Karte reinstecke, nimmt er die Config aus dem RAM. oder?
Ich brauch also auf eine neue SD Karte keinerlei Files draufspielen, stimmts soweit?
Wenn ich aber jetzt den Logger an einen anderen Heli stecken möchte, der eine andere Config hat, reicht es doch dann aus, die neue Config auf die Karte zu spielen, oder? Der JLog müsste ja dann seine im RAM verwerfen und die neue annehmen.
Hintergrund ist der, das ich für diverse Helis, jeweils eine SD Karte haben möchte. So das ich nicht immer die Karte umschreiben muss. Auf den SD Karten ist dann die jeweilige Config des Helis drauf.

[Uwe Caspart]

AW: J-Log-Rund um die Briefmarke für den Jive

Heute ist Fragestunde.

Hab gerade meine Logs ausgelesen und die rpms haben überhaupt nicht gepasst.
Config gecheckt und siehe da, da Pole standen auf 6 statt 10, ratio auf 1:1 statt 1:10.
Quasi reset der Config. Wie geht das?

[dl7uae]

AW: J-Log-Rund um die Briefmarke für den Jive

Zu dem Karten-Thema: Sieht so aus, als würde ich doch eine Lösung finden.


Uwe: Von selbst vergisst der nichts, der hat sich auf die Defaultwerte gestellt.
Früher hatte ich noch eine Prozedur für einen Emergency Reset, man musste dazu den seriellen Eingang eine Weile auf Masse halten, der ist aber nicht mehr drin, war bei ausgelieferten Versionen nie drin.
Es gibt nur eine Möglichkeit für ein Reset des Inhalts des Config Files auf Defaultwerte: Der Logger hat einmal beim Starten aus CONFIG.txt nur Müll gelesen, im Grunde genommen geht das nur, wenn der File zwar existent ist, aber Länge Null hat, - dann schreibt er seine Defaultwerte in den File und in den EEPROM und benutzt die im nun folgenden Run.


Peter: Die Prozedur ist folgende:

Zunächst: Ja, die SD muss NICHTS enthalten, der Logger legt alles selbst an.

Nach dem Start liest der Logger aus seinem EEPROM (nicht RAM, dessen Inhalt ist flüchtig, Licht aus, Kto leer) die Einstellungen. Das sind die letzten Einstellungen, die er aus einem CONFIG.txt las.

Dann wertet er CONFIG.txt aus und korrigiert nur die Werte für den folgenden Run und im EEPROM, die anders sind. (Weil, so eine EEPROM-Zelle hat eine begrenzte Wiederbeschreibbarkeit, es heisst, 100.000 Mal, allerdings hat's wohl noch nie jemand auf der Welt (also nicht auf JLog spezialisiert) geschafft, eine Zelle wirklich zu töten.)

Danach schreibt er alles noch mal komplett zurück in den CONFIG.txt.

Ist der CONFIG.txt nicht da, erzeugt er ihn mit dem Inhalt seiner Werte im EEPROM.

Warum schreibt er CONFIG.txt immer zurück?
Die Werte, die er aus dem EEPROM liest und die aus CONFIG.txt werden jedesmal auf Sinnfälligkeit und Einhaltung von Limits geprüft (Konsistenzcheck). Ist was unkoscher, wird es korrigiert.

Nur zur Info: Im EEPROM und in CONFIG.txt stehen auch Dinge, die zwar der Logger nicht braucht, aber JLC, um nach dem Einlesen von CONFIG.txt wieder genau so zu erscheinen (z.B. in dem Mode von dreien, den man wählte, das Ratio einstellen zu wollen), wie zuvor vor dem Abspeichern des Config Files.

[Schneipe]

AW: J-Log-Rund um die Briefmarke für den Jive

Das heisst.....den Logger aus dem Heli A, mit einer neuen SDkarte in einen anderen Heli B. Schreibt der Logger das Configfile von Heli A drauf. Dann muss man es über JLCII umschreiben, auf den Heli B.

Oder besser gesagt, wie bekomme ich eine neue Config zum laufen? Kann man das Eeprom rücksetzen?
Oder reicht es, die neue SD Karte mit dem passenden Configfile einzustecken und Starten?

[dl7uae]

AW: J-Log-Rund um die Briefmarke für den Jive

Ist die Karte B jungfräulich, bekommt sie beim Start des Loggers einen CONFIG.txt, der die Einstellungen aus dem EEPROM enthält, also die, die CONFIG.txt von Karte A enthält, wenn mit dieser der Logger zuvor mal startete.

Will ich andere Einstellungen auf Heli B, muss Karte B einen CONFIG.txt mit den Einstellungen für Heli B enthalten.

CONFIG.txt hat Priorität, überschreibt die Einstellungen im EEPROM.

Lediglich die laufende Dateinummer hängt am Logger und nicht an CONFIG.txt (könnte ich eigentlich mal ändern). Wenn die letzte Nummer 33 in Heli A war, ist die nächste auf Karte B 34 usw.

Man kann das Reset-Flag in CONFIG.txt setzen (mit JLC), dadurch wird die laufende Nummer auf 0 zurückgesetzt, aber auch alle Log-Files und -Directories gelöscht. Danach setzt der Logger das Flag in CONFIG.txt wieder zurück auf 0 (inaktiv).

Also zwei Karten mit jeweils einem spezifischen CONFIG.txt mitnehmen, und alles is schick.

[dl7uae]

AW: J-Log-Rund um die Briefmarke für den Jive

<OT>

Ich wollte gerade "Unconditional Surrender" rufen, da hab' ich doch'n Weg gefunden.

Diese SD ist ja so uuuunglaublich schnarschig beim Schreiben, dem Ding kann man im Laufen die Schuhe besohlen..

Das kostete nun mehr als 250 Bytes RAM (SRAM, nicht FlashROM!), das wird sich bald rächen, wenn weiterer Code hinzu kommt..

Der ganze Mist "sozialer Rücksichtnahme" gegenüber Nutzschrott hat mind. 24h reine Arbeitszeit gekostet. Wenn man mir dereinst auf der Intensivstation den Tubus in den Schlund steckt, werde ich das bedauern..