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

  1. Space

    Space New Member

    Die 2 ;; sind pfui :goth: , weil sie das Aufbauschema (CSV) durchbrechen und in einer For Next/Schleife im Microprozessor des Loggers eine Sonderbehandlung erfordern.
  2. Thomas

    Thomas New Member

    Aha?
    Dann speichere mal eine Datei als CSV und schau sie Dir im Texteditor an. Und wieso soll eine Sonderbehandlung erforderlich sein?

    Gruss
    Thomas
  3. Space

    Space New Member

    ..das bezog sich nicht auf das technisch/syntaktisch richtige CSV, sondern auf. Es war die meschliche Lesbarkeit gemeint.

    Zurück zur Ursprungsfragestellung die da war:

    Wie erkennt Logview das eine interne Zeit generiert werden muss und nicht der erste empfangene Wert die Zeit/timetick darstellt
    Antwort:
    Durch 2 ;; , sprich ein Wertfeld ohne Wert.

    Das finde ich nicht schön aber ich beuge mich zur Not der Übermacht. Einfacher würde ich es finden, wenn in der INI Logview mitgeteilt wird, das Wert1 nicht die Zeit ist sondern diese intern generiert werden soll.

    Bei der Errechnung der Checksumme zählt "leer" dann wohl als 0.
  4. Dominik

    Dominik Administrator Staff Member

    Moin !

    Öhm Jungs nix für ungut, aber wir diskutieren hier eigentlich etwas vollkommen triviales.

    Also in der INI Datei gibt es zwei Einträge:
    TimeStep = xxxx ms
    TimeGiven = YES / NO

    So damit könnte man sehr einfach alles konfigurieren.
    Ist TimeGiven = NO wird über den TimeStep die Zeit von LV berechnet.
    Ist TimeGiven = YES aber der Wert = 0 weil da zwei ;; stehen, dann berechnet ebenfalls LV.
    Ist TimeGiven = YES und ein Wert zwischen den beiden ;; dessen Position ja bekannt ist, dann nimmt LV die Zeit eben. Fertig is der Laden. So können alle Senden wie sie mögen.
    TimeStep muss aber immer definiert sein. Dann muss LV nicht zwischen den Telegrammen die Zeit stoppen. Aber der Sendeinterval sollte eh bekannt sein.
  5. Thomas

    Thomas New Member

    Hm, also langsam blicke ich nicht mehr durch. Sorry.
    Ich denke, es soll en "open"-Format werden dass möglichst universell ist? Jetzt soll auch noch der timestep angegeben werden. Was ist, wenn der Sender den exakten Abstand zwischen zwei Telegrammen nicht immer einhalten kann, dafür aber im Mittel über einen längeren Zeitraum betrachtet?
    Ich fürchte, dass ganze wird so nichts weil es mittlerweile viel zu kompliziert ist. Jetzt wird auch plötzlich wieder die "menschliche Lesbarkeit" in den Vordergrund gerückt - vorher wollten wir ein kompaktes Format. Diese Sachen wiedersprechen sich nunmal.

    Vielleicht sollten wir wieder von vorne Anfangen, und zwar mit einem Lastenheft was das Format können muss, was es können sollte und vorauf wir verzichten.

    Gruss
    Thomas
  6. Dominik

    Dominik Administrator Staff Member

    Moin !

    Hmm ist es das nicht? Man kann alles nach seinen Vorstellungen konfigurieren denke ich ...

    Das ist LV Standard. Das hat jede Geräteunit.

    Tja, dann müssen wir eben noch eine Möglichkeit schaffen, dass die Zeit zwischen den Telegrammen berechnet wird. Ist auch machbar. Dann gäbe es eben noch eine Möglichkeit mehr.

    Sehe ich nocht so. Ich denke wir haben schon ne ganze Menge zusammengetragen. Es muss nur mal in eine komplette Auflistung geschrieben werden. Mal sehen ob ich das heute mal machen kann.

    Hmm, was dann sag doch mal was aus deiner Sicht nicht passt. Oder was du jetzt als unnötig erachtest.

    Ich zitiere mal dein erstes Posting zu dem Thema:
    Code:
    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)
    Das haben wir doch bis auf ein paar Kleinigkeiten 1:1 umgesetzt. Ok, Kanal ist gesplittet und hat jetzt noch den Status, aber ansonsten is doch genau dein Vorschlag umgesetzt.
    Dazugekommen sind nur ein paar Kleinigkeiten die es noch flexibeler machen.

    Und Holger wird heute noch was zu fragmentierten Paketen schreiben. Wir werden das doch supporten.
  7. Space

    Space New Member

    Also für mich ist dasb Thema mit dem Post gestern von Dominik abgehakt.
    Damit bin ich eigentlch wunschlos glücklich :)
  8. wkrug

    wkrug New Member

    Jetzt muß ich dann doch noch mal blöd nachfragen...
    Die Integer Werte werden dann aber als ASCII Werte übertragen ?

    Das würde die Lesbarkeit mit einem Terminal Programm extrem vereinfachen.
    Ich find das für den Entwickler, bei der Fehlersuche, einfacher als sich mit nicht lesbaren Sonderzeichen rumzuschlagen.
    Zeichnet man dann noch die Daten auf, wäre es ein leichtes dieses Format in EXCEL zu importieren und die Auswertung dort zu fahren (Pfui kein LogView ;) ).
    Die Übertragungsgeschwindigkeit kann ja noch erhöht werden, bei DMX 512 machen die 250kBit/sec mit nem Microcontroller.

    Als Checksumme würde ich das EXOR Verfahren anwenden und die Summe als normales Byte übertragen. Das Additions Überlauf Verfahren wäre aber auch kein Problem für einen Microcontroller.

    Die .ini Datei muss dann wohl auch für jede Eigenentwicklung neu definiert werden ?
    Vieleicht wäre es möglich eine universelle einheitenlose .ini mit 8 Kanälen zu generieren.
    Wenn sich der Microcontroller Programmierer an die Vorgabe dieser .ini hält braucht er zum testen an Logview selber nichts zu ändern.
    Hat man erstmal 5 bis 6 verschiedene .ini beisammen, wird es dann doch ein ganz schönes gepfriemel mit der Einbindung in eine neue Logview Version.
  9. Dominik

    Dominik Administrator Staff Member

    Moin !

    Also es wird zwar nicht so ganz leserlich, aber man wird schon was erkennen können. Im Telegramm stehen eben keine Float Werte (also mit Nachkommastelle), sondern nur gaze Zahlen die eben mit einem gewissen Faktor behaftet sind. Lesen kann man das schon im Terminal.
    Mal sehen vielleicht kann man da auch was zu definieren ... Muss ich mir mal überlegen.

    Und was die INIs angeht. Da haben Holger und ich die Idee, das die INI Datei mit in LOV Datei geschrieben wird. So hat man immer die richtige INI zur Datei. Wie wir die Auswahl machen welche INI Datei beim Starten eines neuen Projekts denn Verwendung findet steht noch nicht fest. Aber da hät ich gerade auch schon eine Idee.

    Also noch ein bisserl abwarten. ;)
  10. wkrug

    wkrug New Member

    Nö, eilt nicht ich hab da schon noch genug zu tun.
    Es wäre schön, wenn die Details geklärt sind und das Protoll steht eine Newsletter an die Logview User zu schicken.
  11. wkrug

    wkrug New Member

    Ich hätte da noch einen Vorschlag zu machen.
    Wie wärs, wenn man Anstatt des letzten ; ein anderes Steuerzeichen oder ein zusätzliches für ein fertiges Frame nehmen würde z.B die #.
    Dann könnte der Microcontroller eine Checksumme ermitteln, obwohl er die Länge des gesamten Protokolls nicht zu kennen braucht.
    Und die Methode würde auch flexible Datenlängen zulassen.
    Ich bin zwar auch kein Protokoll Experte, verspreche mir aber dadurch eine noch höhere Flexibilität und eine einfachere Programmierung für den Microcontroller.

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

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

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

    wobei die letzte Variante natürlich wieder den CSV Standard untergräbt und die Vorherige 1Byte mehr übertragen muß.

    In die Checksummenbildung würden dann alle Bytes zwischen $ und # mit einbezogen.
  12. Wolfi

    Wolfi New Member

    Hallo,
    der Vorschlag von wkrug wird übrigens bei NMEA GPS Format auch so gehandhabt. Dort ein *

    Hier mal drei Datensätze aus meinem SD-Logger Prototyp für GPS-Daten (erste beiden Zeilen). Ferner Höhe aus Druck (Meter über Startpl.), Empfängerspannung(mV), Motorstrom(A), Motorspannung(mV) in $PLOGG, dritte Zeile, CS hat noch gefehlt.
    Die ersten beiden Zeilen verarbeite ich in :) LogViewGPS :) , geht sehr gut, die dritte wird überlesen ist auch gut so.

    Könnte die dritte in das Universalformat umprogrammieren, schön wäre es wenn dann die beiden GPS Zeilen dazwischen das Universalformat nicht stören würden. Bitte daran denken.

    $GPGGA,144747.000,4742.9008,N,00926.7363,E,1,11,0.7,538.2,M,48.0,M,,0000*56
    $GPRMC,144747.000,A,4742.9008,N,00926.7363,E,9.07,70.78,260307,,*38
    $PLOGG,118,5581,43,20469,*
    $GPGGA,144748.000,4742.9015,N,00926.7400,E,1,11,0.7,544.9,M,48.0,M,,0000*57
    $GPRMC,144748.000,A,4742.9015,N,00926.7400,E,10.22,78.01,260307,,*00
    $PLOGG,125,5610,44,20539,*
    $GPGGA,144749.000,4742.9018,N,00926.7444,E,1,11,0.7,551.4,M,48.0,M,,0000*52
    $GPRMC,144749.000,A,4742.9018,N,00926.7444,E,11.40,91.62,260307,,*0B
    $PLOGG,131,5568,43,20479,*

    PS: Steigflug eines 5m-ThermikXXXL mit 6,3kg

    Da $Pxxxx bei NMEA zulässig ist kann man diese Datei auch problemlos in .kml Datei für Google earth wandeln. Sollte dann aber mit einem Universalformat dazwischen auch kein Problem machen. Mit selbst geschriebenen Konverter-Programm eh nicht.

    Gruß
    Wolfgang

    Also immer schön auch an dem Uni-Format dran bleiben, es besteht Bedarf.;)
  13. Dominik

    Dominik Administrator Staff Member

    aktueller Stand neu zusammengefasst

    Moin !

    Ich habe mal den aktuellen Stand zusammengefasst und hoffe nix vergessen / übersehen zu haben.

    Würde alle bitten, das mal zu lesen und zu verifizieren.
    @Holger: Wir sollten uns am Donnerstag mal Gedanken dazu machen was ich unter "offene Punkte" geschrieben habe ...

    Attached Files:

  14. Space

    Space New Member

    Also ich finde alles (fast) so wieder, wie ich es mir vorstelle.

    Allerdings kann ich mich mit dem " # " als Trennzeichen vor der CS nicht unbedingt anfreunden.

    Der Microcontroller weiss doch am besten, wann die Daten gesendet wurden und er die Checksumme raushauen muss. Der muss doch den Datensatz nicht parsen....:p

    In dem Minilogger sende ich die Daten in einer For Next Schleife immer im Format
    <Daten> <Trennzeichen> macht in Bascom PRINT Variable ; ";" ;

    Wenn ich nun vor dem Senden der CS das Trennzeichen verändern musss, ist das mehr Aufwand!


    Gut finde ich die Idee das eine NULL als Checksumme immer als gültig gilt. Das macht in Anwendungen wo die Fehlerfreiheit egal ist und die Resourcen sehr beschränkt sind, die Sache einfacher.


    Einen Wizard oder eine GUI für die Erstellung der INI Files halte ich nicht für notwendig. Derjenige welcher eine Anwendung für das Openformat entwickelt, wir sicher nicht an dem erstellen des INI-Files scheitern.
  15. Dominik

    Dominik Administrator Staff Member

    Moin !

    Nuja das mit dem # war wkrug´s Vorschlag. Mir ist es letztlich egal wie wir das machen. Generell muss ich aber sagen das durchgehende Trennzeichen einfacher zu handhaben sind. Aber das sind auch nur 3 Zeilen Code mehr bzw. weniger ;)

    Vielleicht kann wkrug ja nochmal was dazu schreiben ob das unbedingt erforderlich ist.
  16. wkrug

    wkrug New Member

    Nein, absolut erforderlich ist das '#' oder ein anderes Trennzeichen nicht.
    Ich dachte es wäre halt einfacher im Sendetelegramm nach einem Steuerzeichen zu suchen und dann bis dahin eine Checksumme auszurechnen.
    Ein weiterer Vorteil wäre eine flexible Datensatzlänge.
    Denn es wäre ja dann egal ob ein Datensatz dann 5 Werte oder 20 überträgt, weil ein Ende ja mit einem eindeutigen Trennzeichen definiert ist.
    Wie Logview mit sowas klarkommt ist wieder eine andere Sache.

    Ich hätte noch eine Frage zur Checksummenbildung.
    Wie soll die aussehen ?
    Wenn Logview eine Gegenrechnung machen soll müssen wir uns da schon auf ein Verfahren festlegen.
    Mein Vorschlag wäre eine EXOR Checksumme für Jedes Byte zwischen dem '$'(wird nicht in die Berechnung einbezogen) und inklusive dem letzten ';'.
    Es wäre natürlich auch eine Summenüberlaufmethode denkbar, also ASCII 1.Zeichen + ASCII 2. Zeichen + .......+ ASCII letztes Zeichen.
    Die entstehenden Codes können dabei natürlich ausserhalb des ASCII Codes liegen und auch den Steuerzeichenbereich des PC's beeinflussen.
    Um aber den vollen HEX bereich als ASCII zu übertragen zu können bräuchte man 3Zeichen (000...255) oder man benutzt die HEX Darstellung (00...FF).
    Wobei natürlich die HEX Darstellung mit einem Microcontroller einfacher zu realisieren ist - Wie schaut das bei Logview aus ?
    Durch die Prüfsummenbildung bin ich auch auf die Idee mit dem Datensatzendezeichen '#' gekommen, weil da bräuchte ich ab dem '$' nur so lange EXOR machen (bzw. addieren), bis eine '#' auftaucht, ohne die eigentliche Länge des Strings zu kennen.
    Ein kleines Problem gibt es auch noch in 'C' - da wird ein Datensatzende als ASCII 0 eingesetzt. Folglich sollte des ASCII Code 0 nicht im Telegramm auftauchen - natürlich kann man das aber auch in C umgehen wenn man die String Funktionen austrickst, oder man verwendet die Übertragung der Prüfsumme als (HEX-) ASCII.

    Ich hoffe meine Überlegungen sind für alle nachvollziehbar.
    Schön wäre es wenn die strittigen- unklaren Fragen bald geklärt würden, dann könnte ich schon mal einen ersten Protokollversuch proggen.

    Ich kämpf zur Zeit mit den Funkmodulen (RFM01, 02) von Pollin rum.
    Die Dokumentation für diese Teile ist wirklich besch....eiden.
    4 Datenblätter lesen, die man nicht ausdrucken kann um die nötigen Informationen rauszufiltern macht nicht wirklich Spaß.
    Wenn das läuft, könnte man schon mal an eine erste Applikation für Logview denken.
    Wie wär ein Telemetriesender ?
  17. Gromit

    Gromit New Member

    Hallo zusammen

    Ich bin zurzeit daran, Unilog Live-Daten per 2.4Ghz auf ein am Boden stationiertes Display zu übertragen. Der Empfänger sollte das empfangene natürlich in irgend einer Form auf eine SD-Card bringen. Die Idee ist, das Logview die Daten dann entsprechend anzeigen kann. Darum eine Frage; ist das diskutierte Open-Format wie angegeben von in der aktuellen Version Logview lesbar?

    Zusätzlich zu den von Unilog bekannten Werten kommen noch solche für die Empfangsstärke der beiden Funkmodule etc.

    Herzliche Grüsse
    Uwe
  18. Holger

    Holger LogView Team

    Hallo Uwe,

    Nein, das Open-Format ist noch nicht in LogView umgesetzt und somit nutzbar.

    Ist aber für die nächste Zeit geplant!

    Gruß, Holger
  19. Dominik

    Dominik Administrator Staff Member

    Moin !

    Tja da war Holger mal schneller als ich ... Sowas :rolleyes:

    @wkrug:
    Naja wir können da mehrere Verfahren einbinden. No Prob. Guggst du hier in der InI Datei:
    Weil LogView ist es vollkommen egal wie und was es zur Prüfsumme heran ziehen soll. Das ist nur eine Funktion mehr.

    Hmm, selbst wenn es so wäre. Man könnte für diesen Fall eine extra Behandlung einführen. Die eben checkt ob am Ende ein chr(0) ist. Wenn der Rest passt wäre das kein Problem.

    Das ist Shit equal :D Du kannst senden wie du magst:
    Schaut sich eigentlich gokeiner die Textdatei mit dem Format mal genau an :p ?

    Mich würde noch die Meinung von Thomas interessieren ob er mit dem aktuellen Vorschlag leben kann.
  20. Dominik

    Dominik Administrator Staff Member

    erste Ergebnisse ...

    Moin Jungs !

    Tja was lange wehrt wird endlich langsam gut :D
    Schaut mal die Datei im Anhang.

    Ich sach nur ... OpenFormat Auswertung in LogView. Zu grossen Teilen schon dynamisch aufgebaut anhand der INI Datei. Faktoren und Offsets werden auch schon sauber ausgewertet.
    Ich glaube ich habe da morgen was am Start :cool:

    Nachtrag ...
    Habe auch einen kleinen aber feinen OpenFormat Simulator geschrieben. Der is noch nicht ausgereift, aber er tut schon was er soll. Und denn noch meine verwendete INI ...

    Attached Files:

Share This Page