Forum by DL7UCX

Hallo Ben,

erster Kurztest:
Positiv: Fldigi wird gefunden und startet auch bei Auswahl des Mode "PSK..." automatisch.

Negativ: Es scheint keinerlei Interaktion zwischen UcxLog und Fldigi zu geben:
Eintragen eines Calls in UcxLog oder Fldigi hat keine Auswirkungen auf das jeweils andere Programm.
Auch wird scheinbar keine Frequenz übergeben (Anzeige in Fldigi: 0.000).

Anmerkung: Wechsel von PSK -> CW ließ Fldigi beim ersten Versuch geöffnet, erneuter Wechsel nach PSK ließ dann ein zweites Fldigi Fenster aufgehen.
Nachdem ich alle Fldigi Fenster geschlossen hatte, war dieses Verhalten nicht mehr nachzuvollziehen und das Programm wurde beim Wechel von PSK -> CW ordnungsgemäß geschlossen.

Testumgebung kleiner Rechner:

• Win XP Pro
• Fldigi 3.21.78

Korrektur:
Wenn ich in Fldigi den Mode wechsle (Contestia, PSK, Olivia, ...) ändert sich der Mode in UcxLog, jedoch nicht in Fldigi
Kann aber ansonsten keinerlei zusätzliche Interaktion zwischen den beiden Programmen feststellen.

Moin moin

- erster Test um 02:00 UT. FLDigi startet und ich kann von UCXLog aus senden.
- die HamLib Schnittstelle zum TRX musste deaktiviert werden. UCX und FLDigi beeinflussen sich und mein TRX landet bei 0.00000 Hz
- bei mir funktioniert die Callübergabe FLDigi Richtung UCXLog (klick auf ein Call im Received Digital Fenster) ohne Probleme.
Hi Dominik. was willst Du von UCX zu FLDigi übertragen? Ich verstehe es so, dass FLDigi nur als 'Modem' läuft.
Alle Logbuchfunktionen sollten in FLDigi abgeschaltet sein. Ich nutze auch nur die Funktionstasten/Festtexte im UCXLog. Halt wie bisher bei MMTTY.

Ich spiele morgen weiter. Vielen Dank für die Mühe Ben!

'73 Thomas

Hallo,

Fldigi soll nur als Modem laufen, dort stellt man nur Mode/Submode und Audio-Frequenz ein.
Kann den Parameter "--wfall-only" (= Waterfall only) leider nicht verwenden, da dann der RX falsche Zeichen liefert.

Am Start von Vorgängerversionen (vor .78) arbeite ich noch ...

73 Ben

Nachtrag: ... die 7.38 Beta 6 sollte nun auch einen eingegebenen Pfad akzeptieren.

Hallo,

nach der Installation von Fldigi und auch bei jedem Ändern des Installationspfades erscheint die Windows-Abfrage, ob ich den Firewall für das Programm öffnen möchte (was ich nicht tat).
Kennt jemand die Hintergründe dafür?

73 Ben

DL7UCX hat geschrieben: Nachtrag: ... die 7.38 Beta 6 sollte nun auch einen eingegebenen Pfad akzeptieren.

Hallo Ben,

mit Beta 6 läuft es !

TNX
Gregor DL9MEU

Hallo Ben,

DL7UCX hat geschrieben:nach der Installation von Fldigi und auch bei jedem Ändern des Installationspfades erscheint die Windows-Abfrage, ob ich den Firewall für das Programm öffnen möchte (was ich nicht tat).
Kennt jemand die Hintergründe dafür?

die Win-Firewall führt eine Liste der erlaubten Programme. Um diese freigegebenen Programme eindeutig identifizieren zu können wird hier der absolute Pfad abgespeichert. Somit verschwindet die Datei aus der Liste, sobald der absolute Pfad geändert wird und das Programm muss daraufhin neu zugelassen werden (sonst könnte sich ja ein Schadprogramm einfach explorer.exe nennen und hätte sofort freien Internetzugriff).

Aktueller Stand von mir:

