Telexforum.de

Evtl hat der Effekt auch damit zu tun, ähnlich was Franz beschrieben hat: Wenn ich am T51 (Wählscheibe "ja") das Wetter abrufe, muß ich, wie dann ausgedruckt wird, meinen KG mit ZV bestätigen. Mach ich das am F2000 (Wählscheibe "nein"), läuft das automatisch weiter, ohne dass ich ZV geben muß. Für mich nicht störend, aber es hat mich anfangs etwas gewundert

Hallo zusammen,

Willi, vielen Dank für deine ausführlichen Worte, denen ich zu 100% zustimme, dennoch wenige Worte ergänze:

Fernschreiber hat geschrieben: ↑Mi 5. Aug 2020, 03:59 Im i-Telex sind durch Tastwahl und Nrs-Wahl bzw. an/abschalten von Datum/Zeit die unterschiedlichsten Kombinationen möglich. Ein externes System wie ein Dienst muss bei Anruf damit rechnen, das die Endstelle eine KG-Abfrage schickt oder auch nicht. Ruft ein Dienst eine Rufnummer an, kann ein Datum/Zeit kommen oder nicht. Die Einzig verlässliche Abhilfe , um dieses Durcheinander zu regeln, kann nur in der Teilnehmerserverdatei liegen. Dort müsste eine Kennung im Datensatz liegen welche zu Steuerungszwecken verwendet werden kann; z.B. Anschluss ist ein Dienst, KG-Abfrage unterbinden.

Prinzipiell ein guter Ansatz, aber dann müssen die "Flags" in der Teilnehmerserver-Datei und die persönlichen Einstellungen "synchronisiert" werden. Zu Zeiten der Bundespost denkbar, heute möchte ich das nicht mehr machen.

Fernschreiber hat geschrieben: ↑Mi 5. Aug 2020, 03:59 Für mich stellt sich momentan die Frage, welche Zeitspanne ist für Datum/Zeit vorgesehen und welches Zeitfenste schliesst sich daran für die KG-Abfrage an. Diese Zeiten könnte man im Diensteserver berücksichtigen um Pausen einzulegen und passend immer wieder die Zeichsätze passend zu stellen.

Die erste Frage ist leicht zu beantworten:
Das Datum wird von der Ethernet-Karte (einstellbar) gesendet, sobald der angewählte Fernschreiber betriebsbereit ist. Und das kann zwischen 0 und 8 Sekunden dauern. Warum so lange? Wenn der angewählte Fs im Lokalbetrieb ist, dann geht erst die Schnarre los und nach X Sekunden (habe schon mal 5 Sekunden gemessen) wird erst von Lokalbetrieb auf Anrufbetrieb umgeschaltet. Um auf der sicheren Seite zu sein, ist das Timeout dafür bei der Ethernetkarte 8 Sekunden. Falls in dieser Zeit der Fernschreiber nicht anspringt (keine Netzspannung), dann kommt anstelle des Datums die "Abweisung" mit DER.
Bei Tastaturwahl wird der WerDa-Code von der Schnittstellenkarte (also TW39 oder ED1000) gesendet, sobald die Schnittstellenkarte von der Ethernetkarte das Zeichen "Verbindung steht" empfangen hat und danach 0,5 Sekunden vergangen sind.
Es wird zweimal Zi und ein WerDa gesendet. Falls von der Gegenstelle nichts als Antwort kommt (pure Bu-Umschaltungen werden ignoriert), dann wird nach 5 Sekunden erneut Zi+Zi+Werda gesendet.
Sobald selbst geschrieben wird oder tatsächlich sinnvolle Zeichen von der Gegenstelle kommen, wird die "WerDa-Automatik" abgeschaltet.
Dieser Algorithmus wurde im laufe der Zeit mehrfach geändert, kann also im Detail abweichen.
(PS: Glücklich bin ich damit selbst nicht mehr, aber nun ist es mal da und wie Willi treffend schreibt, sollte jeder "Server" damit klarkommen)

