Hallo zusammen, eigentlich eine 'Allerweltsfrage', aber ich finde keine Antwort: Ich möchte einen 'virtual com port' mitschneiden. Der USB-Stick DV4mini verhält sich wie ein USB-VCOM und über ein Terminal will ich den Datenverkehr mitschneiden. Unter Windows 7 hatte ich das schon öfter gemacht. Aber unter Win10 läuft com0com nicht und ich finde auch keine Alternative. Kaufsoftware könnte ich mir vorstellen, wenn es im Trial keine Einschränkungen gibt oder falls jemand von konkreten positiven Erfahrungen berichten kann. Hat jemand einen Tipp? VG Torsten
Torsten C. schrieb: > Aber unter Win10 läuft com0com nicht Auf der com0com-Seite selbst ist bizarrerweise Reklame für ein kommerzielles Produkt von Eltima zu finden: http://com0com.sourceforge.net/ Sowas habe ich auch noch nicht gesehen. Das eigentliche Problem dürften signierte Treiber sein. Die soll es für com0com hier geben: http://pete.akeo.ie/2011/07/com0com-signed-drivers.html (da steht zwar als Datum was von 2011, die Treiber aber sind vom Juni 2016)
:
Bearbeitet durch User
Das gute: Cool, klappt! :-) Danke, Rufus! Das schlechte: Ich hatte wohl einen Denkfehler: Man müsste das DV4mini-Control-Panel (das betreffende Programm) dazu bringen, sich statt mit COM8 (Bild) mit CNCA0 oder CNCB0 zu verbinden, weil man geöffnete Ports gar nicht aufsplitten (anzapfen) kann. Ich probiere mal, ob ich mit WireShark USBPcap was sehe. Aber eigentlich wollte ich die Daten in Echtzeit haben, nicht aus einer Log-Datei.
Torsten C. schrieb: > COM8 (Bild) mit CNCA0 oder CNCB0 zu verbinden Du kannst die Dinger auch umbenennen, so daß Dein abzuhörendes Programm auch die com0com-Ports akzeptieren sollte.
:
Bearbeitet durch User
Schau mal nach hub4com, das gibt es auch im Umfeld von com0com... ist ein scriptconfigurierbarer Hub, mit dem Du in sämtliche Himmelsrichtungen routen kannst.
@STM32: So wie in Variante 1? Ich behaupte mal: Das geht mit hub4com nicht. Oder bin ich zu blöd? Es wäre aber cool, wenn das ginge. :) Variante 2 wäre ohne hub4com: * Ein neues Paar aus CNCX und COM8 erzeugen. * Logger mit COM 8 verbinden (der ist dann belegt und wird nicht mehr gefunden) * Im Logger CNCX TX an COM8 RX streamen (und loggen) … und COM8 TX an CNCX RX streamen (und loggen) * Programm "SUT1" starten, das findet dann nur COM9 … hoffentlich. Das könnte gehen. Ich probiere das morgen mal, mit einem Logger in C#.NET, wenn es keine bessere Idee gibt. Ich hoffe, dass nicht auch noch DTR, CTS, RI usw. verbunden werden müssen.
Ich behaupte, es geht. Nur zusammengetippelt, ohne Gewähr: hub4com.exe --baud=115200 --octs=on --odsr=on --route=\\.\COM9 \\.\CNCA1 \\.\COM9 \\.\CNCB1
STM32 schrieb im Beitrag #4734687: > --route=\\.\COM9 \\.\CNCA1 \\.\COM9 \\.\CNCB1 Und dann geht COM9 TX bei COM8 RX an? ?! Und wohin geht COM8 TX? Falls das ein Tippfehler war, vielleicht meintest Du: * --route=\\.\COM9 \\.\CNCA1 \\.\COM8 \\.\CNCB1 ¯ Dann ginge COM8 TX zwar an CNCB1 RX, aber immer noch nicht an COM9 RX, so wie ich das verstehe. Mit zwei Terminals sehe ich noch kein Land. Ein 'man in the middle' scheint leider nötig. :-(
Danke, Helen. Wie gesagt: Über ein Terminal-Programm (zwei Terminal-Fenster) will ich den Datenverkehr mitschneiden. Ich finde keinen Hinweis, dass man mit 'virtual-null-modem.com' die beiden TX-Streams 'anzapfen' und auf zwei weitere Ports leiten kann. Siehe auch Variante 1 im Bild oben.
:
Bearbeitet durch User
... ich hatte ja gesagt, nur schnell zusammengetippelt... nocheinBeispile: hub4com.exe --baud=115200 \\.\COM1 \\.\COM21 \\.\COM23 \\.\COM25 --route=0:1 --fc-route=0:1 --route=1:0 --fc-route=1:0 --route=0:2 --route=1:3 Bei diesem Aufruf hast Du 4 Ports. Du routest jetzt Com 1 <=> Com 21 Com 1 => Com 23 Com 21 => Com 25 Du kannst also wirklich in alle Himmelsrichtungen, okay?
Aaaaa! Jetzt habe ich das Konzept von hub4com.exe endlich verstanden. Logisch: * Die Port-Paare bleiben bestehen. * Man benötigt 3 Port-Paare * hub4com öffnet und blockiert die angegebenen Ports. Also müssen die Terminals sich mit den Gegenseiten der Port-Paare verbinden (blaue Pfeile). Danke für Deine Hartnäckigkeit, STM32 und auch nochmal an Rufus. SUT1 findet COM9 und es klappt nun auch mit den Terminals. :)
Torsten C. schrieb: > * Die Port-Paare bleiben bestehen. > * Man benötigt 3 Port-Paare > * hub4com öffnet und blockiert die angegebenen Ports. Genau. Stell Dir einfach vor, die Portpaare seien Kabel, die Du in einen Hub steckst. Intern routen tust Du mit dem Script. Torsten C. schrieb: > Danke für Deine Hartnäckigkeit, STM32 Keine Ursache. Hilf halt auch mal anderen ;-)
Torsten C. schrieb: > auch nochmal an Rufus. Danke; ich werd's vermutlich selbst demnächst brauchen und bin insofern schon mal froh darum, das Windows-10-Problem gelöst zu haben. Reiner Eigennutz also ...
Es ist zum Mäuse melken. :-( Mit Putty klappt es. Will ich nun ein C#-Programm verbinden, dann geht es nicht. Kann das damit zusammen hängen, dass weder am CN2A-RX noch am CN1A-RX (siehe Bild) ein RX angeschlossen ist? Also daran, dass CN1B-TX und CN2B-TX ins 'leere' gehen? System.IO.Ports.SerialPort.DataReceived() wird ausgelöst, aber System.IO.Ports.SerialPort.BytesToRead ist immer == 0. Auch System.IO.Ports.SerialPort.BaseStream.BeginRead() ruft nie den Delegaten auf. Die Variante mit dem BeginRead()-Delegaten, die auch nicht auf empfangene Zeichen reagiert, habe ich von: http://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport
:
Bearbeitet durch User
Ich hab mir das C#-Beispiel nicht angeguckt, aber auf Anhieb hätte ich die Handshakesignale im Verdacht....
SerialPort.Handshake steht auf "Handshake.None". Schade, das kann also nicht die Ursache sein. PS: Für --route=0:2 und --route=1:3 gibt es oben ja kein entsprechendes "--fc-route". Ich wüsste auch nicht, womit man den Flow-Control verbinden sollte. Oder sollte ich für "--fc-route" vielleicht noch zwei weitere Port-Paare einrichten, wo dann z.B. Putty dran hängt? ?!
:
Bearbeitet durch User
Schau Dir mal die Ruhezustände der Handshakeleitungen an. Putty ist da sehr robust, was das anbelangt. Es kann schon sein, daß unter DOTNET die Schniittstellensignale anders oder eben interpretiert werden.
STM32 schrieb im Beitrag #4736365: > Schau Dir mal die Ruhezustände der Handshakeleitungen an. Meinst Du die Properties im C# SerialPort? Mach ich heute Nachmittag, aber wie bringt mich/uns das weiter? Oder meinst Du noch eine andere Anzeige-Möglichkeit, die ich nicht kenne?
Naja, ich meinte, daß, dadurch das der Ruhezustand nicht durchgeroutet wird, eventuell der Port eventuell aktive Handshakes sieht.
Auch wenn der Thread schon älter ist noch eine kostenlose Alternative eines VSPE. Nachteil: Wird nur an lizenzierte Funkamateure abgegeben aber wer einen DV4mini nutzt (Hotspot für digitale Voicemodes auf VHF und UHF) hat eine solche Lizenz. Einfach mal nach K5FR VSPM googeln. Auf der Seite wird man aufgefordert ihn mit angabe des Rufzeichens zu kontaktieren und er schickt dann eine Kopie per eMail. Ich nutze die Software um meinen RedPitaya SDR auch über meine Logbuchsoftware per CAT steuern zu können. Dazu brauchte ich ein Comport Paar das die Software PowerSDR mit meinem Logger verbindet. Gruß und 73´s ... Jürgen DF___
Bitte 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.