Discussion in 'OpenFormat' started by franc.marx, Jun 18, 2007.

  1. franc.marx

    franc.marx New Member

    Hallo an alle,

    für den Betrieb von LV an so mancher Hardware, bei der es wichtig ist hohe Datenmengen auszugeben und mitzuloggen schlage ich ein Binärformat vor.

    Um höchste Nutzdatenrate zu erreichen also schlank und kompakt wie nur möglich, d.h. Infos Kanalnummer, Meßbetrieb etc. nur optional.

    Vorschlag für den Paketaufbau:
    SYNC,DATA....,CRC

    SYNC: könnte aus 1-3 bytes bestehen: z.b. FF,AA oder AA,55 oder 55,AA,55
    DATA: Binärdaten mit 8,16 oder 32 bit, signed oder unsigned
    CRC: CRC8 sollte reichen, ansonsten optional auch einen CRC16

    Bei diesem Paketaufbau wird/sollte sich LV spätestens nach einem Paket synchronisiert haben, d.h. auch beim Aufschalten von LV in eine bereits laufende Übertragung.

    Was meint Ihr dazu?

    Gruß
    Franc
  2. wkrug

    wkrug New Member

    Das wird dann ein sehr schlankes Format.
    Wie sollen in deinem Format verschiedenartige Nutzerdaten gekennzeichnet werden ?
    Du willst ja vermutlich Char (8Bit) Int (16Bit) und Long Int (32Bit) und eventuell auch Float Zahlen miteinander mischen ?
    In einem Frame sollte das auch möglich sein.
    z.B. Für eine Spannung reicht mir ein Int, für die Drehzahl gibts dann ein Long Int.
    Wenn es tatsächlich um hohen Datendurchsatz geht würd ich zwischen den einzelnen Werten auch kein Trennzeichen verwenden. Also müssten die Datenlängen in der Ini eingestellt werden.

    z.B.
    WERT1=Spannung=Int (Alternativ "16")
    WERT2=Drehzahl=Long Int (Alternetiv "32")
    WERT3=Strom=Int (Alternativ "16")
    WERT4=Blattanzahl=Char (Alternativ "8")
    WERT5=Temperatur=signed Int (Alternativ "-16"??)
    ...
    usw.
    Ich würd auch nicht unbedingt "krumme" Bitzahlen nehmen auch wenns den Code um ein paar Bit kürzer machen würde. Also keine 7Bit Zahlen oder 13Bit.
    Ein vielfaches von 8 wäre meiner Meinung nach ein guter Ansatz, ein vielfaches von 4 wär auch noch OK.
    Natürlich kommte es drauf an, ob das in Logview so möglich ist, aber das kann nur Dominik beantworten.

    Die 3 Sync Bytes find ich auch OK, eventuell sollten es aber 3 Verschiedene sein Vorschlag: AA 55 CC
    Man kann aber auch was anderes nehmen.
    Ich vermute, das Du auch ohne Steuerzeichen auskommen willst (<CR><LF>).
    Da Du aber die Anzahl der Zeichen in der Ini drin hast (Summe der Bytes aus der Definition) kannst Du die Synchronisation wunderbar durch die Startbytes finden.
    Also nach jedem Übertragenen Frame ein Sync senden, das sollte es gewesen sein.
  3. franc.marx

    franc.marx New Member

    Hi,

    der Aufbau des Frames muß in der *.ini exakt definiert sein. Darin steht die Bitlänge und ob signed/unsigned.

    Von Float würde ich absehen, da es auf unterschiedlichen Systemen/Compilern eine vielzahl unterschiedlicher Formate gibt.

    Kein Trennzeichen, für was auch?

    Krumme Bitzahlen verlangsamen nur die Zusammenstellung/Aufbereitung der Sendedaten.

    Gruß
    Franc
  4. wkrug

    wkrug New Member

    Dann wären wir beide zu 100% der gleichen Meinung.
    Mal schaun, was die anderen Forumsteilnehmer noch dazu sagen.
    Bei der Checksumme würd ich mich auf die 8Bit Checksumme beschränken.
    Ich kann in einer 16Bit Checksumme nicht wirklich einen frappierenden Vorteil entdecken.
    Die Checksummenbildung ist, soweit ich auf dem aktuellen Stand bin, mit Überlaufverfahren oder EXOR möglich. Auch 00 = ohne Checksumme ist möglich.
    Ich persönlich bin ein EXOR Fan, weil man bei der Kontrolle nur das gesendete Byte mit den Daten verwursteln (EXOR) muss und im Gutfall als Ergebnis "0" erhält.
    Die Frage ist nur noch, bezieht man die Syncbits (z.B. AA 55 CC) in die Berechnung mit ein oder nicht.
    Beim ASCII Format ist das Startzeichen "$" mit dabei.

    Ob man beim Binär Format nicht doch noch eine Kanalinformation, Stati und Zeitstempel vorsehen sollte ist noch so eine Frage ??? - als abschaltbare Option wärs sicher nicht schlecht.
  5. franc.marx

    franc.marx New Member

    Hi,

    zum Thema Checksum:
    da im Binärformat die SYNC-Zeichenfolge theoretisch auch vorkommen kann
    und u.U. auch dann noch die CHECKSUM stimmt, meine ich daß eine
    CRC8 sehr sinnvoll wäre. Letztere läßt sich auch auf kleinen Controllern
    mit wenigen Befehlen rechnen.
    => sehr gute Sicherung des Frames bei minimalem Rechenaufwand.

    also am besten wahlweise XOR-CHKSUM oder CRC8 in der *.ini einstellen.

    Gruß
    Franc
  6. wkrug

    wkrug New Member

    CRC8 ist schon OK, aber auch da könnte theoretisch bereits in den Werten der Sync String auftauchen.
    Nachdem also mal eine Synchronisation gefunden wurde, müsste nur kontrolliert werden, ob der Sync String noch an der richtigen Stelle sitzt und im Fehlerfall neu Synchronisiert werden.
    Ausserdem musst du bei CRC8 das Äquvalent, also die Methode und die Startwerte genau definieren, da gibt es nämlich sehr viele Möglichkeiten.
    Das ist auch ein Grund, warum ich persönich CRC Methoden nicht so gerne mag.
    Bei den 1Wire Chips wird auch eine Checksumme nach CRC brechnet, soweit ich weiß ist das aber CRC16 (lang ists her...).
    Am besten gleich ein Codeschnipsel in ASM für die gebräuchlichen Controller (ATMEL + PIC) in der Definition mit reinstellen.

    ASM sollte sich in fast jeder Entwicklungsumgebung einbauen lassen und es würden wirklich alle User nach dem selben Schema rechnen.
  7. Space

    Space New Member

    Mir fehlt da für mich im Moment der praktische Bezug....kannst du mal Anwendungsbeispiele nennen, welche trotz hoher Baudrate auf der RS232 ein Problem haben die Daten im Livebetrieb zu übertragen?

    Thomas
  8. franc.marx

    franc.marx New Member

    wkrug:
    CRC8 läßt sich mit einer einfachen 256-Byte Tabelle und ein paar Operationen sehr schnell berechnen.

    Eine einfache Checksum ist bei einem binärformat zu unsicher, möchte hier nicht auf die theoretischen Hintergründe eingehen. Mit CRC8 bei Paketlängen von bis zu 50 Byte in Verbindung mit einem 2-3Byte SYNC ist die Sicherheit schon sehr sehr gut.

    space:
    Anwendungsbeispiel ist z.B. Echtzeitmeß- und Rechendaten aus einem Microcontrollersystem herauszuholen.
    Beispiel: 30 Variablen(16bit) je 1ms Zykluszeit mitloggen

    Gruß
    Franc

Share This Page