KX2 und Winlink / Winmore via USB ?

Mit dem USB Kabel kannst Du den KX2 steuern und mit der Elecraft Software auch die Geräteintenre PSK31/63 und CW Funktion mit dem PC steuern. Aber eine Souncard-Funktion ist im KX2 nicht integriert. Deshalb musst Du für Winmore eine Verbindung von der PC Soundkarte zum Mikrofon und Kopfhöreranschluss machen.

73, Peter - HB9PJT

Zitat

Mir ist auch bislang nicht klar warum, wenn unsere Geraete doch nun eine USB-Schnittstelle haben, da immer noch mit COM aus der RS232 Welt hantiert werden musz.

Also das kann ich Dir sagen :
Das ist eine definierte Schnittstelle, die es ermöglichst, das gerät X mit Software Y zusammenarbeiten kann.
Wenn es darum geht, nur ein paar Daten zu übertragen ist die super.

Die Probleme die Du hattest, hatte ich übrigens auch schon mit anderen Schnittstellen ( festplatten.. etc.. ) und bei genauerer Betrachtung, lag der Fehler dann eher an der Implementierung von :
Hardware, Treiber, Anwendungssoftware, Betriebsystem oder der Fehler saß einfach vor meinem Rechner !
Es gibt noch einen Grund für die "COM" schnittstelle : Sie ist verdammt einfach.
Zumindest für den Geräteentwickler. z.B. Controller.
Ein paar Bytes zu empfangen (z.B. die eingestellte Frequenz) ist mit wenigen Befehlen sehr einfach zu realiseren.
Aber ! Die Einfachheit, ist auch ihre grösste flexibilität !
z.B. musst Du gar nicht USB nutzen. Serielle Daten lassen sich auch wunderbar über Bluethooth übertragen.
d.H. wenn ein Atmel Controller einen VFO (z.B. SI570) ansteuert, kannste Dir aussuchen, ob Du an ihm ein USB-Converter anschließt, oder ein Bluethooth Modul.
Wenn Du etwas pfiffig bist, kriegst sogar beides hin.
z.B. habe ich mir aus einer ollen Wettersonde mir eine sehr gute GPS Maus gebaut, die man per Bluethooth ans Tablet anbinden kann, wie auch per USB.
Und eine 5Eur Powerbank übernimmt übrigens die Stromversorgung.
(Nicht nur da.. auch mein Frequenzzähler ist mittlerweile dadurch Wireless.)

Und nur weil etwas "Alt" ist, ist es noch lange nicht "depricated"... also der X86er Befehlssatz stammte aus den 60ern..
DMA, Multitasking, etc.. sogar aus den 50ern..
http://www.heise.de/tp/artikel/42/42501/1.html

Das zum Thema "Altmodisch".

Moin,

Zitat von DL4KE

Mir ist auch bislang nicht klar warum, wenn unsere Geraete doch nun eine USB-Schnittstelle haben, da immer noch mit COM aus der RS232 Welt hantiert werden musz.
Man kann doch sonst hunderte USB-Geraete an seinen laptop anschlieszen und nirgendwo kommt ein Hersteller auf die Idee dem Anwender was von "COM" zu erzaehlen,
einfach dran,fertig. Nur bei den Afu-Geraeten wollen alle immer noch diesen altmodischen COM-schnickschnack installiert haben. Ich kann mein handy, meine festplatte und was weisz ich alles an den Laptop stecken, da war niemals irgendwo was von "COM" gestanden. Das ging einfach.

Da muss ich mal Einspruch einlegen! USB hat einen ganz gravierenden Nachteil, es gibt keine garantierten Antwortzeiten! Aus diesem Grunde wird in der professionellen Steuerungstechnik RS232, RS485, RS422 und IEEE 488 eingesetzt. In unserem Hobby kann man dies bemerken, wenn man über einen USB Seriell Adapter ein CW Interface steuert. Ab ca. 20 WpM entstehen zum Teil gravierende Latenzzeiten, man gibt ein Dit und am nächsten Tag schaltet der Trx auf Tx um Das war mit ein Grund für z.B. den Winkeyer.

USB ist eine Technik für Consumer Elektronik, aber nichts für den ernsthaften Anwender, der erwartet, dass das angeschlosse Gerät sofort reagiert. Die Gerätehersteller, die ihre Transceiver mit RS232 ausrüsten, sind Profis, die anderen Bastelbuden

