mikrocontroller.net

Forum: PC-Programmierung RS232 String in Python entschlüsseln


Autor: Maddin S. (maddin91)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin gerade etwas verwirrt bei der Entschlüsselung eines Empfangenen 
Strings über RS232 mit Python.

Ich empfange in regelmäßigen Abständen einen Datenstring von einem 
Messgerät, den ich entschlüsseln möchte. Es sollten Daten wie 
Temperatur, Druck und Spannung enthalten sein. Leider enthält der String 
anscheinend zahlreiche Sonderzeichen, die sowohl in Python als auch in 
unterschiedlichen Editoren komplett unterschiedlich dargestellt werden.

So sieht der String aus (in Python wieder ganz anders, siehe Screen):

6 6 ñÛ„5á°X+íê,‚\+È      æÊ       '       â    j


Per Zufall bin ich darauf gestoßen, dass mir "print(string, 0)" den 
String anscheinend ohne die Sonderzeichen liefert (siehe Screenshot). 
Und das scheint mir der richtige String zu sein, mit dem man auch was 
anfangen kann. Leider ist es mir nicht möglich diese Darstellungsart 
irgendwie anders zu reproduzieren. Warscheinlich ist es ein ganz banales 
Problem ich komm aber einfahc nicht auf die Lösung. Und wieso zeigt die 
Print-Funktion hier überhaupt so ein unterschiedliches Verhalten?

Viele Grüße
Martin

Autor: DPA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Per Zufall bin ich darauf gestoßen, dass mir "print(string, 0)" den
> String anscheinend ohne die Sonderzeichen liefert (siehe Screenshot).
> Und das scheint mir der richtige String zu sein, mit dem man auch was
> anfangen kann.

Dass dort sind einfach nur die nicht darstellbaren Zeichen escaped. Bist 
du dir sicher, dass, dass die Baudrate usw. stimmen?
Ansonsten sind es vermutlich Binärdaten. Da würde ich erstmal einen 
Hexdump vieler Nachrichten machen, eine Liste welche werte man glaubt, 
dass übertragen werden sollten, und dann schauen, ob man irgendwelche 
Zusammenhänge findet. Wenn man das Messgerät kennen würde, vielleicht 
würde man dann dazu auch noch was finden.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
print() bringt dir gar nichts, das interpretiert den String in 
irgendeinem Encoding. Je nach Encoding sieht das unterschiedlich aus, 
aber vermutlich sind alle falsch. Du musst dir die einzelnen Bytes 
anschauen, am besten als Hex.

Es kann aber auch gut sein, dass die Daten Müll sind, wegen falscher 
Baudrate etc.

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Baudrate etc. stimmt.

Ich hatte mir jetzt gedacht, dass es evtl. Hex-Zahlen sind, die jeweils 
durch ein "\x" getrennt sind und mir das halt immer als Sonderzeichen 
angezeigt wird. Ist das keine Möglichkeit?

Autor: Martin H. (horo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kann helfen, die Daten mit dem Scope anzuschauen und die kürzeste 
Bitdauer zu suchen, daraus kannst Du die Bitrate bestimmen:
~100 µs => 9600, 50 µs => 19200,... ~9 µs => 115200.
Ansonsten ist ein Hexdump ein Mittel der Wahl, um die Werte zuzuordnen.

Gibt es zu dem Messgerät ein zugehöriges PC-Programm, mit dem Du 
sinnvolle Daten empfängst oder hast Du nur das Gerät zur Verfügung?
Hersteller und Typ-Bezeichnung wäre auch interessant zu wissen.

Ciao, Martin

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> dass es evtl. Hex-Zahlen sind, die jeweils durch ein "\x" getrennt sind
> und mir das halt immer als Sonderzeichen angezeigt wird. Ist das keine
> Möglichkeit?

Nein, ziemlich sicher ist das keine Möglichkeit.

Nimm ein Programm wie z.B. hterm und zeichne damit die empfangenen Daten 
auf. Sieh Dir an, wie hterm die Daten anzeigt.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Ich hatte mir jetzt gedacht, dass es evtl. Hex-Zahlen sind, die jeweils
> durch ein "\x" getrennt

Das \x kommt von der Darstellung als Hexzahl (siehe Escape-Sequenz auf 
Wikipedia)

Da die Daten nicht Menschenlesbar vorliegen, werden es wohl Binärdaten 
sein.
Das Format sollte im Manual zum Messgerät stehen.

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Bis hier hin schonmal danke. Das mit der Darstellung hab ich jetzt 
verstanden.

Ich versuche jetzt aus dem Hex-Dump einen Bezug zu den Daten zu 
erkennen.

Falls jemand Lust hat mitzurätseln =) :