• Senden eines Festtextes (F1...F11) funktioniert. Bei Freitexten (per Hand eingegeben) bleibt der Transceiver aber auch nach Abarbeitung aller Zeichen auf Sendung stehen und geht auch nach längerer Zeit nicht wieder zurück.
  Habe gesehen, dass sich das Feld "MOX" automatisch aktiviert, sobald man einen Text eingibt. Wenn man diesen Haken wieder weg nimmt, geht der TRX dann zurück auf Empfang.
• Call-Übernahme hatte ich falsch verstanden, ich dachte ich müsste in Fldigi auf das Call klicken. Im Received Digital Fenster von UcxLog funktioniert es einwandfrei.
  Gibt es die Möglichkeit hier auch andere Dinge als das Call per Rechtsklick-Auswahl zu übernehmen (Name, QTH, Locator, evtl. RST+Exchange)?
• Nach Neustart des PCs heute morgen funktioniert plötzlich auch die wechelseitige Mode-Übernahme.

73 Dominik

Hallo Dominik,

danke für die Erklärung, nun verstehe ich fast, wieso bei der Pfad-Änderung die Frage der Firewall erneut kam.
Merkwürdig ist nur, daß ich eben vorher gar nichts freigegeben hatte, somit gab es auch nichts neu zuzulassen.
Was der Firewall da nicht gefällt, ist mir auch noch unklar:
- Outgoing ist doch normalerweise offen (oder es ist ein abartiges Port?).
- Incoming sollte eher nicht auftreten.

Das Verhalten mit "MOX" (Hotkey TAB) sollte normal und unverändert gegenüber MMTTY und PSKCore sein (wenn man zu langsam schreibt, darf nicht wie bei CW auf Empfang geschaltet werden, sonder es wird "Idle" gesendet).

Die Übernahme aus dem "Received"-Fenster sollte auch unverändert sein, ich muß dazu in die Help schauen:

Ein einfaches Anklicken eines Wortes oder das Markieren von Text durch Ziehen mit der Maus bewirkt die Übernahme in das letzte zuvor ausgewählte Textfeld des aktiven Work-Fensters, falls dieses Feld leer ist (Ausnahme: Im Contest-Kontrollnummern-Feld wird angehängt).
Wenn auf das Leerzeichen zwischen 2 Worten geklickt wird, werden beide übernommen (hilfreich bei zweiteiligen Kontrollnummern).

Ein Doppelklick bewirkt die Übernahme des angeklickten Wortes in das Call-Sign-Feld des letzten aktiven Work-Fensters.

Zusätzliches Betätigen der Strg- oder Umschalt-Taste bewirkt das unbedingte Anhängen an bzw. Überschreiben von bestehenden Text.

Übrigens, bei HELL wird nichts gesendet, da UcxLog die eigene Sendung nicht empfangen ("sehen") kann.

73 Ben

Hallo Ben,

DL7UCX hat geschrieben:Was der Firewall da nicht gefällt, ist mir auch noch unklar

da kann ich leider keine definitive Antwort zu geben, aber das könnte vielleicht damit zusammenhängen, dass Fldigi auf irgendeinem Port lauscht zwecks Datenverkehr mit anderen (externen ?) Modulen zur TRX-Steuerung, etc.
Somit wäre das dann ja irgendwie schon ein Serverdienst, der Incoming lauscht.
Vielleicht musste anfangs gar nichts freigegeben werden, weil das schon das Installationsprogramm für den ursprünglichen Pfad übernommen hat. Aber auch das ist Spekulation.

MOX und die Felder-Übernahme ist mir jetzt klar und sollte tatsächlich unverändert bleiben.

73 Dominik

Moin moin

Mein Tag 2 mit UCXLog/FLDigi: RTTY

Bisher habe ich für RTTY 'MMTTY in LSB' und für andere Betriebsarten FLDigi in USB benutzt. Dies funktioniert
besonders bei klick auf RTTY-Clusterspots sehr gut.

