Baudrate RS232 herausfinden

Da Einfachste ist mit einem Oszilloskop die Zeit fuer ein Bit zu messen.

Michael Glaser schrieb:
> Kann mir einer sagen, welche Baudrate es ist?

ja, "geloggt" mit 115k (test_115.log)

was drin steckt, das ginge mit der richtigen Baudrate loggen oder Oszi 
und beim loggen ansehen.

Für alle i∈[0,98] hat das Byte an der Position 4+260·i den Wert 53+i.

Zufall?

Wenn nicht, dann hast du die richtige Baudrate bereits gefunden.

Wenn du etwa dreimal so viele Daten (also statt 5 ca. 15 Sekunden)
aufzeichnest, müsste dieses Zählerbyte irgendwann überlaufen. Falls dann
eines der beiden Nachbarbytes inkrementiert wird, kannst du ziemlich
sicher sein, dass die Daten mit Absicht so aussehen und damit die 115200
Baud stimmen.

Ich hab mir das File mal mit nem simplen Textviewer angeschaut. 
Interessant die rot eingerahmte Spalte. Fällt da was auf? ;)
Das ist viel zu viel System für ne zufällige Zeichenfolge aufgrund 
falsch eingestellter Baudrate. Ich denke daher, dass die 115 kBd schon 
völlig korrekt sind, nun muss man nur noch herausfinden, was die Daten 
zu bedeuten haben.

Christian M. schrieb:
> Hei, super beobachtet.

Das geübte Programmierer-Auge erkennt sofort die ASCII-Tabelle, wenn es 
sie sieht. ;)

Die enthält ja nur 00- und E0-Bytes. Da war deine erste Datei spannender 
:)

Was für eine Antwort erwartest Du?
Die Baudrate scheint immernoch zu passen.
Wie die Daten zu interpretieren sind, musst Du wissen.
Vielleicht kann hier jemand dabei helfen, wenn Du sagst woher die Daten 
stammen...

Michael Glaser schrieb:
> Habe es mit 115k probiert.
Warum?
Hast du es auch mal mit anderen Baudraten "probiert"? Es gibt ja nicht 
allzuviele "genormte"...

So auf die Schnelle:

Man kann die Daten ähnlich wie im ersten Beispiel in Abschnitte
unterteilen, die sich in ähnlicher Form wiederholen. Allerdings waren
diese Abschnitte im ersten Beispiel 260 Byte groß, jetzt sind es nur
noch 256 Byte. Außerdem werden vor dem ersten dieser gleichartigen
Abschnitte noch Daten übertragen, die nicht in dieses Schema passen
(vielleicht eine Art Startmeldung).

Wie im ersten Beispiel enthält jeder dieser Abschnitte eine Art
fortlaufende Nummer. Im erste Beispiel wurde diese von 53 bis 151
hochgezählt. Da diese Zahlen mit 8 Bit darstellbar sind, war es nicht
klar, ob diese Nummer aus einem einzelnen oder aus mehreren Bytes
bestehen (s. mein Beitrag vom 30.5.). Im neuen Beipiel kann man
erkennen, dass die Nummer aus zwei Bytes im Little-Endian-Format
zusammengesetzt ist. Ihr Wert reicht von 11 bis 2372.

Der Bytestrom enthält somit eine aufsteigende Sequenz von über 2000
16-Bitzahlen, die kaum durch falsche Abtastung entstanden sein kann. Die
115 kbaud würde ich damit als endgültig gesichert ansehen.

Vielleicht schaue ich mir die Daten heute Abend noch einmal etwas
genauer an.

Darf man fragen, von welchen Geräten diese Daten stammen?

Michael Glaser schrieb:
> Habe ich das richtig verstanden: beim ersten, kurzen Log sind es
> 260Zeichen zwischen Anfangs- und Endzeichen. Jetzt, beim 2ten Log, sind
> es 256 Zeichen?

Es gibt keine expliziten Anfangs- und Endzeichen und auch keine
Prüfsumme zur Erkennung von Übertragungsfehlern, was bei einem auf
RS-232 laufenden Kommunikationsprotokoll schon etwas seltsam ist.

Hier sind ausschnittsweise drei Beispieldatensätze aus der neuen
Log-Datei:

1

<——————————————————————————————— 256 Bytes ———————————————————————————————>

2

0b 00 ... 91 01 00 8d 02 00 7b 23 01 ... 2d 05 64 47 ... 64 49 8b ... 00 00

3