36 01 00 31 00 F1 01 DB 01 C3 01 91 01 3C 02 F5
01 AF 01 5B 01 2B 01 EB 02 EA 02 2C 01 8B 01 5E
02 2D 01 C8 00 00 00 02 00 00 00 66 CA 01 00 01
00 00 00 00 00 0A 00 02 00 13 00 00 00 11 00 05
00 E2 07 02 00 00 00 10 00 0D 0C

Und die dazu gehörenden Messwerte:

HV [V]:      1723.2
M_ [°C]:     60.3
D_ [°C]:     32.8
Pres [Bar]:  1000.4
Flow[l/h]    34.70
C_DPUMP[mA]: 59.20


Ist das so der richtige Weg?

Gruß
Martin

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Ist das so der richtige Weg?

Ja.

Jetzt brauchst du noch mehr von den Datensätzen, damit du erkennen 
kannst, wo sich etwas ändert.
Mal absichtlich einen Wert (deutlich) ändern (z.B. Druck) und schauen 
wie die Daten dann aussehen.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau, erstmal einfach 50 verschiedene Datensätze hintereinander an 
derselben Stelle vom Bildschirm ausgeben in Hex, und da wo's flackert 
sind die Messwerte ;)

Autor: Bert3 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
1. Was für ein Messagerät ist denn genau (Hersteller, Typ usw.)?
  ->Vielleicht finden sich ja Dokus/Tools
2. Hast du ein Programm vom Hersteller das dir die Daten über RS232 
liefert?
  ->Also hast du eine Programm/Daten-Referenz für die Analyse?
3. Wie ist dein Log-Aufbau, hast du ein Hersteller-Programm, forderst 
Daten an und schaust Live was auf der Leitung passiert oder hängst du 
dich einfach an die RS232 und schon sprudeln Daten?
  ->Manche Messgeräte senden ständig Daten über die Leitung (und da ist 
alles drinn), andere liefern nur Daten wenn man sie gezielt danach fragt 
(request/response), manche müsse mit x Werten konfiguriert werden und 
sprudeln dann automatisch usw. - es ist völlig unklar was dein Gerät 
macht, abhängig davon muss deine Analysen ganz unterschiedlich sein

mit dem Portmon kann man live zu schauen: 
https://docs.microsoft.com/en-us/sysinternals/down...

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

sorry für die späte Rückmeldung.

@Bert3: Das Gerät sendet erst Daten, wenn vom PC die entsprechenden 
Befehle gesendet werden. Diese Befehle konnte ich aber bereits abfangen. 
Und ja, ich habe eine Herstellersoftware, die mir Vergleichsdaten 
liefert.


Ich habe es jetzt endlich geschafft, mir eine kleine GUI zu basteln, die 
mir die Hex-Daten in 2-Sekunde abständen live anzeigt. Das hat leider 
etwas länger gedauert, weil die Lösung nicht ganz trivial war. Jetzt 
hats aber geklappt und ich kann jetzt auch sehen welche Hex-Daten sich 
regelmäßig ändern. Jetzt muss ich also nur noch den Bezug zu den realen 
Messdaten finden.

Bis hier hin schonmal vielen Dank!

Gruß
Maddin

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was für ein Messagerät ist denn genau (Hersteller, Typ usw.)

was isses denn nu