Für meinen SDR mit PowerSDR habe ich nun im 'Other Interfaces Menue' den Haken bei MMTTY weggenommen und bei FLDigi gesetzt.
Sideband auf USB und TX Mode auf Data/Pkt. Dadurch wird der TRX auf den richtigen Mode 'DigiU' (DigitalUSB) gesetzt.

Ein grosser Unterschied zu MMTTY ist, dass UCXLog nicht mehr mit der festen Markfrequenz von 2210 rechnet.
Ich habe 3KHz Bandbreite im TRX eingestellt und kann dort auf jede Station klicken und bin transceive. Bitte
beachten, dass zu niedrige Frequenzen zu störenden Mischprodukten in der eigenen Aussendung führen können. Dies
ist der Grund für die meist benutzten 'Hightones' bei 2KHz.

Die ersten Klicks auf RTTY Clusterspots haben mich etwas verwirrt. Wenn ich es richtig verstehe, wird bei einem RTTY
Clusterspot die jeweilige NF-Frequenz auf der FLDigi gerade steht für die Berechnung der VFO-Frequenz genutzt und die
QRG im TRX dementsprechend angepasst.
Für die Übersichtlichkeit würde ich mir einen einstellbaren festen Offset, auf dann FLDigi gesetzt wird, wünschen.
Also z.B. immer auf 2000Hz im Wasserfall, auch wenn die Frequenz im FLDigi vorher eine andere war

Die Umschaltung von anderen Modes auf RTTY funktionierte hier nicht immer. Das werde ich weiter beobachten..

FlDigi hat auch seine Tücken. Bei einer Neuinstallation, bzw. löschen des Datenverzeichnisses 'fldigi.files' im
User Home Verzeichnis, muss nach durchlaufen des Startassisten unbedingt 'save config' im Configure Menü gewählt werden.
Sonst landet man beim nächsten Start wieder im Startassistenten und UCXLog teilt mit, dass FLDigi nicht verbunden werden
konnte.

Nach dem Update auf eine neue FLDigi Version werden alle Einstellungen über das genannte 'fldigi.files' von der neuen Version
übernommen. Zu beachten ist, dass die neue FLDigi-Version selbst in einem neuen Verzeichnis im Programmverzeichnis
installiert wird. Dieser neue Pfad muss in den UCXLog FLDigi Einstellungen angepasst werden.

... wird fortgesetzt ...

vy '73 Thomas

Hallo Thomas,

RTTY mit Fldigi habe ich noch gar nicht probiert, es ist wie gesagt ein früher Teststand, weil ich nicht länger im eigenen Saft schmoren wollte ...
Wenn ich das richtig verstanden habe, sollte die Fldigi-NF beim Umschalten auf RTTY immer auf eine feste Frequenz gesetzt werden.
Start mit 2210 und individuell einstellbar ?
Beim Umschalten mittels Cluster-Spot-Klick weiß ich noch nicht, wie das Timing läuft.
Das Dilemma beim Fldigi-Interface ist die zeitliche Verzögerung von etwa 200ms, dafür könnte sie auch in ZL laufen, braucht nur keiner

73 Ben

DF2LH hat geschrieben: Ein grosser Unterschied zu MMTTY ist, dass UCXLog nicht mehr mit der festen Markfrequenz von 2210 rechnet.
Ich habe 3KHz Bandbreite im TRX eingestellt und kann dort auf jede Station klicken und bin transceive. Bitte
beachten, dass zu niedrige Frequenzen zu störenden Mischprodukten in der eigenen Aussendung führen können. Dies
ist der Grund für die meist benutzten 'Hightones' bei 2KHz.

