UCXLog and FLdigi?

[DL7UCX]

Nein, der Fehler ist jetzt beim Befehl an Windows, Fldigi.exe zu starten. Da läuft ein weiterer Timeout von 5s.

Vorher war das die Kommunikation, die geht auch zu irgendeiner Fldigi, deshalb half Dein Starttrick.

73 Ben

[DL7UCX]

Hallo,

in 7.38 Beta 11 einige Änderungen:

- Startparameter -FLDIGI... nicht mehr erforderlich
- Help ergänzt "General - Digital Modes (RTTY, PSK ...)"
- Knopf "QSY" im Receive-Fenster (Hotkey STRG+Y)
- "Wait" mit 1..9 s einstellbar (für Wolf)
- Timeout beim Prozeßstart auf 9 s erhöht (für Wolf)
- Mißlungenes Schließen von Fldigi behoben

Wenn sich der langsame Start von Fldigi auch bei anderen als Problem bestätigt, werde ich über einen Schalter, der Fldigi nach dem ersten Start offen hält, nachdenken müssen.
Das wird wohl erst im Mai werden, bin vorher 3 Wochen nach ZA unterwegs.
Leider läßt sich Fldigi nicht unsichtbar schalten (wie MMTTY) und der Betrieb als "Nur Modem" ist wegen falscher RX-Daten auch bis auf weiteres nicht möglich.

73 Ben

[DL7BJ]

Moin,

ich hatte eben das Phänomen, dass fldigi gar nicht starten wollte. Aber auch direkt
an der console nicht, "C++ Runtime Error".

Ich vermute, dies lag daran, dass bei mir in fldigi RigCtrl eingeschaltet war und in
UCXLog ebenfalls. Seit ich RigCtrl in fldigi abgeschaltet habe, geht es einwandfrei
und startet auch sofort.

Evtl. besteht bei dem langsamen Start ein Zusammenhang, dass fldigi evtl. ewig
probiert, die bereits von UCXLog belegte Schnittstelle zu öffnen. Wenn fldigi gar
nicht oder langsam startet, einfach mal die ganze TRX Steuerung abschalten.

73, Tom

[DL7UCX]

Hallo,

der "C++ Runtime Error" weist auf eine falsche oder unzureichende Programmierung in Fldigi hin.

In jedem Fall darf in Fldigi keine TRX-CAT-Steuerung verwendet werden (s.a. Help).

73 Ben

[DL9MEU]

Hallo Ben,
hier einige Testergebnisse
fldigi 3.21.80. UCX 7.38.11, TS 480, XP, bisher nur Empfang
Start:
flldigi gespeichert mit RigCAT ein, Device: Com 3, XML aus
UCX gespeichert mit SSB
TRX läuft auf 28120 in USB

1. Versuch
UCX Start
QSO Work SSB
Umschalten auf PSK
TRX geht auf LSB (!)
fldigi geht auf, RigCAT ein, Device: ---, XML aus

UCX QSY
TRX geht auf USB (!), aber nur dann wenn tatsächlich QRG Sprung notwendig ist!
TRX macht QSY aber in die falsche Richtung (zb statt -300 +600)

fldigi wird umgestellt auf RigCAT aus, Device: --- , XML ein

UCX QSY
TRX geht auf USB (!) aber nur dann wenn tatsächlich QRG Sprung notwendig ist!
TRX macht QSY aber in die falsche Richtung (zb statt -300 +600)
d.h. keine Veränderung des Verhaltens

2. Versuch
flldigi gespeichert mit RigCAT aus, Device: --- , XML ein
UCX gespeichert mit PSK
TRX läuft auf 28120 in USB

UCX Start
QSO Work ist bereits auf PSK
TRX bleibt in USB
fldigi geht auf, RigCAT aus, Device: COM1 (??), XML ein

UCX QSY
TRX bliebt auf USB
TRX macht QSY aber in die falsche Richtung (zb statt -300 +600)

UCX Umschalten auf CW
TRX geht auf CW, fldigi aus
UCX Umschalten auf PSK
TRX geht auf LSB (!)
fldigi geht auf, RigCAT aus, Device: COM1 (??) XML ein
UCX QSY
TRX geht auf USB (!) aber nur dann wenn tatsächlich QRG Sprung notwendig ist!
TRX macht QSY aber in die falsche Richtung (zb statt -300 +600)

