Hallo, habe hier eine sr-Datei und hätte gerne gewußt, was es für eine Baudrate ist. Irgendwie schaffe ich das Ermitteln nicht. Vielen Dank.
> Irgendwie schaffe ich das Ermitteln nicht.
Was machst Du denn? Ich kommme auf grob 20kBd/s. Falls es eine
Standardbaudrate ist dann vermutlich 19k2. Für genauere Werte musst du
mit einer wesentlich höheren Frequenz sampeln.
Hallo Karl, ich meine Manfred, mit sigrok und seinen Protokoll Dekodern kannst du jetzt selbst herausfinden ob es sich um einen uart ascii Datenstrom handelt oder nicht. viel Glück!
g457 schrieb: > Für genauere Werte musst du > mit einer wesentlich höheren Frequenz sampeln. Ist eventuell von Vorteil. Kleiner Tipp noch wie UART Daten aussehen sollten findest du in den Beispielen http://sigrok.org/download/source/sigrok-dumps/sigrok-dumps-0.1.0.tar.gz
so, 2.sr jetzt mit höherer Auflösung. Bleibt es bei den 19k? Und ist 3.sr 57k-Baudrate? Ich danke euch
> 2.sr jetzt mit höherer Auflösung. Sehr schön. > Und ist 3.sr 57k-Baudrate? Sieht mehr nach 115k2 aus. HTH
vielen Dank :) aber bei 2.sr ist es kein normales "8-Data mit einem Stop-Bit und kein Parity", oder?
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.
> Jetzt die 2.sr
Sieht nach 19k2 aus.
danke. Aber die Signal-Flanken/Anzahl unterscheidet sich doch irgendwie stark. Sieht so ein normales 8-Bit-Signal aus?
> Aber die Signal-Flanken/Anzahl unterscheidet sich doch irgendwie > stark. Sieht so ein normales 8-Bit-Signal aus? Auf die Schnelle betrachtet finde ich keine Sonderbarkeiten. Worauf genau stellst Du ab?
@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.
Hallo Yalu, danke für deine Hilfe, wie bist du von den beiden Hex-Werten auf den dezimalen Endwert (zb Datenquelle 24=80) gekommen? Habe Lo und High in binär umgerechnet, oder beide Hex-Werte addiert, komme aber nie auf 80. Du hast also fast 34 Datenquellen gefunden, von denen 14 konstant sind und die 255 kontinuierlich alle ca 100ms um 2 hochgezählt wird, habe ich das richtig verstanden? Vielen Dank
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.
Vielen Dank. Du hast mir sehr geholfen. Ich muß leider noch einmal fragen: in der angehängten Datei, kannst du da auch was erkennen? Also so eine Schematik wie bei der letzten Datei? Vielen Dank.
Re: Arbeitet hier jemand m [code]Code in anderen Sprachen, ASCIIit sigrok pulseview?Baudrate gesucht
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.