Forum by DL7UCX

Hallo.
Ich muss hier mal etwas weiter ausholen: Habe PowerSDR mit FA-SDR , TS-850 und einen K3 am UcxLog. Ein VirtualSerialPortEmulator mit TCP-Server stellt dem Netzwerk die Band-Information vom K3 zur Verfügung. Am anderen Ende des Netzwerkkabels sitzt ein Raspberry, der die Band-Information ablauscht und der RS-232 Schnittstelle des SteppIR-Controllers zur Verfügung stellt. Soweit funktioniert das.
Nun möchte ich aber der SteppIr auch die Band-Informationen von PSDR und TS-850 übergeben, ohne dass der Controller Amok läuft, weil alle Geräte Informationen schicken. Gibt es die Möglichkeit, dass UCX-Log nur die Informationen vom aktuell selektierten Gerät auf die Schnittstellen sendet? Oder hat jemand eine Idee auf die ich einfach nicht komme?
Eventuell hat ja jemand das schon mal gemacht.

Martin

Hallo Martin,

UcxLog hat für jeden eingestellten TRX einen Thread laufen, der auf dem gewählten COM-Port zyklisch den CAT-Status-Befehl sendet (außer in einem ICOM-TRCV-Mode) und die Antwort empfängt.
Ich sehe noch keinen überzeugenden Grund, das nur für den gewählten aktiven TRX zu tun.

73 Ben

Hallo Ben.
Ich könnte mir vorstellen, dass einige OM das auch gerne sehen würden, weil sie die Informationen auf irgendeine Weise weiterverarbeiten wollen: zum Antenne steuern, Zweit-RX folgt der Frequenz des TRX, Datenfunksoftware ist immer auf der richtigen Schnittstelle oder sowas.
Vielleicht könnte UCX-Log den Datenverkehr des gewählten TRX zusätzlich zur RS232 noch auf einen mithilfe eines VSPE erstellten virtuellen Port schicken.
Dieser Port wäre immer derselbe, egal welcher Transceiver gewählt ist.
Ich bin mir im Klaren, dass das bei speziell meinem Setup nur geht, wenn alle TRXe Kenwood sprechen.
Oder man übersetzt die Informationen bevor sie weiterverarbeitet werden: Icomisch rein -> Hilfsprogramm -> Kenwoodisch raus -> Datenendgerät.

Martin

Hallo Martin,

ich halte das noch nicht für ausgegoren.
Erst möchtest Du zwei COM-Ports deaktivieren und dann noch ein weiteres einführen

Antennen schalten kann man jetzt schon aus UcxLog.
Zum Zweit-RX und weiteren Ideen muß man erstmal analysieren,
- was man genau womit und warum machen will,
- was es schon für Möglichkeiten gibt,
- wie universelle Lösungen aussehen könnten und
- wie die allgemeine Interessenlage ist.

73 Ben

Es stimmt, es ist keineswegs ausgegoren. Deshalb stelle ich ja im Forum die Idee zur Diskussion. Vielleicht gibt es noch andere, die so etwas machen wollen.
Vielleicht gibt es eine Lösung und ich komme nur nicht drauf.
Also: Ist hier noch jemand der die Band-Daten vom gewählten TRX auf einer Schnittstelle braucht und was möchte er damit machen, bzw. im Falle von nur 1 TRX, macht er bereits damit und wie?

Martin

Hallo Martin,
hier wird der Datenverkehr zwischen einem Kennwood TS-570 und UCXlog mitgehört. Die im Telegramm enthaltene Frequenzinformation wird zur Antennenumschaltung und zur frequenzgesteuerten Umschaltung des Antennentuners AT-502 von Hamware genutzt.
73 Wolfgang

Hallo Wolfgang,

das ähnelt dem was ich mache. Machst du das ausschliesslich über RS-232?
Und es geht nur mit 1 TRX an 1 bestimmten Schnittstelle, oder?
Was ich meine: Wie würdest du es lösen, wenn du 2 oder 3 TRXe an 2-3 Schnittstellen hättest?

Martin

Hallo Martin,
der TS-570 hat nur eine RS232. Auf der Rechnerseite wird ein COM-Port benötigt. Wenn nicht vorhanden, hilft ein USB/Seriell-Adapter.Wenn zwei weitere Kenwood wahlweise genutzt werden sollen, wäre es eventuell sinnvoll das über LAN zu realisieren.
Ob so etwas funktioniert, kann ich nicht sagen.
Oder Du schaltest von Hand den Controller von Hand auf die gewünschte CAT.
73 Wolfgang

Hallo Martin,

wenn ich mich recht erinnere, besitzt Du auch ein "UcxLog-Interface", worüber das Band und der aktive TRX ausgegeben werden können.
Das reicht aber nicht?

73 Ben

Moin Moin.

dl8dww hat geschrieben:Hallo Martin,...
....Wenn zwei weitere Kenwood wahlweise genutzt werden sollen, wäre es eventuell sinnvoll das über LAN zu realisieren.
Ob so etwas funktioniert, kann ich nicht sagen.

Ja! Das funktioniert über das Lan. Mit einfachen Mitteln aber eben nur für 1 TRX.

dl8dww hat geschrieben: Oder Du schaltest von Hand den Controller von Hand auf die gewünschte CAT.
73 Wolfgang

Der Controller ist nicht im Shack. Bei dir (Antennentuner) auch nicht, oder?

DL7UCX hat geschrieben:Hallo Martin,

wenn ich mich recht erinnere, besitzt Du auch ein "UcxLog-Interface", worüber das Band und der aktive TRX ausgegeben werden können.
Das reicht aber nicht?

