Sendetiming Rundschreibdienst

[BjoernS]

Hallo zusammen,

vorweg: Ich bin mir nicht sicher, ob meine Fragen hier richtig aufgehoben sind, da sich Entwickler- und Anwenderperspektive überschneiden, bei Bedarf bitte verschieben.

Heute kam ein Rundschreiben vom Rundsendedienst bei mir an, mit zwei Besonderheiten:

1. Die für den Kennungsgeberablauf vorgesehene Zeit war sehr kurz, mein FS kam nicht mit und so gab es Zeichensalat
2. Die Sendegeschwindigkeit des Rundsendedienstes ist recht hoch, durchschnittlich ca. 80 Zeichen/s (gegenüber 6,7 Zeichen bei 50 Bd)

Zum Verständnis muss ich noch kurz etwas ausholen (eigentlich wollte ich das erst gesammelt vorstellen sobald es gut funktioniert). Meine T1000 am piTelex ist im Moment im "Offline"-Probebetrieb, d.h. sie ist aufgrund des hohen Standby-Verbrauchs normalerweise ausgeschaltet und bei eingehendem FS wird die Netzspannung per Relais zugeschaltet. Die Reaktionszeit des FS auf A=>Z-Wechsel verlängert sich dadurch von ca. 240 ms auf 2,4 s. Sobald die eingehende Verbindung getrennt wird, läuft eine Zeit von 30 s ab (ca. 200 Zeichen), damit der FS den Empfangspuffer leerschreiben kann (der vom Gegenüber normalerweise nicht voller als 50 Zeichen geschrieben werden sollte), und dann schaltet das Relais ab.

Heute lief es also so, dass beim Verbinden des Rundsendedienstes das Datumsbanner, WRU, CR, LF gesendet wurden, mit Antwort des KG sind das insgesamt bis zu 47 Zeichen zu drucken (ca. 7 s). Nach 9 s wurde weitergesendet, was mit der Einschaltverzögerung zu Datensalat geführt hat.

Die restliche Nachricht wurde dann mit ca. 600 Bd gesendet. Nach Trennen der Verbindung war noch so viel im Puffer (ca. 1700 Zeichen), dass die 30 s nicht ausgereicht haben und der FS abgeschaltet wurde. [Letzteres ist hausgemacht, was mir erst beim Schreiben der Nachricht auffiel, denn piTelex saugt einfach alle Empfangsdaten schnellstmöglich in seinen faktisch unbegrenzten Empfangspuffer auf, ohne die ACK-Drosselung zu benutzen.]

Hat sonst jemand Probleme mit dem Empfang der Rundschreiben, oder passt bei euch alles? Schön wäre aus meiner Perspektive eine etwas längere Zeit für den Kennungsgeberablauf, ggf. 1 s Warten auf "Sendepause" des Gegenüber.

Grüße


Björn

P.S.: Vielleicht sollte ich einfach die T1000 auf 100 Bd aufdrehen ...

[dh0jsv]

Bei mir kam das Rundschreiben perfekt an, aber ich nutze ja auch das originale i-Telex. Damit wird es wohl eher keine Probleme geben...

[FredSonnenrein]

Rückfrage an Björn: Welchen Wert sendet dein System im ACK-Telegramm, wenn (beispielhaft) 60 "Bytes" (also 5-Bit-Worte) in dem "unbegrenzen" Empfangspuffer gespeichert sind und schon 10 "Codes" an den Fernschreiber gesendet worden sind (also insgeamt 70 Codes empfangen worden sind)?

Und dass anstelle von 30 Sekunden auch der Fernschreiber genau dann ausgeschaltet werden sollte, wenn die Verbindung abgebaut worden ist UND der Empfangspuffer leer ist, ist dir inzwischen wohl auch klar ;-)

[BjoernS]

Hallo Fred,

in der aktuellen Fassung ist es piTelex egal, was der Fernschreiber macht Also wird mit jedem empfangenen Baudot-Data-Paket der Empfangszähler um die Länge des Paketinhalts erhöht und ein Acknowledge mit diesem Zähler im Datenteil zurückgesendet.

Meine Lösung(?) aktuell ist wie von dir erwähnt, das Schalten des Relais vom Puffer des ED1000-Moduls abhängig zu machen. (Ursprünglich waren die 30 s auch nicht als Zeit zum Wegschreiben gedacht, sondern um die Schalthäufigkeit zu begrenzen, z.B. wenn der Newsdienst mehrere Nachrichten hintereinander schickt.)

In der Spezifikation steht ja klar drin, dass Acknowledge nur die gedruckten Zeichen zurückgeben sollte und überhaupt erst nach Druckerstart gesendet werden sollte. Da die Module für die i-Telex-Verbindung und ED1000 getrennt sind, wissen die derzeit nicht genug voneinander. Die Architektur hat Vorteile (z.B. hatte das Archivmodul die obige Nachricht schon komplett weggespeichert), aber gerade im Hinblick auf das Timing (Warten auf Kennungsgeber) scheint es mir sinnvoll, da zumindest eine Drosselung einzubauen ... das vom Rundsendedienst geschickte WRU am Ende der Nachricht blieb komplett unbeantwortet, weil der FS erst ein Drittel der Nachricht gedruckt hatte.

(Im Dialog mit echten FS hat das keine praktische Auswirkung, da diese nicht schneller senden können.)

Grüße


Björn

[detlef]

Der Acknowledge ist in WinTlx auch eine ewige Baustelle. Ich habe das schon 3 mal umgebaut, aber immer wieder gibt es irgendwelche Probleme.

[FredSonnenrein]

