Auto-Connect & Alternativen

[DL7UCX]

Hallo Dominik,

die Erfolgsquote muß sich zeigen, es ist schon früher aufgefallen, daß manche TRX definiert vor oder nach UcxLog eingeschaltet werden wollen, da sie sich sonst verschlucken.
Der Effekt, daß die PC-COM-Ports klemmen, scheint aber beseitigt.

Läßt sich denn Dein TS-480 unmittelbar nach dem Auto Detect mit den richtigen Werten verbinden, ohne UcxLog neu zu starten?

73 Ben

[DL7UCX]

Ich habe noch mal 1 Stoppbit probiert, das wird auch richtig eingestellt.
Wird denn beim Auto Detect des TS-480 der genau richtige Wert auch durchlaufen?

73 Ben

[DL6ER]

Hallo Ben,

[...]es ist schon früher aufgefallen, daß manche TRX definiert vor oder nach UcxLog eingeschaltet werden wollen[...]

Das konnte ich bisher nicht beobachten, da der PC relativ langsam hochfährt, läuft der TRX aber immer schon lange, bevor das Log gestartet ist.

Läßt sich denn Dein TS-480 unmittelbar nach dem Auto Detect mit den richtigen Werten verbinden, ohne UcxLog neu zu starten?

Ja das geht, wenn der Auto Detect ohne Ergebnis durchgelaufen ist (oder abgebrochen wird), bleiben die CAT-Einstellung ja offensichtlich unverändert und ohne TRX- und/oder UcxLog-Neustart funktioniert die CAT (ob es da vielleicht eine Verzögerung von ein paar Sekunden gibt (bis es wieder funktioniert) kann ich aber nicht sagen, habe mir darüber keine Gedanken gemacht).

Wird denn beim Auto Detect des TS-480 der genau richtige Wert auch durchlaufen?

Ja das passiert, da habe ich mich auch so gewundert, sowohl 9600 8N2 und später 9600 8N1 werden durchlaufen, ohne dass irgendetwas außergewöhnliches passiert...

73 Dominik

[DL7UCX]

Hallo Dominik,

in UcxLog scheint es dann nicht zu hängen, ich muß wahrscheinlich doch mal meinen TS-480 aus dem Auto ausbauen ...

73 Ben

[DL6ER]

Hallo Ben,

werde bei nächster Gelegenheit noch etwas mehr testen, aber das wird frühstens in zwei Wochen sein...
Kann auch einmal Ham Radio Deluxe installieren und schauen, ob Auto-Detect hier erfolgreich ist. Wenn es ja wirklich ein prinzipielles Problem ist (verschiedene Baudraten zu schnell hintereinander )...

73 Dominik

[DL7UCX]

Hallo Dominik,

nicht nötig, habe den TS-480 ausgebaut ...
Und man kann beim Test noch an vielen Schrauben drehen.

73 Ben

[DL7UCX]

Hallo,

nun sollte der Auto Detect in 6.85 Beta 22 noch etwas besser sein, der TS-480 wird auf jeden Fall erkannt.
Das Problem lag darin, daß er beim ersten richtigen Status-Request noch etwas "verwirrt" geantwortet hat und ich den Empfangspuffer nicht noch einmal geleert hatte.

73 Ben

An Thomas: Vielleicht geht es jetzt?

[DL6ER]

Hallo Ben,

vielen Dank für die zügige Umsetzung! Teste in Kürze noch selbst, aber wenn dein TS-480 gefunden wird, dann vermutlich alle

73 Dominik

[DL7UCX]

Hallo Dominik,

interessanterweise erkennt der Auto-Detect 2 Stoppbits, womit der TS-480 (entgegen dem Manual: 1 Stoppbit) auch stabil arbeitet.

73 Ben

[DL6ER]

Hallo Ben,

das wundert mich überhaupt nicht, es wird vermutlich jedes 8N1 Gerät auch mit 8N2 laufen.
Sehen wir uns den Unterschied auf der technischen Ebene genauer an:

Im Wartezustand liegen die Pegel auf "1" - Aktiv hingeben bedeutet einen Pegel von "0" (genau invertiert zu gewöhnlichen logischen Pegeln).

Somit liegt die ganze Zeit eine "1" an, bis irgendwann die Aktivität mit einem Start-Bit ("0") eingeleitet wird. Dann folgen die 8 Daten-Bits und kein Check-Bit (8 N 1).
Den Abschluss machen dann 1 oder bei uns jetzt auch 2 Stopp-Bits, die per Definiton "1" Pegel führen und somit am Ende im Prinzip nicht mehr von dem Wartezustand zu unterscheiden sind.

Ihr einziger Zweck ist es, dem empfangenden Gerät ein bisschen Zeit zu lassen, bevor die nächsten Daten - durch edas nächste Start-Bit angekündigt - hinterher kommen.

Ein zweites Stopp-Bit verlängert nur die Zwangs-Wartezeit vor der nächsten Übertragung um die Datenlänge eines Bits (bei 9600 um etwa 100 Mikrosekunden ).

Da das serielle Protokoll aber asynchron arbeitet, gibt es keine Zeitfenster, die eingehalten werden müssten und ich kann mir keine Situation vorstellen, wo es dadurch Probleme geben könnte