0c 00 ... 95 01 00 8d 02 00 7b 24 01 ... 2d 05 64 3d ... 64 49 8b ... 00 00

4

0d 00 ... 94 01 00 8d 02 00 7b 24 01 ... 2d 05 64 33 ... 64 49 8b ... 00 00

Die ersten beiden Bytes bilden die fortlaufende 16-Bit-Nummer, von der
ich oben schrieb (hier also dezimal 11, 12 und 13). Man erkennt in den
Datensätzen an mehreren Stellen ähnliche Bytefolgen. Da diese sich alle
256 Byte in ähnlicher Form wiederholen, kam ich zum Schluss, dass die
Datenübertragung wohl in Sätzen zu je 256 Byte erfolgt.

Die Log-Datei enthält 592384 Bytes und damit 592384/256=2314 Datensätze.
Die ersten beiden davon sind anders aufgebaut als der Rest (der zweite
besteht sogar aus lauter Nullen), deswegen betrachten wir nur die 2312
verbleibenden Datensätze.

Die Frage ist nun, welche Bedeutung die 256 Bytes jedes Datensatzes
haben. Die ersten beiden, also Byte 0 und Byte 1, nummerieren die
Datensätze einfach durch. Von den restlichen 254 Bytes ändern sich viele
während der Aufzeichnung überhaupt nicht. Möglicherweise ändern sie
sich, wenn irgendwelche Komponenten der Maschine aktiviert werden, was
aber zum Zeitpunkt der Aufzeichnung nicht geschehen ist.

An anderen Stellen ändern sich die Bytes aber tatsächlich, und ich
vermute, dass es sich dabei größtenteils um irgendwelche Sensormesswerte
handelt, da ihre Werte relativ kontinuierlich steigen und fallen, aber
nicht so systematisch wie die laufenden Nummern in den ersten beiden
Bytes. Bei einigen Bytes habe ich den Eindruck, dass sie für sich
alleine einen 8-Bit-Messwert darstellen, andere scheinen als Byte-Paar
einen 16-Bit-Messwert zu bilden.

Ich habe die veränderlichen Bytes bzw. Byte-Paare über alle 2312
Datensätze als Digramme (32 Stück) plotten lassen und die Plots als
Zip-File angehängt. In den Dateinamen sind jeweils die Byte-Positionen
der geplotteten Daten innerhalb der Datensätze angegeben. Zusätzlich
habe ich eine Datei mit den 32 Datenreihen in Tabellenform angehängt.

Zwei Beispiele dieser Plots habe ich exemplarisch direkt angehängt,
damit nicht jeder das ganze Zip-File herunterladen und auspacken muss.
Die Daten in byte002-003.png könnten vielleicht den Motorstrom eines der
Antriebe darstellen. Die Daten in byte161-161.png könnten vielleicht von
einem Inkrementalgeber mit 8-Bit-Zähler stammen, mit dem die Drehzahl
bspw. einer ständig laufenden Spindel überwacht und geregelt wird.

Einige der Diagrammkurven weisen große Sprünge auf, um dann wieder für
eine gewisse Zeit konstant zu verlaufen. Evtl. sind das gar keine
Messwerte, sondern Statusinformationen.

Um das Ganze genauer zu analysieren, müsste man die gesendeten Daten
beobachten, während die Maschine läuft, um zu sehen, wie sie sich bspw.
mit der Position und der Geschwindigkeit der einzelnen Antriebe ändern,
Einige der im Log unveränderlichen Daten zeigen vielleicht auch den
Status von Bedienelementen an und können durch Betätigen derselben zur
Änderung bewegt werden.

Du hast also noch einige Arbeit vor dir, wenn du tatsächlich das
kommunikationsprotokll vollständig analysieren möchtest ;-)

Michael Glaser schrieb:
> Ich danke für die Analyse und werde wohl das Wochenende deine
> Ausführungen auswerten, so gut es geht ;)
>
> Es gibt also keine Start/Stopzeichen, wie noch beim ersten Log von dir
> vermutet, richtig? Ich bin jetzt leider total enttäuscht, ich dachte
> nämlich, daß das der Ansatz ist, die Daten loggen und entschlüsseln zu
> können? Denn wie soll man den Anfang bzw. das Ende der 256byte finden?
> Der Datenzähler ändert sich ja und kann so keinen "Nullpunkt" mehr
> bilden...

Sehr gute Analyse, Yalu, chapeau!!!