in der aktuellen Fassung ist es piTelex egal, was der Fernschreiber macht Also wird mit jedem empfangenen Baudot-Data-Paket der Empfangszähler um die Länge des Paketinhalts erhöht und ein Acknowledge mit diesem Zähler im Datenteil zurückgesendet.

Genau das ist das Problem:
Der Rundsendedienst glaubt (durch den Wert den er per ACK gemeldet bekommt), dass das "WerDa" längst auf dem Fernschreiber angekommen ist.
Da das Werda bereits am Fernschreiber ist und 7 Sekunden lang keine Kennung zurück kam, hat dein Fernschreiber offensichtlich keinen funktionierenden Kennungsgeber.
Davon geht der Rundsendedienst jedenfalls aus.
Du solltest deine Architektur der Spezifikation anpassen.
Beispielsweise so, dass das ED1000 Modul wirklich die Zeichen aus dem Puffer zeichenweise abholt und sofort an den Fernschreiber sendet.
Im ACK-Packet wird dann der Wert "Zeichenzähler minus aktuellem Pufferinhalt" gesendet. So macht es das i-Telex.

[Fernschreiber]

Hallo Björn,
ich muss Fred recht geben, passe dein System der Spezifikation an bzw. implementiere es wie eine Echtzeitanwendung. Die Lagerung im Puffer ist keine Verarbeitung im Sinne eines Drucks auf dem Papier. Merkwürdig ist aber das die Rundsendeeinrichtung trotz der richtigen Ackverarbeitung kein mittleres Limit bei etwa 7Zeichen/sek zu kennen scheint. Diese telexfremden Systeme (auch meine Server die Thomas hostet) müssen bei Sendegeschwindigkeit gedeckelt werden, mit oder ohne Ackberücksichtigung. Der Empfangspuffer darf nur mit Daten für wenige Sekunden gefüllt werden, um Echtzeitaktionen wie aut. KG-Austausch zu ermöglichen. Daran muss sich eine Sende/ Empfangssoftwareentwicklung messen lassen. Das unsere Pi's schier unerschöpfliche Empfangspuffer (kann man aber begrenzen) haben, führt hier zu einem falschen Ansatz. Einfache Regel: mittlere Geschwindigkeit von etwa 50 Baud auf allen Transportebenen und "Denken" wie ein mechanisches System. Am Ende hämmert nämlich ein feinmechaninsces Wunderwerk den Typenhebel auf's Papier.
Gruß
Willi

[ProjektTelefon]

Hier kam das Rundsenden auch perfekt an! Schmeiß den pi-Telex Schrott weg, und hol dir das echte i-Telex

[FredSonnenrein]

ich muss Fred recht geben, passe dein System der Spezifikation an bzw. implementiere es wie eine Echtzeitanwendung. Die Lagerung im Puffer ist keine Verarbeitung im Sinne eines Drucks auf dem Papier. Merkwürdig ist aber das die Rundsendeeinrichtung trotz der richtigen Ackverarbeitung kein mittleres Limit bei etwa 7Zeichen/sek zu kennen scheint.

Prinzipiell kann das i-Telex auch mit 100 Baud Maschinen umgehen, es gab schon eine entsprechende Testinstallationen.
Korrekte ACK-Verarbeitung vorausgesetzt könnten sich "schnelle" Systeme dieser Geschwindigkeit auch anpassen.
Ich hatte diesen Aspekt mit Paul, dem Entwickler der Rundschreibeinrichtung, auch besprochen.

Diese telexfremden Systeme (auch meine Server die Thomas hostet) müssen bei Sendegeschwindigkeit gedeckelt werden, mit oder ohne Ackberücksichtigung. Der Empfangspuffer darf nur mit Daten für wenige Sekunden gefüllt werden, um Echtzeitaktionen wie aut. KG-Austausch zu ermöglichen. Daran muss sich eine Sende/ Empfangssoftwareentwicklung messen lassen.

Das sehe ich persönlich anders, aber es ist natürlich die sichere Seite, die Sendegeschwindigkeit zu begrenzen, um mit Systemen klar zu kommen, die ACK nicht korrekt senden oder (ASCII-Modus) gar keine "Empfangskontrolle" besitzen.

Das unsere Pi's schier unerschöpfliche Empfangspuffer (kann man aber begrenzen) haben, führt hier zu einem falschen Ansatz. Einfache Regel: mittlere Geschwindigkeit von etwa 50 Baud auf allen Transportebenen und "Denken" wie ein mechanisches System. Am Ende hämmert nämlich ein feinmechaninsces Wunderwerk den Typenhebel auf's Papier.

So sollte es sein, aber vielleicht vermehren sich irgendwann die 100 Baud Liebhaber, zu empfehlen natürlich aus Verschleißgründen nur mit elektronischen Fernschreibern.

Viele Grüße,

Fred

[Franz]

Hallo, habe von allem leider kein Wort verstanden kann nur folgendes aus laufendem Betrieb sagen:

wird ein TW39 Anschluß auf Wählscheibe "ja" eingestellt, wird grundsätzlich nach Verbindungsaufbau kein KG des Adressaten automatisch abgefragt, dann werden die Meldungen des "Rundschreibe-Servers" (oder wie das heisst) nicht unterbrochen und gut empfangen...

wird ein TW39 Anschluß auf Wählscheibe "nein" (also Tastaturwahl) eingestellt, wird grundsätzlich nach Verbindungsaufbau der KG des Adressaten automatisch abgerufen und diese KG Abfrage "knallt" genau in die Meldungen des Rundschreibeservers rein.

Weiß nicht, ob das was weiterhilft, aber das ist bei mir so....

Grüße Franz