Habe mich noch an einer kleinen einfachen Grafik versucht:


Wie man also einfach sehen kann, gibt es keinerlei Unterschiede am Signal selbst und ein TRX wird es daher auch nicht unterscheiden können.

Ist am PC 8N2 und am TRX 8N1 kann es also keine Probleme in Richtung PC -> TRX geben, wenn jedoch viel Text in RIchtung PC <- TRX gesendet wird, könnte es passieren, dass der TRX eine neue Übertragung einleitet, während der Computer eigentlich noch das zweite Stopp-Bit erwartet. "Eigentlich" steht daher kursiv, da die meisten seriellen Controller mit dieser Problematik umgehen können, da sie nicht auf den Stopp-Bits bestehen und sofort eine neue Übertragung starten können. Wenn man jetzt noch über CTS/RTS ein Handshaking hätte, ist man aber auch dafür abgesichert.

Hoffe ich konnte ein bisschen Licht auf den Hintergrund werfen

73 Dominik

[DL7UCX]

Hallo Dominik,

das ist mir schon klar, deswegen beginnt mein Auto Detect auch mit 2 Stoppbits.

Der Haken bei der Einstellung "2 Stoppbits" ist eben nur, ob der empfangende UART zwei Stoppbits erwartet oder sich mit einem Stoppbit zufrieden gibt.
"Klassich" erwartet er wirklich 2 Stoppbits, aktuell scheinen sich aber zumindest manche auch mit 1 (bei Einstellung auf 2) zufrieden zu geben.
Das ist sehr "Nutzerfreundlich", weil dann die Angabe der Stoppbits überflüssig wird (Senden: 2, Empfangen: 1), im CAT-Manual des FT-5000 steht dazu z.B. nichts mehr.

Es funktioniert also immer, wenn 2 Stoppbits gesendet werden und der Empfang von einem Stoppbit reicht.

Aber woher weiß ich nun, warum es mit "2 Stoppbits" am PC und "1 Stoppbit" lt. TS.480-Manual geht?
Dafür gibt es zwei undokumentierte Möglichkeiten:
1. Mein PC-COM-Port begnügt sich beim Empfang mit einem statt zwei Stoppbits
ODER / UND
2. Der TS-480 sendet immer 2 Stoppbits.

Die Antwort scheint es nur mit Probieren zu geben.
Mit der Analyse des TS-480-Signals am Oszi könnte man Frage 2 beantworten.
Und so schön wie 1. ist, es verringert etwas die Empfangssicherheit, falls die Übertragung gestört ist.

73 Ben

[DL6ER]

Hallo Ben,

Es funktioniert also immer, wenn 2 Stoppbits gesendet werden und der Empfang von einem Stoppbit reicht.

Es würde vermutlich einen nicht wirklich gerechtfertigten Programmieraufwand erfordern, aber theoretisch müsste es ja möglich sein, dass man dem UART nicht alle Zeichen zusammenhängend liefert, die er dann selbstständig sendet, sondern jedes Zeichen einzeln sendet, eine gewisse Zeit wartet (9600 8N2 -> 11/9600 Sekunden) und erst dann das nächste Zeichen hinterher schickt

Somit könnte man den UART mit 8N1 initialisieren und empfangen und mit 8N2 senden (durch die simulierte Pause)...

Dann wäre die Einstellmöglichkeit wirklich obsolet und man bräuchte sich nur über die Baudrate zu sorgen!
Wenn drei Einstellungsfehlermöglichkeiten 8 / N / 1 wegfallen, kann es ja nur einfacher werden, welcher TRX braucht +/- 8 Datenbits und noch ein Check-Bit?...

Glaube kaum, dass es das noch irgendwo gibt...

73 Dominik

[DL7UCX]

Hallo Dominik,

das verzögerte zeichenweise Senden über das COM-Port scheitert nicht nur am Aufwand sondern auch an Windows, da es kein Echtzeitbetriebssystem ist.
Man hat weder einen präzisen, hochauflösenden Timer, noch weiß man, wie (gleichmäßig) schnell ein Zeichen über das Windows-API und Treiber zur Hardware gelangt.

73 Ben

[dl8dww]

Hallo Ben,
Bei meinen TS-570 habe ich 9k6 8N1 eingestellt.Beim Scan wird der TRX gefunden (9K6 8N2)
Im Handbuch zum TS-570 sind mit Ausnahme 4k8 Bd immer nur ein Stoppbit.

4800 8N2 soll bei Datenübertragung von oder zu einen anderen Kennwood gewählt werden.
Werkseitig ist 9k6 eingestellt.
Könnte es sein, dass beim Scan eine falsche Anzeige erscheint?
Stelle ich von Hand bei 4800Bd unterschiedliche Stoppbits zwischen UCXLog und Kennwood ein,und führe keinenScan durch, funktioniert die Steuerung nicht.
Bei 9600 ist es unschädlich ,was im UCXLog eingestellt wird.
73 Wolfgang

[DL7UCX]

Hallo Wolfgang,

nach erfolgreichem Auto-Detect werden die Werte der COM-Settings in die Anzeige übernommen, die auch für die manuelle Einstellung verwendet wird, insofern wäre eine falsche Anzeige während des Auto-Detect theoretisch möglich, danach aber nicht.

73 Ben