Soweit die ersten Testergebnisse
73 de Gregor

[DL7UCX]

Hallo Gregor,

die entscheidende Einstellung kann ich nicht entdecken (oder es hat mich erschlagen):
Settings - Station - Other interfaces - Sideband LSB/USB
Das muß mit der Fldigi Seitenbandlage übereinstimmen.

Bitte keine Testergebnisse mit Fldigi - RigCat EIN oder XML AUS, das kann aus Sicht von UcxLog nichts werden.

73 Ben

[DL9MEU]

Hallo Ben,
Du hast schon richtig geschaut, im Gegensatz zu mir...
Es stand natürlich im UCX auf LSB.
OK, jetzt steht es auf USB.

Wenn ich zB den TRX auf LSB laufen habe und dann fldigi starte, holt sich fldigi (wenn ich es starte ohne UCX) die Info aus dem TRX und zeigt LSB an, unabhängig davon, wie ich fldigi vorher geschlossen habe.
Neue Runde
Ich stelle fldigi mit CW ab, der TRX läuft auf LSB und starte dann UCX
1. Versuch
UCX Start
QSO Work ist bereits auf PSK
Der TRX bleibt auf LSB
fldigi startet und zeigt CW an
erst wenn ich ein echtes QSY mache, geht der TRX auf USB
und der Sprung ist korrekt
Anzeige im fldigi bleibt auf CW
2. Versuch
UCX Start
QSO Work ist auf SSB
Der TRX bleibt auf LSB
UCX Umschalten auf PSK
fldigi startet und zeigt CW an
erst wenn ich ein echtes QSY mache, geht der TRX auf USB
und der Sprung ist korrekt
Anzeige im fldigi bleibt auf CW

Es gibt beim fldigi nirgends eine default-Einstellung der TRX-Betriebsart, sondern fldigi holt sich diese, solange es in stand-alone-Betrieb ist, aus dem TRX. Wenn fldigi ferngesteuert ist, holt es sich die Betriebsart natürlich nicht aus dem TRX. Eine Änderung der Betriebsart im fldigi während Fernsteuerung hat keinerlei Einfluss auf irgendwas..

Für die Betriebsart scheint mir eher ein Synchronisation zwischen TRX und UCX erforderlich zu sein, d.h. UCX gibt die Betriebsart an den TRX vor.

RigCAT und XML: solange fldigi von UCX aus gestartet wird, kann ich bis jetzt keinen Einfluss der Einstellungen RigCat und XML in fldigi erkennen.
73 de Gregor

[DL7UCX]

Hallo Gregor,

der große Unterschied bei den digitalen Betriebsarten über Audio ist, daß der TRX einen anderen Mode als UcxLog verwenden muß.
Der TRX kennt nur SSB oder Packet/Digital dafür, aber nicht PSK, MFSK ...

Deshalb gehen solche Modes logisch nur, wenn sie in UcxLog eingestellt werden und UcxLog dann beim TRX SSB/Digital einstellt.

Dieser Ablauf kollidiert beim Start mit einem anderen Feature:
Wenn der TRX vor UcxLog schon läuft, übernimmt UcxLog Frequenz/Mode vom TRX. Das ist für viele Nutzer wichtig, geht aber nicht bei den digitalen Modes.
Der Vorgang ist an sich schon sehr kompliziert, ich will da für die digitalen Modes keine Ausnahme versuchen.

Also bitte bei Digital:
- TRX nach UcxLog einschalten (schon vor dem UcxLog-Start zu "hören" macht bei Digital auch wenig Sinn)
- Digitalen Mode in UcxLog einstellen

Es gibt beim fldigi nirgends eine default-Einstellung der TRX-Betriebsart, sondern fldigi holt sich diese, solange es in stand-alone-Betrieb ist, aus dem TRX.

Da Du RigCat nicht einschalten darfst (Kollision des COM-Ports), kann Fldigi den Mode nicht vom TRX holen.
Ich hatte den Eindruck, es verwendet LSB, ob es einstellbar ist, weiß ich nicht.

