Discussion in 'OpenFormat' started by Space, Jan 8, 2007.

  1. Space

    Space New Member

    Es gibt verschiedenst kleine Projekte und Eigenentwicklung, welche Daten visualisiert haben möchten.
    Aktuell ist das der Minilloger V2 als auch eigene Derivate von dem Minilogger V1. Auch das Logformat vom Opencharge verwendet derzeit ein vorhandenes Datenformat eines kommerziellen Ladegerätes, was einiges Einschränkungen bedeutet.

    Angeleht an einem CSV Format, möchte ich die Definition eines offenen Formates anregen. Das könnte etwa so aussehen:

    • 10 Datenkanäle
    • 1'er Datenkanal ist die X-Achse
    • Einheit und Faktor Definition im INI File
    • zusätzlich 5 frei zu berechnende Datenkanäle nach einfachen durch in den INI File zu definierenden Formeln( z.B. Ch12 = CH10 * Ch1 oder aufsummierend CH12=Ch12+Ch3)
    • Universelle Trennung der gesendetet Daten durch ein Trennzeichen (;) dadurch variable Bytelänge der Daten) und/oder definierter Abschluss eines Datenblocks durch ein Sonderzeichen.
    Zukünftige Projeke sollten diese Format als Standart ansehen und für ihrer Entwicklung nur passende INI's mitliefern.

    Thomas
  2. Holger

    Holger LogView Team

    Hallo Thomas,

    das ist ein interessanter Vorschlag!

    Und das ist ein Thema, worüber Dominik und ich schon oft gesprochen haben. Wir haben uns gerade in den letzten Tagen auch über die mögliche Verwendung von regular expressions Gedanken gemacht.
    Dein Vorschlag eines offenen Datenformats klingt sehr vielversprechend und erscheint mir auch umsetzbar.
    Es muss in dem von Dir erwähnten ini-File dann auch Anweisungen geben, wie LogView z.B. den Beginn eines Datensatzes erkennen kann. Und ob ein Wert z.B. beim Beginn eines Datensatzes wieder auf Null gesetzt werden soll. ...
    Da ist also noch einiges an Details festzulegen.

    Wir hoffen, dass sich noch viele Leute an der Diskussion dazu beteiligen werden!

    Der bisherige Stand der Umsetzung eines Universalformates in LogView ist in etwa folgendes:

    1.) Es muss ein Basisformat geben, welches ohne Änderungen sofort zu brauchbaren Ergebnissen in LogView führt.

    2.) Bei Bedarf kann man nachträglich über zusätzliche Steuerdateien Erweiterungen/Änderungen/Anpassungen vornehmen.

    3.) Die Trennung der einzelnen Daten in einem Wertesatz (entspricht beim Empfang einem Datentelegramm) erfolgt durch ein Trennzeichen, z.B. das Semikolon. Abschluss eines Wertesatzes über Sonderzeichen.

    4.) Die Werte selbst werden nicht mit Dezimaltrennungen versehen. Da es international nun mal Unterschiede bei der Verwendung von Komma und Punkt gibt, würde das insgesamt mehr Ärger als Nutzen bringen.
    Deshalb werden z.B. Spannung, Strom, Kapazität und andere elektrische Kennwerte als Tausendstel übertragen, also in mV, mA, mAh.

    Bis auf den Punkt 2.) erfüllt das bereits in LogView integrierte Datenformat 'Testformat Lader' diese Anforderungen. (Für Datenlogger gibt es das 'Testformat Logger'). Das Format geht im Moment von einer festen Länge von 44 Zeichen aus, das könnte man aber bei Bedarf flexibel halten. Für feste Längen ist die Verarbeitung in LogView generell schneller.

    An Punkt 2.), also die Erweiterbarkeit der Auswertung, kann man arbeiten.

    Zum Testen hier mal die Details des Datenformates 'Testformat Lader':
    (realisiert für max. 3 Kanäle)

    {-------------------------------------------------------------------------------
    Datenformatbeschreibung
    Schnittstelle: 9600 Baud
    8 Datenbits
    N keine Parität
    1 Stopbit
    Code:
     
    [FONT=Courier New]        1         2         3         4[/FONT]
    [FONT=Courier New]1234567890123456789012345678901234567890123 4[/FONT]
    [FONT=Courier New]k;tttttt;UUUUU;IIIII;CCCCCC;TTTTT;xx;y;zzz<cr><lf>[/FONT]
    [FONT=Courier New]k Kanalnummer (1, 2 oder 3)[/FONT]
    [FONT=Courier New]tttttt Zeit in Sekunden (neuer Datensatz beginnt bei 0) [/FONT]
    [FONT=Courier New]UUUUU Spannung in mV[/FONT]
    [FONT=Courier New]IIIII Strom in mA[/FONT]
    [FONT=Courier New]CCCCCC Ladung in mAh[/FONT]
    [FONT=Courier New]TTTTT Temperatur in 0.1°C Schritten[/FONT]
    [FONT=Courier New]xx Zyklusnummer (wenn keine Zyklen verwendet werden = 00 ansonsten[/FONT]
    [FONT=Courier New]steht dort halt die Zyklusnummer)[/FONT]
    [FONT=Courier New]y Status dezimal (0 = laden, 1 = entladen, 2 = Pause,[/FONT]
    [FONT=Courier New]9 = keine Aktion)[/FONT]
    [FONT=Courier New]zzz Erweiterungen (im Moment einfach 000 dezimal)[/FONT]
    
    Hinweise:
    ------------------------
    1) Die Daten kommen im Sekundentakt. Die Zeit beginnt bei 0 Sekunden !
    2) Wenn Spannung oder Strom nicht in 1000er Schritten zur Verfügung stehen,
    muss der Wert passend ausgegeben werden (10V = 10000 im Datenformat)
    3) Wird normal geladen / entladen ist die Zyklusnummer gleich 00. Werden
    Zyklen verwendet, beginnt der Zyklenwert mit 01.
    4) Der Status muss passend gesetzt werden. Für Laden, Entladen entsprechend
    0 bzw. 1 in dezimal ausgeben. Wenn der Lader eine Pause macht
    (z.b. zwischen Laden und Entladen), dann muss eine 2 gesendet werden.
    Macht der Lader nichts, also ist er mit seiner (Ent-)Ladung durch,
    dann sendet er 9.
    9 wird auch nach dem Start gesendet, erst wenn der Lader seine
    Arbeit aufnimmt, geht dieser Wert auf 0,1 oder 2.
    5) Die Erweiterungen sind im Moment ungenutzt. Hier einfach 000 dezimal senden.
    6) Die Kanalnummer ist bei Geräten mit einem Ausgang halt immer 1. Bei
    mehreren Ausgängen je nach Ausgangszahl.
    Jeder Kanal sendet trotzdem im Sekundentakt. Alternativ sendet jeder
    Kanal nur alle x Sekunden. Dabei muss aber auf die Zeit geachtet werden.
    Diese Zeitangaben müssen stimmen!
    7) Es können auch permanent Daten gesendet werden. In diesem Fall muss aber
    bei sinnlosen Telegrammen die Zeit auf 000000 stehen und der Status auf 9.
    -------------------------------------------------------------------------------}

    Und zur Vollständigkeit hier noch das Datenformat 'Testformat Logger':
    (realisiert für max. einen Kanal)

    {-------------------------------------------------------------------------------
    Datenformatbeschreibung
    Schnittstelle: 9600 Baud
    8 Datenbits
    N keine Parität
    1 Stopbit
    Code:
     
    [FONT=Courier New]        1         2         3         4[/FONT]
    [FONT=Courier New]12345678901234567890123456789012345678901234567 8[/FONT]
    [FONT=Courier New]k;tttttt;UUUUU;IIIII;CCCCCC;PPPPPP;TTTTT;y;zzz<cr><lf>[/FONT]
    [FONT=Courier New](48 Byte)[/FONT]
    [FONT=Courier New]k Kanalnummer (Hier immer 1)[/FONT]
    [FONT=Courier New]tttttt Zeit in Sekunden (neuer Datensatz beginnt bei 0) [/FONT]
    [FONT=Courier New]UUUUU Spannung in mV[/FONT]
    [FONT=Courier New]IIIII Strom in mA[/FONT]
    [FONT=Courier New]CCCCCC Ladung in mAh [/FONT]
    [FONT=Courier New]PPPPPP digitaler Zähler[/FONT]
    [FONT=Courier New]y Status dezimal (0 = laden, 1 = entladen, 2 = Antriebsmessung,[/FONT]
    [FONT=Courier New]9 = keine Aktion)[/FONT]
    [FONT=Courier New]zzz Erweiterungen (im Moment einfach 000 dezimal)[/FONT]
    
    Hinweise:
    ------------------------
    1) Die Daten kommen im Sekundentakt. Die Zeit beginnt bei 0 Sekunden !
    2) Wenn Spannung oder Strom nicht in 1000er Schritten zur Verfügung stehen,
    muss der Wert passend ausgegeben werden (10V = 10000 im Datenformat)
    3) Der Status kann passend gesetzt werden - muss aber nicht
    4) Die Erweiterungen sind im Moment ungenutzt. Hier einfach 000 dezimal senden.
    5) LogView startet die Aufzeichnung beim Erkennen einer 000000 in der Zeit und
    einem Wechsel im Status von 9 auf 0 oder 1 oder 2.
    Infos zu PPPPPP digitaler Zähler
    Dieser Zähler kann mit einer beliebigen Zahl beschrieben werden. So kann man
    hier z.B. einen Drehzahlmesser mit übertragen. Wichtig ist hier nur folgendes:
    Der Zähler wird von LogView nicht angepasst. Es müssen also (falls erforderlich)
    Berechnungen vom Logger vorgenommen werden!
    -------------------------------------------------------------------------------}

    Gruß, Holger
  3. Space

    Space New Member

    Hallo Holger,

    du sprichst mir so aus dem Herzen mit der Definition des Openformates. Punkt 1-4 stimme ich uneingeschränkt zu.
    Zu dem Punkt 2:
    Mal überlegen, was muss definiert werden für eine Erweiterung...?

    Also grundsätzlich erstmal muss definiert werden ob es sich um einen 'realen' Datenkanal handelt welcher vom Lader/Logger empfangen wird, oder um einen reinen rechnerischen Kanal der sich aus anderen Werten zusammenrechnet.

    Dann sollte als einfachste rechnerische Korrektur ein Faktor definierbar sein, welche 'default "1" ist.

    Die Einheit muss definiert werden, z.B. "eta" oder "RPM"

    Die "geografische" Lage im Datenframe, z.B. das die Daten nach dem 7'en Trennzeichen im Frame übermittelt werden.

    Was fehlt.....?




    'Testformat Lader' bzw. 'Testformat Logger':

    Ich gehe mal davon aus, das bei dem 'Testformat Lader' die Geschwindigkeit von 9600 einfach über das Ini file verändert werden kann? Stichwort Prozessortakt und RS232 Taktfehler...

    Wunsch währe noch, die X Achse (Sekunde) auch per Kanal zu übermitteln. Das hat den Vorteil dass ich Logview auch bei laufender Ladung/Logging nachträglich einschalten kann.

    Die Anzahl der Kanäle sind meiner Meinung nach zu gering, sonst würde ich mit Opencharge dort aufspringen. Ich würde gerne hier flexibel agieren, also auch mal eine Interne Variable auf einem Kanal ausgeben...definiert das ganze im INI File ;) .

    Ich denke das Interesse an einem Openformat beschränkt sich auf Personen mit eigenen Projekten (z.B. ich mit Opencharge) oder Gemeinschaftsprojekten wir Minilogger (V1/2) oder deren Derivaten.

    Vielleicht kann man ja mit einem offenen Format auch einen Standart setzen, so das zukünftig auch kommerzielle Hersteller ein Openformat verwenden oder warum erfindet jeder das Rad neu, wenn er etwas mit RS232 Schnittstelle auf den Markt bringt.


    Thomas
  4. Holger

    Holger LogView Team

    Hallo Thomas,

    Das ist doch im Datenformat für jeden Kanal schon separat drin:

    Ja, so isses.

    Kein Problem. Das läßt sich mit relativ wenig Aufwand auf 8 Kanäle aufbohren. Hat bisher nur niemand gebraucht.

    Das wäre ne feine Sache! :)

    Gruß, Holger
  5. Wolfi

    Wolfi New Member

    Ich habe hier einen Eigenbau SD Card Logger (FAT) mit PIC gebaut. Zeichnet momentan NMEA Daten vom GPS im Flieger auf. Können dann direkt mit LVGPS ohne Umwege dargestellt werden.
    Jetzt will ich natürlich noch 2x U, I, Kapazität, Drehzahl und Temp. erfassen und speichern.
    Habe eben oben das Testformat Logger angesehen, ist sicher sehr sinnvoll.
    Mir ist noch nicht ganz klar, wie ich die beiden Datensätze GPS-NMEA und Messdaten verheiraten soll.
    Im NMEA Format gibts ein proprietäres Format (tolles Wort):
    $Pxx,yyyyyyy,zzzzzzz,aaaaaa,bbbbbbbb,ccccc*cs
    Zeile hat max 82 Zeichen, Daten werden durch Komma getrennt,*cs ist Checksumme.
    Das wäre die einfachste Einbindung der zusätzlichen erfassten Daten.
    Und es wäre alles NMEA konform.
    Danach könnte ein kleines Programm unter Windows die $Pxx Daten-Sätze entnehmen und in Testformat Logger wandeln und als Datei für LV speichern.
    Jetzt bin ich mir nur nicht sicher ob LV solche Dateien lesen kann. Bekomme ich aber dann raus.
    Was haltet Ihr von meinem Vorhaben?
    Gruss
    Wolfgang
  6. Holger

    Holger LogView Team

    Hallo Wolfgang,

    hört sich interessant und gut an.
    Halte uns bitte auf dem Laufenden!

    Gruß, Holger
  7. Space

    Space New Member

    Hab mal ne Frage, wegen dem definierten Trennzeichen sollt die Byteanzahl pro Datenkanal eigentlich egal sein, oder?

    Beispiel:
    k;tttttt;UUUUU;IIIII;CCCCCC;PPPPPP;TTTTT;y;zzz<cr><lf>

    für ;tttttt; muss nicht ;000009; gesendet werden sondern es geht auch ;9;


    Der Print Befehl in Bascom verbraucht 228 Bytes mehr, als der Printbin Befehl. Diese 228 Bytes würde ich gerne sparen (das sind ~12% des ATTINY26 Speichers)....
    ..könnt ihr das in dem Teslogger/Lader Format implementieren das in dem Ini File auch konfiguriert werden kann ob ASCI Werte oder Binärwerte ausgewertet werden sollen?
    Das Trennzeichen ( ; sollte dann wohl als $H3B gesendet werden.

    TH
  8. Dominik

    Dominik Administrator Staff Member

    Moin !

    ein klares Nein.

    ein klares geht nicht

    Noch kurz ein paar Worte hierzu. Das Format ist im Moment sehr statisch. Also es werden bei der Auswertung direkt Positionen abgegriffen und nicht nach ; gesucht. BsP:
    Code:
    Ladungswert_mAh := StrToInt(Copy(Data,[B] 22,6[/B]));
    Ich könnte das natürlich alles umstellen. Das macht dann aber die Erkennung etwas schwieriger ob die ankommenden Daten denn auch wirklich gültig sind.

    Hmm, könnten wir sicherlich einbauen. Wobei man dann genau definieren sollte wie das genau ausschaut. Also wieviel Bytes hat dann die Zeit, die Spannung, etc. Und wie soll die ganze Sache umgerechnet werden?
    Sind 0500h dann 12,8V als Bsp?
    Vielleicht kannst du hier mal beschreiben wie nach deiner Vorstellung die Sache in HEX aussehen sollte. Dann schaue ich mal ob man das umsetzen kann.
  9. Space

    Space New Member

    Hy Holger,

    das klingt ja nicht so gut. Das ";" wird im Moment nur als Dummy mitgeführt.Das heisst man muss von der Loggerseite her, die Stopfnullen generieren. Das müsste unter Bascom dann so aussehen:
    Code:
    Dim S as String * 5
    S = Str(zahlenvariable)
    S = Format ( s; "00000")
    
    Das sind 168 Bytes extra unter Bascom, für die Formatierung eines 5 Byte Blocks. Für einen 4 Byte Block wird fast nochmal das selbe an Platz benötigt. Für 6 Byte Blöcke etc... das kann doch der Gigaherz Prozessor mit der 500GByte Festplatte viel besser als der Attiny26....der arme Atmel snüfff.:dontknow: Die Formatierung selbstgestrickt, bringt auch nicht deutlich mehr Ersparnis, das habe ich schon in Opencharge geprüft.
    Erinnere ich mich recht, LV ist unter Pascal programmiert. Ein einfaches "cut" gibt es dort nicht?:
    STROM=$( echo $LOGSTRING | cut -f 3 -d ";" )
    Ich denke da müsst ihr wirklich nochmal ran, um ein sauberes CSV Format auszuwerten, ansonsten kann man das nicht ein offenes Format nennen.:p



    Der Unterschied zwischen PRINT und PRINTBIN unter Bascom als Beispiel:
    Dim WERT as WORD
    WERT = 100
    print WERT ' ergibt "100" als Output
    printbin WERT ' ergibt "b" als Output, vom Terminalprogramm interpretiert
    Im Minilogger V1 wird das ganze so verwendet:
    printbin WERT_highbyte
    printbin WERT_lowbyte
    oder noch einfacher

    printbin WERT ' sendet WERT_lowbyte printbin WERT_highbyte

    Wenn ich mir die Logformate anderer in LV eingebundene Lader anschaue, kommt das bereits zur Anwendung, oder? Auch hier das selbe Thema, zwischen Print und Printbin sind das 218 Byte Flashspeicher.
  10. Thomas

    Thomas New Member

    Hi zusammen,

    ich will auch mal in die ´Kerbe von space schlagen. Im Moment ist es bei den universellen Testformaten (Lader / Logger) tatsächlich so, dass dem Sender mit der Aufbereitung der Daten eine gehörige Last aufgebürdet wird.
    Ich würde folgendes für ein offenes Format vorschlagen:

    K;T;X1;X2;X3;X4;X5;X6;X7;X8;CS<cr><lf>

    K...Kanalnummer (Integer von 1 bis 999)
    T...Zeit (Integer von 0-4294967296, also 32Bit ohne Vorzeichen, 1 entspricht 10ms)
    X1-X8...Werte (Integer 32Bit mit Vorzeichen, also -2147483648 bis 2147483647)
    CS...Prüfsumme (optional, 0-99, 0 wird immer als gültig anerkannt, CS-Berechnung noch festzulegen)

    Ausgabe als ASCII
    führende Nullen nicht erforderlich
    ; (Semikolon) als Trennzeichen für die Daten
    bei jedem Kanal wird die Zeit mitgesendet
    jeder Kanal umfasst maximal 8 Werte
    die Einheit für die einzelnen Werte und die Bedeutung der Kanäle wird in einem INI-File festgelegt
    eine Telegram ist maximal 115Byte lang

    Bsp. für das Inifile für Ladegeräte:
    [Kanal1]
    status=standby
    X1_name="Spannung"
    X1_skalierung="0.001"
    X1_einheit="Volt"
    X2_name="Strom"
    X2_skalierung="0.001"
    X2_einheit="Ampere"
    X3_name="Temperatur"
    X3_skalierung="0.1"
    X3_einheit="°C"
    X4_name=""
    X4_skalierung=""
    X4_einheit=""
    X5_name=""
    X5_skalierung=""
    X5_einheit=""
    X6_name=""
    X6_skalierung=""
    X6_einheit=""
    X7_name=""
    X7_skalierung=""
    X7_einheit=""
    X8_name=""
    X8_skalierung=""
    X8_einheit=""
    [Kanal2]
    status=laden
    X1_name="Spannung"
    X1_skalierung="0.001"
    X1_einheit="Volt"
    X2_name="Strom"
    X2_skalierung="0.001"
    X2_einheit="Ampere"
    X3_name="Temperatur"
    X3_skalierung="0.1"
    X3_einheit="°C"
    X4_name="Kapazität"
    X4_skalierung="1"
    X4_einheit="mAh"
    X5_name=""
    X5_skalierung=""
    X5_einheit=""
    X6_name=""
    X6_skalierung=""
    X6_einheit=""
    X7_name=""
    X7_skalierung=""
    X7_einheit=""
    X8_name=""
    X8_skalierung=""
    X8_einheit=""
    [Kanal4]
    status=entladen
    X1_name="Spannung"
    X1_skalierung="0.001"
    X1_einheit="Volt"
    X2_name="Strom"
    X2_skalierung="0.001"
    X2_einheit="Ampere"
    X3_name="Temperatur"
    X3_skalierung="0.1"
    X3_einheit="°C"
    X4_name="Kapazität"
    X4_skalierung="1"
    X4_einheit="mAh"
    X5_name=""
    X5_skalierung=""
    X5_einheit=""
    X6_name=""
    X6_skalierung=""
    X6_einheit=""
    X7_name=""
    X7_skalierung=""
    X7_einheit=""
    X8_name=""
    X8_skalierung=""
    X8_einheit=""

    Der Lader sendet jetzt z.B.
    1;100;12500;0;;;;;;0
    1;200;12400;0;;;;;;0
    --> der Lader ist im standby, sendet jede Sekunde, misst 12.5V und 0.0A, Temp wird nicht ausgegeben
    --> jetzt startet eine Entladung, der Lader sendet deshalb jetzt auf Kanal3
    3;300;11900;1000;;0;;;;;;0
    3;400;11900;1000;;1;;;;;;0
    -> sendet auch jede Sekunde, 11.9V, 1A, keine Temp., 0 bzw. 1mAh

    Ich denke, damit hätten wir einen guten Kompromiss für beide Seiten: Die Sender-Seite ist relativ resourcenschonend für Mikrocontroller, die Daten sind notfalls am Terminal lesbar, die Stringauswertung lässt sich mittels Abzählen der Semikolons erschlagen, bei 999 möglichen Kanälen lassen sich ausreichend viele Zustände abbilden

    Schöne Grüsse
    Thomas
  11. Dominik

    Dominik Administrator Staff Member

    Moin !

    So jetzt ists langsam Zeit für mich mal das Ruder in die Hand zu nehmen weil hier (wie ich meine) das ein oder andere aus dem selbigen läuft ;)

    @Space:
    Warum schreibst du Hallo Holger und antwortest auf mein Posting ? :)

    Soderle ...
    eins mal generell vorwech. Die beiden Protokolle Lader und Datenlogger sind entstanden, um Leuten eine einfache Mögliochkeit zu geben, ihre Bastelei mit LogView zum drehen zu kriegen. Diese Protokolle waren nie dazu gedacht (!) das sie alle möglichen Erdenklichkeiten berücksichtigen und obendrein auch noch in jeder Hinsicht frei konfigurierbar sein sollen.
    Wie gesagt das war nie (und wird auch nie) Absicht dieser Implementierungen.

    Worüber wir hier reden (oder sagen wir wo das hier hingeht) ist die Implementierung eines neuen Datenformats, was wesentlich komplexer ist, und in vielerlei Hinsicht weitaus flexibeler.
    Soweit mein Vorwort ...

    Klares JA

    Klar. Uns ist aus LV Sicht mehr oder minder vollkommen egal wie der Lader / Logger seine Daten sendet. Von uns aus kann er sie auch forher in Römische Zahlen wandeln und als ASCII codiert zum Rechner senden :cool:

    Nur um nochmal auf die beiden Testformate einzugehen. Es war niemals Absicht das die so viel können sollen und auch nicht so konfigurierbar sein sollten. Das mag nun dem ein oder anderen nicht gefallen, aber ich sage mal so ... Besser erstmal zwei einfache Formate als Nüscht.

    So, kommen wir mal zu dem Openformat. Ich finde die Bezeichnung goned zu übel. Ich könnte mir vorstellen dass das ein ganz neues Format werden könnte. Der Vorschlag von Thomas gefällt mir schon ganz gut weil eben sehr flexibel. Wenngleich da einige Details noch goned berücksichtigt sind:
    K...Kanalnummer (Integer von 1 bis 999)
    Oilda, was hast du vor? Wozu eine solch imense Menge an Kanälen?? Das könnte LV im Moment auch garnicht abbilden. Wir sind im Moment bei max. 10 Kanälen wenn ich das recht im Kopf habe. Und das ist schon ne ganze Menge. Kann man sicher erweitern, aber ich denke das reicht für normale Projekte, oder?
    Datensatztrennung
    Wie soll LogView entscheiden wann ein neuer Datensatz anfängt? Vielleicht sollte man das auch definieren können. Es ist ungünstig das LV sofort aufzeichnet, wenn Daten kommen. Da kriegt man ne Endloskurve ...
    Werte als HEX
    Man sollte wenn auch die Möglichkeit bieten, dass die Werte in ASCII und in HEX gesendet werden können. Das würde der Forderung von Space nachkommen.
    Stati
    Eine Möglichkeit irgendwelche Stati zu übergeben ist auch noch goned vorgesehen. Und vielleicht sollte es auch eine Möglichkeit geben, dass man Informationen als Text senden kann. Das könnte LogView durchaus auch verarbeiten und würde Möglichkeit geben, dass sich ein Gerät erstmal zu erkennen gibt. Z.B. durch das senden der aktuellen Firmware, etc
    Unter Stati generell würde ich aber auch sowas wie Gerätestati verstehen. Also Kanal läd, entläd, etc.

    Und man könnte auch die Beschränkung auf 8 Werte umgehen. In der INI definiert man einfach wieviele Werte der Kanal bietet. Und die werden dann auch von LogView eingerichtet und abgefragt.

    So und dann hamma aber generell ein Problem. Man kann das alles implementieren und das wird sicher keine schlechte Sache. Wenn ich recht überlege könnte man sogar Positionen angeben und vorhandene Datenformate damit mappen. :cool: Das wäre durchaus vorstellbar. Nur wer soll des olles testen? Weil man hätte ja eine Unmenge an Szenarien die man ausprobieren könnte. Wer würde sich da freiwillg melden?

    Ich könnte da höchstens anbieten ein kleines Testproggy zu schreiben, was diverse Formate generieren kann und senden kann. Das wäre dann aber nur die Grundlage für Tests.

    So und nun seid ihr mal wieder dran mit posten ... ;)
  12. Holger

    Holger LogView Team

    Ich sehe das auf alle Fälle auch schon als Diskussion zu einem neuen Open-Format an!

    @Thomas,

    bis auf die mögliche Kanalanzahl stimme ich zu. Da ist eine Begrenzung auf 8 programmtechnisch sinnvoll.

    Dafür könnte die Anzahl der Werte je Kanal durchaus höher sein, maximal 20. Diese Anzahl könnte man auch im ini-File festlegen.
    Insgesamt könnte man so also 160 verschiedene Werte übertragen.

    Für eine freie Umrechnung der Werte sollte anstelle von 'Skalierung' ein 'Offset' und ein 'Faktor' verwendet werden. So mache ich das auch bei den externen Eingängen des UniLog.

    Anzeigewert = (Datenwert - Offset) * Faktor

    Damit ist dann praktisch jede Umrechnung möglich und der Controller müsste die Werte überhaupt nicht anpassen oder vorausberechnen.

    Die flexible Trennung der Werte durch ein festes Trennzeichen, z.B. Semikolon, ist eigentlich gar kein Problem. Verwenden wir bei einigen Geräten ja auch schon.

    Der Vorschlag mit der Checksumme ist auch nicht schlecht. Den möglichen Bereich würde ich aber nicht so sehr einschränken.

    Gruß, Holger
  13. Dominik

    Dominik Administrator Staff Member

    Damit hast du 50% von dem wiederholt was ich kurz zuvor schrub :D
  14. Holger

    Holger LogView Team

    Na dann passts doch! :)

    Da haben sich unsere Antworten (fast) zeitgleich überschnitten. Dauert halt mit dem Analogmodem alles etwas länger! :mad:

    Gruß, Holger
  15. Thomas

    Thomas New Member

    Die Kanalnummern sind eigentlich mehr Identifikatoren und beinhalten den Status gleich mit.
    Bsp. Lader:
    1...Ausgang eins Laden, Strom, Spannung, Kapazität
    2...Ausgang eins Entladen, Strom, Spannung, Kapazität
    3...Ausgang zwei Laden NiMh, Strom, Spannung, Kapazität
    4...Ausgang zwei Laden LiPo, Strom, Spannung, Kapazität
    5...Ausgang zwei Entladen, Strom, Spannung, Kapazität
    6...Ausgang eins Fehler
    7...Ausgang zwei Fehler
    8...Eingangsspannung
    usw.

    Bsp. Logger:
    1...Fehler, keine weiteren Werte
    2...standby, Strom, Spannung, Temperatur
    3...standby, Drehzahl
    4...standby, Höhe, Steigrate
    5...Aufzeichnung, Strom, Spannung, Temperatur
    usw.

    Lasst uns mal den Ansatz verfeinern:

    $i;t;x1;x2;x3;x4;x5;x6;7;x8;cs;<cr><lf>

    Das ist ein Datentelegramm.
    1) Es fängt immer mit $ an.
    2) i ist der Identifier. Ein bis drei Ziffern. Muss vorhanden sein.
    3) t ist die Zeit zu der der Absender die folgenden Werte erhoben hat. Kann fehlen, wir dann vom Empfänger mit seiner Systemzeit beim Empfang ergänzt.
    4) x1-x8 die Werte. Wie oben beschrieben mit Vorzeichen. Können auch fehlen, die Semikolons müssen aber stimmen.
    5) cs ist die Prüfsumme. Muss gesendet werden. Ein oder zwei Ziffern, 0 ist immer gültig.
    6) <lf> ist das Endekennzeichen des Telegramms. Alle Zeichen zwischen der Prüfsumme und <lf> werden vom Empfänger ignoriert.
    7) das letzte Semikolon nach cs ist Absicht.

    Zum Trennen von Datensätzen dient das spezielle Telegramm:
    $0;;;;;;;;;;0;<cr><lf>
    Damit kann der Sender dem Empfänger gezielt sagen, dass ein neuer Datensatz anfängt.

    Mehr Werte pro Telegramm würde ich nicht zulassen. Ich will aus verschiedenen Gründen die maximale Länge eines Telegramms auf unter 128 Zeichen begrenzen.
    Faktor und Offset statt Skalierung im Ini-File sind ok.
    Ob die Werte als ASCII oder Hex codiert werden ist aus Sicht des Mikrocontrollers egal. Wenn dann müsste man die Daten binär senden, aber dann sind wir schon wieder ein ganzes Ende weg von "universell".

    Ach ja, die Ähnlichkeit der Telegramme zu NMEA-Sätzen ist verblüffend...

    Gruss
    Thomas
  16. Dominik

    Dominik Administrator Staff Member

    Grosser Einspruch. Das würde bedeuten wir hätten nur einen Kanal. Das ist Murks. Ich würde sagen, generell ist dein i eine gute Idee. Das entspricht meiner Vorstellung von einem Stati. Auch das mit 0 = neuer Datensatz ist ok.

    Aber da muss noch eine Kanalnummer vor. Weil sonst hat ein Lader mit 2 Kanälen ein Prolem das auch mitzuteilen!

    Das kannst du ja auch nachwievor machen. Wenn ich in der INI definiere
    Code:
    maxValues K1 = x
    dann kannst du dir das so einstellen wie du magst. Auch deine X1-X8 Situation ist damit ohne Stress abbildbar. Und Leute die mehr wollen können das tun.

    Ich würde das Format wenn gerne richtig offen und flexibel halten. Sonst gehen hinterher wieder Diskussionen los "Ich will aber dies und das ...". Das sollte man dann von Anfang an vermeiden ;)
  17. Thomas

    Thomas New Member

    Das sollen Sie aber nicht tun dürfen, wenn sie innerhalb der specs bleiben wollen. Neben Logview sollen auch noch andere die übertragenen Daten auswerten können. Und diese anderen haben vielleicht etwas weniger Ressourcen zur Verfügung.
    Das verstehe ich nicht. Wieso hat der Lader ein Problem das mitzuteilen?

    Gruss
    Thomas
  18. Dominik

    Dominik Administrator Staff Member

    Moin !

    Hach endlich mal wieder Diskussionen mit dir ... Wie habe ich das vermisst in deiner Abstinenzzeit :D

    Öhm, man kann es doch erstmal flexibel halten. Und man kann ja eine Empfehlung dazugeben was sinnvoll ist und was mit den meisten Softwaren lesbar ist. Wie gesagt, dein vorgeschlagenes Format ist ja ohne Stress zu realisieren. Nur wer eben mag kann das Format weiter aufbohren oder eben nach seinen Vorstellungen nutzen. Da kann ja nix gegen sprechen, oder?
    Meine Vorstellung von so einen OpenFormat ist eben ein sehr flexibeles Gerüst. Und nicht ein Konstrukt was von Anfang an wieder diverse Einschränkungen hat.

    Wo soll er das denn tun? Mit deinem i willst du ja den Status übermitteln. Wo sagt ein Lader dann das die gesendeten Daten z.B. für seinen 2ten Ladeausgang gelten? Status + 100??
  19. Thomas

    Thomas New Member

    Zum Beispiel.

    Ist doch nur eine Definitionsfrage im Ini-File. Beispielsweise ein Lader mit zwei Ausgängen. Ausgang eins kann nur Konstantstrom laden, Ausgang zwei ein bisschen mehr. Ausgang zwei kann sogar Einzelspannungen messen.

    i=1 ... Ausgang 1 standby (kein Akku)
    i=2 ... Ausgang 1 laden, Spannung, Strom
    i=3 ... Ausgang 2 standby
    i=4 ... Ausgang 2 laden Lipo, Spannung, Strom, Kapazität, Temperatur
    i=5 ... Ausgang 2 laden Lipo, Einzelspannung Zelle1-6
    i=6 ... Ausgang 2 laden FePo, Spannung, Strom, Kapazität, Temperatur
    i=7 ... Ausgang 2 laden FePo, Einzelspannung Zelle1-6
    i=8 ... Ausgang 2 entladen, Spannung, Strom, Kapazität, Temperatur

    Der Lader sendet:
    $1;100;;;;;;;;0
    $3;100;;;;;;;;0
    eine Sekunde Pause
    $1;200;;;;;;;;0
    $3;200;;;;;;;;0
    eine Sekunde Pause
    Laden wird gestartet (3Zellen FePo, jede Zelle hat 2.5V, der Pack also 7.5V, geladen mit 1A)
    $0;;;;;;;;;;;0
    $1;350;;;;;;;;0
    $6;350;750;100;0;21;;;;;0
    $7;350;250;250;250;;;;;;;;;0
    eine Sekunde Pause
    $1;450;;;;;;;;0
    $6;450;750;100;1;21;;;;;0
    $7;450;250;250;250;;;;;;;;;0
    usw. (die Semikolons habe ich jetzt nicht gezählt)

    Flexibilität ist gut und soll. Aber irgendwo gilt es einen Kompromiss zu finden. Das Datenformat soll u.a. erweiterbar sein. Aber bitte so, das es dann abwärtskompatibel bleibt. D.h. dass ein "alter" Empfänger einen "neuen" Sender auch versteht. Aber halt nur die Sachen, die der "alte" Empfänger gelernt hat. Wenn jetzt jemand daher kommt und plötzlich 9 oder 10 Werte in ein Telegramm packt kommt der Empfänger durcheinander, weil er keinen so grossen Datenpuffer hat und das Ende nicht findet. Nicht jeder Empfänger der Daten lässt sich über ein Ini-File steuern. Bei machen gehts nur hard-coded. Wenn jetzt (um beim Beispiel oben zu bleiben) ein neues Telegramm mit i=9 dazukommt ist das kein Problem für den alten Empfänger, das neue versteht er halt nicht, den Rest schon.
    Das Datenformat soll einfach sein. D.h. der Sender muss die Daten einfach und ohne viele Klimmzüge aufbereiten können (Stichwort führende Nullen), der Empfänger soll die Daten prüfen können (Prüfsumme). Das Format soll kompakt sein (auch führende Nullen, Werte die nicht gebraucht werden - das kostet alles nur Zeit bei der Übertragung).

    Gruss
    Thomas
  20. Holger

    Holger LogView Team

    Hallo Thomas,

    den Verzicht auf eine Kanalnummer und die Beschränkung auf maximal 8 Werte empfinde ich als ziemliche Einschränkung, was das Format dann kann.

    Wie soll man denn i festlegen, damit man alle möglichen Fälle von vornherein abdeckt? Wenn man eine Kanalnummer voranstellen würde (entspricht der Zuordnung zu einem Ausgang eines Laders), dann könnte man i beliebig erweitern, ohne an Grenzen zu stoßen, die nach Deinem Vorschlag durch den nächsten Kanal gegeben wären.

    Ok, das sind zwei Byte mehr ( k; ) , aber ich denke das könnte es wert sein.

    Die Begrenzung auf eine bestimmte Werteanzahl (z.B. 8) ist auch etwas unbefriedigend, finde ich.
    Wenn man für eine Geräteserie (Stichwort hardcoded) abwärtskompatibel bleiben möchte, dann muss man halt bei einer einmal festgelegten Anzahl bleiben, ob nun 4 oder 6 oder 8 ...
    Erweiterungen für neue Geräte könnte man dann immer noch über zusätzliche, neue i einführen.

    Obwohl, wenn ich mir's recht überlege (hab mir viel Zeit genommen), dann könnte man wirklich mit 8 Werten auskommen und das dann über i quasi 'umschalten'.
    Also z.B. bei i=1: Spannung, Strom, ....
    Bei i=2 dann Höhe, Drehzahl, Temperatur1, Temperatur2, ...
    Sinnvollerweise sollte das (wenn möglich) bei gleicher gemeldeter Zeit erfolgen, um Probleme bei der Auswertung und Darstellung zu vermeiden.

    Die entscheidende Frage dazu ist halt wirklich, ob man sich den begrenzten Möglichkeiten eines empfangenden Controllers beugt oder die Grenzen deutlich weiter steckt!

    Gruß, Holger

Share This Page