Sendetiming Rundschreibdienst

todo
Benutzeravatar

dh0jsv
Rank 4
Rank 4
Beiträge: 299
Registriert: Di 3. Sep 2019, 14:28
Wohnort: Zwickau
Hauptanschluß: 785069 frhuf dd

Re: Sendetiming Rundschreibdienst

#21

Beitrag: # 20064Beitrag dh0jsv »

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 :)
Sven, DH0JSV
-------------------------------------------
785069 frhuf dd (T51)
784223 nema dd (F2000)
6292941 sik d (T1000)

Anschlüsse 24/7 erreichbar

----------------------
Prüfkoffer DE2000
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Sendetiming Rundschreibdienst

#22

Beitrag: # 20067Beitrag FredSonnenrein »

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!).
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 3):
detlefFernschreiberBjoernS
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.

Fernschreiber
Rank 3
Rank 3
Beiträge: 230
Registriert: Sa 17. Dez 2016, 15:28
Wohnort: Münster
Hauptanschluß: 25060 schuett d
Kontaktdaten:

Re: Sendetiming Rundschreibdienst

#23

Beitrag: # 20078Beitrag Fernschreiber »

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
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag (Insgesamt 3):
detlefFredSonnenreinBjoernS
Hauptnummer 25060
25061117 ufs lingen  T68d     Dw 890 
89899 schuett d        T1000   Dw 894  Hauptstelle
826433b vdm d         T100     Dw 891
841226 mizg d           Lo15     Dw 895
84635 norman d        T100     Dw 896
Benutzeravatar

Topic author
BjoernS
Rank 3
Rank 3
Beiträge: 199
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Sendetiming Rundschreibdienst

#24

Beitrag: # 20130Beitrag BjoernS »

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.
:thumbup:

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
844767 twtr d
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Sendetiming Rundschreibdienst

#25

Beitrag: # 20131Beitrag FredSonnenrein »

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.
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 4):
BjoernSReinholdKochFernschreiber380170JFK
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

Topic author
BjoernS
Rank 3
Rank 3
Beiträge: 199
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Sendetiming Rundschreibdienst

#26

Beitrag: # 20150Beitrag BjoernS »

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. :p
Heartbeats abgestellt, Acknowledge an: Alles super. Ich schreibe Datum/Uhrzeit zu, letztes Ack hat als Daten 0, dann erst kommt das WerDa. :freu:

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
844767 twtr d
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Sendetiming Rundschreibdienst

#27

Beitrag: # 20151Beitrag FredSonnenrein »

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. :p
Heartbeats abgestellt, Acknowledge an: Alles super. Ich schreibe Datum/Uhrzeit zu, letztes Ack hat als Daten 0, dann erst kommt das WerDa. :freu:

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.
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
BjoernS
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

Topic author
BjoernS
Rank 3
Rank 3
Beiträge: 199
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Sendetiming Rundschreibdienst

#28

Beitrag: # 20152Beitrag BjoernS »

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
844767 twtr d
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Sendetiming Rundschreibdienst

#29

Beitrag: # 20160Beitrag FredSonnenrein »

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.
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
BjoernS
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

Topic author
BjoernS
Rank 3
Rank 3
Beiträge: 199
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Sendetiming Rundschreibdienst

#30

Beitrag: # 20161Beitrag BjoernS »

Fred, vielen dank für deine Auskünfte :thumbup:

Grüße


Björn
844767 twtr d
Antworten

Zurück zu „Dienste“