UCXLog and FLdigi?

[DL7UCX]

Habe noch was gefunden, die Fldigi-XML-RPC-Beschreibung ist unvollständig (veraltet), qrx ...

[DL9MEU]

Fldigi löscht wie gewollt sichtbar das RX-Fenster und liefert dann aber etwas später 10 bis 30 neue Zeichen im Empfangspuffer, alles Müll. Das wird im RX-Fenster dort auch in Schwarz angezeigt, der folgende richtige Sendetext in Rot.
Verschiedene Versuche, diese falschen Zeichen zu löschen oder auszusortieren sind gescheitert.

Hallo Ben,

nur Vermutung aber vielleicht ein Hinweis:
Den Effekt kann ich nur bei FEC- Betriebsarten feststellen.
Bei diesen Betriebsarten läuft aber nach Abschluss des Empfangs noch eine ganze Weile die Dekodierung weiter und der FEC-Algorithmus spuckt noch Daten aus.
73 Gregor

[DL7UCX]

Hallo Gregor,

in einer anderen Quelle habe ich bessere RPCs (u.a. zum Auslesen der wirklich gesendeten Zeichen) gefunden, das sollte das FEC-Problem lösen.
Es ist einiges in 7.44 Beta 4 "Redesignd", hoffentlich ohne neue Fehler ...

73 Ben

[DL7UCX]

In Beta 6 auch mit "Modem only" in Settings-Station...

[DL9MEU]

Hallo Ben,

das war ein riesen Schritt, congrats!
FLDIGI 3.21.83 / Modem only / UCX 7.44 Beta 6 / WIN 7 /FA Interface / TS 480 / ohne RSID
F1: CQ auf cq geändert

Betriebsarten ohne FEC
PSK 31
F1 i.O.
F8 i.O.

PSK 125
F1 i.O.
F8 i.O.

DominoEX 11
F1 i.O
F8 einmal von 10 fehlte der letzte Buchstabe

Betriebsarten mit FEC
MFSK 16
F1 i.O
F8 i.O.

Contestia 8/500
F1: der erste Buchstabe fehlt manchmal
F8: der erste Buchstabe fehlt manchmal


Olivia 16/500
F1 : letzter Buchstabe fehlt fast immer
F8 : letzter Buchstabe fehlt fast immer

RSID am Ende funktioniert nicht (ist weniger tragisch).

73 Gregor

[DL7UCX]

Hallo nochmal,

in 7.44 Beta 7 noch zwei kleine Korrekturen:

• Timeout am Ende des Sendens erhöht, der letzte Buchstabe sollte nun nicht mehr fehlen.
• Bei Contestia wird das erste Zeichen definitiv zu Fldigi gesendet und trotzdem meist nicht gesendet.
  Habe beim Start des Sendens ein führendes Leerzeichen eingebaut.

73 Ben

[DL9MEU]

Große Klasse!

FLDIGI 3.21.83 / Modem only / UCX 7.44 Beta 7 / WIN 7 /FA Interface / TS 480 / ohne RSID

Betriebsarten ohne FEC
PSK 31
F1 i.O.
F8 i.O.

PSK 125
F1 i.O.
F8 i.O.

DominoEX 11
F1 i.O
F8 I:O

Betriebsarten mit FEC
MFSK 16
F1 i.O
F8 i.O.

Contestia 8/500
F1 i.O
F8 i.O.

Olivia 16/500
F1 i.O
F8 i.O.

Bei Contestia wird das erste Zeichen definitiv zu Fldigi gesendet und trotzdem meist nicht gesendet.
Habe beim Start des Sendens ein führendes Leerzeichen eingebaut.

Frage: Würde an Stelle des Leerzeichnes auch ein Zeilenvorschub funktionieren?
Könnte bei allen Betriebsarten so sein.
73 Gregor

[DL7UCX]

Hallo Gregor,

das sieht ja erfreulich aus

Habe in 7.44 Beta 8 statt des Leerzeichens bei Contestia ein führendes LF (Line feet) eingebaut, das wird dann im Receive-Fenster unterdrückt, falls es gesendet wurde.
Interessanterweise wurde LF im Gegensatz zu normalen Zeichen immer richtig von Fldigi als gesendet quittiert.

Generell möchte ich das LF nicht voranstellen, da es einige Korrekturrechnungen erfordert um festzustellen, wann alle Zeichen wirklich von Fldigi gesendet wurden.

73 Ben

[DL9MEU]

Hallo Ben,

ufb!