Tja, ungeframte serielle Protokolle sind richtig ekelig... dann kann es 
sein, dass entweder das timing kritisch ist (also z.B. zwischen Ende 
eines Frames und Start des neuen Frames strikte Zeitvorgaben bestehen) 
oder aber zusätzliche Leitungen zur Synchronisation benutzt werden. Für 
beides reicht das logging in der Form nicht aus. Müsstest Du mal ein 
Oszi ranhängen und möglichst ein komplettes Paket mitschneiden, dabei 
alle durchverbundenen Leitungen (ausser vielleicht Masse ;-)) 
anschliessen.

Du sagst ja aber, dass das physikalische Protokoll RS232 ist. Hast Du 
beide Seiten zum loggen zusammengeführt, oder ist das nur der Trace in 
eine Richtung? Fehlen also vielleicht Soft ACKs, die das Protokoll 
synchronisieren?

Michael Glaser schrieb:
> Denn wie soll man den Anfang bzw. das Ende der 256byte finden?

Es könnte einfach eine Ruhepause zwischen den Datensätzen sein. Diese 
kann man mit einer Timeoutbehandlung beim Lesen herausfinden. Aus Deinen 
Logs gehen solche Zeiten (Timestamps) ja leider nicht hervor.

Sollten die Daten tatsächlich kontinuierlich übertragen werden, kannst 
Du Dich nur auf bestimmte Muster einklinken, d.h. Du wartest, bis eine 
unveränderliche Bytesequenz kommt. Yalu schrieb ja, dass einige Werte 
innerhalb des Datenstroms konstant sind.

Michael Glaser schrieb:
>
> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Bei HTerm kannst Du mit Zeitstempeln loggen.

Aber wie war das mit der Rückrichtung? Ist die im log mit drin?

Das einfachste wäre ein Logik-Analyser...oder ganz simpel ein Oszi.
Bit-Zeit ablesen und in Baud umrechnen.

Angenommen die 115k stimmen, was fängst du mit dieser Info an, wenn du 
nicht weißt, wie die Daten zu interpretieren sind?

Denn: Wenn man wüsste wie die Daten (Protokoll) zu interpretieren sind,
wüsste man, was an Byte[0], Byte[1] usw. erwartet wird...und dann könnte 
man die Baud-Einstellung solange ändern, bis es passt.

Von was für einem Gerät sind die Daten?

Michael Glaser schrieb:

> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Indem Du mal 15€ für einen CHina-Logicanalyzer ausgibts, dazu ein 
Breakoutboard mit einem MAX3232, die beiden Receive-Kanäle des MAX3232 
mit auf die serielle Leitung (RX und TX) klemmst und dann am LA die 
Bitzeit ausmisst. Bingo. Länger als eine Stunde sollte das eigentlich 
nicht dauern.

fchk

Michael Glaser schrieb:
> Timing? also es ist definitiv nur die RS232-Leitung. Nix weiter, kein
> Shake oder DX oder so.

Das habe ich auch nicht erwartet. Aber ich vermute, dass zwischen den 
256 Byte-Paketen eine Pause ist, die man detektieren kann.

> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Gar nicht. Dafür müsstest Du schon ein eigenes Programm schreiben, 
welches ab einer bestimmten Timeout-Schwelle die mittlerweile 
übertragenenen Zeichen ausgibt. Haben die ausgegebenen Werte einen 
Abstand von 256, hast Du die Schwelle gefunden.

Michael Glaser schrieb:
> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
> einrichten, was speziell auf Timing aus ist?

Du kannst im HTerm zumindest einstellen, nach wieviel ms er in einer 
neuen Zeile beginnen soll:
"Newline after ... ms receive pause (0=off)"

Falls jeder Datensatz mit diesem "2@P`5)" beginnt, dürfte es nicht 
schwer sein - bis es geordnet untereinander steht.

Adam P. schrieb:
> Michael Glaser schrieb:
>> Wie könnte man denn ein besseres Logging über ein Terminalprogramm
>> einrichten, was speziell auf Timing aus ist?
>
> Du kannst im HTerm zumindest einstellen, nach wieviel ms er in einer
> neuen Zeile beginnen soll:
> "Newline after ... ms receive pause (0=off)"
>
> Falls jeder Datensatz mit diesem "2@P`5)" beginnt, dürfte es nicht
> schwer sein - bis es geordnet untereinander steht.