Eine Änderung der Betriebsart im fldigi während Fernsteuerung hat keinerlei Einfluss auf irgendwas..

Bei mir schon, Du mußt Mode+Submode in Fldigi anklicken.

RigCAT und XML: solange fldigi von UCX aus gestartet wird, kann ich bis jetzt keinen Einfluss der Einstellungen RigCat und XML in fldigi erkennen.

Wenn RigCat auf demselben COM-Port ist, kann es eigentlich nicht funktionieren. Die TRX-Frequenz bekommt Fldigi übrigens von UcxLog!
Wenn Fldigi ohne XML-RPC fernsteuerbar ist, ist das dort ein Fehler.

73 Ben

[DL9MEU]

Hallo Ben,
sri, habe mich nicht immer ganz deutlich ausgedrückt, mal sind T(RX)-Modes (LSB/USB) gemeint , mal D(igi)-Modes (RTTY, PSK....)

Hallo Gregor,
der große Unterschied bei den digitalen Betriebsarten über Audio ist, daß der TRX einen anderen Mode als UcxLog verwenden muß.
Der TRX kennt nur SSB oder Packet/Digital dafür, aber nicht PSK, MFSK ...
Deshalb gehen solche Modes logisch nur, wenn sie in UcxLog eingestellt werden und UcxLog dann beim TRX SSB/Digital einstellt.

Klar, D-Modes müssen im UCX eingestellt werden, aber der TRX muss auch auf dem richtigen T-Mode stehen, und das macht etwas Probleme, wenn der TRX nicht auf dem richtigen T-Mode steht.

Dieser Ablauf kollidiert beim Start mit einem anderen Feature:
Wenn der TRX vor UcxLog schon läuft, übernimmt UcxLog Frequenz/Mode vom TRX. Das ist für viele Nutzer wichtig, geht aber nicht bei den digitalen Modes.
Der Vorgang ist an sich schon sehr kompliziert, ich will da für die digitalen Modes keine Ausnahme versuchen.

Könnte man das denn dadurch "bereinigen", dass UCX beim Start eines fldigi D-Modes den TRX in den richtigen T-Mode bringt?

Also bitte bei Digital:
- TRX nach UcxLog einschalten (schon vor dem UcxLog-Start zu "hören" macht bei Digital auch wenig Sinn)
- Digitalen Mode in UcxLog einstellen

Das ist ziemlich unpraktisch: Station +PC einschalten, Station abstimmen, wenn dann Windows endlich hochgefahren ist, kommt UCX hinzu
oder man ist in SSB oder CW unterwegs, will auf Digi umsteigen...

Da Du RigCat nicht einschalten darfst (Kollision des COM-Ports), kann Fldigi den Mode nicht vom TRX holen. Ich hatte den Eindruck, es verwendet LSB, ob es einstellbar ist, weiß ich nicht.

Klar, fldigi braucht den T-Mode in Fernsteuerfall auch nicht! fldigi gibt den T-Mode nicht automatisch vor, sondern er ist über fldigi manuell richtig einzustellen.

Wenn erst UCX und dann fldigi mit RigCAT durch UCX gestartet wird passiert (zumindest bei mir ) nichts, fldigi findet den gewünschten Post schon besetzt und kann deshalb nicht darauf zugreifen. Deshalb bleibt bei fldigi das Feld "Device" leer.

Eine Änderung der Betriebsart im fldigi während Fernsteuerung hat keinerlei Einfluss auf irgendwas..
Bei mir schon, Du mußt Mode+Submode in Fldigi anklicken.

Sri, ich meinte die T-Betriebsart (LSB/USB), die Wahl der D-Betriebsart funktioniert natürlich!

RigCAT und XML: solange fldigi von UCX aus gestartet wird, kann ich bis jetzt keinen Einfluss der Einstellungen RigCat und XML in fldigi erkennen.

Wenn RigCat auf demselben COM-Port ist, kann es eigentlich nicht funktionieren. Die TRX-Frequenz bekommt Fldigi übrigens von UcxLog!
Wenn Fldigi ohne XML-RPC fernsteuerbar ist, ist das dort ein Fehler.