Hallo Thomas,
bei FLDIGI gibt es ja die Funktion QSY, die die Mittenfrequenz auf 1 kHz (NF) bringt, indem die TRX-QRG entsprechend verändert wird.
Ich nehme an, dass der Wert bei einem KHz liegt, hat seinen Grund darin, dass es ja relativ breitbandige Betriebsarten gibt. Würde man die Mittenfrequenz auf 2 kHz oder höher legen, könnte es mit den Filtern schnell eng werden.
Vorschlag zur Diskussion:
Wenn eine QRG aus dem Cluster angewählt wird, wird gleichzeitig diese bereits vorhandene QSY Funktion ausgeführt.
Das hätte zur Folge, dass dann, egal wo der TRX vorher steht, die Mittenfrequenz auf 1 kHz liegen würde.
Das ist im Betrieb für den OP nachvollziehbar und läge dann im Zielkorridor der "normalen" Einstellung der variablen (DSP-) Filter.
HW?
73 de Gregor

Hallo,

die QSY-Funktion von Fldigi ist nicht von außen (über XML-RPC) auslösbar.
Außerdem nützt das nichts, da der TRX durchgängig in allen Modes von UcxLog gesteuert werden muß, nicht von Fldigi (und das soll auch so bleiben).

Die QSY-Funktionalität muß also in UcxLog realisiert werden, dazu ist nur zu definieren, was das machen soll:
Ändern der aktuellen NF auf einen vorgegebenen NF-Wert und entgegengesetzte Korrektur der TRX-Trägerfrequenz, so daß die Tonhöhe der empfangenen Station unverändert bleibt.

Höhe der vorgegebenen NF:
Gängige Werte: 1000, 1275, 2000, 2125
1 kHz mag für die Filter hilfreich sein, ist bei SSB-breitem Sendekanal aber ungünstig, die die erste Oberwelle ungehindert durchkommt (Schon geringe Verzerrungen im NF-Kanal führen zu einer Nebenwelle in 1kHz Abstand).
2 Khz oder mehr sind hier besser, wenn sich die TRX-Filter so einstellen lassen.
Vermutlich muß das irgendwo durch den Nutzer einstellbar sein.

73 Ben

In 7.38 Beta 7 eine kleine Korrektur, damit beim Umschalten RTTY zu/von anderen Digimodes die Fldigi durchgehend geöffnet bleibt.

73 Ben

Hallo Ben,

DL7UCX hat geschrieben:Höhe der vorgegebenen NF:
[...]
Vermutlich muß das irgendwo durch den Nutzer einstellbar sein.

insbesondere aus dem Grund, dass die Pegel eher in seltenen Fällen so eingestellt sind, dass Verzerrungen vermieden werden, finde ich es völlig okay den Nutzer zu seinem Glück (und dem Vermeiden von unnötigen Störungen) zu zwingen. Ich sehe dieses Argument durchaus gut genug, um auf eine weitere Einstellungsmöglichkeit zu verzichten.
Ansonsten wird es auch die Experten geben, die die NF auf 500 Hz setzen, weil ihnen der hohe Ton unangenehm, etc. ist. Lattenzaun ahoi.

73 Dominik

Nach ersten Tests hier meine 5 Cent ..

• 1. Pfad wird gefunden !
  2*. Received Digital Window meldet "Fldigi Connection Failed." Erst nach dieser Meldung kommt Fldigi zum starten und hat keine Funktion.
  
  * Wird Fldigi vorab gestartet und dann der Mode PSK gewählt kann UCXLog Fldigi connecten. Nachteil! Durch dieses vorgehen wird ein weiteres fldigi Fenster gestartet ( ist ja auch klar ). Dabei übernimmt bzw. bekommt das zuerst connectete fldigi Fenster die Funktion, daß andere wird wie gehabt nicht connectet. Muss man dem Fldigi etvl. mehr Zeit zum starten geben ? Am Rechner liegt es nicht das er zu langsam ist. Hier ein I7 in use.

Evtl. kann man auch prüfen ob fldigi.exe schon gestartet im Prozess ?

Da es sich aber um einen frühen Betastatus handelt bin ich sicher das man das alles in den Griff bekommt. Weitere Tests folgen hier. Danke erst mal Ben. Good Job !!!

OS: Windows 7 pro 64Bit
UCXlog: v7.38 Beta 7
Fldigi: v3.21.78
PC: Intel I7

73 Wolf