Autor: mmm (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dein eigentliches Problem "Interpretation der Daten" hat ja erstmal mit 
Python wenig zu tun.

Wenn Du dann aber weißt, wo welche Daten in welchem Format stehen, wird 
struct.unpack Dein Freund. Einfach einen Formatstring und Deinen 
empfangenen String "reinwerfen" und schon hast Du die Daten als 
Variable.


Maddin S. schrieb:
> Jetzt
> hats aber geklappt und ich kann jetzt auch sehen welche Hex-Daten sich
> regelmäßig ändern. Jetzt muss ich also nur noch den Bezug zu den realen
> Messdaten finden.

Poste doch mal ein Paar Daten hier...

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

sry dass ich mich erst jetzt melde, ich bin vorher nicht dazu gekommen 
an dem Projekt weiter zu arbeiten.

Ich habe inzwischen herausgefunden, dass jeweils eine HEX-Zahl vom 
Messgerät einem einzelnen Messwert entsprincht, die HEX-Zahl jedoch in 
der Herstellersoftware weiter umgerechnet wird um so auf den reellen 
Wert zu kommen. Hier am Beispiel des kompletten HEX-Blocks erklärt:

36 01 00 2F 00 EF 01 D9 01 C2 01 8D 01 65 02 CF
01 A2 01 59 01 2B 01 ED 02 E9 02 2C 01 8A 01 64
02 2C 01 C8 00 00 00 02 00 00 00 E6 EA 01 00 01
00 00 00 00 00 0B 00 1D 00 31 00 00 00 01 00 06
00 E2 07 02 00 00 00 10 00 C6 0C

Die 6. Zahl (EF) gibt einen Druck in mBar an:
EF = 995,5 mBar

Die 8. Zahl (D) gibt eine Spannung in Volt an:
D9 = 1715,9 V


An den Messdaten in der Hersteller-Software ist auch gut zu erkennen, 
dass die Daten zwar mit Nachkommastelle angegeben werden, diese aber nur 
aus der einen Hexzahl berechnet wird. Die Zahlen springen also immer 
zwischen mehreren fixen Werten hin und her.
Hier im Beispiel für den Druck erklärt.

EF =  995,5 mBar
F3 = 1005,3 mBar
F4 = 1007,7 mBar
F5 = 1010,1 mBar

Sieht zumindest nach einem linearen Zusammenhang aus.

Autor: Bert3 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
1. Immer noch kein Geräte typ,name?

2. Warum sollte ausgerechnet ein Messgerät einen Messwert mittels 
skalierung auf ein Byte runterrechnen? Finde ich ein bisschen komisch, 
sind bestimmt mehr bytes beteiligt

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und 3. Du musst zu jedem Wert den entsprechenden hex dump dazu stellen 
sonst hat hier keiner eine chance deine annahme zu prüfen - und es ist 
wichtig das der wert wirklich 100% zu dem hexdump passt

Autor: Joachim B. (jar)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Maddin S. schrieb:
> sorry für die späte Rückmeldung.
Maddin S. schrieb:
> sry dass ich mich erst jetzt melde

immer dein sorry, warum beantwortest du nicht die Frage?

Bert3 schrieb:
> 1. Was für ein Messagerät ist denn genau (Hersteller, Typ usw.)?
>   ->Vielleicht finden sich ja Dokus/Tools
Bert3 schrieb:
>>Was für ein Messagerät ist denn genau (Hersteller, Typ usw.)
>
> was isses denn nu
Bert3 schrieb:
> 1. Immer noch kein Geräte typ,name?

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> 36 01 00 2F 00 EF 01 D9 01 C2 01 8D 01 65 02 CF
> 01 A2 01 59 01 2B 01 ED 02 E9 02 2C 01 8A 01 64
> 02 2C 01 C8 00 00 00 02 00 00 00 E6 EA 01 00 01
> 00 00 00 00 00 0B 00 1D 00 31 00 00 00 01 00 06
> 00 E2 07 02 00 00 00 10 00 C6 0C
>
> Die 6. Zahl (EF) gibt einen Druck in mBar an:
> EF = 995,5 mBar
>
> Die 8. Zahl (D) gibt eine Spannung in Volt an:
> D9 = 1715,9 V

Je nachdem, ob das Messgerät in Little- oder Big-Endian sendet, kann 
auch das Byte davor oder danach dazugehören.

Dann wäre das z.B.
0x01EF = 995,5 mBar
0x01D9 = 1715,9 V

oder
0x00EF = 995,5 mBar
0x01D9 = 1715,9 V

Das kannst du feststellen, wenn der Luftdruck soweit steigt, dass das 6. 
Byte 00 wird.

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Gerät habe ich nicht genannt, weil es keinem etwas sagen wird und es 
auch keine Dokumentation dazu zu finden gibt, weil es so ein spezielles 
Gerät ist:

Bruker: Raid M100

Was genau gehört denn zu dem Hex-Dump noch dazu? Ich dachte es wäre 
einfach die Darstellung der Daten in Hex-Form?

Warum ein Messwert nur in einem Byte übertragen wird verstehe ich auch 
nicht ganz. Ich bin mir aber ziemlich sicher, dass das so ist. Die 
Software zeigt Veränderungen in den Messwerten auch nur in großen, 
gleichbleibenden Sprüngen an.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann schon sein. Du kannst ja mal schauen, ob die Sprünge in der 
Software die gleichen sind wie die, die du in den Bytes siehst. Es 
könnte aber auch mehr als ein Byte pro Wert sein.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schreib ein Programm, dass von dir erzeugte Daten an das Anzeigeprogramm 
schickt.

Dann weißt du genau, was rein geht und kannst gezielt Daten vorgeben.

Es gibt verschiedenen Programme, womit du dich in eine serielle 
Verbindung/Schnittstelle einklinken kannst.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Das Gerät habe ich nicht genannt, weil es keinem etwas sagen wird und es
> auch keine Dokumentation dazu zu finden gibt, weil es so ein spezielles
> Gerät ist:
>
> Bruker

https://de.wikipedia.org/wiki/Bruker
wenn es dieses Bruker ist dann sagt mir das schon was, aber OK das Gerät 
kenne ich nicht.

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Gerät habe ich nicht genannt,
>weil es keinem etwas sagen wird

sowas wir hier aber eher als überlesen oder unwissentlich ignoriert 
gewertet :) - schon oft wurde ewig gepostet und am Ende gab es ein 
fertiges github Projekt oder Doku mit allen Infos