73 Ben

Nein, ich habe kein solches Interface. Falls ich mal ein Interface erwähnt habe, ist das ein Pegelwandler für TTL <> RS-232 und stammt aus einer Pre-UCX-Log Zeit. Dieser Wandler hat aber auch nur 1 Com-Schnittstelle.
Ich glaube, wir reden irgendwie aneinander vorbei. Ich versuche es nochmal genauer zu erklären:
Der Steppir Controller steht im alten Shack ca 40m vom neuen Shack entfernt und ist mithilfe eines Raspberry über Lan an den Rechner angebunden, auf dem UCX-Log läuft.
Am UCX-Log sind an 3 Schnittstellen je 1 TRX angeschlossen.
Das ComPort des TRX 1 wird mithilfe eines VSPE gesplittet, sodass UCX-Log und der VSPE die Bandinformationen abhören können. Der VSPE stellt einen TCP-Server bereit, der die Bandinformationen über z.B. Port 5555 ins Lan gibt. Der Raspberry lauscht mithilfe eines TCP-Clients an Port 5555 und gibt die Bandinformationen auf die Schnittstelle des SteppIR Controllers. Das funktioniert simpler als Ihr denkt und ist mit keinerlei Programmieraufwand verbunden, also auch für normale Anwender und Nicht-Linuxer realisierbar. Wenn jemand wissen möchte wie das geht, bitte sagen.
Nun habe ich also die Bandinformationen des TRX 1 am Controller. Will ich die Bandinfo vom TRX2 am Controller haben, habe ich ein Problem: Entweder ich splitte die Schnittstelle des TRX 2 in gleicher Weise wie die von TRX 1 und schicke sie auf die gleiche virtuelle Schnittstelle und dann über den TCP-Server Port 5555. Dann muss ich aber immer eins der beiden Geräte ausschalten. Oder ich schicke die Bandinfo auf einem anderen Port über den TCP-Server. Dann muss ich dem Raspberry das mitteilen. Also Client stoppen, TCP-Port ändern und mit neuem TCP-Port starten, der nun auf TRX 2 hört. Das ist für den Laien machbar, nur eben umständlich.
Ich könnte aber auch am LPT-Port abgreifen, welcher TRX gewählt ist und es dem Raspberry mitteilen, sodass dieser selbst den richtigen TRX zum SteppIr Controller leitet. Ab hier wird es für den Laien kompliziert und ist ohne Programmieraufwand nicht zu machen.
Deshalb wäre es sinnvoll, an immer der gleichen Schnittstelle- virtuell oder echt - ausschliesslich die Bandinfo des *gewählten* TRX zu haben. Ein automatischer Antennenkoppler im Shack oder ein SteppIR Controller haben dann immer die richtige Bandinfo. Stellt man diese Schnittstelle mithilfe VSPE dem Lan bereit, ist es egal wo das Datendendgerät steht. Das Datenendgerät könnte eine auf einem (entfernten) PC laufende Anwendung sein, über (W)Lan ein Remote Controller, oder über Internet an einem beliebigen Ort stehen.

Wenn ich zu kompliziert denke, bitte auf Kurs bringen.

73 , Martin

Hallo Martin,

sri, beim UcxLog-Interface habe ich Dich verwechselt.
Es gibt ein Interface zum Selbstbauen (EXPANDIO + 8 Bauelemente), das von UcxLog automatisch erkannt wird (ohne spezielle Treiber!).
Man kann die Bänder und die aktiven TX-Nummern und CW/PTT der TXs auf die Ausgangsleitungen legen.
Mangels Interesse habe ich das nicht weiter publiziert.

73 Ben

Hallo Ben,
arbeitet dieses Interface mit einem PIC 18F2550? und wo findet man die Firmware?
73 Wolfgang

Hallo Wolfgang,

der EXPANDIO-Schaltkreis ist fertig programmiert (findet man im Internet).
Ich habe ein paar hier, muß den mit einigen Daten versehen, damit UcxLog ihn erkennt.

73 Ben

Hallo Ben,

ich würde mich mal hier einklinken.

Bisher habe ich auch den VSPE verwendet, damit UCX und MixW (+evtl. andere Spezielle Programme) "gleichzeitig"
(=Parallel laufen können und ich nicht erst eins schließen muss um den Port freizugeben) auf den TRX zugreifen können.
Jetzt musste ich aber meinen Rechner austauschen und nun steht ein 64 Bit Rechner unter dem Tisch. Dafür gibt es
aber keine (kostenfreie) Version eines solchen Programm's. Meine Idee, die ich jetzt mal wieder vorbringen wollte ist folgende:
- UCXLog kommuniziert mit dem TRX
- UCXLog stellt eine Virtuelle Schnittstelle zur Verfügung auf die andere Programme zugreifen können
- dabei hat UCXLog die "macht", also wenn das Externe Programm etwas möchte was UCXLog warum auch immer nicht
möchte/kann oder wenn's ausgelastet ist, kann es einfach in's leere laufen

Habe ich das Verständlich formuliert?

Ein Vorteil sehe ich z.B. auch darin dass nicht jedes mal wenn ein Programm z.b. die QRG wissen will, dieses vom TRX abgefragt werden muss, da das UCXLog ja bekannt ist.

73, Marc

Hallo Marc,

UCXLog stellt eine Virtuelle Schnittstelle zur Verfügung auf die andere Programme zugreifen können

Da ergeben sich natürlich sofort einige Fragen:

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

73 Ben