Batterietester für NiMh und LiIon mit AVR-DOS Datenlogger

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Ich bin kein Batteriefachmann, wills auch nicht werden.

      Pluto25 schrieb:

      Ist das nicht eher ein normales Verhalten? Wenn der Akku leer ist bricht die Spannung stärker ein bei Belastung. Wie ist die Kurve denn bei einem Neuen?
      So, hab nochmal vier Messungen ins Excel gekippt, ist auch ein Neuer dabei
      Das ganze grob kommentiert

      Vier Kandidaten

      ENELOOP_schlecht: 850mAh Soll, 790mAh Ist, ca 8 Jahre alt, kaum benutzt, regelmäßig geladen
      ENELOOP_gut: 850mAh Soll, 780mAh Ist , ca. 4 Jahre alt, kaum benutzt, regelmäßig geladen
      HTRONIC: 750mAh Soll, 337mAh Ist, ?? Jahre alt, lag vergessen und tiefentladen in der Schublade
      EBL_NEU: 1100mAh Soll, 1080mAh Ist, 2 Monate alt, unbenutzt

      Der ENELOOP_schlecht zeigt analog #16 einen extremen Anstieg des RI zum Ende
      Dieses Verhalten ist reproduzierbar und kein Messfehler.

      Damit lass ichs gut sein. Will ja nur aussortieren was ganz müllig ist.

      Vergleich 4fach.jpg



      Bin gespannt was @laase mit seinem Luxustester für Ergebnisse hat.
    • Danke für die Vorab-Lorbeeren, aber so luxuriös wie Deiner wird meiner nicht! Er hat nur mehr Kanäle (4), dafür nimmt er aber keine ganzen Entladekurven auf, sondern es geht um Schnelltests von möglichst vielen Zellen in möglicchst kurzer Zeit. (Außerdem lädt er nur, entladen kann er gar nicht. Wenn "zu volle Zellen" herumliegen, müssen die vorerst noch manuell entladen werden. Mal sehen, ob ich das später auch noch mit automatisiere.)

      Daher will ich mich auch auf Li-Ion beschränken (LFP/NMC/NCA) und nehme nur den Spannungsanstieg dU/dt bei konstantem (vorher in 1..6A wählbarem) Strom auf. Das soll eine ungefähre Aussage der Kapazität ermöglichen. Bei NMC/NCA erwarte ich, daß das recht gut klappt, bei LFP wird das naturgemäß schwieriger, da die Spannungskurve beim Laden (wie übrigens auch beim Entladen) sehr viel flacher als bei NMC/NCA ist. (Leider haben die 8-Bit AVR's ja auch nur 10Bit AD-Auflösung; da wäre ein anderer µC mit 12Bit vll nochmal interessant) LFP ist in der Hinsicht vergleichbar mit NiCd. Für LFP werde ich also möglicherweise keine Aussagen zur absolut erwartbaren Kapazität treffen können, wahrscheinlich aber wenigstens Zellen untereinander vergleichen können.
      Aber natürlich spielt, wie auch bei Deinen Tests an NiCd/NiMh, der Ri eine sehr wichtige Rolle: meiner praktischen Erfahrung nach ist es bei vielen Anwendungen nicht der SoH (state of health, also C_ist/C_nominal), der das Leben der Zelle begrenzt, sondern der Ri. Er läßt die Spannung unter die 3- bzw 2.5V Schwelle fallen und das Gerät schaltet einfach ab. Ein Anwärmen des Akkus hilft manchmal noch eine Weile (Ri sinkt; deshalb muß der 4-Kanal Tester unbedingt auch die Temperatur erfassen), aber das Ende naht ...
      Der Ri wird durch die Spannungsänderung bei "Austasten" des Ladestroms ermittelt, "weit genug weg" von den jeweiligen Ladeendspannungen der Zellchemien (LFP unter 3.4V und NMC/NCA unter 4.0V). Konvention wären hier eigentlich 1kHz, aber so schnell ist meine eher statische Stromregelung und auch meine Meßwerterfassung nicht. Es wird wohl eher auf eine 10-20ms Austastung hinauslaufen.

      Achso: ein kleines feature hat der Tester denn aber doch noch: wegen der geringen Spannungsänderungen, insbesondere an LFP Zellen, sollen nicht auch noch Änderungen der Kontaktierungswiderstände an den Zellen "mitgemessen" werden. Der Tester hat daher konsequent 4-Leiter-Messung (separate Messleitungen von den Zellen zu den Differenzverstärkern).

      Problematisch werden "geplatete" Zellen sein, also solche, die zB mit vergleichsweise hohem Strom bei niedriger Temperatur geladen wurden. Diese zeigen manchmal Anomalien im Spannungsverlauf; auch einige Zeit gleich bleibende bis hin zu fallenden Spannungen treten mitunter auf. Aber wenigstens die Ri-Messung wird hoffentlich auch an solchen Exemplaren eine Aussage möglich machen.
    • Hallo @Riedleweg
      in Sachen SD-Speicherung bin ich noch ein 'absolute beginner'. Nachdem ich mich gestern Nacht ziemlich abgemüht habe, aber es auch mit Hilfe Deines Codes (vielen Dank Dir dafür!) dann endlich geklappt hat und KEINE Formatierung der SD-Karten mehr gelöscht und in 'RAW' verwandelt wurde, möchte ich Dich (oder gern auch die anderen hier) zwei Dinge fragen:

      - wie bekommt die abgespeicherte Textdatei ggf. ein aktuelles Datum? Du beschreibst zwar einen "Header" und es stehen nachhher Tag und Uhrzeit IN der Datei, aber die Datei selbst wird mir im Win Explorer stets mit '01.01.2001' angezeigt. Wenn ja, wie ließe sich das ggf. ändern? Oder muß man damit leben? Die Daten für eine Übernahme der Uhrzeit stünden ja eigentlich "im System zur Verfügung"?!
      - das ist mir etwas peinlich aber: worin unterscheiden sich eigentlich 'write #channel' und 'print #channel'? Du verwendest in Deinem Code BEIDE Befehle. Beide erzeugen gleichermaßen lesbare Zeilen in der gespeicherten Textdatei. Beide ermöglichen das sequentielle Schreiben, während die Datei geöffnet ist. Mit beiden lassen sich sowohl Variableninhalte, wie auch Textstrings abspeichern. Mit 'strg16="" : print #20 strg16' erzeugst Du eine Leerzeile. Ok, das scheint mit 'write' nicht zu gehen. Dafür lassen sich die Kommata, die bei einer CSV-Datei zum späteren Einlesen in Excel oä wichtig sind, offenbar einfacher mit 'write' erzeugen. Zur "Erzeugung" des Headers verwendest Du überwiegend 'print', zum späteren fortlaufenden Speichern der Variablen mit Kommas dazwischen nimmst Du 'write'. Kann man das irgendwie "kurz und knackig" erklären?

      In meinem Projekt will ich statt der DS1307 Echtzeituhr einen internen Timer des Atmega2560 verwenden. Er hat ja genug davon. Da es eh eine Menüführung per Encoder gibt, soll der Nutzer, ausgehend vom letzten im EEprom abgelegten Zeitpunkt, stets bei Start ein neues Datum und eine neue Zeit einstellen. Ich weiß noch noch nicht, ob ich es mit Bascom-Hausmitteln (die scheint es ja offenbar zu geben?) und einem Uhrenquarz an den Timerpins des Atmega mache oder mir aus dem 16MHz Haupttakt per 16-Bit Timer einen sekündlichen Interrupt ableite und die Fortzählung der Zeit dann "händisch" erledige. Mit letzterem kenne ich mich schon etwas aus, das erste (Hausmittel wie zB "config clock") wäre Neuland ...

      Viele Grüße, Lars

      P.S.: ich verwende übrigens die "MMCSD_HC.LIB" und kann damit bisher alle von mir getesteten SD-Karten einwandfrei beschreiben. Getestet habe ich von 250MB (Spez. 1.x) über 2GB (ebenfalls noch das "alte" 1.x; sonst offenbar ein Sonderfall, da es ab 2GB auch schon SD-HC gibt und die Karte von meinem älteren "MP3-Konverter-Plattenspieler", einem USB-SD-Stick und einem MP3 Player zB nicht "genommen" wird), über 8GB, 16GB SD-HC (Spez 2.0) bis hin zu 32GB SD-HC. Formate habe ich FAT(16) und FAT32 probiert, Sektorengrößen 4096 (wie von Dir vorgeschlagen), aber auch "Standard". Schnellformatierung und "ohne das Häkchen". Immer per Windows "Datenträgerverwaltung". Alle Karten werden korrekt erkannt, Spezifikation ausgelesen, Speichergröße ermittelt (zeige ich an), erlauben das Speichern und anschließende Auslesen am PC. Ich habe allerdings keine Micro-SD's getestet (keine zur Hand). Bei welchen Karten außer den Micros hattest Du ggf. noch Probleme?
      Was war der Grund dafür, daß Du nicht die *_HC.lib genommen hast? Beansprucht der Code dann mehr Flash-Speicher und lässt zu wenig "Luft" in einem Atmega328?
    • uups, doch noch Fragen: "Strom aus stabilen 5V" könnte bei mir knapp werden; hast Du vielleicht einmal untersucht, wieviel die SD-Karten (bzw. der gesamte SD-Adapter mit SD) beim Schreiben "ziehen"? Es wird ja manchmal von ">200mA" berichtet?!
      Macht es einen Unterschied, ob ich die Datei nach dem (groß-)blockweisen speichern schließe und für's nächste Schreiben nach ein paar Minuten neu und nur kurz öffne, oder ist die SD bei nur geöffneter Datei und "Schreiberwartung" ansonsten unauffällig im Verbrauch? Mit meinem "USB-Doctor", der nicht sonderlich genau bei kleinen Strömen und in der Auflösung ist, kann ich ab Einstecken der Karte einen (Mehr-)Strom von ca. 10-20mA beobachten, unabhängig vom Typ der Karte. Den Strom beim Speichern konnte ich bisher nicht ermitteln (ging zu schnell).
      Mit Config SPI ... Clockrate = 4 ... meine ich, aus den 16MHz Quarztakt einen 4MHz Takt für die SPI-Übertragung zu erzeugen (ohne das jedoch mal mit Oszi geprüft zu haben). Würde Clockrate = 16 (dann mutmaßlich nur 1MHz SPI-Takt) eventuell eine Verringerung der Stromaufnahme beim Schreiben bewirken oder passiert das Gegenteil, nämlich daß die hohe Stromaufnahme sich einfach nur "länger hinzieht" und ich letztlich noch mehr Probleme habe, den "Stromblock [mA * ms]" mit einem dicken ELko abzupuffern?
    • Uff, so viele Fragen

      Ich kämpf grad mit "homeschooling" mit 3,5 Kindern. Der Tag ist zu kurz weil man ja irgendwie auch noch "homeoffize" machen muss um die Kohle für die nächste Nicht-Urlaubsreise ranzuscheffeln.
      (das 0,5 Kind ist das vom Nachbarn das ab und zu mitbetreut wird. Legal weil 1 Fremdkopf im Haushalt is ja erlaubt....)

      laase schrieb:

      - wie bekommt die abgespeicherte Textdatei ggf. ein aktuelles Datum? Du beschreibst zwar einen "Header" und es stehen nachhher Tag und Uhrzeit IN der Datei, aber die Datei selbst wird mir im Win Explorer stets mit '01.01.2001' angezeigt. Wenn ja, wie ließe sich das ggf. ändern? Oder muß man damit leben? Die Daten für eine Übernahme der Uhrzeit stünden ja eigentlich "im System zur Verfügung"?!


      - worin unterscheiden sich eigentlich 'write #channel' und 'print #channel'
      Das Filedate kann man mit AVR-Dos nicht schreiben. Hab mal nichts darüber gefunden und auch die MCSELEC-Doku war nicht ergiebig.
      Wäre schön aber geht halt nicht. Evlt kann man ja den Filename aus dem Zeitstempel generieren.


      Das mit dem #Write ist einfach praktisch da man in der Lib den Feldtrenner hinterlegen kann und sich keinen Kopf darüber machen muss das irgendwie in einen String zu packen.
      Steht in der CONFIG_AVR-DOS

      Quellcode

      1. ' Character to separate ASCII Values in WRITE - statement (and INPUT)
      2. ' Normally a comma (,) is used. but it can be changed to other values, f.E.
      3. ' to TAB (ASCII-Code 9) if EXCEL Files with Tab separated values should be
      4. ' written or read. This parameter works for WRITE and INPUT
      5. ' Parameter value is the ASSCII-Code of the separator
      6. ' 44 = comma [default]
      7. ' 9 = TAB ' [default = 44]
      8. Const Cvariableseparator = 59


      Der DS3231 ist der absolute Overkill aber er lag halt in der Bastelkiste. Und war ganz praktisch da er ja den konfigurierbaren Ausgang SQW hat für den Sekundentakt.

      Stromverbrauch der SD-Karte hab ich nicht gemessen da alles über ein USB-Steckernetzteil versorgt wird.

      Da ich noch mit einem universellen Datenlogger liebäugle wird das ein Thema werden. Mein Ansatz hier ist ein anderer nämlich:
      - Zwischenspeichern auf einem ext. EEPROM wie hier z.B. --> 24FC1025
      - Wenn der voll ist oder irgendwas triggert den Inhalt in einem Rutsch auf die SD schieben.

      So, ich seh grad die ersten Arbeitsaufträge für die Kinder trudeln grad ein, oh mann oh mann.....sorry für die Kürze der Antworten....
    • War doch sehr ergiebig, danke!
      Meine 2,5 Kids haben morgen übrigens Ferien und die Eltern sind sehr erleichtert drüber, weil sie dann endlich mal etwas "besser" homeoffice machen können. ;)
      Hut ab mit dem externen EEprom und dem Umspeichern! Da kannst Du 128.000 Bytes drin abspeichern! Angenommen, Du "produzierst" 4 Bytes je Sekunde (je 1 Word für Spannung und Strom), dann könntest Du immerhin 32.000 Sekunden (etwas mehr als 8h) speichern, bevor Du alles auf die SD schiebst. Das ist ganz ordentlich.
      Ich werde da deutlich fauler sein und die 8000 Bytes des internen SRAm des Atmega2560 nutzen (bzw das, was nach dem Abzug der Programmvariablen noch davon übrig bleibt). Mit 4 Byte je Sekunde komme ich dann immer noch auf ca. eine halbe Stunde. Da sollen die Akkus eigentlich längst durch sein mit ihrem "Schnelltest".
      Moment, stimmt nicht, ich habe ja vier Kanäle und will zusätzlich auch noch die Temperatur aufzeichnen. Naja, wie auch immer, ich werde wohl alle paar Sekunden auf die SD umspeichern. Muß testen, wie lange ich Zeit habe im Sekunden-getakteten Programm (wieviel "Luft" mir sicher bleibt) und dann anpassen, ob es alle 10, 16, 30,32,60 oder whatever Sekunden sind, wo ich speichere.
    • "Sammelt das AVR Dos nicht alleine die Daten bis eine Page voll ist bevor es die Daten auf die SD schreibt?"
      Das wäre einerseits komfortabel, andererseits auch doof, weil ich ja eigentlich gern selbst bestimmen möchte, zu welchem Zeitpunkt und wie lange geschrieben wird.
      Wenn ich AD-wandle, will ich ruhig und störungsfrei AD-wandeln und nicht nebenbei noch derbe Spannungsspikes auf der Versorgung haben, die mir die Messung verhageln.

      "Die Dateien haben drei mal Datum. War keins davon richtig? ... Welches Datum meinst du?"
      Ich denke, er meint mindestens das Erstellungsdatum und das Bearbeitungsdatum, die beide im Windows-Explorer angezeigt werden bzw. zur Anzeige auswählbar sind. Mangels Echtzeituhr konnte ich das natürlich nicht testen. Hast Du vielleicht mal, Riedleweg? Wie heißen die Datumsangaben Deiner Dateien?
    • ich geb's offen zu: hier versagt gerade mein Vorstellungsvermögen!
      Ich habe "offene" *.bin Dateien, die ich mit flush in einem Rutsch auf die SD speichere? Ja aber wo sind denn diese *.bin Dateien, wenn nicht eh schon auf der SD?
      Ich glaube, ich muß hier noch viel tiefer rein in die Materie ...
    • ist jetzt vielleicht nicht der richtige Platz hier für so eine Fragerunde, aber: muß ich es mir so vorstellen, daß wenn ich "write #ch" oder "print #ch" verwende, gar nicht in diesem Moment die Karte beschrieben wird, sondern zu irgendeinem späteren Zeitpunkt, den AVR-DOS festlegt?
      Und ist es so, daß ich mit dem Befehl flush() diesen Zeitpunkt vorziehe?
      Das heißt ganz konkret, daß ich einen Datenlogger programmieren könnte, der alle 100ms per 'Write' 8 Bytes "schreibt" und meine SD-Karte wäre NICHT nach 3 Stunden kaputt? Weil die Daten nämlich in Wirklichkeit gar nicht alle 100ms geschrieben werden, sondern abhängig von AVR-DOS nur in sehr viel längeren Abständen? Mit welcher Variable bzw. Anweisung werden denn dann diese Abstände bestimmt? Und wie lang sind diese Zeitspannen, wenn ich kein Flush() manuell aufrufe?
    • Es sammelt bis ein Sektor (256Byte) voll ist oder die Datei geschlossen wird, bzw eine andere geöffnet wird. In Deinem Beispiel ca alle 3 Sekunden.
      Damit würde eine 1MB SD ca 400/40 Jahre halten. Wiki:
      "Die geschätzte Lebensdauer wird bei SLC-NAND-Chips mit 1.000.000, beim Einsatz von MLC-NAND-Chips mit 100.000 Schreibvorgängen angegeben."

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Pluto25 ()

    • Ah, danke! Wieder richtig was dazugelernt! Werde mir das bei Gelegenheit mal mit dem Oszi anschauen, wann er speichert.
      Und dann auch versuchen, es mit flush() so zu beiinflussen, daß dann gespeichert wird, wenn mir, rein störungstechnisch betrachtet, ein guter Zeitpunkt vorzuliegen scheint (z.B. NACH den AD-Wandlungen).
    • laase schrieb:

      "Die Dateien haben drei mal Datum. War keins davon richtig? ... Welches Datum meinst du?"
      Ich denke, er meint mindestens das Erstellungsdatum und das Bearbeitungsdatum, die beide im Windows-Explorer angezeigt werden bzw. zur Anzeige auswählbar sind. Mangels Echtzeituhr konnte ich das natürlich nicht testen. Hast Du vielleicht mal, Riedleweg? Wie heißen die Datumsangaben Deiner Dateien?
      Sorry, Antwort mit Verspätung

      Hab mal alle Spalten eingeblendet die irgendwas mit Datum/Zeit etc zu tun haben könnten und gefüllt sind.

      Ist immer nur statisch der 01.01.2001. Ein akt. Datum wird nicht weggeschrieben. Habe auch nichts gefunden wie das mit AVR-Bordmitteln bewerkstelligt werden könnte

      Screenshot 2021-02-06 095121.jpg
    • Riedleweg schrieb:

      Ist immer nur statisch der 01.01.2001. Ein akt. Datum wird nicht weggeschrieben. Habe auch nichts gefunden wie das mit AVR-Bordmitteln bewerkstelligt werden könnte
      Das sieht so aus, als ob du keine Uhrzeitroutinen in dein Programm eingebaut hast. deshalb bewegt es sich auch nicht.
      Config Clock und dann einen eigenen Interrupt oder Config DCF77. Letzteres konfiguriert dir sogar schon eine fertig laufende Uhr.
    • Hallo Michael,
      habe mir config clock mal angeschaut. DCF77 kommt für mich nicht in Frage, da im Haus an vielen Stellen kein DCF77 empfangen wird, zumindest nicht zuverlässig. Im Keller schon gar nicht. Einen Uhrenquarz möchte ich auch nicht verwenden, denn der 16MHz Quarz ist schon auf dem (Arduino) Mega2560 board.
      Config Clock = Soft bedingt aber einen Uhrenquarz (zumindest laut Bascom-Hilfe). Die Option Gosub = Sectic bedingt wiederum das vorherige Setzen der Option "Soft".
      Wie kann ich Config Clock nutzen und die Variablen _sec usw automatisch von "Clock" setzen lassen, wenn ich einen 16Bit Timer den Sekunden-Interrupt erzeugen lasse?

      Normalerweise würde ich den Interrupt so erzeugen und "händisch" die Zeit- und Datumsvariablen setzen und "laufen lassen":

      Quellcode

      1. 'Konfiguration
      2. $regfile = "m2560def.dat"
      3. $hwstack = 100
      4. $swstack = 100
      5. $framesize = 120
      6. $crystal = 16000000 'Quarzfrequenz
      7. Dim Seconds As Byte
      8. Dim Secondsold As Byte
      9. Dim Minutes As Byte
      10. Dim Hours As Byte
      11. Dim Days As Byte
      12. Dim Istneuesekunde As Bit 'Flag dafür, daß man in irgendwelchen langwierigen Encoder-Menü-Operationen jetzt unbedingt zur Hauptroutine zurückspringen muß
      13. Const Timer1reload = 15625
      14. Config Timer1 = Timer , Prescale = 1024
      15. Load Timer1 , Timer1reload
      16. on ovf1 Timer1_isr
      17. enable timer1
      18. start timer1
      19. enable interrupts
      20. 'hier jetzt das Programm
      21. '...
      22. 'darin:
      23. Gosub Alte_zeit_aus_dem_eeprom_holen
      24. Gosub Neue_zeit_per_encoder_einstellen
      25. '...
      26. Do
      27. Hierherzurueck:
      28. Istneuesekunde = 0
      29. Gosub Zeitweiterstellen 'das entfällt dann durch die Config Clock???
      30. Gosub Wichtige_zeitkritische_sachen
      31. '...
      32. Gosub Superlangedauernde_einstellerei
      33. If Istneuesekunde = 1 Then Goto Hierherzurueck
      34. '...
      35. Loop
      36. Wichtige_zeitkritische_sachen:
      37. '...
      38. 'Spannung und Strom sekündlich messen und ins SRAM speichern
      39. 'ggf. Werte per LCD auf den anderen (nicht gerade zu parametrierenden) Kanälen anzeigen
      40. 'ggf. richtige Datei öffen, auf SD speichern, wenn xyz Byte in einem Kanal "voll"
      41. '...
      42. Return
      43. Alte_zeit_aus_dem_eeprom_holen
      44. 'readeeprom ...
      45. Return
      46. Neue_zeit_per_encoder_einstellen:
      47. 'bietet letztbekanntes Altdatum als Startwert an
      48. 'hier ein längeres Einstellmenü, das u.a. den Timer 3 (auch ein 16Bit Timer) nutzt
      49. Return
      50. Zeitweiterstellen:
      51. If Seconds >= 60 Then
      52. Seconds = 0
      53. Incr Minutes
      54. End If
      55. If Minutes >= 60 Then
      56. Minutes = 0
      57. Incr Hours
      58. End If
      59. If Hours >= 24 Then
      60. Hours = 0
      61. Incr Days
      62. End If
      63. 'usw.
      64. Return
      65. Superlangedauernde_einstellerei:
      66. '...
      67. If Istneuesekunde = 1 Then Goto Sofortraushier
      68. '...
      69. Sofortraushier:
      70. Return
      71. 'das hier ganz zuletzt hinter den Subs:
      72. Timer1_ISR:
      73. Load Timer1 , Timer1reload
      74. Incr Seconds
      75. Istneuesekunde = 1
      76. 'Add your ISR code here
      77. Return
      78. 'Timer value explination
      79. ' The timer is a 16Bit timer, it overflows when the timer reaches 65536
      80. ' The AVR is running at 16000000Hz, the prescaler is 1024
      81. ' Each tick is 0,064 ms - (1 / CPUSpeed in KHz ) * Prescaler
      82. ' The timer needs 15625 ticks to reach the required time ( 15625 * 0,064 = 1000ms)
      83. ' The start value for the timer must be set to 49911 so that it will overflow at 65536 after 15625 ticks
      84. ' NOTE: The load command does the inversion for you (256-value or 65536-value)
      Alles anzeigen
      Wenn ich später die Stunden, Minuten und Sekunden anzeige oder per Drucker ausdrucke, erscheint eine "3" natürlich als "3" und nicht als "03". Das sieht ein klein wenig ungweohnt aus, ist aber für mich nicht weiter schlimm.

      Wie könnte ich config clock hier sinnvoll einbauen?
      Würde mir Config clock hier (neben der oben besprochenen Speicherung von SD-Dateien mit dem "richtigen" Erstellungsdatum) auch den Vorteil bringen, daß die LCD- und Druckausgabe gleich im Format "TT.MM.JJ hh:mm:ss" mit ggf führenden Nullen erscheint?

      Viele Grüße, Lars