(am besten nutzt du beim Antworten einfach die Nummern bei meinen Fragen 
dann ist klar das du dich mit jeder Frage "beschäftigt" hast)

1. Welches Programm nutzt du für das RS232 Logging - oder machst du 
selber den Port auf und gibst alles aus was da so kommt?

Portmon von Microsoft
https://docs.microsoft.com/en-us/sysinternals/down...

Free Serial Analyzer von HHD
https://freeserialanalyzer.com/

AGG Software - free
http://www.aggsoft.com/serial-data-logger/

2. Hast du ein vollständiges Log von Start der Bruker-Software(Port 
öffnen), über Messwerte lesen bis zum Ende(Port schliessen) - mit dem 
Wissen könnte man einfach die Bruker-Software mit einem virtuellen Port 
(oder Nullmodem-Kabel zwischen 2 Ports) verbinden und die Log-Daten per 
Serial write vorgeben, wenn das klappt kannst du einfach an den 
Hex-Werten rumspielen und schauen was die Bruker-Software dazu sagt - 
falls da keine Checksumme drinn ist - die du dann aber eh noch knacken 
musst :)

3. du brauchst mehr Extrem-Werte für die Analyse also 0v, 1000mv, oder 0 
oder 1bar usw., natürlich auch mehr Zwischen-Werte - zu jedem Wert muss 
ein Hex-Dump vorliegen, kannst du Extrem-Werte an den Sensoren 
"erzeugen", wäre gut um zu erkennen was passiert wenn 1 byte nicht mehr 
reicht oder Little/Big Endian