Meine Empfehlungen lauten:
Server-Dienste (also die, die angerufen werden), sollten nach der Anwahl erstmal 1,5 Sekunden "still" sein. In dieser Zeit sollte ein ggf. gesendetes "Automatik-WerDa" angekommen sein. Auf das WerDa darf auch mit dem "normalen" Begrüßungstext geantwortet werden.
Alle Dienste, die Benutzereingaben abfragen, sollten WerDa ignorieren.
Bei einer Benutzereingabe sollte der "Fragetext" gedruckt werden, dann sollten die ACK-Telegramme ausgewertet werden. Solange der ACK-Zähler nicht bestätigt, dass das letzte Zeichen des Fragetextes angekommen ist, können "entgegenkommende" Zeichen ignoriert werden.
Das gilt auch, falls der Dienst die Kennung der Gegenstelle automatisch abfragen will: WerDa senden, auf das "passende" ACK warten und dann einen Zeitgeber starten, der 5 Sekunden auf das erste "Antwortzeichen" wartet und jede Unterbrechung von mehr als 2 Sekunden bei der Antwort als "Kennungsende" interpretieren. (Bauchwerte, bei den 5 Sekunden unsere internationalen Anwender berücksichtigen!).

Hallo Fred,
danke für die sehr detaillierten Ausführungen. Vielleicht findet sich ja mal jemand der das ähnlich den ED1000 Beschreibungen hier im Wiki im Zeitstrahl mit den Zeiangaben einpflegt und in der Beschreibung" i-Telex System" integriert.
Deine Empfehlungen habe ich damals in den KLKL-Servern aus eigener Überlegung fast genauso implementiert, welch Zufall. Das Einbinden der ACK's wäre natürlich noch das Sahnehäubchen zwecks Optimierung, aber auch nicht ganz ohne Risiko(siehe Björn's Philisophie).Ich habe damals Zeitlimits gesetzt.
Das wichtigste ist aber bei alldem, das wir solche Effekte analysieren, Empfehlungen anbieten können und das System immer wieder diskutieren.
"Quick und Dirty"-Lösungen haben bei der Komplexität keine große Chance.

Gruß
Willi

Hallo zusammen,

FredSonnenrein hat geschrieben: ↑Mi 5. Aug 2020, 08:11 Das Datum wird von der Ethernet-Karte (einstellbar) gesendet, sobald der angewählte Fernschreiber betriebsbereit ist. Und das kann zwischen 0 und 8 Sekunden dauern. Warum so lange? Wenn der angewählte Fs im Lokalbetrieb ist, dann geht erst die Schnarre los und nach X Sekunden (habe schon mal 5 Sekunden gemessen) wird erst von Lokalbetrieb auf Anrufbetrieb umgeschaltet. Um auf der sicheren Seite zu sein, ist das Timeout dafür bei der Ethernetkarte 8 Sekunden. Falls in dieser Zeit der Fernschreiber nicht anspringt (keine Netzspannung), dann kommt anstelle des Datums die "Abweisung" mit DER.
Bei Tastaturwahl wird der WerDa-Code von der Schnittstellenkarte (also TW39 oder ED1000) gesendet, sobald die Schnittstellenkarte von der Ethernetkarte das Zeichen "Verbindung steht" empfangen hat und danach 0,5 Sekunden vergangen sind.
Es wird zweimal Zi und ein WerDa gesendet. Falls von der Gegenstelle nichts als Antwort kommt (pure Bu-Umschaltungen werden ignoriert), dann wird nach 5 Sekunden erneut Zi+Zi+Werda gesendet.
Sobald selbst geschrieben wird oder tatsächlich sinnvolle Zeichen von der Gegenstelle kommen, wird die "WerDa-Automatik" abgeschaltet.
Dieser Algorithmus wurde im laufe der Zeit mehrfach geändert, kann also im Detail abweichen.
(PS: Glücklich bin ich damit selbst nicht mehr, aber nun ist es mal da und wie Willi treffend schreibt, sollte jeder "Server" damit klarkommen)