Du hast auch bei beim "Save as" die Option, Zeitstempel in den log 
einzufügen, was die Interpretation natürlich etwas schwerer macht. Aber 
wenn Du über ein einzelnes Zeichen mit der Maus wanderst, kriegst Du im 
jeweiligen Tooltipfenster auch die Zeitstempel.

Michael Glaser schrieb:
> Hat man nach dem Einsetzen der Übertragung das erste Zeichen, hat man
> auch den Anfang, richtig?

Ja, korrekt. Gerade wenn irgendwelche Frame-Markierungen in den Daten 
wie <STX> und <ETX> fehlen, wäre das eine sinnvolle Herangehensweise.

Michael Glaser schrieb:
> Es gibt also keine Start/Stopzeichen,

Genau.

> wie noch beim ersten Log von dir vermutet

Wo habe ich das vermutet?

Frank M. schrieb:
> Es könnte einfach eine Ruhepause zwischen den Datensätzen sein.

Diese Pausen sind definitiv vorhanden, zumindest im ersten Log vom
30.5., denn:

Michael Glaser schrieb:
> ich habe hier eine Datei, geloggt aus einer RS232-Schnittstelle. Ca 5sek
> lang.

Die Datei umfasst 25740 Byte. Bei 260 Byte pro Datensatz sind das genau
99 Datensätze. Also wird alle 5s/99=51ms ein Datensatz übertragen. Die
eigentliche Übetragung der 260 Bytes dauert aber bei 115200,8,N,1 nur
260·10/115200Hz=23ms. Es verbleibt also eine Pausenzeit von 51ms-23ms
=28ms, die, wenn sie immer am Ende eines jeden Datensatzes eingefügt
wird, durchaus zur Synchronisation genutzt werden könnte.

Diese Pausen erhöhen auch deutlich die Wahrscheinlichkeit dafür, dass
Start und Ende des Logs jeweils zwischen zwei Datensätzen liegen. Und
tatsächlich ist die Länge beider Logs (sowohl des alten als auch des
neuen) ein ganzzahliges Vielfaches der jeweiligen Datensatzlänge.

Michael Glaser schrieb:
> Diesmal im Ruhezustand und dann mit Start und kurzem
> Lauf der Maschine.

Falls die 115k stimmen, dann stimmt ebenfalls deine Aussage:
Ruhezustand -> kurzer Lauf.

Nehmen wir mal an, der Datenstream bildet interne Daten-Register ab 
(Zähler, Messwerte, etc.), dann erkennt man dies in deinem Log.

Annahme: 260 Byte / Datensatz
Log-Datei hat 3458 Datensätze
Datensatz 0 - 1733 = Ruhezustand
Bei Datensatz 2896 ist noch etwas passiert, mehr Mess/Datenwerte.

Sieht man ganz gut mit dem Prog. "HxD".
Zeilenbreite auf 260 Stellen und dann mal runter scrollen.

Hast mal mein Vorschlag probiert?

- Log die Daten einfach, ohne Interpretation in ein File
(so wie du es schon gemacht hast)
- Öffne diesen Log mit dem Programm 'HxD' und stell dort die Anzahl an 
Bytes auf 260.

Dann hast du dein 'Counter' an Offset 0xEF und 0xF0.

Oder im HTerm nicht nach X ms eine neue Zeile, sondern nach 260 Bytes.

Kannst ja mal ausprobieren.

OK, hast wohl recht, 260 scheint wirklich nicht korrekt zu sein.
Zumindest in soweit nicht konsistent, dass die erste Zeile zu allen 
anderen passt.

...hab grad alle Dateien offen.

23.log:
Hier scheint 260 zu passen, der Counter folgt immer auf die Sequenz
32 40 50 60 <Counter>

18.log:
22.log:
115k_6a.log:
Bei diesen Logs hab ich unterschiedliche Längen und dann passen diese 
nur für die ersten 2 Zeilen.

Falls der Datenstream zu Beginn mit 32 40 50 60 beginnt und, da sich 
dies immer wiederholt und danach der Counter steht, ist es evtl. auch 
die Kennung für einen Datensatz.

Kommisch ist nur das es einmal passt und dann wieder nicht.

Irgendetwas läuft beim Aufzeichnen der Daten falsch.

Ziemlich sicher ist, dass die Daten in Blöcken konstanter Länge
übetragen werden. Bei deinen ersten Logs war die Blocklänge 260 Bytes,
dann hast du Logs mit einer Blocklänge nur 256  gepostet. Zwischendurch
enthielten die Logs nur Mülldaten. Bei den neuen Logs ist die Blocklänge
wieder 260, allerdings ist bei drei der vier Logs der erste Block
unvollständig.

