Direkte Anbindung an Omni-Rig von CW-Skimmer

[dl8dww]

Hallo Ben,
mit 7.67 Beta sehe ich nun auch FA/FB-Kommandos.
Da UCXLog immer das FA-Kommando ausgibt, ist FB und IF vielleicht für Omni-Rig nicht notwendig.
73 Wolfgang

[DL7UCX]

Hallo Wolfgang,

bei der Auswahl 3 "Kenwood frequency (IF)") wird das IF-Kommando ausgegeben, nicht FA.
Vielleicht hast Du FA bei Auswahl 2 "TRX out copy" gesehen.

Wie gesagt, die Ausgabe von "Kenwood freq. IF+FA+FB" (Auswahl 4) war ein Versuch, weil nicht klar war, was gebraucht wird.
Das muß keiner benutzen, aber es schadet nichts.

73 Ben

[DD0VS]

Hallo Ben und Mitleser,

hier die Settings von OMNIRig für die SDRCOnsole:

161014-Omnirig-setting-SDRConsole-SDR-Play-K3.JPG (28.91 KiB) 7208 mal betrachtet

hier die Settings für den CW Skimmer

161014-Omnirig-setting-CW-Skimmer-K3-Audio.JPG (61.89 KiB) 7208 mal betrachtet

hier das UCXLog Setting:

161014-UCXLog-Setting.JPG (12.91 KiB) 7208 mal betrachtet

Die SDRConsole folgt der Frequenzanzeige am K3 der Skimmer zeigt 0,00 an.

Soweit der Stand der DInge hier.

Die Funktionalität mit der SDRCOnsole bringt mich schon mal weiter.

vy73
Harald

[DL7UCX]

Hallo Harald,

wenn ich das richtig verstehe, gelangt also die Frequenz von UcxLog zu OmniRig, aber von OmniRig nicht zum Skimmer.
Die beiden gekoppelten (virtuellen?) COM-Ports sind COM1 (UcxLog) und COM2 (OmniRig).

73 Ben

[DD0VS]

Hallo Ben,

korrekt. COM1 und COM2 sind virtuell und gekoppelt.

vy73
Harald

[DF9OB]

Hallo,

auch ich bin über Omni-Ric gestolpert. Bei mir kommt Omni-Ric folgendermaßen zum Einsatz:

TRX1: Yaesu FT-950 und TRX2: Yaesu FT-991 welche an meinem Notebook in Verbindung mit UcxLog super zusammenspielen . Von meinem FT-950 greife ich das IF-Signal ab und lasse mir das Spektrum mittels SDRUNO anzeigen. Damit die Cat-Steuerung mit SDRUNO <-> FT-950 funktioniert benötige ich den Einsatz von Omni-Ric.

Leider kann ich nur eines der beiden Programme (zumindest wenn ich über eine CAT-Steuerung meines FT-950 verfügen möchte) nutzen . Entweder läuft UcxLog oder SDRUNO mit Unterstützung der CAT-Schnittstelle.

Wünschenswert währe, dass UcxLog die "Sprache" von OmniRic verstehen würde, damit die CAT-Steuerung bei beiden Programmen funktionieren würde.

Vielleicht helfen folgende Links weiter:
http://www.dxatlas.com/omnirig/
http://www.dxatlas.com/omnirig/CompatibleSoft.txt
http://wd5eae.org/Software.html#HRDU
https://www.youtube.com/watch?v=E62JcI9P8Xk

@Ben, sollte ich mich zu "verwirrt" ausgedrückt haben, können wir auch gerne direkt kommunizieren.

Gruß Bernd
DF9OB

[DL7UCX]

Hallo Bernd,

das generelle Problem ist immer noch, daß unter Windows nur 1 Programm ein bestimmtes COM-Port öffnen kann.

Deswegen können nicht UcxLog und OmniRig gleichzeitig über CAT auf den TRX zugreifen.
Da hilft auch nicht, wenn UcxLog die Sprache von OmniRig versteht.

Die bisherige Lösung ist, einen sogenannten COM-Port-Splitter (Treiberprogramm) einzusetzen, was mehr oder weniger gut geht.

Ich habe nun die alternative Möglichkeit erwogen, die TRX-CAT-Steuerung über ein zweites COM-Port zu OmniRig durchzuleiten.
Das bedingt, daß zusätzlich zum TRX-COM-Port ein Paar von 2 verbundenen COM-Ports (physikalisch oder virtuell) geschaffen wird.

UcxLog leitet in einem ersten Schritt die TRX-CAT-Daten an dieses COM-Port-Paar zu OmniRig weiter (nur Output).
Dort muß also die Frequenz ankommen.

Wenn das geht (wie bei Harald), kann ich darüber nachdenken, ob ich bei diesem zweiten COM-Port nicht nur den Output, sondern auch den Input implementiere, was aufwendiger ist.
Dann könnte UcxLog Änderungen der Frequenz von OmniRig zum TRX weiterleiten.