Habe in 7.44 Beta 8 statt des Leerzeichens bei Contestia ein führendes LF (Line feet) eingebaut, das wird dann im Receive-Fenster unterdrückt, falls es gesendet wurde.
Interessanterweise wurde LF im Gegensatz zu normalen Zeichen immer richtig von Fldigi als gesendet quittiert.

Läuft !
Werde mir jetzt auch mal die anderen Betriebsarten anschauen.

TNX und 73 Gregor

[DL7UCX]

Hallo Gregor,

ich weiß nicht, welche Modes es noch mit höheren Datenraten gibt, da brauche ich Hinweise.
Eventuell muß dann der Sendepuffer mit mehr Datenvorlauf gefüllt werden.
Im Augenblick wird das bloß bei BPSK/QPSK 63/125 von 3 auf 4 bzw. 6 Bytes erhöht.

73 Ben

[DL9MEU]

Hallo Ben,

ich weiß nicht, welche Modes es noch mit höheren Datenraten gibt, da brauche ich Hinweise.
Eventuell muß dann der Sendepuffer mit mehr Datenvorlauf gefüllt werden.
Im Augenblick wird das bloß bei BPSK/QPSK 63/125 von 3 auf 4 bzw. 6 Bytes erhöht.

Ich mache die nächsten Tage mal eine Zusammenstellung
73 Gregor

[DL9MEU]

Hallo Ben,
Bevorzugte Betriebsparameter
Dieser Wert kommt dann zum tragen, wenn aus UCX heraus im FLDIGI eine neue Betriebsart angewählt wird.
Dazu gibt es Empfehlungen, die auch auf derseite von Dave W1HKJ etwas versteckt aufgeführt sind.
http://www.w1hkj.com/FldigiHelp-3.21/Modes/index.htm
Sie sind
PSK31
Contestia 8/500
DominoEX11
MFSK 8
MT63-1000
RTTY 45
Thor11
Thorb2
Für Olivia ist 32/1000 angegeben, in der Praxis ist es aber in der Regel 8/500, nicht zuletzt wegen der Bandbreite, um bandplanconform zu sein.
Die Datenraten habe ich per email verschickt.

73 Gregor

[DF2LH]

Moin moin

die 'Modem only' Einstellung finde ich sehr gelungen. So habe ich es mir immer gewünscht

Gibt es noch eine Möglichkeit die Zeit zwischen PTT (bei mir UCXLog Control via CAT an FlexRadio/ANA100D) die sofort beim drücken einer F-Taste schaltet und dem einsetzen der RTTY-Töne von FLDigi zu verringern. Diese Zeit ist mit FLDigi mindestens doppelt so lang gegenüber MMTTY als Modem. Bei einem normalen QSO egal, aber im Contest oder Pileup ist die Reaktionszeit doch entscheidend.

Schönen Sonntag!

'73 Thomas

[DL7UCX]

Hallo,

in 7.44 Beta 11 ist der Sendepuffer-Vorlauf an die Datenraten aller Modes angepaßt.

Die Default-Submodes bei der Modewahl aus UcxLog sind so korrigiert:
PSK31
DominoEX11
MFSK 8
Thor11
Thorb2
Olivia 8/500
MT63-1KS (MT63-1000 kennt Fldigi nicht)

Bei RTTY und Contestia ist der Submode an der Fldigi-Schnittstelle nicht verfügbar, hier wird aber anscheinend von Fldigi der letzte verwendete gewählt.

Die Zeit von "PTT an" bis zum Senden von Fldigi ist durch die nötigen XML-RPCs gegeben:
1. text.clear_tx
2. main.tx
3. text.add_tx

Ich habe in Beta 11 den RPC "text.clear_rx" rausgenommen, damit sollte es 125ms schneller gehen.
Auf clear_tx möchte ich aber sicherheitshalber nicht verzichten.

Damit dauert es jetzt ca. 125 ms bis Fldigi auf Senden schalten soll und 250ms bis die ersten Sendezeichen zu Fldigi geschickt werden. Wie lange es innerhalb Fldigi bis zum Empfang und Verarbeitung dauert, weiß ich nicht (ich schätze unter 100ms).

73 Ben

Nachtrag: Möglicherweise dauert es auf langsamen PC länger, wenn man Fldigi verwendet, sollten es schon mindestens 2 Kerne mit 2GHz sein.

[DL9MEU]

Hallo Ben,

habe mal wieder getestet
FLDIGI 3.21.83 / Modem only / UCX 7.44 Beta 12 / WIN 7 /FA Interface / TS 480 / ohne RSID
PSK 500, QPSK 500; DominoEX22, DominoEX4, MFSK64, Thor4.
Bei allen scheint jetzt der Abaluf zu stimmen.
UFB!

73 Gregor