Arbeitet hier jemand mit sigrok pulseview?Baudrate gesucht

Manfred schrieb:
> Und ist 3.sr 57k-Baudrate?

Nö. 115200 passt besser.

Manfred schrieb:
> vielen Dank :) aber bei 2.sr ist es kein normales "8-Data mit einem
> Stop-Bit und kein Parity", oder?

Wir sehen kein 2.sr hier. Haste vergessen zu posten.

@Manfred, Karl oder wie du immer heißen magst:

Dass es 19200 baud sind, habe ich dir doch schon in deinem anderen
Thread ausführlich dargelegt, da hättest du dir den Logic-Analyser
sparen können:

  Beitrag "Re: Wie die Baudrate am Pin rausfinden?"

Hättest du ein paar der Antworten gelesen, anstatt die hilfsbereiten
Forenteilnehmer dumm anzupöbeln, wäre dir aufgefallen, dass deine
mit 19200 baud aufgenommene Logdatei

  Beitrag "Re: Wie die Baudrate am Pin rausfinden?"

sehr plausibel aussieht:

  Beitrag "Re: Wie die Baudrate am Pin rausfinden?"

Ich habe die Datei auch einmal angeschaut und Folgendes herausgefunden:

Die Messwerte werden in 5 Byte großen Nachrichten übertragen, die
folgendermaßen aufgebaut sind:

1

Byte-Nr.  Inhalt

2

—————————————————————————————————————————————————————————————

3

   1      Datenquelle (1 bis 31, 33, 254 oder 255)

4

   2      0xA3 (in der Logdatei immer gleich)

5

   3      Messwert (High-Byte)

6

   4      Messwert (Low-Byte)

7

   5      Prüfsumme (8-Bit-Summe der Bytes 1 bis 4)

8

—————————————————————————————————————————————————————————————

Allein die Tatsache, dass die Prüfsumme für alle 843 Nachrichten stimmt,
zeigt schon, dass die 19200 baud richtig sind.

Immerhin kennen wir nun Dank der Messung mit dem Logic-Analyser das
Timing der Übetragung.

Die Datenquelle 254 liefert einen Wert, der jedesmal um 2 hochgezählt
wird, und zwar im Mittel alle 99,24 ms. Möglicherweise bildet dieser
Wert zusammen mit dem Wert einer anderen Nachricht die aktuelle Uhrzeit.

Für alle anderen Datenquellen sind die Werte in der Logdatei konstant,
nämlich:

1

Datenquelle  Wert

2

—————————————————

3

     2        104

4

     4         25

5

     5        455

6

    11         46

7

    12        147

8

    13          1

9

    14        103

10

    20         20

11

    24         80

12

    27        128

13

    29        100

14

    31          1

15

    33        146

16

   255          3

17

alle anderen    0

18

—————————————————

Stellen die Daten tatsächlich Messwerte von Temperatur, Luftdruck u.ä.
dar, ist es nicht verwunderlich, dass sie sich nicht ändern, da sie in
der Logdatei nur über einen Zeitraum von nur 5,1 s aufgezeichnet worden
sind.

Manfred schrieb:
> Hallo Yalu, danke für deine Hilfe, wie bist du von den beiden Hex-Werten
> auf den dezimalen Endwert (zb Datenquelle 24=80) gekommen?

Die Nachricht von Quelle 24 lautet:

  18h A3h 00h 50h 0Bh

Der Suffix "h" steht dabei für hexadezimal.

  18h   = 24 ist die Nummer der Quelle.
  0050h = 80 ist der Wert.
  0Bh   = (18h + A3h + 00h + 50h) modulo 100h ist die Prüfsumme.

> Du hast also fast 34 Datenquellen gefunden,

Ja. Genauer gesagt, gibt es 34 Nachrichtentypen. Es kann auch sein, dass
für eine Quelle (d.h. Sensor) mehrere Nachrichten unterschiedlichen Typs
gesendet werden, um bspw. mehr als 2 Bytes Nutzdaten zu übertragen, ohne
dabei die feste Nachrichtenlänge von 5 Bytes zu sprengen.

Sollte also die Nachricht 254 tatsächlich etwas mit der Uhrzeit zu tun
haben, wird der enthaltene 16-Bit-Wert spätestens nach etwa 55 Minuten
überlaufen, der Rest der Uhrzeit muss deswegen in weiteren Nachrichten
übertragen werden.

> von denen 14 konstant sind

Es gibt 33 Quellen (alle bis auf Quelle 254), deren Werte konstant sind.
Zu den 14 explizit aufgelisteten kommen noch die unter "alle anderen"
zusammengefassten 19 Quellen, die immer den Wert 0 haben. Das sind die
Quellen 1, 3, 6-10, 15-19, 21-23, 25, 26, 28, und 30.

> und die 255 kontinuierlich alle ca 100ms um 2 hochgezählt wird

Ja.

Ich habe auch mal die Daten aus der Logic-Analyser-Datei 2.sr
ausgewertet, die du ja zu einem späteren Zeitpunkt aufgenommen hast,
weswegen zumindest bei den Sensoren für Temperatur, Luftdruck u.ä.
Änderungen zu erwarten sind. Tatsächlich haben sich die Werte von vier
Quellen gegenüber deiner alten Logdatei 19_rs.log verändert:

1

              Wert in   Wert in

2

Datenquelle  19_rs.log    2.sr

3

———————————————————————————————

4

     2          104       103

5

     5          455       432

6

    11           46        50

7

    20           20        19

8

———————————————————————————————

Die Werte von Quelle 254, die ständig hochgezählt werden, sind natürlich
auch anders.

Manfred schrieb:
> in der angehängten Datei, kannst du da auch was erkennen? Also so eine
> Schematik wie bei der letzten Datei?

Man erkennt, dass sich die meisten Daten alle 260 Bytes wiederholen, das
ist aber auch schon alles. Dass die allermeisten Bytes 0 sind, deutet
daraufhin, dass bei der Übertragung massenhaft Frame-Errors aufgetreten
sind. Du hast also vermutlich die Baudrate des Empfängers verstellt, um
zu testen, ob damit nicht besser verwertbare Ergebnisse herauskommen :)

Nein, glaub mir: 19200 Baud mit 8 Datenbits und ohne Parität ist die
richtige Einstellung. So groß ist kein Zufall der Welt, dass bei
falscher Baudrate und bei dieser Datenmenge trotzdem ein konsistentes
Prüfsummenschema erkennbar ist, wie ich es oben beschrieben habe.

Es ist jetzt an dir, die richtige Zuordnung zwischen Sensoren und
Nachrichten zu finden. Wie ich schon im letzten Thread geschrieben habe,
braucht man dazu mehr Informationen als nur eine Logdatei.