Das kann wohl nur w1hkj wirklich beantworten , den ich bisher immer sehr hilfsbereit erlebt habe.

Noch eine Frage zum TX-Betrieb: Wie erkennt UCX, das ja die Kontrolle über die PTT hat, dass fldigi fertig ist mit senden?

73 de Gregor

[DL7UCX]

Hallo Gregor,

ich glaube, der Irrtum beginnt damit, daß Du meinst, UcxLog würde den TRX-Mode nicht einstellen. Das stimmt nicht.

Der TRX-Mode wird eingestellt, wenn er sich in UcxLog geändert hat.
Bsp.:
CW --> PSK: TRX-Mode wird von CW auf SSB/Digital+USB/LSB geändert
PSK --> CW: TRX-Mode wird von SSB/Digital auf CW geändert
PSK --> RTTY (mit MMTTY/FSK): TRX-Mode wird von SSB/Digital auf RTTY geändert
PSK --> RTTY (ohne MMTTY): TRX-Mode bleibt unverändert (SSB/Digital)

Wenn beim Start von UcxLog (z.B. in PSK) der TRX schon läuft (z.B. in SSB) KANN UcxLog nicht wissen, was Du möchtest:
- In SSB arbeiten (weil der TRX so steht)
oder
- in PSK arbeiten (weil UcxLog beim letzten Lauf so beendet wurde)

Bei den nicht-digitalen Modes geht das, bei den digitalen nicht.

Wenn Dein TRX also unbedingt vor UcxLog laufen muß, kannst Du nur mit einem Trick arbeiten:
Mode in UcxLog 2x wechseln (PSK -> CW -> PSK). das sollte den TRX-Mode richtig einstellen.

Noch eine Frage zum TX-Betrieb: Wie erkennt UCX, das ja die Kontrolle über die PTT hat, dass fldigi fertig ist mit senden?

Leider läßt sich der Füllstand des Sendepuffers in Fldigi nicht abfragen. Deshalb kontrolliert UcxLog, ob alle zu sendenden Zeichen empfangen wurden und schaltet dann auf Empfang.
Zur Sicherheit wird auch auf Empfang geschaltet, wenn eine gewisse Zeit nichts mehr empfangen wurde.

73 Ben

[DL9MEU]

Leider läßt sich der Füllstand des Sendepuffers in Fldigi nicht abfragen. Deshalb kontrolliert UcxLog, ob alle zu sendenden Zeichen empfangen wurden und schaltet dann auf Empfang.
Zur Sicherheit wird auch auf Empfang geschaltet, wenn eine gewisse Zeit nichts mehr empfangen wurde.
73 Ben

Ich hoffe, ich habe das richtig verstanden, wenn UCX alle Zeichen "empfangen" hat, die es gerade angewiesen hat zu senden, wird die PTT weggeschaltet.
Dies macht aber Probleme an zwei Stellen:
1.) Betriebsarten mit FEC (Forward Error Correction) zB Olivia
Der eigentliche Text ist gesendet, und der Sendespeicher (des zu übertragendenden Textes ) ist damit leer (?) , aber die Sendung geht noch eine ganze Zeit weiter, weil weitere Daten gesendet werden, die der Empfänger für die FEC braucht.
2.) RSID /Video ID
Hier wird, wenn die Funktion eingeschaltet ist, nach dem eigentlichen, zu sendenden Text, ein weiterer Datenblock zur ID gesendet.
In beiden Fällen taucht da nichts im Send/Receive-Fenster auf.
Wenn ich das richtig verstehe, hat UCX aber schon vorher PTT wegeschaltet. Ist das so?

73 de Gregor

[DL7UCX]

Hallo Gregor,

probier es doch bitte einfach mal aus.

Ob der "Sendespeicher leer" ist, ist irrelevant, es geht nur um den vollständigen Empfang im Empfangsspeicher.
Wenn es nicht korrekt läuft, habe ich keine Idee, wie ich Fldigi die Information entlocken sollte.

73 Ben

[DL7BJ]

Moin,