4. am besten machst du mal ein vollständiges Log - mehr als nur ein paar 
Bytes mit n Messwertänderungen - dazu dann eine Liste mit dem Messwerten 
dann haben wir mal was "grosses" zum anschauen

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Das kann schon sein. Du kannst ja mal schauen, ob die Sprünge in der
> Software die gleichen sind wie die, die du in den Bytes siehst. Es
> könnte aber auch mehr als ein Byte pro Wert sein.

Genauso ist es ja.

EF =  995,5 mBar
F3 = 1005,3 mBar
F4 = 1007,7 mBar
F5 = 1010,1 mBar

Das sind die Werte für den Druck. Alle Werte dazwischen werden nicht 
angezeigt. Die Sofware springt bei Änderungen nur zwischen diesen festen 
Werten hin und her. Zwei Messwerte (Temperatur und Spannung) kann ich 
aktiv beeinflussen. Da werde ich nachher mal gucken, ob sich da noch 
weitere Hex-Werte mit ändern.


@Bert3:

zu 1: Für das Live-Plotting der Hex-Daten habe ich mir wie gesagt eine 
Python GUI geschrieben. Parallel checke ich das ganze mit HTerm gegen, 
um sicher zu gehen, dass nirgendwo ein Fehler in meinem Progrtamm ist.

zu 2: Ich habe ein vollständiges Log, ja. Aber das ist extrem lang (mehr 
als 100.000 Zeichen).

zu 3 und 4: Werde ich mal versuchen. Wie gesagt, kann ich leider nur 
zwei Messwerte aktiv beeinflussen. Bzw. Bei der Spannung sogar nur an 
oder aus.

Ich melde mich dann wieder wenn ich neue Daten zum spielen hab =)

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Sven B. schrieb:
>> Das kann schon sein. Du kannst ja mal schauen, ob die Sprünge in der
>> Software die gleichen sind wie die, die du in den Bytes siehst. Es
>> könnte aber auch mehr als ein Byte pro Wert sein.
>
> Genauso ist es ja.
>
> EF =  995,5 mBar
> F3 = 1005,3 mBar
> F4 = 1007,7 mBar
> F5 = 1010,1 mBar

Genau, die Frage ist dann bloß noch, ob das Byte davor sich noch ändert, 
wenn du den Druck zu hoch oder zu niedrig machst.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sendet der PC auch was (Kommandos an das Gerät)?

Spendier mal eine zweite (virtuelle) serielle Schnittstelle.
Dein Python Programm empfängt Daten vom Herstellerprogramm (über die 
virtuelle Schnittstelle) und leitet die 1:1 ans Gerät (an der realen 
Schnittstelle) weiter.
Zudem empfängt es Daten vom Gerät. Diese kannst du manipulieren und an 
das Herstellerprogramm weiterleiten.
So kannst du andere Werte erzeugen.

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist der Aufbau dann so?

Raid M100 <-- RS232 -->
  Python GUI oder HTerm
  Bruker Software

oder gibt es gar keine Bruker Software auf deinem PC

1.
>zu 1: Für das Live-Plotting der Hex-Daten habe ich mir wie gesagt eine
>Python GUI geschrieben. Parallel checke ich das ganze mit HTerm gegen,
>um sicher zu gehen, dass nirgendwo ein Fehler in meinem Progrtamm ist.

d.h. du hast keinen RS232 Monitor(mitlesen wären Gerät mit einer 
Software kommuniziert) sondern
eben deine oder die Bruker-Software an dem Gerät?


2.
>zu 2: Ich habe ein vollständiges Log, ja.
>Aber das ist extrem lang (mehr
>als 100.000 Zeichen).

einfach auf einen freien Hoster stellen z.B. https://uploadfiles.io/ 
oder http://www.tinyupload.com/

3.
>zu 3 und 4: Werde ich mal versuchen. Wie gesagt, kann ich leider nur
>zwei Messwerte aktiv beeinflussen. Bzw. Bei der Spannung sogar nur an
>oder aus.

Versuch dein Glück :)

4.