73 Ben

[DF9OB]

Hallo Ben und alle mitlesenden,

ich habe mich mit der Thematik noch mal intensiv beschäftigt. Meine Einschätzung und Interpretation möchte ich hier abschließend kundtun.

@Ben; ich bin ein begeisterter Nutzer von UxcLog und hoffe Dir mit dieser (aus meiner Sicht) abschließenden Zusammenfassung nicht auf die Nerven zu gehen.

In den vorangegangenen Beiträgen wurde speziell das Programm CW-Skimmer angesprochen. Dies war nun auch die Ausgangsfrage. Bei meinen Recherchen habe ich erkannt, dass durch die Nutzung von Omni-Ric bereits mehrere Programme die „Dienste“ von Omn-Ric nutzen. Siehe hierzu auch: http://www.dxatlas.com/omnirig/ und vor allem http://www.dxatlas.com/omnirig/CompatibleSoft.txt.
Meine Einschätzung ist, dass sich hier niemand von Omni-Ric abhängig macht sondern eher die angebotene Schnittstelle ergänzend nutzt.
In der Übersicht (Anlage) habe ich versucht schematisch aufzuzeigen, wie ich die Funktionsweise von Omni-Ric verstanden habe. Daraus ist erkennbar, dass nur ein Programm (nämlich Omni-Ric) physikalisch mit den COM-Ports kommuniziert.

Meine Frage/Idee an Ben; wäre es nicht einfacher die Schnittstelle/Technik von Omni-Ric zu nutzen als einen „Kunstgriff“ mittel Paralleler Com-Ports vorzunehmen?

Kopplung_OmniRic.jpg (69.97 KiB) 7167 mal betrachtet

Gruß an alle
Bernd / DF9OB

[DL6ER]

Hallo Bernd,

Meine Frage/Idee an Ben; wäre es nicht einfacher die Schnittstelle/Technik von Omni-Ric zu nutzen als einen „Kunstgriff“ mittel Paralleler Com-Ports vorzunehmen?

Als ebenfalls erfahrener Programmierer nehme ich nun mal vorweg, dass es absolut nicht "einfacher" wäre, denn UcxLog ist so gebaut, dass es stets über eine serielle Schnittstelle in direktem Kontakt mit einem TRX steht. Ich denke es würde ein kompletter konzeptioneller Umbau anstehen, wenn man diesen Weg gehen will - mit all der Arbeit und den Unwägbarkeiten, die damit üblicherweise einher gehen.

73 Dominik

[DL7UCX]

Hallo Bernd,

ich stimme Dominik zu.

UcxLog kommuniziert selber mit einer Unmenge von Transceivern und zwar sehr effektiv und für mich jederzeit beeinflußbar und überschaubar.
Ich werde UcxLog bestimmt nicht ohne große Not von Fremd-Software abhängig machen

Ein gutes, aber abschreckendes Beispiel ist Fldigi, mit dem ich eine Kopplung eingebaut habe, um die eher speziellen digitalen Modes (außer RTTY und PSK) zu ermöglichen.
Diese Schnittstelle ist dermaßen "universell", daß sie eine undiskutable Menge von Laufzeit und Prozessor-Last bewirkt.

Meine Erfahrung zeigt, daß einige wenige Nutzer immer kompliziertere Software-Gebilde betreiben, um spezielle Wünsche zu realisieren.
Das wollen und brauchen 99,5 % der UcxLog-Nutzer nicht, viele können und verstehen es auch nicht

Daran muß ich auch in Anbetracht meiner beschränkten Entwicklungskapazität einfach immer wieder denken

73 Ben

[DF9OB]

Hallo Ben, Hallo Dominik
hallo @all

mein Ansinnen ist nicht als Minderheit der UcxLog-User Deine Entwicklung infrage zu stellen. Vielmehr hatte ich angenommen, dass eine Kopplung mit Omni-Ric eine interessante Ergänzung wäre . Bedeutet dies jedoch eine Designveränderung von UcxLog und der damit einhegenden Risiken, gebe ich euch beiden Recht. Lieber auf diese Art von Kopplung verzichten und dafür ein sehr gut laufendes UcxLog nutzen können .

Als Alternative ist es möglich, wie bereits weiter vorne beschrieben, auf kommerzielle Software zur Port-Splittung wie z.B. „Serial Port Splitter“ der Fa. Eltima http://www.eltima.com/de/products/serialsplitter/ zurückzugreifen. Die SW habe ich heute intensiv getestet und alles was ich mir vorstelle funktioniert . Ich möchte hier keine Werbung machen. Diese SW war die erste auf die ich von Unseren Entwicklern im qrl aufmerksam gemacht wurde.

@Ben; ich bin weiterhin der Meinung, dass Du ein Super Programm entwickelt hast und hoffe, dass Dich solche Diskussionen nicht entmutigen; dies wäre niemals meine Absicht.