Ich habe von allen vier Logs jeweils die ersten drei Blöcke gehexdumpt.
Jede Zeile des Dumps enthält 26 Bytes, ein kompletter Block besteht
somit aus 10 Zeilen. Jeder Block beginnt mit der Bytefolge 32 40 50 60,
gefolgt vom Low- und High-Byte der fortlaufenden 16-Bit-Zahl.

Wenn man im ersten Block an geeigneter Stelle eine geeignete Anzahl
Bytes einfügt, stimmen sowohl die Blocklänge als auch ein Großteil des
Inhalts mit den anderen Blöcken überein. Die fehlenden Bytes sind in den
Dumps mit "--" gekennzeichnet.

Bei 115k_6a.log fehlen 25 Bytes, bei 18.log 18 Bytes und bei 22.hex 4
Bytes. Nur 23.log ist vollständig. Die fehlenden Bytes deuten auf einen
Pufferüberlauf, Übertragungsfehler o.ä. hin.

Ich weiß nicht, ob deine Tools fehlerhaft sind oder ob du sie falsch
bedienst. Auf jeden Fall erschwerst du die Analyse damit gewaltig.

Ich habe aber sowieso meine Zweifel, ob es dir jemals gelingen wird, das
Protokoll zu entschlüsseln. Dazu enthalten die Blöcke einfach zu viele
Daten, die sich über einen längeren Zeitraum nicht ändern. Aber selbst
diejenigen Daten, die veränderlich sind und tatsächlich physikalische
Mess- bzw. Stellgrößen zu enthalten scheinen (s. mein Beitrag vom
28.06.) sind nur schwer konkreten Sensoren bzw. Aktoren zuzuordnen, wenn
man die Maschine nicht im Detail kennt.

Ein gewisse Chance, das Protokoll zu entschlüsseln, würde ich höchstens
dann sehen, wenn jemand, der sowohl Ahnung von der Analyse unbekannter
Protokolle als auch von Fräsmaschinen hat, vor Ort direkten Zugriff auf
die Maschine und einen Einblick in ihren inneren Aufbau hat. Aber selbst
dann gestaltet sich die Sache immer noch sehr schwierig.

Warum benutzt du die Fräsmaschine nicht einfach, wie sie ist, und
erfreust dich an den schönen Dingen, die man damit fertigen kann?

Grundsätzliche Frage:
Wann fängst du an 'aufzuzeichnen'?

Datei: 115k_5b.log
Hat eine Datensatzlänge von 260 Byte, jedoch fängt hier der Mitschnitt 
mit
7d 00 01 ff ... an?!

Kann es sein, dass du bei manchen Logs mitten im Betrieb anfängst die 
Daten aufzuzeichnen?

Datei: 115k_4.log
Datensatzlänge 260 Byte und fängt mit 32 40 50 60 an.

Kannst du vllt. mal bitte eine Log anhängen wo du das Aufzeichnen 
startest, bevor du die Maschine einschaltest. (Also von Anfang an)

Michael Glaser schrieb:
> Was meinst du mit "fehlen"?

Bei deinen vorherigen Log Dateien, fehlten bei einigen in den ersten 2 
Datensätzen Bytes. Warum auch immer.

Yalu X. schrieb:
> Ich habe aber sowieso meine Zweifel, ob es dir jemals gelingen wird, das
> Protokoll zu entschlüsseln.

So sehe ich das auch.

:-D

Das erklärt natürlich einiges.

Dann erstell mal ein Log vom Start an und über eine längere Zeit (inkl. 
einigen Aktionen der Maschine).

Hast du für uns nicht mal den Hersteller und Typ der Maschinensteuerung?

Das ist jetzt das Problem, welches wir schon angesprochen hatten.
Die Interpretation der Daten kann beliebig kompliziert sein, da die 
Werte alles bedeuten könnten, sie könnten 8, 16, 32 bit sein.

Mir ist noch aufgefallen, da der Counter nur 16-bit hat, erfolgt nach 18 
Std. ein Überlauf.

Michael Glaser schrieb:
> 2@P' scheint wohl doch der Anfang zu sein