Bei Handy, Festplatte, Drucker usw. kommt es nicht auf das Zeitverhalten an, es wird auch immer ein Datenstrom übertragen und keine einzelnen Bytes. Wenn man nur wenige Bytes sendet, kommt es auf die Implementierung an, USB arbeitet da mit Timeouts, wartet also, ob da noch mehr kommt, bevor dies weitergeschickt wird. Ausserdem wird nicht gesendet, wenn das Betriebssystem des PC meint, es müsste erst mal was anderes machen. Das fällt bei den genannten Geräten nicht weiter auf, wenn aber ein Byte in 20ms raus sein muss, sehr wohl. Bei den USB Seriell Wandlern hilft es dann evtl, den FiFO für den virtuellen COM Port zu deaktivieren. Eine Garantie gibt es aber dabei nicht.

73, Tom

Genau aus diesem Grund habe ich in meine PC's zusätzliche COM-Schnittstellen eingebaut. Damit entfällt bei mir einiger Ärger. Die Schnittstellenkarten werden sogar von Windows 8 und 10 problemlos erkannt.

Diese Aussage mit CW über eine USB Schnittstelle war mir auch bakannt. Die Frage war nur, aus welcher Zeit und mit wie alter Hardware diese Beobachtung war.

Mit einem ca. 10 Jahre altem Desktop und einem Microham USB Interface über Steuerleitung getastet (Wintest) konnte ich bis 40WPM keine signifikanten Jitter Erscheinungen oder gar Aussetzer beobachten. Also scheinen aktuelle Rechner insgesamt schnell genug zu sein auch ohne Echtzeit Betriebssystem die Anforderungen für ein CW-Keying über USB auf RS232 Interface erfüllen zu können. Da 40WPM jenseits meiner CW-Fähigkeiten liegt, habe ich es nicht im Dauertest geprüft, sondern nur mit einen mehrfach gestartetem CW-Ruf, den ich dann per Oszilloskope an dem Antennenausgang aufgezeichnet hatte.

Es ist eben die Frage, mit was für Rechenleitungen/Betriebssystemen die Beobachtungen ab 20WPM gemacht wurden. Ich vermute, dass ist mit einigermaßen aktueller Hardware, die nicht mit unsinnigen parallel laufenden Programmen überlastet ist, mit USB Interfaces keine Timing Probleme mehr auftreten werden.

Die Win-Keyer selbst benutzen ja auch eine Serielle Schnittstelle, die heute meist nur noch über USB anschließbar ist. Der Unterschied ist nur, dass einzelne Zeichen über die Schnittstelle in die Sendeque gestellt werden und das Tasten der Zeichen dann durch den eingebauten Chip veranlasst wird.

Das ist meiner Meinung nach bald überfällig, da man bei den neueren TRX dieses auch über CAT -Befehle für die meisten üblichen Betriebsarten (CW, RTTY, PSK) machen kann. Da geht es "nur" noch darum, dieses auch in der entsprechenden PC-Software umzusetzen.

vy73 de Karsten, DD1KT

Moin,

das hat mit der Geschwindigkeit, dem Alter des PC und Echtzeit nichts zu tun, sondern mit dem Design von USB. USB ist nicht darauf ausgelegt, einzelne Bytes zu senden, sondern arbeitet mit Streams. Echtzeit sagt erst mal nichts darüber aus, welche Zeiten definiert sind. Auch ein System mit der Antwortzeit von einer Stunde ist ein Echtzeitsystem, wenn die Antwort garantiert ist.

Hast Du bei Deinem Messaufbau den Abstand zwischen den Zeichen und den Dits und Dahs kontrolliert? Wurde dass Verhältnis von z.B. 1:3 immer eingehalten? Sind die Pausen mit korrekter Länge übertragen worden? Darauf kommt es bei CW an.Wenn Du mit dem Oszilloskop nur die Dits und Dahs kontrollierst, weisst Du noch nicht, ob das a ein a war, oder ein e und t.

Man muss dazu gar nicht an den Senderausgang gehen, der Mithörton langt schon.

Je nach Implementierung des Treibers, des verwendeten Chips, was noch auf dem Bus hängt und gerade auf dem Rechner läuft kommt es auch bei modernen Rechnern zu diesen Erscheinungen. Das ist bekannt, nicht nur bei CW, sondern auch in der Steuerungstechnik z.B. mit einem HART Modem an einem USB Seriell Wandler.