Manchmal ist eine Geräte-Simulation wirklich eine gute Idee d.h. man 
koppelt die Bruker-Software
an einen (echten) oder virtuellen Port und schickt einfach die geloggten 
Daten da durch dann kann man gezielt an jedem Byte drehen und schauen 
was Bruker dazu anzeigt

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch, natürlich gibt es die Bruker-Software auf dem PC. Ohne die ist das 
Gerät auch nicht zu gebrauchen, weil dieses immer nur Daten sendet, wenn 
sie angefordert werden. Vom PC wird also immer eine Anfrage geschickt 
und das Gerät antwortet.

Meine Verkabelung ist im Moment so, dass ich das Gerät über ein 
serielles Y-Kabel am PC angeschlossen habe. Die eine Seite hängt dabei 
an einem USB-Serial Converter am PC und an der anderen Seite kann ich 
einzelne Adern vom Y-Kabel abgreifen und am pyhsikalischen Serial-Port 
des PCs anschließen. So kann ich das Gerät ganz normal mit der Bruker 
Software Verbinden und steuern und parallel auf dem anderen Port 
mithören. Leider kann ich so immer nur in eine Richtung mithören. Also 
entweder die vom PC ausgehenden oder eingehenden Daten.

Ich wollte es ursprünglich mit einem virtuellen Port machen (mit 
com2com). Leider hab ich das aber auch nach ausgiebigem Versuchen nicht 
hinbekommen, darum die Lösung mit dem Sniffer-Kabel.

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Leider kann ich so immer nur in eine Richtung mithören.

1. Hast du die schon probiert

Portmon von Microsoft (im Kompatibilitäts-Modus)
https://docs.microsoft.com/en-us/sysinternals/down...

oder

Free Serial Analyzer von HHD
https://freeserialanalyzer.com/
Achtung läuft nur 5 Tage oder so - davon hatte ich bei einem Kunden mal 
die Pro-Version

oder

http://sudt.com/en/ap/index.html
den habe ich auch mal verwendet

was ist mit Frage 2 und 4 aus meinem letzten Post?

Autor: Maddin S. (maddin91)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