Nicht 2@P', sondern 2@P` bzw. 32 40 50 60 in Hexdarstellung. In der
letzten Logdatei steht allerdings vor dem ersten Datenblock noch ein
einzelnes NUL-Byte (hex 00). Möglicherweise sendet die Maschine dieses
Byte einmalig direkt nach dem Einschalten. Dass viele deiner Logdateien
direkt mit der Sequenz 32 40 50 60 beginnen, deutet daraufhin, dass die
Pause zwischen den einzelnen Datenblöcken genau vor dieser Sequenz liegt
und diese somit den Anfang des Datenblocks darstellt. Das NUL-Byte am
Anfang der Logdatei kannst du also zunächst einmal ignorieren.

> und der Counter befindet sich an der richtigen Stelle

Ja.

> nur wie bekomme ich raus, ob es ein 16-Bit-Wert ist (also 2 Bytes
> einen Wert ergeben) oder ein 8bit-Wert (ein 1Byte ein Wert)?

Man kann da nur raten, vermuten und hoffen :)

Beim Zählerwort ist es noch relativ klar. Byte 4 des Datenblocks wird in
jedem neuen Block inkrementiert und springt nach FF wieder auf 00
zurück. Bei jedem dieser Rücksprünge wird Byte 5 inkrementiert. Hier ist
ein entsprechender Ausschnitt aus der Logdatei in Hexdarstellung:

1

Byte 4   Byte 5

2

  ⋮        ⋮

3

  FD       00 

4

  FE       00 

5

  FF |     00 |

6

  00 |     01 |

7

  01       01 

8

  02       01 

9

  ⋮        ⋮

Das sieht also sehr stark nach einem 16-Bit-Zähler aus.

Bei halbwegs stetigen Mess- oder Stellwerten kann man eine ähnliche
Überlegung anstellen. Hier ist ein Ausschnitt der Logdatei für Byte 6
und 7 jedes Blocks:

1

Byte 6   Byte 7

2

  ⋮        ⋮

3

  96       03 

4

  D5       03 

5

  D1 |     03 |

6

  1A |     04 |

7

  1A       04 

8

  47       04 

9

  98       04 

10

  AF       04 

11

  EC |     04 |

12

  07 |     05 |

13

  F9 |     04 |

14

  06 |     05 |

15

  D9       04 

16

  DD       04 

17

  AF       04 

18

  75       04 

19

  75       04 

20

  2D       04 

21

  29 |     04 |

22

  E5 |     03 |

23

  D5       03 

24

  C6       03 

25

  ⋮        ⋮

Die Zahlenwerte in Byte 7 werden immer dann inkrementiert, wenn Byte 6
einen großen negativen Sprung macht. Umgekehrt wird Byte 7 immer dann
dekrementiert, wenn Byte 6 einen großen positiven Sprung macht. Das
deutet darauf hin, dass die großen Sprünge von Byte 6 durch Überläufe
verursacht werden, die jeweils zu einem Übertrag nach Byte 7 führen.

Hat man erst einmal diesen "Anfangsverdacht", kann man die Daten auch
grafisch vergleichen (s. Anhang). Welche der beiden Kurven würdest du
als die "richtigere" ansehen?

Michael Glaser schrieb:
> aber wenn ich 96 03 zusammenfasse zu 9603

Vertausch das mal.

0x0396 = 918dez

Guten Morgen,

falls die 2 Byte zusammengehören, dann könnte es sich um eine 
Vorzeichenbehaftete 16bit Zahl handeln (int16_t).

Dann würde das Byte 55 wirklich von 0 direkt auf 255 springen, wenn der 
Wert in den Negativen Bereich wechselt. Anbei eine kleine Grafik zur 
Verdeutlichung.

Das ist einfach:

BA 03 -> 0x03BA / 0x80 = 7.453
D9 01 -> 0x01D9 / 0x80 = 3.695
37 00 -> 0x0037 / 0x80 = 0.43
...

Negative Werte - oberstes Bit gesetzt:

FA FF -> -(0x10000 - 0xFFFA) / 0x80 = -0.046875
40 FF -> -(0x10000 - 0xFF40) / 0x80 = -1.5
usw.

Das sieht für mich nach einer Form von Festkomma-Arithmetik aus. Die 
Division durch 0x80 entspricht einem entsprechenden Shift nach rechts.

EDIT:
Siehe auch Festkommaarithmetik

Xaver schrieb:
> Wenn es immer komisch aussieht, dann mal mit float probieren...

Wieso? Das sind 16-Bit-Festkommazahlen in Zweierkomplementdarstellung
mit 7 (binären) Nachkommastellen. Frank hat die Umrechnung, bei der die
erwarteten Ergebnisse herauskommen, doch schon geliefert.