Telexforum.de

Ich habe inzwischen das DHL Paket mit den Lochstreifen vorliegen, diese werden die Tage mit Thomas zusammen über seinen Rekorder aufgezeichnet und dann auf dem Dienste Server bereitgestellt.

ProjektTelefon hat geschrieben: ↑Fr 2. Okt 2020, 14:47 Ich habe inzwischen das DHL Paket mit den Lochstreifen vorliegen, diese werden die Tage mit Thomas zusammen über seinen Rekorder aufgezeichnet und dann auf dem Dienste Server bereitgestellt.

Ihr wollte die alle nochmal einlesen? Wozu habe ich mir dann die Mühe gemacht?
Ich habe die teilweise korrigiert. Das wollt ihr jetzt alles nochmal machen bzw. die Fehler drinlassen obwohl fehlerkorrigerte Versionen vorliegen?

So, jetzt mische ich mich auch nochmal ein.
Als die von Detlef eingelesenen Baudotarts von Thomas mal lokal ausprobiert worden sind, schrieb er mich an das etwas nicht stimmen kann. Die Arts werden nicht richtig gedruckt. Daraufhin habe ich die Dateien mal angesehen, auch bei mir konnte man kaum erahnen was der Druck werden soll. Da es bei Detlef aber anscheinend funktioniert, muss die Datei so defekt nicht sein. Es blieb nur ein Punkt mit hoher Wahrscheinlichkeit übrig, der sich nach Betrachtung des Binärfiles und Vergleich mit den (gottseidank) mitgelieferten Bildern schnell bewahrheitete.
Detlef hat die Baudotdaten schlichtweg an der falschen Stelle mitgeschnitten, macht diesen (Gedanken) Fehler in seiner SW bei der Wiedergabe nochmal und schon passt es nach aussen wieder. Falsche Stelle markiert hier den Lesepunkt im Empfangsprozess. Bei i-telex werden die Baudotdaten vom FS verkehtrum von der Ethernetseite übertragen und werden auf der Empfangsseite dann wieder zurüchgedreht (siehe Protokoll). Wie immer Detlef das eingelesen hat, diese Funktion hat leider fälschlicherweise zugeschlagen und ein Blick in den Hexeditor (siehe Bilder) zeigt, das die Zeichenwerte bei bekannten Zeichen (vom Bild) dem gespiegelten Wert entsprechen. Hätte Detlef das nach dem ersten File doch bloß mal mir einem neutralen Editor gecheckt. Das ist ein allseits bekanntes Phänomen, das wenn man in seinem Mikrokosmos entwickelt, schnell den Output erreicht aber interne Vorgänge übersieht. Fatalerweise fällt der Effekt nicht unbedingt auf wenn man immer die alten eigenen Sourcen neu arrangiert. Das es jetzt mir dem experimentellen Baudotserver geht, zeigt nochmals das die Platform in der Tat nach aussen funktioniert, intern aber mit gedrehten Daten operiert. Anders ist der Umstand der gedrehten Zeichen kaum zu erklären. Ich unterstelle Detlef hier einen ungewollten Flüchtigkeitsfehler und die investierte Zeit ist anerkennenswert. Ausserdem hat Detlef im #3 Artikel hier definitiv erklärt, die Datei muss bit für Bit mit dem Lochstreifen übereinstimmen. Detlef, das hier ist kein Vorwurf, ich habe die Spiegelfunktion auch langsam reengineert, da sie damals nirgens erwähnt war. Fakt ist, die Files sind in dieser Form nicht in dem Baudotserver von Thomas einsetzbar. Fatalerweise tauschen sich durch das Spiegeln die für Baudoarts extrem wichtigen Zeichen ZL und WR. Das alles rauszubekommen und zu dokumentieren dauert leider etwas, und so kann ich erst jetzt eine fundierte Aussage dazu machen sonst hätten wir schon früher etwas dazu gesagt.
In den Bildern ist die Hexdatei, das Sollbild und die Spiegeltabelle zu sehen. Versucht selbst die Hexdaten mit dem Bild in Einklang zu bringen, es wird nur über die Spiegelfunktion gelingen. Das Telexbild zeigt den durch eigentlich WR , aber nach ZL gewandelte Steuerzeichen gestreckten Verlauf.
Detlef, ich hoffe Du siehst das hier sportlich und eher als Unterstützung zur Ursachensuche.

Gruß
Willi

In welcher Reihenfolge man die Bits abspeichert, ist doch reine Definitionssache. Das ist keine Frage von richtig oder falsch. Das Format in den ZIP-Files ist das Format, das WinTlx verwendet. Das stand doch auch dabei.

Ich hatte Thomas ja angeboten, die Daten in dem Format zu liefern, wie er sie benötigt.
Sowohl per PN als auch hier im Thread: viewtopic.php?p=20644#p20644

Das wäre für mich eine Sache von wenigen Minuten gewesen, die Daten zu drehen. Warum habt ihr denn nicht einfach mal nachgefragt?

Achso, soll ich euch die Files im gewünschen Format schicken?

