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

  1. Space

    Space New Member

    Nun möchte ich auch mal wieder....
    Es scheint so, als ist die Diskusion ins Stocken geraten. Da ich derzeit an der nativ RS232 Software für den Minnilogger arbeite, habe ich da ein gewisses Interesse an der schnellen Realisierung des Openformates.
    Wenn ich micht nicht Täusche sind nur 4 Punkt auf Basis des letzte Vorschlags von Thomas (der andere ) offen:

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

    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.
    1. Die Entstehung der Prüfsumme is noch nicht definiert
    2. Definition der Kanalnummer im Identifier integriert (Thomas) oder als extra Wert?
    3. Begrenzung auf max. 8 Werte sinnvoll?
    Trennung von Datensätzen, Vorschlag von Thomas $0;;;;;;;;;;0;<cr><lf>

    Zu 1. , der Prüfsumme
    Einfach und pragmatischer bewährter Vorschlag, eine Bytevariable bei der Aufsummierung aller Werte überlaufen lassen:´

    bytvariable=0
    bytvariable = wert1 + bytevariable
    bytvariable = wert2 + bytevariable
    bytvariable = wert3 + bytevariable
    etc....
    Prüfsumme = bytevariable

    Es ist kein Beinbruch, wenn trotz richtiger Prüfsumme aber 2 falschen Werten die trotzdem eine richtige Prüfsumme ergeben trotzdem in LV zur Anzeige kommen, deshalb sollte als Prüfsumme ausreichend sein und ist leicht in Loggern/Ladern realisierbar.


    Zu 2. , Kanalnummer
    Vorschlag von mir, da auch für Menschen leichter Lesbar, den Kanal als extra Wert zu übermitteln. Also:
    $K;i;t;x1;x2;x3;x4;x5;x6;7;x8;cs;<cr><lf>
    K = Kanalnummer
    i = Identifier des Staus. Die Stati sind wie von Thomas vorgeschlagen im Inifile frei als Text definierbat. Z.B: Stati 1 = Laden FePo , 2 = laden NiMh etc...


    Zu 3. , nur 8 Werte?
    Ich verstehe das Argument von Thomas (der andere) auch nicht richtig. Die Möglichkeit in Logview mehr als 8 Werte darzustellen muss nicht genutzt werden aber sollte auf jeden Fall vorhanden sein. Es besteht ja immer die Möglichkeit im INI File nur 8 Werte zu definieren.


    Zu 4. , Trennung von Datensätzen
    Der Vorschlag von Thomas schaut doch gut aus $0;;;;;;;;;;0;<cr><lf>
    Zusätzlich sollte ein neuer Datensatz erkannt werden, wenn folgende Bedingung erfüllt ist:
    t_alt > t_neu , also immer wenn der gerde gelesene Timewert kleiner ist als der zuletzt empfangene. das hat so auch schonmal beim Pulsarformat so funktioniert, wurde Logview aber leider in den neueren Versionen wieder aberzogen.

    Wo können wir nun einen Haken drann machen?
  2. Holger

    Holger LogView Team

    Da kann ich im wesentlichen nur zustimmen!

    Thomas?


    Wenn im ini-File nur eine Namenszuordnung zu den Stati erfolgt, also keine Information an LogView enthalten sind, worum es sich dabei
    eigentlich genau handelt, kann man keine weitergehenden Berechnungen oder ähnliches erwarten. Es wird dann also nur dargestellt, was über die Schnitsttelle reinkommt und es ist kein LV-eigenständiges Berechnen von z.B. Leistung oder Energiesumme möglich. Denn ausgehend von Thomas Vorschlag kann dann ja mal Spannung, Strom, Kapazität, ... und dann wieder Einzelzellenspannungen kommen.
    Es ist mir noch nicht klar, wie das funktionieren soll. Ich halte das für zu wenig Information für LV. Wie soll man bei ständig wechselnden Stati z.B. wissen, welche Stati gemeinsam und welche getrennt dargestellt werden müssen?
    Es könnte also notwendig werden, im ini-File wenigstens eine Gruppierung oder nähere Bestimmung von Stati vorzunehmen.

    Gruß, Holger
  3. Space

    Space New Member

    Huhu Holger,

    musst du nicht vorschlafen? :D :eek:

    OK, ich bin wieder sachlich....;)

    Für die Berechnungskanäle habe ich ja schon mal vorgeschlage diese auch im INI File definieren zu wollen:

    Beispiel für eine Leistungsberechnung

    X20 = X1(I) * X2 (U)

    oder (Energie)Summen

    X21 = X3(old) + X3(new)

    Hierfür einen Syntax im INI File zu definieren, welche für LV leicht auswertbar ist, scheint hier die Herausforderung zu sein.

    Mir persönlich sind aber diese "errechneten" Kurven nicht so wichtig.

    Thomas
  4. Dominik

    Dominik Administrator Staff Member

    Moin !

    So jetzt ich :rolleyes:

    Also ich kann Space auch nur zustimmen. Ist letztlich das was Holger und ich ímmer wieder plediert haben. Aus meiner Sicht kann man da so einen Haken dran machen.
    Kernaussage von uns war ja auch immer:
    - Kanal extra in einem Byte
    - Anzahl Werte ja nach INI Datei

    Doch ich denke schon. Zunächst mal stimme ich dem zu was Space da schreibt. Man könnte einfache mathematische Zusammenhänge in der INI definieren. Dafür müssen wir dann einen kleinen Parser schreiben der das auswerten kann.
    Und ich bin gerade am überlegen ob es nicht sogar machbar wäre, in der INI Datei gleich die richtigen Variablen Namen abzulegen die für die Berechnungen dann nötig sind. Mir schwebt da etwas vor. Und zwar kann man auch aus Listenaufzählungen Einträge in einer INI Datei sichern. Ich habe das schon mal geproggt. Diese Listeneinträge (z.B. type TLVDeviceID) lassen sich direkt wieder verwerten obwohl das ja eigentlich nicht geht. Da gibts zwei Funktionen für.
    So wenn man nun dort direkt Variablen angeben könnte, dann hätte man ja schon einiges gewonnen ...

    Und zu den Stati, nunja da kann es nur so sein dass das das Gerät überwachen muss (müssen da jetzt wirklich 3* das hin :eek: ). Es ist halt immer so das die Trennung wie Space schon schrub bei $0;;;;;;;;;;0;<cr><lf> und t_alt > t_neu erfolgt. Dazwischen können die Stati meinethalben nach Gusto wechseln. Da muss jeder dann selber wissen wie er damit klar kommt. Den Stati könnte man dann wieder mitführen als Grafik und Tabelle wie beim Akkumatik.

    So, ich mach mich mal auf die Suche bezüglich der Variablen in INI ablegen Sache ;)
  5. Holger

    Holger LogView Team

    Im Prinzip schon, das stimmt natürlich. Aber man ist halt immer so unvernünftig... :eek: :D

    Gruß, Holger
  6. Wolfi

    Wolfi New Member

    Hallo Openformat Definierer,
    habe eben mal Eure Beiträge gelesen, klingt ja jetzt am Ende alles sehr gut. Bin schon auf das Ergebnis gespannt, da auch ich gerne mit dem Openformat arbeiten will. So ich geh jetzt mal zwei Wochen in Urlaub (ohne Laptop). :)
    ...übrigens GPS NMEA Format verwendet XOR Verknüpfung für die Check-Summe. Vorteile ?
    Und in Eurem Fall: $i;t;x1;x2;x3;x4;x5;x6;7;x8;cs;<cr><lf>
    vom i bis einschließlich dem ; vor der Check-Summe.

    Viel Erfolg,
    Wolfgang
  7. Thomas

    Thomas New Member

    So, ich auch mal wieder, schön das es weitergeht!

    Kanal & Status:
    Wieviel Kanäle und Stati sollen denn erlaubt sein? (sprich wieviel Ziffern im Telegramm) Wegen mir können wir die auch trennen, ich bin aber nach wie vor der Meinung, dass das Telegramm dadurch unnötig länger wird.

    Anzahl der erlaubten Werte (und damit maximale Länge des Telegramms):
    Ich habe mir durchaus was gedacht, als ich gesagt habe, ein Telegramm soll nicht länger als 120Byte sein. Dabei spielt nicht nur der Puffer eine Rolle, wenn ein Mikrocontroller das Telegramm empfangen soll. Beim Senden ist es genauso.
    Ausserdem wollen wir ja offen für die Zukunft sein: Es gibt schon eine Diskussion den Minilogger drahtlos mit einem PPC auszulesen. Dazu würde ein einfacher & billiger Funktransmitter. Der Nachteil dieser Technik: Die Transmitter können im allgemeinen nur Blöcke <128 Byte übertragen. Ein längeres Telegramm müsste also vom Sender auch noch extra gesplittet werden.
    Oder werde ich falsch verstanden? Ich möchte nicht generell nur 8 Werte übertragen. Ich möchte nur, dass pro Telegramm nur 8 Werte erlaubt sind. (Bzw.: Das die maximale Telegrammlänge begrenzt ist). Halt so wie bei NMEA. Hier ist ein Telegramm (bzw. NMEA-Satz) auf 82 Byte begrenzt. Trotzdem lassen sich viel mehr Daten übertragen, weil am Anfang steht was folgt, z.B. GPRMC oder GPGGA usw.

    Prüfsumme:
    Völlig egal. Nach meiner Erfahrung sind sowohl die "BytesSummenüberlauftechnik" als auch die XOR-Methode völlig ausreichend.

    Gruss
    Thomas
  8. Space

    Space New Member

    Ups, hier stockt es wieder, dabei wartet der Minilogger doch auf eine schönesAnzeigeprogramm :)

    Checksumme:
    Da wir uns alle einig sind, daß die Checksumme am Frameende keine so wesentliche Bedeutung hat, können wir hier denke ich einen Haken anmachen. In der neuen Miniloggerversion habe ich (glaube ich..) mit einem Byteüberlauf das ganze realisiert. Haken drann :)


    128 Byte maximal pro Frame:
    Mir persönlich fehlt das praktische Beispiel, in dem mehr als 128 Byte/Frame ein Problem darstellen. Ich würde vorschlagen wir vertrauen hier Thomas (mal :D) und gehen davon aus das mehr als 128 Byte ein Einschränkung im Openformat bedeuten würde. Das heist es muss ein Verfahren definiert werden, in dem die Frames fragmentiert übertragen werden können.
    Das Framefragmentierung kann nur funktionieren, wenn Logview zusammenhängende Frames erkennt. Vorschlag, kein extra Sequenzbyte einführen, sondern in dem Stati-Byte das mit unter zu kriegen.

    Kanal & Status:
    1 Byte Kanal
    1 Byte Status
    ..sollte doch reichen, wenn der Bytewert zählt und nicht der ASCII Wert
    Vorschlag :

    1 ist nicht 1 sondern 49 Dezimal
    Die oberen 2 Bit im Statibyte sind für die Fragmentierungsnummerierug vorgesehen. Die unteren 6 Bit, dienen dem Stauscode.
  9. Dominik

    Dominik Administrator Staff Member

    Moin !

    Etwas. Hat aber auch einen Grund (zumindest bei mir). Ich baue gerade einen Quadcopter und da sind einige Tests nötig. Da muss LV im Moment ein ganz bisserl hinten an stehen. ;)

    Ich sehe da generell gokein Problem. Wenn man meint man muss unter 128 Byte bleiben dann sendet man eben so viele Werte wie man im Telegramm unter bekommen kann.
    Wie schon öfter geschrieben ist es doch eine reine Konfigurationssache der INI Datei, was denn im Format übertragen wird und was später angezeigt wird. Und wenn jemand 20 Werte übertragen will und nicht auf die 128 Byte achten muss kann er das eben auch tun.

    Ich möchte die aktuellen erkenntnisse nochmal zusammenfassen. Weil wir müssten ja auch wenn irgendwann mal mit der Umsetzung beginnen und uns nicht tot diskutieren ;)

    Also:
    $k;i;t;x1;... bis xN;cs;<cr><lf>

    1) Es fängt immer mit $ an.
    2) i ist der Identifier / Status. Ein bis drei Ziffern. Muss vorhanden sein und muss (!) in der INI Datei zum Openformat definiert werden !!
    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.
    Es muss in der INI Datei auf jeden Fall der TimeStep angegeben werden. Sonst kann LV das nicht sauber berechnen.
    4) x1-xN die Werte. Wie oben beschrieben mit Vorzeichen. Können auch fehlen, die Semikolons müssen aber stimmen. Die ANzahl der Werte wird in der INI Datei festgelegt. Max. sind derzeit (wenn ich nicht irre) 20 Kurven pro Kanal in LogView möglich. Also hätten wir hier auch eine kleine Einschränkung.
    5) cs ist die Prüfsumme. Muss gesendet werden. Ein oder zwei Ziffern, 0 ist immer gültig. Checksumme kann man immer noch einbauen in LV. Das sehe ich auch erstmal als unkritisch. Sollte aber vorgesehen werden.
    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.
    8) k ist ein Byte und definiert den Kanal. LV kann im Moment max. 10 Kanäle verarbeiten. Die ANzahl der Kanäle muss in der INI Datei definiert werden!
    9) Fragmentierungen sollten aus LV Sicht vermieden werden. Das bedeutet nämlich das wir die Pakete extra verwalten und ggf. zusammensetzen müssen. Wenns eben geht sollten wir das erstmal vermeiden.
    10) Der Status ist während eines Datensatzes veränderbar, hat aber keinen Einfluss auf die Datensatztrennung. Der Status nach $0;;;;;;;;;;0;<cr><lf> definiert den Datensatznamen!
    11) $k;0;;;;;;;;;;0;<cr><lf> beginnt einen neuen Datensatz für Kanal k. Additiv überwacht LV die Zeitabstände zwischen den Telegrammen und fängt einen neuen Datensatz an falls die aktuelle Zeit < als die letzte Zeit ist.

    Die INI Datei sieht in etwa folgendermassen aus:
    Code:
    #######################################################################
    ##                     Openformat Einstellungen                      ##
    #######################################################################
    ## Welches Gerät ist angeschlossen?                                  ##
    [B][Gerät][/B]
    Name      = OpenFormat
    TimeStep_ms   = 1000
    KanalAnzahl   = 1
    WerteAnzahl   = 6
    ## Der Seperator ist frei wählbar. Warum auch nicht ... :-)
    Seperator   = ;
    ## Wir könnten hier mehrere Möglichkeiten bieten die man einstellen kann
    ## Die Auswertung macht dann LogView
    ## XOR, ADDIEREN, ...
    Prüfsummenberechnung  = XOR
    ## Damit LV unproblematisch die Stati lesen kann muss die Anzahl 
    ## angegeben werden!
    StatiAnzahl   = 5
     
    [B][Stati][/B]
    ## Die Stati sind letztlich nur Texte. Damit LogView die lesen kann
    ## müssen die führenden Nullen gesetzt werden! Sonst kann das Stress
    ## beim Einlesen geben. 
    001    = Laden (Normal)
    002    = Laden (Reflex)
    003    = Entladen
    004    = Auffrischen (E-L-E-L)
    005    = Akku zerstören :-)
     
    ## Konfiguration der seriellen Schnittstelle                         ##
    ## Der Port steht in der Settings.INI !! > globale Einstellung       ##
    ## Stopbits: 0 = 1 Stopbit, 1 = 1.5 Stopbits, 2 = 2 Stopbits      ##
    ## Parität:  0 = None, 1 = Odd, 2 = Even, 3 = Mark, 4 = Space        ##
    [B][serielle Schnittstelle][/B]
    Baudrate   = 9600
    Datenbits   = 8
    Stopbits   = 0
    Parität    = 0
    #ClusterSize negativ bedeutet variable ClusterSize !!
    #Bei variabler ClusterSize wird hier der erwartete Maximalwert mit
    #negativem Vorzeichen angegeben!!
    #(Bei Unsicherheit lieber etwas mehr)
    #ClusterSize null bedeutet ClusterSize unbekannt!!
    ClusterSize      = 44
    ## Hier wird das Zeichen angegeben, das am Ende eines Telegramms steht 
    ## - wird nur bei variabler Telegrammlänge benötigt
    ## - das letzte Zeichen im Telegramm muss (!) dafür immer gleich sein
    ## LF = 10 dez.      CR = 13 dez.    -1 = variabel aber kein LineEndChar 
    LineEndChar   = -1
    SetDTR                   = 0
    SetRTS                   = 0
    ## TimeOuts                  ##      
     
    [B][Schnittstelle TimeOuts][/B]
    ##DelayTime :      in Mikrosekunden
    ##ExtraDelayTime : in Millisekunden
    RTOCharDelayTime  = 2000
    RTOExtraDelayTime        = 400
    WTOCharDelayTime         = 50
    WTOExtraDelayTime  = 500
     
    [B][Anzeige Einstellungen][/B]
    ## Konfiguration der Ausgänge und der übermittelten Größen           ##
    ## Hier wird jede Messgröße mit allen nötigen Werten versorgt        ##
    ## die man in LogView brauchen könnte.          ##
    ## Hier steht also alles für die Tabelle, die Gauges, die            ##
    ## Buttons über der Grafik, etc.                                     ##
    Zeitbasis1 = Zeit
    Einheit1 = s
    Symbol1 = t
    ## genereller Aufbau einer Messgröße                ##
    ## Hinweis zu xxx11 erste Zahl = Kanal(1-8), zweite = Nummer der Messgröße(1-12)##
      ## *** Globale Datenbeschriftung ***
      ## hier steht ein informativer Name
     
    ## Zeit, Spannung, Strom, Temperatur
    ## nicht in Grafik: Lade-/Entladestatus, Gerätenummer
    ## zusätzliche 3: Ladung [mAh], Leistung [W], Energie [Wh]
    ## Spannung, Strom, Ladung [mAh], Leistung [W], Energie [Wh]
    Messgröße11  = Spannung
    Skalierung11  = 0.001
    Offset11  = 0.0
    Faktor11  = 1.0
    Einheit11  = V
    Symbol11           = U
     
    Messgröße12  = Strom
    Skalierung12  = 0.001
    Offset12  = 0.0
    Faktor12  = 1.0
    Einheit12  = A
    Symbol12           = I
     
    Messgröße13  = Ladung
    Skalierung13  = 1.0
    Offset13  = 0.0
    Faktor13  = 1.0
    Einheit13  = mAh
    Symbol13           = C
     
    Messgröße14  = Leistung
    Skalierung14  = 0.1
    Offset14  = 0.0
    Faktor14  = 1.0
    Einheit14  = W
    Symbol14           = P
     
    Messgröße15  = Energie
    Skalierung15  = 0.1
    Offset15  = 0.0
    Faktor15  = 1.0
    Einheit15  = Wh
    Symbol15           = E
     
    Messgröße16  = Temperatur
    Skalierung16  = 0.01
    Offset16  = 0.0
    Faktor16  = 1.0
    Einheit16  = °C
    Symbol16           = T
     
       ## *** Tabelle ***
    ## TabellenWerte: Anzahl der Spalten der Datentabelle
    ## (nur die ersten vier können auch analog angezeigt werden)
    TabellenWerte1 = 7
       ## Überschrift der Tabellenspalten
    Tabellenüberschrift10 = Zeit [s]
    Tabellenüberschrift11 = Spannung [V]
    Tabellenüberschrift12 = Strom [A]
    Tabellenüberschrift13 = Ladung [mAh]
    Tabellenüberschrift14 = Leistung [W]
    Tabellenüberschrift15 = Energie [Wh]
    Tabellenüberschrift16 = Temperatur [°C]
     
       ## *** Analoganzeigen, Gauges ***
    ## GaugeBeschriftung: steht unter der analogen Anzeige
    ## MaxWert: maximal Wert des Gauge (min ist immer 0)
    ## Teiler: Anzahl der Unterteilungen
    ## HINWEIS:
    ## MaxWert / GaugeTeiler muss eine gerade Zahl ergeben
    ## sonst kommt es zu Anzeigefehlern bei den Analoganzeigen !!!
    GaugeBeschriftung11 = Spannung
    GaugeEinheit11      = V
    GaugeSymbol11       = U
    GaugeMaxWert11     =12 
    GaugeTeiler11     =2
     
    GaugeBeschriftung12 = Strom
    GaugeEinheit12      = A
    GaugeSymbol12       = I
    GaugeMaxWert12     =2
    GaugeTeiler12     =2
     
    GaugeBeschriftung13 = Ladung
    GaugeEinheit13      = mAh
    GaugeSymbol13       = C
    GaugeMaxWert13     =50
    GaugeTeiler13     =2
     
    GaugeBeschriftung14 = Leistung
    GaugeEinheit14      = W
    GaugeSymbol14       = P
    GaugeMaxWert14     =30 
    GaugeTeiler14     =6 
     
       ## *** Grafik ***
    ## die Beschreibung des Buttons
    ## wird gesetzt wenn die Achse nach dem Start sofort sichtbar ist ('Linie' Button ist gedrückt)
    ## Spannung, Strom, Ladung [mAh], Leistung [W], Energie [Wh]
    GrafikButton11 = Spannung
    GrafikAktiv11 =0
    GrafikButton12 = Strom
    GrafikAktiv12 =1
    GrafikButton13 = Ladung
    GrafikAktiv13 =1
    GrafikButton14 = Leistung
    GrafikAktiv14 =0
    GrafikButton15 = Energie
    GrafikAktiv15 =0
    GrafikButton16 = Temperatur
    GrafikAktiv16 =0
    Ich habe die INI absichtlich mal auf einen Kanal beschränkt.

    @Holger:
    Wir müssen uns dann mal überlegen wie wir die Infos im Stream ablegen können. Vermutlich müssen grosse Teile der INI mit in den Stream, oder?

    So habe ich da jetzt was wesentliches vergessen?
  10. Space

    Space New Member

    Das Ansinnen von Thomas (der andere:) ) ist ja, bei einem Lader/Logger welcher aus welchen Gründen auch immer (z.B.Blutoth), auf 128 Bytes in der Übertragung beschränkt ist, mehr Daten zu übermitteln als es in den 128 sonst möglich ist. => Framefragmentierung


    Der Erste Wert im Frame, wird der generell als Zeitbasis herangezogen? Alternativ könnte für den Messstandbetrieb auch LV eine interen Zeitbasis (Realtime) generieren. Das ganze muss im INI File konfigurierbar sein.


    Ansonsten giere ich nach der Umsetzung, das schaut sehr "Open" aus, und Stati 5 ist ein Muss :D
  11. Holger

    Holger LogView Team

    @Dominik
    Auf alle Fälle! Das wird noch ein ganz besonderer Spaß! :eek: :p

    Finde ich persönlich echt blöd! Macht nur Ärger! Aber wenn das wirklich wichtig ist, da müssen wir uns wohl was einfallen lassen. :rolleyes:
    Das Problem ist ja nicht, das zu verstehen, sondern das elegant im internen Datenhandling von LV unterzubringen. Und ganz besonders die Fehlerbehandlung ist dadurch nicht sonderlich lustig. Viel Arbeit, von der man an der Oberfläche zum Schluss nicht mehr viel sieht.

    Stimmt. Und genau deswegen reicht es meines Erachtens für ein vollkommen offenes Format nicht aus, den Stati nur Namen zuzuweisen. Da muss noch mehr Information reingepackt werden oder etwas spezielles festgelegt werden.

    Dann sieht man aber bei reiner Textanzeige (z.B. Hyperterminal) evtl. nicht mehr viel, wenn bereits das zweite Byte verstümmelt angezeigt wird oder ein ASCII-Steuerzeichen ist.

    Das wäre so eine Festlegung, mit der man was anstellen könnte. Man könnte dann auf der Empfangsseite die Daten zusammensammeln und einer Zeit (Timestamp) zuordnen, bis die empfangene Fragmentnummer nicht mehr steigt.
    Nicht korrekt empfangene oder fehlende Fragmente könnten z.B. durch Nullen aufgefüllt werden.
    Was macht man, wenn Frames fehlen und danach aber nix mehr ankommt? Timeout setzen?

    Mit einem "extra Sequenzbyte" könnte man das ganze offen gestalten (also mehr als nur vier mögliche Frames) und komplett lesbar halten.
    Nachteil wäre aber, dass immer eine Fragmentnummer gesendet werden müsste, auch wenn die Fragmentierung gar nicht genutzt wird.

    Evtl. lässt sich aber auch die Beschreibung der Nutzung des Status in das INI-File verfrachten, um möglichst offen zu bleiben. Also z.B. eine Maske, die den eigentlichen Status und die Fragmentnummer trennt.
    Mit "Fragmentmask = 100" könnte man dann mit der Übertragung der Werte "1;" , "101;" , "201;" den Status 1 und die Frames 0, 1, 2 kennzeichnen und hätte die Stati 0 bis 99 zur Verfügung.

    Mit "Fragmentmask = 10" und Übertragung der Werte "1;" , "11;" , "21;" würde man Status 1 und die Frames 0, 1, 2 kennzeichnen und hätte die Stati 0 bis 9 zur Verfügung.

    Für den Fall, dass man aus irgendeinem Grund nur 64 Stati festlegen will, dann muß die Fragmentmask eben auf den Wert 65 gesetzt werden.

    Gruß, Holger
  12. Space

    Space New Member

    Eine Realisierung scheint recht aufwendig zu sein. Sollten wir nicht grundsätzlich nochmal darüber abstimmen ob es ein "Must" ist?

    Da muss Thomas sich mal melden und die Funktion "verteidigen" ;) .

    Wegen mir muss die Funktion nicht implementiert werden. Eventuell später....?
  13. Holger

    Holger LogView Team

    Nun ja, den Ärger werden wir schon in den Griff bekommen.
    Wenn wir immer so schnell aufgeben würden, gäbe es LogView gar nicht. :)

    Die Implementierung der Framefragmentierung muss ja nicht als erstes geschehen, aber das Konzept muss klar sein.

    Wie stehts denn um meinen Vorschlag der konfigurierbaren Framemaske?
    Man könnte damit alles offen halten, reinen ASCII-Text senden, es bleibt alles lesbar und man könte schön auf $ als Startzeichen synchronisieren.

    Gruß, Holger
  14. Thomas

    Thomas New Member

    Och nö, es geht doch auch so voran.
    Wenn ich Holgers Vorschlag richtig verstanden habe ist er "nur" einen winzigen Schritt von meinem Vorschlag entfernt...damit könnte ich wohl leben.
    Holger, vielleicht kannst Du den jetzigen Stand mit Deinem Vorschlag nochmal zusammenfassen?

    Ich denke ja. So war jedenfalls mein Vorschlag. Wenn der Wert fehlt (nicht gesendet wird) setzt der Empfänger seine lokale Zeit ein.

    Gruss
    Thomas
  15. Space

    Space New Member

    Da ist er ja.....:)

    Aber woran erkennnt LV das der erste Wert im Frame kein Timewert ist?

    Das ganze muss man ihm in der INI sagen "INTERNALTIME=yes" ansonsten wird der erste Wert im ersten Fragment als Zeitwert angesehen.
    Ich habe in der Richtung noch nichts im INI-Vorschlag von Dominik gefunden.

    @Holger
    Die Idee mit der Maskierung ist super, da sehr universell ohne den Frame zuseher zu vergößern.
  16. Dominik

    Dominik Administrator Staff Member

    Moin !

    Wenn der TimeStamp angegeben ist hat LogView eigentlich alles zur Berechnung der Zeit.
    Ein Eintrag wie du ihn vorschlägst Space wäre aber sicher eine brauchbare Ergänzung. ;)
  17. Space

    Space New Member

    Das heistt wenn "TimeStep_ms = 1000", wird automatisch der erste Wert als Zeitwert gehandelt.
    Und was sollte man bei "Timestamp_ms =" angeben, damit die Zeit intern generiert werden soll? Die Definition sehe ich nicht....
  18. Thomas

    Thomas New Member

    @space:
    Du brauchst nur die Semikolons zu zählen.

    Gruss
    Thomas
  19. Space

    Space New Member

    ..also wenn mehr Werte/Semikolon kommen, als definiert sind, wird davon ausgegangen das der erste Wert die Zeit enhält?
  20. Thomas

    Thomas New Member

    nee,

    $k;i;t;x1;... bis xN;cs;<cr><lf> mit Zeit (t)
    $k;i;;x1;... bis xN;cs;<cr><lf> ohne Zeit (kein t)

    Gruss
    Thomas

Share This Page