Meine Empfehlungen lauten:
Server-Dienste (also die, die angerufen werden), sollten nach der Anwahl erstmal 1,5 Sekunden "still" sein. In dieser Zeit sollte ein ggf. gesendetes "Automatik-WerDa" angekommen sein. Auf das WerDa darf auch mit dem "normalen" Begrüßungstext geantwortet werden.
Alle Dienste, die Benutzereingaben abfragen, sollten WerDa ignorieren.
Bei einer Benutzereingabe sollte der "Fragetext" gedruckt werden, dann sollten die ACK-Telegramme ausgewertet werden. Solange der ACK-Zähler nicht bestätigt, dass das letzte Zeichen des Fragetextes angekommen ist, können "entgegenkommende" Zeichen ignoriert werden.
Das gilt auch, falls der Dienst die Kennung der Gegenstelle automatisch abfragen will: WerDa senden, auf das "passende" ACK warten und dann einen Zeitgeber starten, der 5 Sekunden auf das erste "Antwortzeichen" wartet und jede Unterbrechung von mehr als 2 Sekunden bei der Antwort als "Kennungsende" interpretieren. (Bauchwerte, bei den 5 Sekunden unsere internationalen Anwender berücksichtigen!).

Danke für die Details. Probiere gerade eine mit heißer Nadel gestrickte Fassung von piTelex aus, wo nur die tatsächlich gedruckten Zeichen im Acknowledge gesendet werden. Sieht soweit gut aus, nur habe ich jetzt ein ganz anderes Problem: Wie i-Telex schreibe ich bei einem Anruf als erstes automatisch Datum/Uhrzeit zu, sobald der FS angelaufen ist. Dabei sende ich jetzt auch ein Ack (mit -24 & 0xff, so dass es am Schluss bei 0 landet). Gleichzeitig (mit dem ersten Ack) schreibt der Rundsendedienst ein WRU. Aufgrund der Architektur von piTelex wird erst WRU, dann Datum/Zeit abgedruckt, was zu ... interessanten Mustern führt. Während des KG-Ablaufs rutscht dann nochmal die ein oder andere Ziffernumschaltung dazwischen, was dann zu "844767 5254 <WRU>" führt, und das Ganze geht von vorne los. Wie löst i-Telex das auf, werden Daten vom Gegenüber zwangsweise nach Datum/Zeit in den Druckerpuffer eingereiht?

Fernschreiber hat geschrieben: ↑Mi 5. Aug 2020, 11:38 Das wichtigste ist aber bei alldem, das wir solche Effekte analysieren, Empfehlungen anbieten können und das System immer wieder diskutieren.
"Quick und Dirty"-Lösungen haben bei der Komplexität keine große Chance.

Vielen Dank auch nochmal an alle, dass man hier so freundschaftlich diese technischen Probleme diskutieren und Lösungen erarbeiten kann. Das ist meiner Erfahrung nach nicht selbstverständlich (obwohl es das m.E. sein sollte).

Grüße


Björn

BjoernS hat geschrieben: ↑Fr 7. Aug 2020, 08:55 Wie löst i-Telex das auf, werden Daten vom Gegenüber zwangsweise nach Datum/Zeit in den Druckerpuffer eingereiht?

Genau so.
Eigene Ausgabe des Datums und das Senden an den Anrufer sind getrennte Abläufe.

BjoernS hat geschrieben: ↑Fr 7. Aug 2020, 08:55 Vielen Dank auch nochmal an alle, dass man hier so freundschaftlich diese technischen Probleme diskutieren und Lösungen erarbeiten kann. Das ist meiner Erfahrung nach nicht selbstverständlich (obwohl es das m.E. sein sollte).

Dem kann ich mich nur anschließen.

Hallo nochmal,

also das war anfangs sehr dubios. Habe jetzt ausprobiert mit zwangsweiser Einordnung der Datum-/Zeitzeile vor allen Daten, die vom Rundsendedienst gesendet werden, inkl. entsprechender Acknowledgepakete; trotzdem sendete der Rundsendedienst sofort sein WerDa.

Dann habe ich bemerkt, dass der Dienst selbst beim Ausbleiben von Acknowledge sendet. Immer nach einem Heartbeat.
Heartbeats abgestellt, Acknowledge an: Alles super. Ich schreibe Datum/Uhrzeit zu, letztes Ack hat als Daten 0, dann erst kommt das WerDa.

Aus diesem Anlass ein paar Fragen zum Heartbeat, die ich mir nicht mit der Spec beantworten konnte:

1. In der Spec steht, dass alle 15 s mindestens ein Ackowledge, Heartbeat oder Baudot Data gesendet werden sollte. Ist das tatsächlich ein ODER, d.h. Heartbeats könnten entfallen, solange ich Acknowledge sende? Zumindest steht ja beim Heartbeat, dass Acknowledge "preferred" ist, wird ersteres dadurch optional?
2. Ist ein Heartbeat wie ein Acknowledge mit Inhalt "zugeschrieben" = "ausgedruckt" zu interpretieren? Scheinbar tut der Rundsendedienst genau das.
3. Dürfen Heartbeats eigentlich auch erst mit laufendem FS gesendet werden, oder schon vorher?

(Würde die Tage anfangen, die Ethernetbeschreibung ins Wiki zu übertragen, danach wäre wohl die i-Telex-Spezifikation eine gute Investition, um besser gemeinsam daran feilen zu können.)

Grüße


Björn

BjoernS hat geschrieben: ↑So 9. Aug 2020, 10:50 Hallo nochmal,

also das war anfangs sehr dubios. Habe jetzt ausprobiert mit zwangsweiser Einordnung der Datum-/Zeitzeile vor allen Daten, die vom Rundsendedienst gesendet werden, inkl. entsprechender Acknowledgepakete; trotzdem sendete der Rundsendedienst sofort sein WerDa.

Dann habe ich bemerkt, dass der Dienst selbst beim Ausbleiben von Acknowledge sendet. Immer nach einem Heartbeat.
Heartbeats abgestellt, Acknowledge an: Alles super. Ich schreibe Datum/Uhrzeit zu, letztes Ack hat als Daten 0, dann erst kommt das WerDa.

Aus diesem Anlass ein paar Fragen zum Heartbeat, die ich mir nicht mit der Spec beantworten konnte:

• In der Spec steht, dass alle 15 s mindestens ein Ackowledge, Heartbeat oder Baudot Data gesendet werden sollte. Ist das tatsächlich ein ODER, d.h. Heartbeats könnten entfallen, solange ich Acknowledge sende? Zumindest steht ja beim Heartbeat, dass Acknowledge "preferred" ist, wird ersteres dadurch optional?
• Ist ein Heartbeat wie ein Acknowledge mit Inhalt "zugeschrieben" = "ausgedruckt" zu interpretieren? Scheinbar tut der Rundsendedienst genau das.
• Dürfen Heartbeats eigentlich auch erst mit laufendem FS gesendet werden, oder schon vorher?

Antworten in kürze:
Zu 1.
Ja es ist egal.
Zu 2.
Nein ein Heartbeat enthält keine zusätzliche Information.
Da ist beim Rundsender wohl ein Bug enthalten.
Der ist bisher nicht aufgefallen, weil i-Telex nach erfolgreicher Verbindungsaufnahne keine Heartbeats mehr sendet. Nur noch Ack, ggf. mit unveränderten Daten.
Zu 3.
Immer.
Gerade wenn noch kein Ack erlaubt ist (weil der eigene Fs noch nicht läuft), dann muss Heartbeat verwendet werden.

FredSonnenrein hat geschrieben: ↑So 9. Aug 2020, 12:04 Nein ein Heartbeat enthält keine zusätzliche Information.
Da ist beim Rundsender wohl ein Bug enthalten.
Der ist bisher nicht aufgefallen, weil i-Telex nach erfolgreicher Verbindungsaufnahne keine Heartbeats mehr sendet. Nur noch Ack, ggf. mit unveränderten Daten.

"Nach erfolgreicher Verbindungsaufnahme" heißt "FS gestartet", oder ist noch etwas enthalten?

Grüße


Björn

BjoernS hat geschrieben: ↑So 9. Aug 2020, 12:25

FredSonnenrein hat geschrieben: ↑So 9. Aug 2020, 12:04 Nein ein Heartbeat enthält keine zusätzliche Information.
Da ist beim Rundsender wohl ein Bug enthalten.
Der ist bisher nicht aufgefallen, weil i-Telex nach erfolgreicher Verbindungsaufnahne keine Heartbeats mehr sendet. Nur noch Ack, ggf. mit unveränderten Daten.

"Nach erfolgreicher Verbindungsaufnahme" heißt "FS gestartet", oder ist noch etwas enthalten?

Korrekt.

Fred, vielen dank für deine Auskünfte

Grüße


Björn