Das lässt sich auch anders herum testen: Klemme mal eine Taste an eine Leitung der RS232 an einem USB Seriell Wandler an und nehme eines der CW Übungsprogramme. Man hört es ab 20 WpM, Tastendruck und Tonausgabe und Zeichenabstände "leiern", mit einer echten RS232 nicht.

73, Tom

Naja.. nur erzeugt mangelnde Echtzeitfähigkeit in dem Fall ( Winmor) nicht zu Problemen..

Eigentich ist das Problem doch folgendes :
Wenn man früher COM1 für z.B. Funke reserviert hat,
COM 2, für ein Modem,
COM 3, für einen TNC...

Wenn an COM2, das Modem AUS war. dann war COM2 immer noch da, aber da darüber gingen keine Daten, und das Programm meckerte. Und gut ist.

hat man jetzt das problem, das der Host also der PC entscheidet, was was sein soll.
https://de.wikipedia.org/wiki/Universal_Serial_Bus

Also je nachdem wo was steckt, und wann es eingestöpselt wird,
z.B. wenn ich erst den TNC einstöpsel, ist der auf einmal COM1.. usw.

Den einzigen Trick den man machen kann, und der ziemlich sicher funktioniert ist :
Man nimmt 2 unterschiedliche Deviceklassen : 02h und 0Ah
Unter Linux erschient die eine als /dev/ttyUSBx und die andere als /dev/ttyACMx
Klappt aber nur mit 2 Geräten.

Unter Windows allerdings.. viel Spass.. nach dem nächsten Update kann alles wieder anders ausschauen !
Wie war das noch mal : Never change a running System ?

Apropos QRP und Winmor : Machst Du Dir eigentlich auch den Spass, Dir eine E-Mail an Dich selbst über eine möglichst weit entfernte Station zu senden ?
Das letztes Jahr, hatte ich damit tierisch Spass, im Stadtpark.
Kommen ein paar Jugendliche an, und fragen mich, was ich da mache.
Ich erkläre es denen so : Ich versuche eine E-Mail an mich selbst zu verschicken über einen "Funkmast" der auf einem anderen Kontinent sich befindet.
Der eine hatte ein wenig Ahnung gehabt, und nachdem ich ihm das etwas näher erklärte, grinste er auch so breit wie ich, und fand das cool.
Vor allem, weil man hier schön sehen konnte, wie die Technik im einzelnen funktioniert.
z.b. sieht man im Wasserfall Mehrwegausbreitung, das Handshake, etc.
Quasi, Mobilfunktechnik zum "Anfassen".

@Tom Ich hatte den Antennenausgang genutzt, da man da die vielfältigsten Vergleichsmöglichkeiten hat.

Ich hatte Fldigi mit Tasten über Ton auf dem rechtem Kanal (mit Microham USB3 Modem), Tasten mit Wintest über RTS (gleiches Modem, umkonfiguriert) und den internen Keyer aus dem Memory des IC756 Pro3 angeschaut.

Das Tasten über den rechten Kanal war dabei noch am schlechtesten, da anscheinend steigene und fallende Flanke bei der Sounderkennung unterschiedliche Verzögerungszeiten haben. Einen Beweis-Test mit niedrigerer Geschwindigikeit habe ich nicht gemacht, das Signal war immer gut brauchbar.

Bei den CW-Trainigsprogrammen nutze ich im Moment die USB-RS232 Schnittstelle nur zur Eingabe. Da ist mir selbst mit meinem >7 Jahre altem Celeron Netbook nichts aufgefallen. Aber so schnell bin ich mit mit der Handtaste auch nicht. Da war eher das Problem, dass HB9HQX die Taste nicht entprellt hatte und ich einen Filter einbauen musste, da sonst die Erkennung durcheinander kam. Wenn ich mal Zeit habe prüfe ich die Ausgabe aus dem Programm über die serielle Schnittstelle.

Ich hatte auch Bedenken mit der USB-RS232 Umsetzung über RTS aber konnte es mit dem Versuch nicht beweisen. Die mit Fldigi implementierte Umsetzung über den rechten Kanal war sogar leicht schlechter, wobei ich da noch einmal prüfen muss, ob man da etwas anpassen kann. Da Fldigi leider das Tasten über RS232 Steuerleitung nicht kann (ich habe es zumindest nicht gefunden) konnte ich nihct alles mit dem gleichen Programm testen. Ich habe aber den Wasserfall von Fldigi auch bei Wintest mitlaufen lassen um noch etwas USB-Load zu erzeugen. Das hat aber nichts geändert.