portmon kenne ich, hab ich auch schon benutzt. Das von SUDT kannte ich 
noch nicht, finde ich aber schonmal sehr gut, danke dafür. Allerdings 
kann keines davon den Datenstrom ablauschen während ich mit der 
Bruker-Software verbunden bin (port already in use). Oder habe ich da 
was übersehen? Der Serial Port Monitor von Eltima kann das, ist aber 
leider nur 14 Tage kostenlos =(

Jedenfalls... Bevor ich jetzt unnötig viel Zeit in dieser Richtung 
investiere, erstmal meine neuen Erkenntnisse:

Ich habe jetzt eine Wertetabelle mit den Temperaturwerten und den 
dazugehörigen Hex-Zahlen (Anhang). Das Gerät verfügt über zwei 
verschiedene Temperatur-Sensoren und beide zeigen exakt die gleichen 
Temperatursprünge an und werden aus den gleichen HEX-Zahlen gebildet.
Auf den ersten Blick scheinen sich die Temperaturwerte linear aus den 
HEX-Zahlen abzuleiten. Wenn man aber genau hinguckt, kann man eine 
minimale Zunahme der Temperatursprünge in Richtung höherer HEX-Zahlen 
sehen.

Deshalb hab ich eigentlich kaum noch einen Zweifel, dass die Temperatur 
Software-intern umgerechnet wird und von den Sensoren bspw. der 
Widerstand oder was auch immer (je nachdem was und wie es gemessen wird) 
übertragen wird. Wahrscheinlich steckt dann sogar noch eine Kalibrierung 
dahinter.
Wenn das wirklich so ist sehe ich keine Möglichkeit aus den Hex-Zahlen 
die dazugehörigen Werten zu berechnen.

Wie seht ihr das?
Lohnt es sich trotzdem noch weiter zu  machen bspw. mit der 
Geräte-Simulation?

schöne Grüße
Martin

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Allerdings kann keines davon den Datenstrom ablauschen während ich mit der
> Bruker-Software verbunden bin (port already in use). Oder habe ich da
> was übersehen?

warum machst du es dir so schwer?

in die RS232 einfach die Leitungen Tx und Rx anzapfen notfalls alle 
benötigten und mit auf 2 andere Schnittstellen geben wenn com1: Bruker 
ist dann Com2 für Rx Daten, Com3 für Tx Daten dann kannst du auf den 
anderen Ports lauschen ohne com1 "already in use"

: Bearbeitet durch User
Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ähnlich mache ich es ja aktuell auch. Nur dass ich entweder Rx ODER 
Tx anzapfe und dann halt jeweils umstecke. Blöd ist nur, dass so die 
eingehenden und ausgehenden Daten immer voneinander getrennt sind und 
ich diese mühsam per Hand auftrennen muss. Um das Protokoll zu verstehen 
wäre es ja am schönsten Anfrage vom Pc und Antwort vom Gerät gleich 
hintereinander zu haben, am besten noch irgendwie markiert um zu sehen 
was eingehende und ausgehende Daten sind.

Oder habe ich dich jetzt falsch verstanden?

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> So ähnlich mache ich es ja aktuell auch. Nur dass ich entweder Rx ODER
> Tx anzapfe und dann halt jeweils umstecke. Blöd ist nur, dass so die
> eingehenden und ausgehenden Daten immer voneinander getrennt sind und
> ich diese mühsam per Hand auftrennen muss

dann hänge einen µC dazwischen und lasse 2 farbig mit Timecode Rx und Tx 
als Ausgabe laufen, dann hast du alles auf einen Screen sogar mit 
Zeitstempel, bei geschickter Anschaltung könntest du auch die Daten 
manipulieren vom µC wenn du nicht nur anzapfst sondern die durch den µC 
leitest.

Autor: Nico W. (nico_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nutze dafür ein Nucleo Board (aktuell nen F446 mit 180MHz). Der hat 
reichlich performance und schnüffelt bei mir RT/TX mit 460kbaud und 
spuckt das dann entweder fertig geparsed oder roh mit 921kbaud raus.

Autor: Maddin S. (maddin91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es jetzt doch mit Com0Com hinbekommen (hatte da auch einen 
Denkfehler). Ich habe mir einfach ein virtuelles Com-Paar erstellt und 
kann jetzt Das Messgerät mit dem physikalischen Port verbinden und die 
Software mit einem der virtuellen Ports. Jetzt habe ich einfach ein 
Python-Programm geschrieben, was die Daten in beide Richtungen weiter 
reicht. Und das scheint auch gut zu funktionieren.

Ich muss hier noch etwas Zeit investieren aber so kann ich schonmal das 
Protokoll in Beide Richtungen abhören und sogar die Daten manipulieren.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Ich habe es jetzt doch mit Com0Com hinbekommen (hatte da auch einen
> Denkfehler). Ich habe mir einfach ein virtuelles Com-Paar erstellt und
> kann jetzt Das Messgerät mit dem physikalischen Port verbinden und die
> Software mit einem der virtuellen Ports. Jetzt habe ich einfach ein
> Python-Programm geschrieben, was die Daten in beide Richtungen weiter
> reicht. Und das scheint auch gut zu funktionieren.
>
> Ich muss hier noch etwas Zeit investieren aber so kann ich schonmal das
> Protokoll in Beide Richtungen abhören und sogar die Daten manipulieren.

Ja, so war das gedacht.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maddin S. schrieb:
> Wahrscheinlich steckt dann sogar noch eine Kalibrierung
> dahinter.
> Wenn das wirklich so ist sehe ich keine Möglichkeit aus den Hex-Zahlen
> die dazugehörigen Werten zu berechnen.

Lass dir mal mit Excel oder LibreCalc die Trendkurve anzeigen.

Autor: Tike Myson (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz doofe Frage: Hast du schon mal bei Bruker nachgefragt? Evtl. Rücken 
die ja das Protokoll einfach raus, evtl. Gegen Unterschrift einer NDA?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.