Hallo, ich habe ein Problem mit einem Messgerät und würde gerne wissen, ob und wie das gelöst werden kann. Es ist vorerst nur eine rein theoretische Frage, ob das machbar ist. Es geht um ein Messgerät, welches per RS232 am PC angeschlossen wird. Das Gerät kann über eine Software auf dem PC gesteuert werden (Start, Stop ....) und sendet die Messdaten an die Software, welche diese darstellt. Leider ist die vom Hersteller gelieferte Software sehr bescheiden und bietet nicht die Möglichkeit die vollständigen Messdaten zu exportieren und richtig zu verarbeiten. Gibt es eine Möglichkeit die Software zu umgehen und so irgendwie an die vollständigen Messdaten zu kommen? Optimal wäre natürlich, wenn man das Gerät über die bestehende Software weiterhin steuert und die Messdaten zusätzlich in einem anderen Programm abfängt. Da die RS232-Schnittstelle aber kein sharing unterstütz geht das glaube ich nicht, oder? Wäre es stattdessen irgendwie möglich die Steuerbefehle von der Hersteller-Software abzufangen, um das Gerät mit einem selbst geschriebenen Programm zu steuern und über dieses ebenfalls die Messdaten zu empfangen? Eine eventuelle Lösung sollte in Python realisiert werden. Oder gibt es für derartige Probleme sogar fertige Softwarelösungen? Viele Grüße Martin
Maddin S. schrieb: > Wäre es stattdessen irgendwie möglich die Steuerbefehle von der > Hersteller-Software abzufangen, um das Gerät mit einem selbst > geschriebenen Programm zu steuern und über dieses ebenfalls die > Messdaten zu empfangen? Bei der Menge der bekannte Details lautet die Antwort 42. > Eine eventuelle Lösung sollte in Python realisiert werden. Oder gibt es > für derartige Probleme sogar fertige Softwarelösungen? Antwort wie oben. Alles ist möglich. Vielleicht ja, vielleicht nein. Oliver
Maddin S. schrieb: > Da die RS232-Schnittstelle aber kein sharing unterstütz geht das glaube > ich nicht, oder? Zwar unterstützt die Schnittstelle kein "Sharing", aber einerseits kann man mit entsprechender Software trotzdem "mithören" (https://docs.microsoft.com/en-us/sysinternals/downloads/portmon) und andererseits kann man sich mit etwas Installationsgefrickel mit hub4com (eien Komponente aus dem com0com-Paket) auch einen "virtuellen Mithörer" zusammenstricken, der dann eigene Software mit den mitgehörten Daten beliefern kann. https://sourceforge.net/projects/com0com/
Was werden denn noch für Angaben benötigt? Es handelt sich um ein ionen mobilitäts spektrometer. Die Daten, die empfangen werden sind Spektren, die über die Zeit gemessen werden. Also x,y-Daten die in bestimmten Zeitabständen gemessen werden. Wie, und in welcher Form diese Daten übermittelt werden weiß ich nicht, weil die Software nunmal nur das ferige Spektrum anzeigt und nicht die hinterlegten Rohdaten.
Rufus Τ. F. schrieb: > Maddin S. schrieb: >> Da die RS232-Schnittstelle aber kein sharing unterstütz geht das glaube >> ich nicht, oder? > > Zwar unterstützt die Schnittstelle kein "Sharing", aber einerseits kann > man mit entsprechender Software trotzdem "mithören" > (https://docs.microsoft.com/en-us/sysinternals/downloads/portmon) und > andererseits kann man sich mit etwas Installationsgefrickel mit hub4com > (eien Komponente aus dem com0com-Paket) auch einen "virtuellen Mithörer" > zusammenstricken, der dann eigene Software mit den mitgehörten Daten > beliefern kann. > > https://sourceforge.net/projects/com0com/ Das ist schon mal ein sehr guter Ansatz, danke. Da werde ich mal versuchen etwas zum laufen zu kriegen.
Evtl. ist das Protokol zwischen "die Software" und dem Messgerät ja vom Hersteller dokumentiert und läßt sich dann einfach "im Program" nutzen. Evtl. ist das Protokol aber auch relativ einfach und läßt sich ggf. durch mitlauschen ermitteln.
Alternative Lösung: RS-232 Kabel anzapfen um mitzuhören. https://www.lammertbies.nl/comm/cable/RS-232-spy-monitor.html
> https://docs.microsoft.com/en-us/sysinternals/downloads/portmon Mit Portmon hab ich auch gute Erfahrungen gemacht. Damit findest du raus, wie die Daten angefordert werden müssen incl. Baudrate, Parität usw. Anschließend kannst du versuchen, mit Hterm auf die selbe Weise Daten anzufordern. Falls das klappt, lassen sich die Daten aufzeichnen und als HEX, ASCII oder Dezimal exportieren. http://www.der-hammer.info/terminal/ Falls dies klappt, kannst du mal so ein Paket hier reinstellen.
Bernd meinte: > Anschließend kannst du versuchen, mit Hterm auf die selbe Weise Daten > anzufordern. das geht aber nur bei einfachsten asyncronen Protolollen. Bei V24 oder HDLC mußt Du nen eigenen Protokollparser schreiben. Das geht auf einem modernen Rechner auch in Python, die Baudrate ist ja maximal 19600 oder weniger. mfg
Erst mal mit "HDD free serial port monitor" (google) mithören. Damit bekommst du einen Eindruck wie kompliziert das Protokoll ist.
Wenn es ohne Software funktionieren muß würde ich das mit Hardware verwenden.
Softwareless meinte: > Wenn es ohne Software funktionieren muß würde ich das mit Hardware > verwenden. Wie würdest Du dann das Protokoll implementieren? Mit ner Schaltung aus "74HC" oder per FPGA? mfg
~Mercedes~ schrieb: > Bei V24 oder HDLC mußt Du nen eigenen Protokollparser schreiben. Hä? ~Mercedes~ schrieb: > die Baudrate > ist ja maximal 19600 oder weniger. Hä? Bist Du Dir sicher, daß Du weißt, wovon Du da redest? V24 ist RS232, das beschreibt die serielle Schnittstelle, so, wie sie ist. Mit HDLC hat das ganze exakt nichts zu tun. Und die maximal mögliche Baudrate der Onboard-Schnittstellen von PCs liegt seit Jahrzehnten bei 115200 Baud (wenn ISA-/PCI-/PCIe-Steckkarten oder USB-Adapter verwendet werden, sind auch deutlich höhere Baudraten möglich).
~Mercedes~ schrieb: > Mit ner Schaltung aus "74HC" oder per FPGA? Einzeltransistoren sind auch eine Altenative.
Pffff,Sorry, > Bist Du Dir sicher, daß Du weißt, wovon Du da redest? > V24 ist RS232, das beschreibt die serielle Schnittstelle, so, wie sie > ist. Das hat man davon, wenn man auf dem Schulhof mal schnell was schreibt und es dann klingelt. ;--O Ich meine natürlich X25 und HLDC ( High Level Data Control ) Nokia benutzt das zum Beispiel sogar von der Anlage zum Servicehörer, warum sollen Meßgeräte was Anders verwenden? mfg
~Mercedes~ schrieb: > warum sollen Meßgeräte was Anders verwenden? Warum sollten sie es tun? Es geht nicht um Raketenwissenschaft. Üblicherweise sind die Protokolle, die hier verwendet werden, einfach strukturiert; oft sogar direkt im Klartext lesbar. HDLC (ohne Buchstabendreher) wäre hier mit sehr großen Kanonen auf sehr kleine Mücken geschossen. Es geht hier um simple Punkt-zu-Punkt-Verbindungen, da wird keins der von Dir erwähnten Verfahren auch nur ansatzweise benötigt.
Vielen Dank schonmal für die zahlreichen Infos. Ich habe es jetzt schonmal geschafft mit dem Serial Port Monitor von Eltima die ankommenden Daten abzufangen. Ich bin allerdings noch etwas erschlagen von den vielen Daten und verschiedenen Fenstern, die mir der Serial Port Monitor bietet. Zumindest konnte ich aber schon den Block mit Messdaten identifizieren, da dieser in einem Abstand von ca. 3 Sekunden vom Gerät gesendet wird und auch so in der Hersteller-Software angezeigt wird. Leider sind diese Daten noch sehr kryptisch, sodass ich damit erstmal nichts anfangen kann. Am Montag werde ich hier weiter machen und versuchen die Daten zu "entschlüsseln".
Maddin meinte: > Zumindest konnte ich aber schon den Block mit Messdaten identifizieren, > da dieser in einem Abstand von ca. 3 Sekunden vom Gerät gesendet wird > und auch so in der Hersteller-Software angezeigt wird. Geil! Und jetzt nimmst Du die Senderichtung auch hinzu und läßt Dir Sende / Empfangsrichtung als abwechselnde Streifen unter- einander anzeigen. Wenns nicht geht, einfach die Hexzahlen hintereinander aufschreiben Jetzt siehst Du die Aktinitäten in Zusammenhang! Messgerät ---> Computer Computer---> Messgerät Messgerät ---> Computer Computer---> Messgerät Da bekommst Du dann auch heraus, was "Ack" und "NACK" also positive und negative Bestätigung sind, und ob eventuell Zähler hoch oder runtergezählt werden. mfg
Rufus Τ. F. schrieb: > HDLC (ohne Buchstabendreher) wäre hier mit sehr großen Kanonen auf sehr > kleine Mücken geschossen. Und ausserdem für kaum jemand verwendbar - wer hat schon einen PC mit synchroner Schnittstelle? Und dann noch Software für HDLC? Das gabs mal als Datev-Anschluss für Steuerberater, ist aber glaube ich ausgestorben. So ein Messgerät wäre praktisch unverkäuflich. ~Mercedes~ schrieb: > Da bekommst Du dann auch heraus, was "Ack" und "NACK" > also positive und negative Bestätigung sind, und ob > eventuell Zähler hoch oder runtergezählt werden. Die gewünschten Daten können ja nur in der Übertragung Gerät -> PC enthalten sein. Ich würde mich erst mal drauf konzentrieren, die Daten zu verstehen, dafür genügt es, die TxD-Leitung parallel an ein Terminal anzuschliessen, entweder physikalisch oder softwaremässig. Um eine Analyse des Handshaking kann man sich später kümmern, sofern das dann überhupt noch von Interesse ist. Georg
Maddin S. schrieb: > Oder gibt es für derartige Probleme sogar fertige Softwarelösungen? Sicherlich gibts die, z.B. den "Klassiker" LabView. Dazu muss natürlich das Protokoll Deines Meßgeräts bekannt sein. Man kann natürlich auch parallel den RS232-Datenstrom Deines Meßgerätes anzapfen und abspeichern. Die Analyse der Daten kann aber recht mühsam sein, insbesondere wenn das Meßgerät die Daten zustzlich verschlüsselt.
Wenn Maddin wirklich von der mitgelieferten Soft weg muß und das Spektrometer "feindlich übernehmen" will, muß er den Protokollstapel möglichst originalgetreu simulieren. Dann kann er nämlich in den Spektrometer auch nach und undokumenterten Funktionen suchen, da kann dann sein eigenes Programm mehr als das Original! :-P @Maddin, was macht ein "Bewegungsspektrometer" eigendlich genau? ;-) Habe von soetwas noch nie gehört ;-O mfg
~Mercedes~ schrieb: > @Maddin, was macht ein "Bewegungsspektrometer" eigendlich genau? ;-) > Habe von soetwas noch nie gehört ;-O guckstdu: Maddin S. schrieb: > Es handelt sich um ein ionen mobilitäts spektrometer. guckstduweiter: https://de.wikipedia.org/wiki/Ionen-Mobilit%C3%A4ts-Spektrometer
> https://de.wikipedia.org/wiki/Ionen-Mobilit%C3%A4t...
Boahh!!!
Und da meint ihr, dies ist keine Raketentechnologie? ;--OO
@Maddin, Du solltest auch die Gegenrichtung
Computer ---> Messgerät anschließen.
mfg
~Mercedes~ schrieb: > Und da meint ihr, dies ist keine Raketentechnologie? Nicht das Protokoll, mit dem das Ding über seine serielle Schnittstelle seine Daten ausgibt. Was das Gerät misst, kann ja gerne beeindruckend komplex sein, aber beim Übertragen von Daten auf seriellen Schnittstellen kochen Messgerätehersteller alle nur mit Wasser, und viele machens dabei noch nicht mal besonders warm.
@Rufus, Ist schon klar. Ich würde auch nie wagen, die Kompetenz eines Hasen anzuzweifeln. ;-P Im Gegenteil, ich würd sie schamlos ausnutzen! ;--P Sauer bin ich trotzdem: Da mache ich mich selbst durch Vertippen in diesem feinem Board madig, versuch es dann in der Stunde zu richten und werde vom Lehre angemacht. "Ja, wie kann ich wagen in seiner Landwirtschaftsschule auf Controllerboards herumzusurfen" Und dann ist das Teil hier ne elektronische Hundenase! mfg
~Mercedes~ schrieb: > Und dann ist das Teil hier ne elektronische Hundenase! Mach hier die armen Hunde nicht verächtlich. Ganz abgesehen davon läuft der Zoll immer noch mit realen Hunden um die Koffer und nicht mit kiloschweren Geräten und Laptop. Warum wohl? Georg
~Mercedes~ schrieb: > Ich würde auch nie wagen, die Kompetenz eines Hasen anzuzweifeln. > Und dann ist das Teil hier ne elektronische Hundenase! Irgendwie hast Du es heute mit den Tiermetaphern. Wo aber ist der Hase? Ist der Hase überhaupt ein Hase, oder ist er ein Kaninchen (was von vielen zwar "Hase" genannt wird, tatsächlich aber eben keiner ist)?
Ich glaube, das Mitlesen und Decodieren des Protokolls bringt Nichts, dann kann der TO ja lediglich das, was das bereits vorhandene Programm ohnenhin schon kann. Zusätzliche Funktionen werden dadurch sicher nicht zum Vorschein kommen.
Naja, zum Exportieren und anders Verarbeiten reicht es doch vollkommen hin die vorhandene Kommunikation zu verstehen. BTW: Man kann auch Daten aus Fensterelementen (ListBox usw.) anderer Programme auslesen. Ist evtl. auch ein Weg wenn das mit dem Protokoll verstehen aus irgendwelchen Gründen nicht klappt.
Guck doch erstmal, ob dein Messgerät von Sigrok unterstützt wird. https://sigrok.org/wiki/Main_Page https://sigrok.org/wiki/Supported_hardware#Multimeters Da sind sehr viele Multimeter hinterlegt.
:
Bearbeitet durch User
Frank E. schrieb: > dann kann der TO ja lediglich das, was das bereits vorhandene Programm > ohnenhin schon kann. Das weiß man nicht. Denn ob die Beschränkung in den übertragenen Daten selbst oder in der die Daten aufbereitenden Software liegt, ist unbekannt. F. F. schrieb: > Guck doch erstmal, ob dein Messgerät von Sigrok unterstützt wird. Wahrscheinlich ist das nicht, denn > Da sind sehr viele Multimeter hinterlegt. das Messgerät ist doch ein bisschen was anderes als ein verbreitetes Multimeter.
Ich meinte das auch mehr wegen des RS232. Vielleicht haben die einfach ein Protokoll das mehrere verwenden. Ich würde die nacheinander einmal durch probieren. Wer weiß, vielleicht kommt zufällig etwas gescheites bei raus. Dann hätte er eine gute Software, die bestimmt keine Wünsche übrig lässt.
Aber vielleicht kann er die Messdaten sonst in einem anderem Programm weiter verarbeiten. Nur ein Beispiel: https://www.electronic-software-shop.com/elektronik-software/realview-30.html
Nun, das Mithören der Daten gelang schon vor zwei Tagen; vielleicht postet der Threadstarter ja mal einen Auszug davon, so daß wir hier da einen Blick drauf werfen können. Möglicherweise erkennt dann jemand das Protokoll.
Rufus Τ. F. schrieb: >> Ich würde auch nie wagen, die Kompetenz eines Hasen anzuzweifeln. > Irgendwie hast Du es heute mit den Tiermetaphern. Wo aber ist der Hase? https://www.weltbild.de/artikel/deko-trends/deko-hase-rufus_24118069-1
Rufus Τ. F. schrieb: > das Messgerät ist doch ein bisschen was anderes als ein verbreitetes > Multimeter. ...aber wird möglicherweise von LabView unterstützt. Eine Anfrage dort könnte sich lohnen. Allerdings ist LabView nicht gerade billig.
Guten Morgen =) nur zufällig hier schrieb: > BTW: Man kann auch Daten aus Fensterelementen (ListBox usw.) anderer > Programme auslesen. Ist evtl. auch ein Weg wenn das mit dem Protokoll > verstehen aus irgendwelchen Gründen nicht klappt. Das ist ein heißer Tipp. In der Software wird das vollständige Spektrum ja graphisch dargestellt. Das Problem ist halt, dass keine Exportfunktion für die hinterlegten Daten zur Verfügung steht. Wenn man das aber irgendwie aus dem Fenster auslesen kann, könnte das Problem damit schon erschlagen sein. Womit könnte man das bewerkstelligen? Im Serial Port-Monitor stehen mir 5 Fenster zur Verfügung. (Table View, Line View, Dumb View, Terminal View, Modbus VIew) Keine Ahnung welche hiervon von Interesse sein könnten. Hier ist trotzdem erstmal ein Teil der ausgelesenen Daten (Terminal View): C. .C.`.C.ÀøB. äB.@ÎB..½B.À®B. ¡B.À˜B.à“B. B.ÀB.àB.àŽB..”B..›B.`¤B.`«B.À±B.`¶B. ·B.À¶B.€´B.à®B.À¨B.€£B..œB..–B.€‘B.`B..B.@ŒB.@ŒB.`ŒB.à‹B.ÀŽB.à‘B.@“B.à •B.@•B.€•B.à”B.à’B.@“B.€‘B.€B.`ŽB.ÀB..ŽB.@ŽB.€ŽB. ŽB..B.€B.àB.@‘B. ”B.À“B. ‘B. B.À‘B. ’B.€‘B.`B. B. B. B..B. B. ŽB.àŒB.ÀŒB.€ŽB. B.`‘B.à’B.@’B.à‘B. ’B.@‘B.àB.àB. B.ÀŽB.àŽB.àB.@ŽB.€B.@B.ÀB..ŽB. ŽB.€B. ŽB.àB.àB..ŽB.àŒB.`ŠB.ÀŠB.à‰B. Das ist nur ein Teil des ganzen Blocks, den ich als den Messdaten-Block identifizieren konnte. Vermutlich kann man damit aber nicht viel anfangen, oder? Ich möchte jetzt nicht die ganze Datei vom Serial-Port-Monitor hier hochladen, sonst komm ich noch in Teufels Küche, wenn der Hersteller rauskriegt was wir mit seinem Gerät machen.
Maddin S. schrieb: > Im Serial Port-Monitor stehen mir 5 Fenster zur Verfügung. (Table View, > Line View, Dumb View, Terminal View, Modbus VIew) Keine Ahnung welche > hiervon von Interesse sein könnten. > Hier ist trotzdem erstmal ein Teil der ausgelesenen Daten (Terminal > View): > .. Dumb View hört sich nach hex-dump an. Bei Binärdaten ist eine Hex-Darstellung sicher hilfreich - bitte einen Daten Block in hex posten. Datenrate, Parität, Stopbits sind richtig eingestellt?
Maddin S. schrieb: > Ich möchte jetzt nicht die ganze Datei vom > Serial-Port-Monitor hier hochladen, sonst komm ich noch in Teufels > Küche, wenn der Hersteller rauskriegt was wir mit seinem Gerät machen. Hast du einen Vertrag mit dem Hersteller der das verbietet?
Maddin S. schrieb: > sonst komm ich noch in Teufels > Küche, wenn der Hersteller rauskriegt was wir mit seinem Gerät machen. Also ist das gewollt vom Hersteller und ihr möchtet jetzt billig an mehr Leistung kommen, die ihr nicht bezahlen wollt? Sehe ich das so richtig?
F. F. schrieb: > Also ist das gewollt vom Hersteller und ihr möchtet jetzt billig an mehr > Leistung kommen, die ihr nicht bezahlen wollt? Sehe ich das so richtig? Leider ist es nicht gerade selten, dass Hersteller von Messgeräten zwar ein gutes Gerät liefern aber eine äußerst bescheidene Software. So auch in diesem Fall. Herstellerseitig gibt es hier einfach keine Möglichkeit an die Daten zu kommen. analysator2 schrieb: > Dumb View hört sich nach hex-dump an. > > Bei Binärdaten ist eine Hex-Darstellung sicher hilfreich - bitte einen > Daten Block in hex posten. > > Datenrate, Parität, Stopbits sind richtig eingestellt? Ich hoffe du hast das so gemeint:
1 | c0 64 42 00 40 64 42 00 40 66 42 00 00 68 42 00 ÀdB.@dB.@fB..hB. |
2 | 80 66 42 00 40 68 42 00 80 66 42 00 80 65 42 00 €fB.@hB.€fB.€eB. |
3 | 80 68 42 00 40 6c 42 00 00 67 42 00 00 66 42 00 €hB.@lB..gB..fB. |
4 | 40 65 42 00 80 66 42 00 80 68 42 00 c0 68 42 00 @eB.€fB.€hB.ÀhB. |
5 | c0 6b 42 00 00 6a 42 00 80 6b 42 00 40 69 42 00 ÀkB..jB.€kB.@iB. |
6 | c0 66 42 00 40 67 42 00 00 6a 42 00 00 6e 42 00 ÀfB.@gB..jB..nB. |
7 | 40 6f 42 00 00 6d 42 00 40 6a 42 00 c0 69 42 00 @oB..mB.@jB.ÀiB. |
8 | 00 69 42 00 00 69 42 00 c0 66 42 00 00 6b 42 00 .iB..iB.ÀfB..kB. |
9 | 40 6a 42 00 40 6c 42 00 00 6f 42 00 00 6e 42 00 @jB.@lB..oB..nB. |
Die Baudrate stimmt definitiv. Die kann ich nämlich auch in der Herstellersoftware einstellen. Bei den anderen Parametern bin ich mir nicht sicher. Hab alle Varainten mal durchprobiert aber keinen offensichtlichen Erfolg. Ich hab mal versucht mit Spy++ das Fenster mit dem Spektrum auszulesen. Leider auch hier kein Erfolg. Gruß Maddin -- [ pre ] [ /pre ] -Tags hinzugefügt -rufus
:
Bearbeitet durch User
Ich machs jetzt einfach mal anders. Im ANhang ist die Datei vom Serial-Port-Monitor. Vielleicht könnt ihr ja damit was anfangen. Gruß Maddin
Vielleicht auch mal Google fragen mit Angabe des Gerätes und Hersteller. Ich könnte mir vorstellen, daß du nicht der einzigste auf der Welt bist, dem gerade diese Software von diesem Gerät nicht zusagt. Vielleicht haben andere Leute schon etwas mehr rausbekommen und im Netz gepostet. Was deine angehängte Datei betriftt : Das scheinen erst "COM1" + 8 Bytewerte zu sein. Wobei zwei Bytewerte immer durch ein Chr$(42) = * + Chr$(0) = Stringende-Zeichen, getrennt sind. Könnte nun sein, daß das schon das ganze Protokoll ist : * + Chr$(0). Kämen denn solche Werte in Betracht ? c0 64 42 00 40 64 42 00 40 66 42 00 00 68 42 00 = 192, 100*64, 100*64, 102*0, 104* Müßte man dann sehen, was die Originalsoftware da genau als Grafik o.ä. ausgibt. Kann aber auch sein, daß ich mich da irre, also ohne Garantie.
Ach ja, da ja immer 2 Bytes + * kommen, könnte es auch ein Word - Wert sein (was ich eher für unwahrscheinlich halte) Für die Zeile c0 64 42 00 40 64 42 00 40 66 42 00 00 68 42 00 kämen da die Werte 25792*25664*26176*26624* raus. Evtl. passt das besser ?
Angehängte Dateien:
-
s1.png
27 KB
Maddin S. schrieb: >
1 | > c0 64 42 00 40 64 42 00 40 66 42 00 00 68 42 00 ÀdB.@dB.@fB..hB. |
2 | > .. |
3 | > 40 6a 42 00 40 6c 42 00 00 6f 42 00 00 6e 42 00 @jB.@lB..oB..nB. |
4 | > |
Wenn man "42 00" ignoriert sieht es so aus.(^) Schön ;-)
Aha, scheinen dann doch 16Bit Word - Werte zu sein, also 2 Bytes lang.
Werde ich gleich mal testen, ob das passen könnte. Kurze Verständnisfrage: Ich habe jetzt 30 Minuten verzweifelt versucht zu begreifen wie man von "C0 64" auf die Dezimalzahl 25792 kommt, bis ich herausgefunden habe dass man hierfür "C0" und "64" vertauschen muss also "64 C0". Kann mir das einer erklären wieso?
Maddin S. schrieb: > Ich habe jetzt 30 Minuten verzweifelt versucht zu begreifen wie man von > "C0 64" auf die Dezimalzahl 25792 kommt, Das geht schneller: https://www.rapidtables.com/convert/number/decimal-to-hex.html?x=25792 oder per DEC-HEX-Umwandlung Deines Taschenrechners.
Was soll ich sagen ... es schein zu klappen =) Im Anhang einmal der Plot aus der Software und der Plot aus den extrahierten Daten. In den Daten sind zwar noch zwei unterschiedliche Spektren vermischt und die Einheiten passen noch nicht, weil die Software die Umrechnung übernimmt, aber man erkennt deutlich, dass es zumindest qualitativ sehr gut zusammen passt. Jetzt kann die Fleißarbeit losgehen und ich versuch die Daten soweit aufzubereiten dass wir das sehen, was wir sehen wollen. Vielen vielen Dank Leute! Gruß Maddin
Für mich sehen die Raw Daten eher nach echten Werten aus (wenn das sein kann? Das wirst du besser beurteilen können) und die der Software nach "glatten" Daten. Je nach dem was man will.
Angehängte Dateien:
-
Raw2.JPG
41 KB
Ja, die Software glättet da so einiges weg. Diese großen Ausreißer sind dadurch zu erklären, dass an diesen Stellen der Wertebereich des 16 Bit WORD Wertes überschritten wird. Die Daten sind an diesen Stellen anstatt der "42 00" durch eine "43 00" getrennt. Wenn ich diese Werte mit 65.535 (maximaler Wertebereich) addiere, sieht es wunderbar aus. freu Gruß Maddin
Nun, vielleicht sind das keine 16-, sondern 32-Bit-Werte.
> c0 64 42 00 40 64 42 00 40 66 42 00 00 68 42 00
kann nämlich auch als die vier Werte
004264c0
00426440
00426640
00426800
gelesen werden
Und wenn da statt "42 00" ein "43 00" steht, passt das ins Schema.
Maddin S. schrieb: > sieht > es wunderbar aus. freu Sieht deutlich mehr nach echten Messwerten aus, als das was die original Software da leistet.
Oder fragen wir doch mal anders rum : Welcher µC ist denn im Messgerät verbaut ? Es gibt ja 8Bit, 16Bit, 32Bit usw. Evtl. kann man ja darüber das Zahlenformat bestimmen. Ich denke mal, daß ein 16Bitter auch eine 16Bit-Zahl verschickt.
Das halte ich für keine zielführende Vorgehensweise. Auch ein 8-Bit-µC kann selbstverständlich 32-Bit-Werte ausgeben. Interessant wäre ein längerer Datenblock als Hexdump, weil irgendeine Art von Synchronisation erfolgen muss. Ohne die könnte man beim Decodieren einfach irgendwo im Datenstrom aufsetzen und liest dann offensichtlichen Müll. Ich nehme mal an, daß das Messgerät nicht einfach so vor sich hinsendet, sondern von der Steuersoftware zum Senden aufgefordert wird. Interessant ist so eine Sequenz, die Aufforderung an das Gerät und die Antwort darauf. Ich nehme an, daß da eine Art Paketheader o.ä. kommen wird, in dem z.B. drinsteht, wieviele Messwerte folgen, oder daß immer eine konstante Anzahl von Messwerten auf jede Aufforderung hin übertragen werden. Mit dem Dump der Eltima-Software lässt sich ohne diese aber nichts anfangen, da die offensichtlich mehr Daten als nur die vom Gerät gesendeten enthält.
Hallo, es wurde doch oben schon Portmon erwähnt. Das kann doch ganz einfach einen Export des Logs ausgeben. Das kann man hier besser einsehen. Man muss nur Portmon starten und dann die Schnittstelle auswählen auf der gelauscht werden soll. Gruß Sven
Gab es schon ganz früher. Hatte ich glatt vergessen. Wenn ein Modem nicht richtig lief, hat man damit geguckt.
Ist ja auch die Frage, ob das Gerät eine Punktmessung oder eine Dauermessung macht, solange etwaige Sensoren etwas hergeben. Also, wie ein Laserthermoter mit dem Laserpunkt eine Punktmessung macht, wenn der Punkt fixiert ist und ein Voltmeter durch Anhalten zweier Kabel (+ und -) eine Art Daeuermessung macht (vlt. 1-3 Sekunden). Beim Voltmeter braucht es da keinen Anstoß, das mißt solange und gibt aus, wie Strom anliegt. Ein Bratenthermometer macht da auch eine Dauermessung. Das muß auch zwei bis drei Sekunden drinstecken, um verwertbare Ergebnisse zu erhalten. Ich glaube, das Prinzip, was ich meine, ist klar. Ich denke, er soll doch mal einfach das Gerät mit HTerm oder Portmon verbinden und eine Messung machen. Wenn dann schon Daten kommen, braucht das Gerät erst gar keine Aufforderung.
:
Bearbeitet durch User
Doch, die Messung muss von der Software aus gestartet werden. Und das Gerät kann Einzelmessungen und Dauermessungen machen, was dann jeweils in der Software ausgewählt werden muss. Portmon hatte ich auch getestet, hatte aber aus irgendeinem Grund nicht funktioniert. Die Möglichkeit die Steuerbefehle abzufangen und ggfs. extern das Gerät zu steuern interessiert mich ohnehin nicht mehr, da es vollkommen ausreicht nur die einkommenden Daten abzufangen und das Gerät weiterhin über die Hersteller-Software zu steuern. Wofür ich jetzt noch eine Lösung brauche, ist die Daten Live auszulesen. Bis jetzt habe ich mit dem Serial-Port-Monitor die Daten aufgezeichnet und manuell den eigentlichen Messdaten-Block extrahiert und mit Python ausgewertet. Das ganze soll jetzt automatisch erfolgen, also ohne den Serial-Port-Monitor. Vielleicht kann man ja mit Com0Com einen virtuellen Port erstellen, den man mittels Python mit dem echten Port (an dem das Messgerät hängt) kurzschließt (also alle Daten in beide Richtungen weiterleiten). Und die Steuerungssoftware würde man dann mit dem virtuellen Port verbinden. Kann das so in etwas funktionieren?
Maddin S. schrieb: > Vielleicht kann man ja mit Com0Com einen virtuellen Port erstellen, den > man mittels Python ... com0com enthält genau dafür hub4com. Da braucht's kein Python.
Maddin S. schrieb: > Da die RS232-Schnittstelle aber kein sharing unterstütz geht das > glaube ich nicht, oder? Notfalls nimmst du einen Lötkolben in die Hand und lötest die RX-Leitung von deinem "Lausch"-Port an die gewünschte Leitung, auf der du mithören möchtest - ganz ohne Software.
Is, therefore,question of whether the device is a point measurement or make a permanent measurement, as long as any sensors give something away. https://www.johnpatel.com/tools/decimal-to-hex-converter/
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.