Leider läßt sich der Füllstand des Sendepuffers in Fldigi nicht abfragen. Deshalb kontrolliert UcxLog, ob alle zu sendenden Zeichen empfangen wurden und schaltet dann auf Empfang.
Zur Sicherheit wird auch auf Empfang geschaltet, wenn eine gewisse Zeit nichts mehr empfangen wurde.
73 Ben

Ich hoffe, ich habe das richtig verstanden, wenn UCX alle Zeichen "empfangen" hat, die es gerade angewiesen hat zu senden, wird die PTT weggeschaltet.
Dies macht aber Probleme an zwei Stellen:
1.) Betriebsarten mit FEC (Forward Error Correction) zB Olivia
Der eigentliche Text ist gesendet, und der Sendespeicher (des zu übertragendenden Textes ) ist damit leer (?) , aber die Sendung geht noch eine ganze Zeit weiter, weil weitere Daten gesendet werden, die der Empfänger für die FEC braucht.
2.) RSID /Video ID
Hier wird, wenn die Funktion eingeschaltet ist, nach dem eigentlichen, zu sendenden Text, ein weiterer Datenblock zur ID gesendet.
In beiden Fällen taucht da nichts im Send/Receive-Fenster auf.
Wenn ich das richtig verstehe, hat UCX aber schon vorher PTT wegeschaltet. Ist das so?

Die xmlrpc Funktionen innerhalb von fldigi rufen nur die Funktionen auf den Buttons auf. Wenn Du im Waterfall-Fenster z.B.
in Olivia den T/R button betätigst, einen Text sendest und mit erneutem Betätigen des T/R Buttons die Sendung beendest,
wirst Du feststellen, dass fldigi noch einen Moment weitersendet. Eben den Rest für FEC. Und dann erst wieder auf RX geht.

Genau diese Funktion des T/R Buttons unter dem Waterfall wird über xmlrpc aufgerufen, mit main.tx und main.rx. Wenn also
alle Zeichen die über xmlrpc an fldigi gingen im Empfangsbuffer wieder "geechot" wurden und dann auf RX umgeschaltet wird,
sollte das kein Problem darstellen. Weiterhin kann auch mit main.get_trx_status genau dieser Status abgefragt werden, um
festzustellen, in welchem Mode fldigi gerade ist.

Es wäre, soweit ich das im Code sehe, kein sehr großer Aufwand eine xmlrpc Methode zu implementieren, die den Status
des Sendebuffers meldet. Es gibt dort eine Funktion eot(void) die true liefert, wenn der Buffer leer ist. Dort könnte man
ansetzen. Nur mal schnell nebenher geschaut.

Wäre es vielleicht möglich, optional fldigi --wo beim Aufruf mitzugeben? Das ist der Waterfall-Only Mode,
was ja eigentlich in Verbindung mit UCXLog ausreichend wäre. Oder übersehe ich da etwas?

73, Tom

[DL7UCX]

Hallo Tom,

Gregor hat mir auch schon Daten dazu geschickt.

Wenn ich das richtig verstehe, sendet Fldigi die FEC/RSID-Daten noch fertig, obwohl UcxLog schon den TX über RPC main.rx abgeschaltet hat.
Das Problem ist dann "nur", daß die PTT aus UcxLog zu früh abgeschaltet wird.
Ob sich das (noch) Senden von Fldigi über main.get_trx_state richtig abfragen läßt, werde ich als nächstes probieren.

Wo siehst Du die Funktion eot ?
Bei http://www.w1hkj.com/FldigiHelp-3.21/ht ... _page.html gibt es die nicht und in Fldigi wollte ich nichts programmieren...

Den Aufruf mit --wfall-only hatte ich schon implementiert, mußte ihn aber wieder rausnehmen.
Beim Auslesen des RX (text.get_rx) kam es zu merkwürdigen Fehlern, ab und zu wurden Zeilenenden und doppelte Zeichen geliefert.
Dazu werde ich (später) wohl mal Kontakt zum Autor aufnehmen müssen.

73 Ben

[DL7UCX]

Hallo,

in Version 7.38 Beta 13 sollte UcxLog auch bei Olivia bis zum Ende auf Senden bleiben.
Hoffentlich ohne Nebeneffekte ...

73 Ben