UCX-Log und 3 TRX an 1 Steppir-Controller

[DO2UDX]

Hallo Marc,

• Welche "anderen Programme" wollen/machen das?
• Gibt es schon Kommando-/Syntax-Definitionen oder andere Vorstellungen?
• Wie universell ist das?
• Wer benutzt das?

73 Ben

Hallo Ben,

ich versuche mal deine Fragen zu beantworten, vielleicht habe ich mich auch etwas ungünstig ausgedrückt, ich meine einen Virtuellen Com-Port

- wollen: alle die auch auf den TRX zugreifen wollen (MixW, JT65, zusätzliches Clusterprogramm...)

- machen: vernünftig eigentlich nur VSPE, aber da hast du wieder ein zusätzliches Programm (geht, ist aber nicht schön)
des weiteren OmniRig, aber das funkt. nur mit Programmen die das unterstützen, also nicht universell

- Definitionen: so wie vom Hersteller des TRX vorgegeben (siehe nächster Punkt)

- Universell: so universell wie die von UCXLog unterstützten TRX, es soll ja 1:1 durchgereicht werden
(bei solchen anfragen wie QRG..., die UCXLog kennt braucht es ja nicht extra beim TRX nachfragen,
sondern kann gleich antworten)

- wer nutzt das: Ich , einen weiteren potenziellen Kandidaten könnte ich dir per PN nennen, ansonsten mal schauen wer sich meldet


73, Marc

[DL7UCX]

Hallo Marc,

ich habe jetzt verstanden, was Du möchtest.

Ich bin davon gar nicht begeistert:

• Aufwand
  Die jetzige Verfahrensweise auf den TRX-COM-Ports würde völlig umgeworfen.
  Jetzt wird auf eine Anfrage nur die bekannte, passende Antwort erwartet, es müßte dann im unbekannten Datenstrom die richtige Antwort gesucht werden.
  Das Senden könnte nicht mehr unmittelbar erfolgen, je nachdem, wer erster war, müßten die eigenen oder die durchzureichenden Daten über Warteschlangen verzögert werden.
  Das Verhältnis von Aufwand zu Nutzen(Nutzern) ist indiskutabel.
• Stabilität
  Nicht alle TRX verkraften CAT-Befehle ohne Pause, diese wäre nicht zu gewährleisten.
  Z.B. eine Überlagerung fremder CAT-Befehle mit CAT-Befehlen zur Tastung wäre ein sehr heikler Fall.
  Und alle Fehler oder Seiteneffekte würden zu Anfragen an mich führen...

73 Ben

[DL1DTL]

Hi,

leider ist VSPE für 64 Bit-Rechner nicht kostenlos, aber mit 25 Dollar immer noch erheblich preiswerter als Virtual Serial Port von Eltima.

Aber vielleicht gibt es noch andere Lösungen für 64-Bit-Rechner?

Klaus DL1DTL

[dm4im]

Ich benutze das auch.
Ich splitte mithilfe von VSPE 32bit das physische Com1 und habe dann ein virtuelles com10 . VSPE erlaubt, virtuelle Ports mehrmals zu öffnen. So greifen meine Datenfunkprogramme
und UCX-Log auf com10 zu . Und eben der TCP-Server von VSPE, der die Banddaten meinem übers Netzwerk remote gesteuerten SteppIR Controller zuführt.

Ausserdem habe ich ein virtuelles COM30 für PowerSDR erstellt und dieses gesplittet auf COM16.
UCX-Log bedient PowerSDR dann als TRX2 auf dem virtuellen COM16.

Deshalb wäre es ja so toll, nur den Datenverkehr vom gewählten TRX auf einer virtuellen Schnittstelle zu haben. Man könnte eine beliebige Software auf der virtuellen Schnittstelle lauschen lassen und hätte immer die Banddaten vom gerade benutzten TRX.

73, Martin

[dm4im]

@DL1DTL:

Schau mal, ob du damit zurecht kommst:

http://k5fr.com/ddutilwiki/index.php?ti ... M#Features
(das könnte aber ELTIMA sein)

bzw.

http://www.telepostinc.com/LPB2.html

[DL7UCX]

Hallo Martin,

Deshalb wäre es ja so toll, nur den Datenverkehr vom gewählten TRX auf einer virtuellen Schnittstelle zu haben. Man könnte eine beliebige Software auf der virtuellen Schnittstelle lauschen lassen ...

Das ist ganz etwas anderes und deutlich einfacher als

"andere auf den TRX zugreifen zu lassen ... 1:1 durchreichen".

73 Ben

[DL1DTL]

@Martin, ja, das ist die Eltima-Software, nur, dass jetzt die Version 7.2 aktuell ist. K5FR läßt die im XP SP3 Kompatibilitätsmodus laufen

Es gibt da noch eine Free Virtual Serial Ports - Software von hhdsoftware: http://www.hhdsoftware.com/free-virtual-serial-ports

Die könnte auch funktionieren.

Aber ich bleibe vorerst bei meiner 32-Bit-Windows-Version.

73

Klaus

[dm4im]

...
Das ist ganz etwas anderes und deutlich einfacher als
"andere auf den TRX zugreifen zu lassen ... 1:1 durchreichen".
73 Ben

Missverständlich ausgedrückt, ich meinte nicht "andere auf den TRX zugreifen lassen", sondern den Datenverkehr abhören.

Euch allen ein Frohes Fest

Martin

[DL7UCX]

Hallo Martin,

dann wollen wir das mal genau definieren:

• Einrichten eines zusätzliches COM-Ports in UcxLog, das nur sendet.
• Das sendet alles 1:1, was UcxLog vom aktiven TRX empfängt.
• Wenn die Bitrate auf dem Ausgangsport kleiner ist, wird zwischengepuffert.
• Wenn die Bitrate auf dem Ausgangsport größer ist, entstehen Lücken zwischen den übertragenen Bytes.

Das kann ich so vormerken, wenn es nützlich ist.

73 Ben

[dm4im]

Ben,
das hört sich vielversprechend an.

73, Martin

[DO2UDX]

Hallo Ben,

löst zwar nicht alle meine "Probleme", aber ich denke das sich das relativ einfach umsetzen lässt
und es hilft.

73, Marc

[DL7UCX]

So richtig einfach ist das leider nicht:
Ich muß das Port irgendwo in den Settings mit allen Werten unterbringen, speichern, das Port öffnen/schließen (mit Fehlerbehandlung) und den Zustand verwalten und es in der Help beschreiben.
Bisher steht das in der To-Do-List nicht im oberen Teil, zu wenige brauchen es !

73 Ben

[DL1DTL]

darf ich das so verstehen, dass ein anderes Programm auf diesen COM-Port zugreifen kann und die dort eintreffenden Informationen lesen und für sich auswerten kann, also z.B. die TRX-Frequenz?

Klaus DL1DTL

[DL7UCX]

Hallo Klaus,

so wäre es, wenn ich das realisiere.
Aber das andere Programm kann nur passiv lesen, was der TRX von sich gibt, das wäre im allgemeinen die Antwort auf eine Status-Abfrage, die mindestens Frequenz und Mode enthält.

73 Ben

[dl8dww]

Hallo Ben,
...da sollte man an diesem Port den Transceifer-Status, wie z.B das IF-Kommando beim Kenwood lesen können
Bei der QRG-Info wäre es wichtig nur die aktuelle Empfangs-QRG zu bekommen, um bei Split-Betrieb Probleme zu vermeiden, die bei unterschiedlichen Frequenzen auftreten würden.
Sinnvoll wäre auch ein einheitliches Datentelegramm.
73 Wolfgang