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
Angehängte Dateien:
-
String.JPG
45 KB
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.
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.
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?
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
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.
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.
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
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.
Genau, erstmal einfach 50 verschiedene Datensätze hintereinander an derselben Stelle vom Bildschirm ausgeben in Hex, und da wo's flackert sind die Messwerte ;)
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/downloads/portmon
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
>Was für ein Messagerät ist denn genau (Hersteller, Typ usw.)
was isses denn nu
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...
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.
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
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
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?
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.
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.
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.
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.
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.
>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/downloads/portmon 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
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 =)
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.
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.
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
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.
>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?
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
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
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?
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.
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.
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.
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.
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.
Ganz doofe Frage: Hast du schon mal bei Bruker nachgefragt? Evtl. Rücken die ja das Protokoll einfach raus, evtl. Gegen Unterschrift einer NDA?
Beitrag #5769589 wurde von einem Moderator gelöscht.
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.