Ein befreundeter OM und langjähriger CW-Contester nutzt mit seinem auch schon etwas älteren Laptop den K3s über USB und Tastet den auch über die USB-RS232 Schnittstelle. Bis jetzt hat er sich nicht beschwert. Nur die Implementierung von FSK über Wintest und mmtty ist noch offen. Da könnte es mit dem einen virtuellem Com-Port und der Nutzung durch 2 Programme (Wintest für Cat, mmtty für Tastung ) Probleme geben. Aber es gibt auch schon Wintest Makros, die RTTY über CAT auf dem K3S machen sollen. Muss noch getestet werden.

vy 73 de Karsten, DD1KT

Moin Karsten,

ich nehme mal den mitteren Screenshot, weil das ja wohl Wintest über RTS ist. Wenn die Zeitbasis 40ms ist (ich kenne die TeK DSO nicht), was ich vermute, da dort Z 40ms steht, dann hat ein Dit ca. 48ms. Das entspricht einer Geschwindigkeit von 25 WpM (WpM = 1200 / T). Das Tastverhältnis scheint ungefähr 1:2.5 zu sein, die Pausen zwischen den Elementen sind zu kurz.

Was man nicht gut erkennen kann, da wäre eine Messung direkt an RTS sinnvoller, ist die Dauer des jeweiligen Dit. Die scheint zwischen den Dits unterschiedlich zu sein, schwankt zwischen ~40 und ~48 ms. Mit der Standardformel gerechnet (50 Dots = PARIS) würde das bereits einer Schwankung von 5 WpM entsprechen.

Was man nun nicht übersehen darf, dass dies eine Momentaufnahme eines einzelnen Zeichens ist. Die Latenzzeiten von USB bedeuten ja nun nicht, dass die immer und bei jedem Zeichen auftreten. Und nochmals, dass ist unabhängig von dem Rechner, die sind allesamt schnell genug. Das Problem liegt im Design von USB - dort wird mit Streams gearbeitet, es gibt Pufferspeicher mit Timeouts. Die Software schickt ein Byte, der USB Treiber wartet nun, ob da noch mehr kommt bevor der dieses Byte auf die Leitung schickt. Nun soll aber gar kein Byte auf die Leitung geschickt werden, sondern mit einer Handshake-Leitung des USB - Serial Chips gewackelt werden.

Ich zitiere mal aus der FAQ zum 232R Chip von FTDI:

"Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis."

Eine andere Beschreibung zu dieser Problematik und auch bezüglich der Nutzung von einzelnen I/O Leitungen der RS232 eines FTDI 232R Chips ist hier zu finden http://hackaday.com/2009/09/22…ion-to-ftdi-bitbang-mode/

"Pulse width modulation makes for a nice visual demonstration of speed but unfortunately can’t really be put to serious use. In addition to the previously-mentioned I/O latency, other devices may be sharing the USB bus, and the sum total is that we can’t count on this technique to behave deterministically nor in realtime. PWM with an LED looks just fine to the eye…the timing is close enough…but trying to PWM-drive a servo is out of the question."

Dazu muss man noch sagen, dass die Standard-PCs intern einen USB-Hub haben, d.h. nicht jede USB-Buchse am Gehäuse ist ein eigenständiger USB Port.

Oder anders gesagt - es kann funktionieren, muss aber nicht und eine Garantie dafür gibt es nicht.

73, Tom

Moin,

ich habe ganz gute Erfahrungen mit diesem USB - Seriell Wandler unter Windows 7, Windows 10 und Linux gemacht:

http://www.reichelt.de/DELOCK-…SEARCH=USB+Seriell+DeLock

Allerdings "würfelt" der auch mal gerne die Reihenfolge der Ports - bzw. wenn man umsteckt. Auf jeden Fall ist ein Wandler mit Chip von FTDI zu bevorzugen.

Beim Pactor-Modem dürfte die Latenzzeit keine so große Rolle spielen, wie beim Schalten eines Pins für die CW Ausgabe.

73, Tom