Hallo Detlef,
für mich hat ein Baudotzeichen mit dem Wert z.B. 1 (E/3) aus dem ITA2 immer den Wert 1, und nicht 16, zumindest an den Endpunkten. Dazu zählt der Lochsteifen wie auch eine Datei(Abbild). Schon umständlich genug das man das auf Eth-Traces umrechnen muß. Das Du das "gespiegelte" Format intern benutzt, ist Deine Sache, hätte ich aber nicht gedacht. Aber jeder wie er es mag.
Dann ist die Ursache ja jetzt klar und für mich erledigt.
Gruß
Willi

detlef hat geschrieben: ↑Fr 2. Okt 2020, 14:02 Ich hab mal den Shutdown() eingebaut. Das ist aber vom Aufbau der Klasse unlogisch, dass man bei einer High-Level-Klasse irgendwelche Low-Level-Funktionen aufrufen muss. Aber was ist bei Microsoft schon logisch.

Habe nochmal ausprobiert (gleiches Verhalten immer noch) und nachgelesen. Die Hohe Schule des Verbindung-Schließens ist wohl ("half-close"):

1. Den Sendekanal schließen: clientInstanz.Client.Shutdown(SocketShutdown.Send);
2. Dann den Empfangskanal leerlesen auf üblichem Wege; sobald 0 zurückkommt (oder auf höheren Ebenen vmtl. eine Exception) sind alle Daten weg
3. Den Empfangskanal schließen: clientInstanz.Client.Shutdown(SocketShutdown.Receive);
4. Den Socket schließen: clientInstanz.close();

Die Specs verbieten es aber m.W. nicht explizit, eine Verbindung "hart" zu schließen. Das ist dann eine Art antisoziales "Und tschüss". Ich hoffe das hilft dir weiter, ich probiere gerne nochmal, wenn du weiterbasteln willst.

Wegen des Dateiformats für die Baudot-Art: Gibt es denn eine "offizielle" Spezifikation, wie herum die Bits in der Datei zu stehen haben? M.E. ist das eine unentscheidbare Debatte wie big-endian oder little-endian, Pizza oder Pasta, Kaffee oder Tee, ...

Grüße & schönes Wochenende


Björn

Dieses Problem ist ja in der Informatik nicht ganz neu
https://de.wikipedia.org/wiki/Byte-Reihenfolge
https://de.wikipedia.org/wiki/Bit-Reihenfolge

Sorry Willi, für das Missverständnis. Ich war einfach davon ausgegangen, das wir über das Format nochmal sprechen, wenn ihr die Files einlest.
Ich wusste ja überhaupt nicht, welches Format ihr auf dem Server verwendet. Kann ja auch sein, dass die Daten im ASCII-Format vorliegen und beim Senden nach Baudot konvertiert werden.

Meine Idee war eigentlich, euch die Daten so zu liefern, wie ihr sie benötigt, damit ihr sie ohne Aufwand einbinden könnt.

BjoernS hat geschrieben: ↑Fr 2. Okt 2020, 17:23 Wegen des Dateiformats für die Baudot-Art: Gibt es denn eine "offizielle" Spezifikation, wie herum die Bits in der Datei zu stehen haben? M.E. ist das eine unentscheidbare Debatte wie big-endian oder little-endian, Pizza oder Pasta, Kaffee oder Tee, ...

Meines Wissens gibt es nur eine Spezifikation, in welcher Reihenfolge die Bits gesendet werden. ITA2 ist ja ein Protokoll und kein Datenformat. Aber wenn es dazu etwas gibt, würde mich das sehr interessieren.
In jedem Byte die oberen 3 Bit frei zulassen, ist ja auch schon eine Konvention. Man könnte die Bits auch nahtlos auffüllen. Früher hätte man das auch gemacht um wertvolle Bytes einzusparen. Ist aber etwas umständlig zu schreiben und zu lesen.

Vermutlich würde ich das heute auch anders herum kodieren, weil das intuitiver. Aber aus irgendeinem Grund habe ich das damals so gemacht und wenn man ein Programm mal freigelassen hat, ist es schwierig, solche Formate nochmal zu ändern. Die Anwender wären darüber wenig erfreut.

Hallo Willi und Detlef,

wenn ich mich hier zu Wort melde, dann in der Hoffnung mit ein paar Informationen die Wogen zu glätten und nicht um Öl ins Feuer zu gießen.

Die ITA2 (CCITT-2, Baudot-Murray-Code) bezieht sich auf die Reihenfolge der übertragenen Bits (Datenschritte) aber nicht auf die Wertigkeit. Bei einen 'E' (bzw. '3') wird erst eine 1 (Stromschritt) und dann 4 mal 0 (Pausenschritt) übertragen.
Die Zuordnung der Wertigkeit kann auf zwei Weisen erfolgen - leider wurden auch beide verwendet.

Geht man von einem UART (Serielles Interface im Computer) aus, wird das zuerst übertragene Zeichen als LSB (1) gewertet und das letzte Bit als MSB (16). Somit wird ein 'E' zur Zahl 1.
Beim i-Telex-Protokoll wird das zuerst übertragene Zeichen als MSB (16) gewertet. Somit wird ein 'E' zur Zahl 16.

Es gibt kein richtig oder falsch bei der Wertigkeit - man muss nur immer bei der Definition einer Übertragung/Speicherung angeben nach welchem Standard (UART, i-Telex) man überträgt.
Im Wiki (https://wiki.telexforum.de/index.php?title=ITA2) sind deshalb auch beide Schrittreihenfolgen aufgeführt um einfacher den entsprechenden Binärcode zu finden.