Viele Grü0e
73 Bernd - DF9OB

[DL7UCX]

Hallo Bernd,

keine Sorge, solche Diskussionen sind kein Problem.
Für mich ist es wichtig, nur Funktionen einzubauen, die für mehrere User hilfreich sind und UcxLog nicht zu sehr aufblähen.
Die "tollste" Software nützt nichts, wenn sie instabil, träge und unübersichtlich wird.

Ziel dieser Diskussion hier war für mich, über Sinn und Bedeutung einer Port-Erweiterung mehr Klarheit zu gewinnen.
Ich denke auch, daß ein Port-Splitter vorläufig eine gangbare Lösung ist.

73 Ben

[DL6ER]

Hallo zusammen,

ich weiß ich spreche eine Minderheit der UcxLog-User an, wenn ich (mal wieder) sage, dass man das bei Linux auch ohne externe Software machen kann. Okay, zurück zum Thema

Muss es eine Kaufsoftware sein? Ich meine ... es mag sein, dass ich schon immer besonders geizig gewesen bin, aber ich kam bislang nicht in die Verlegenheit für ein einziges Stück Software Geld ausgeben zu müssen. Hat sich bereits jemand die Mühe gemacht die zahlreichen von Google gelieferte kostenfreie "virtueller COM Port"-Software durchzuprobieren?

Als Beispiel nenne ich hier mal com0com. Die Beschreibung lautet (ins Deutsche übersetzt):

Dieser Emulator ermöglicht es eine unbegrenzte Zahl an virtuellen COM-Port-Paaren zu erstellen. Jedes COM-Port-Paar besteht aus zwei miteinander verbundenen COM-Ports. Der Ausgang des einen Ports ist der Eingang des anderen und umgekehrt.

Das klingt doch genau nach dem was alle suchen, oder habe ich einen entscheidenden Teil verpasst

Dann gibt es das ganze komplett kostenfrei. Es ist sogar quelloffen - man kann bei Bedarf und mit entsprechenden Kenntnissen also sogar jederzeit selbst Änderungen an der Software vornehmen.
Projektwebseite: https://sourceforge.net/projects/com0com/

HW? ...

73 Dominik

[DL7UCX]

Hallo Dominik,

Jedes COM-Port-Paar besteht aus zwei miteinander verbundenen COM-Ports.

Dieses COM-Port-Paar wird für die (unfertige) Lösung in UcxLog gebraucht.

• UcxLog öffnet ein reguläres COM-Port zum TRX.
• Ucxlog kopiert den Datenverkehr dieses TRX-Port auf ein zweites Port. Dieses ist eine Seite des COM-Port-Paares.
  Mit der zweiten Seite verbindet sich Skimmer/OmniRig und denkt, es wäre der TRX.

Diese Variante wurde nur mit der Output-Datenrichtung zum COM-Port-Paar zu OmniRig realisiert und funktioniert bei Harald.
Es wird die Frequenz vom TRX über UcxLog und OmniRig zum Skimmer geleitet.
Die Gegenrichtung (Skimmer stellt TRX-Frequenz über OmniRig und UcxLog ein), fehlt.
TRX <-- RS-232 --> COM1 <--> UcxLog --> COM2 <--RS-232--> COM3 <--> OmniRig+Skimmer

Ein COM-Port-Splitter bildet ein RS-232-Interface mit zwei Ports.
Damit wird der TRX sowohl von UcxLog als auch von OmniRig abgefragt und gesteuert.
Beide denken, sie würden exclusiv mit dem TRX kommunizieren.
Daß das logisch nicht lösbare Situationen gibt, scheint in der Praxis meistens unerkannt zu bleiben.

73 Ben

[DL6ER]

Hallo Ben,

ich habe Eure Situation schon verstanden, aber Du missverstehst meine Übersetzung:

Jedes COM-Port-Paar besteht aus zwei miteinander verbundenen COM-Ports.

Hier geht es darum, dass dieses Programm immer genau zwei virtuelle COM-Ports miteinander verbindet (nicht z.B. fünf). com0com kann ausschließlich mit virtuellen COM-Ports arbeiten. Eine Anbindung an einen physikalischen COM-Port ist überhaupt nicht möglich. In Deinem Bild würde die Software den im folgenden unterstrichenen Teil zur Verfügung stellen:

TRX <-- RS-232 --> COM1 <--> UcxLog --> COM2 <--RS-232--> COM3 <--> OmniRig+Skimmer

Ob die Verarbeitung seitens UcxLog nur sende- oder auch empfangsseitig bei diesem hier angenommenen COM2, dürfte schließlich für den Splitter egal sein, ermöglicht aber eine (später evtl. einmal gewünschte) Erweiterung auf bidirektionale Verarbeitung seitens UcxLog ohne die virtuelle-COM-Port-Software wechseln zu müssen.

73 Dominik