Wir haben inzwischen so um 1000 KX3/KX2 zusammen mit einem USB/RS232 Konverter ausgeliefert (gehört zum Lieferumfang der Grundgeräte) und praktisch keinerlei Probleme damit. Steckt man den Converter immer in den gleichen USB Port am Rechner, meldet er sich auch immer mit der gleichen COM Port Nummer zurück. In der Werkstatt betreibe ich permanent 3 davon plus 4 "echte" RS232, ohne dass ich je umkonfigurieren muss (unsere Kalibrier Prg. laufen darüber und es wäre eine Katastrophe, wenn ich jedesmal erst den COM Port suchen müsste) Will man mit dem KX2/KX3 soundcardbasierte DATA Modi betreiben, so kann man MIC / KH direkt mit der PC Soundcard verbinden, handelt sich damit aber eventuell Probleme mit Erdschleifen ein. Mit einem Soundcardmodem, wie dem Signalink SLUSB wird das zuverlässig verhindert. Das SLUSB benutzt keinen speziellen Teiber sondern den Windows internen Treiber USBCODEC. Ist man so an den PC angeschlossen, dann läuft die gesamte Remote Steuerung (Frequenzübergabe usw) über den USB/RS232 Converter und die Codierung / Decodierung über SLUSB/Software. Das einzige Problem, was oft bleibt, ist: Die meisten OM versuchen ohne jede Kenntnis direkt mit einer eierlegenden Wollmichsau zu arbeitenb, d.h. mit einer Software, die alles kann und dementsprechend sehr viel interne Konfiguration benötigt. Meine Empfehlung daher: übt erst mal mit einer einfachen Software wie z.B. DigiPan mit der Materie vertraut zu werden, dann klappt das später auch mit der Universal Software.

Moin Moin Tom,

nur um die offenen Fragen soweit zum Ende zu bringen:

Einen CW Geschwindigkeit mit der Länge eines Dits auszurechnen ist schon etwas kritisch. Zumal, wenn man feststellt, dass die Pausen kürzer sind als die Dits. Wenn man über eine längere Zeit die Geschwindigkeit misst, kommt man auf die 60ms pro Dit+Pause. Auch das Tastverhältnis passt dann wieder mit 1:3 (verkürzte Pause, längeres Dah). Aus den Messungen so das Jitter bestimmen zu wollen, ist schwierig mit den Bildern.

Heute Morgen hatte ich im Clubheim Zeit ein paar Messungen zu machen und habe dazu mein Oszilloskope noch einmal mitgenommen.

Die Verlängerung der Sendezeit erklärt sich aus einer noch genauer zu klärenden Zeitkonstante, die durch die ca. 50k im TRX und eine noch nicht geklärte Kapazität von 50-80nF (wenn ich mich nicht verrechnet habe) am Tasteingang (ich vermute HF-Block C im Microham Modem).

Um den Jitter der Flanken zu messen, habe ich das Scope auf "Persist" gestellt und alle getriggerten Messungen von mehreren CW-Aussendungen übereinander gelegt. So kommt man auf einen Jitter von 2,2ms maximal, der im Vergleich zu der 30ms Punkt-Zeit schon unter 10% ist. Ich kann jetzt nicht sagen, ob man das auch hören kann, oder nur messen.

Nach meinem Gefühl kann man das vernachlässigen. Ich hatte mehr Angst, dass die Aussendung irgendwann unverständlich wird, bzw. stark gestört. Als Perfektionist müsste man wohl erst die Abfallverzögerung, d.h. die Zeitkonstante bis die Tastung beendet wird bereinigen, welches aber im Prinzip erst einmal nichts mit USB und RS232 zu tun hat.

Um ein Gefühl für den Jitter mit anderem Rechner/USB-RS232 Umsetzer zu bekommen, habe ich meinen alten Netbook mit USB-RS232 Umsetzer mal mit der Software HB9HQX als Ausgabegerät genutzt, wobei ich bei den 40WPM geblieben bin. Hier liegt der Jitter auch bei 2ms, wobei es sich wie bei dem anderen Umsetzter auch um eine +/-1ms Abweichung zu handeln scheint. Interessanter Weise tritt genau der gleiche Jitter auch bei der Ausgabe von Fldigi auf, wo über die USB Soundkarte getastet wird, was ja eigentlich eine saubere Ausgabe sein sollte.

Meine Schlussfolgerung: Zumindest bei den von mir getesteten USB-Interfaces spricht nach meinen Anforderungen nichts gegen das Tasten eines TRX über die serielle Schnittstelle, auch wenn diese über USB angeschlossen ist.

vy 73 de Karsten, DD1KT