Projekt piTelex - Vorstellung

[Baderbahn]

Hallo Tasto,

die Instanz wird per Aufruf in der rc.local bei Boot automatisch gestartet.

screen -R funktioniert leider nicht.

Grüße,
Simon

[BjoernS]

Moin Simon,

die Instanz wird per Aufruf in der rc.local bei Boot automatisch gestartet.

Wenn du telex.py dort direkt startest, werden i.d.R. stdin/out/err abgehängt und du kannst nur noch im Log verfolgen, was passiert.

Wenn du screen benutzen willst, musst du telex.py "unter" screen aufrufen, z.B. mit

Code: Alles auswählen

/usr/bin/byobu-screen -d -m -S piTelex /home/pi/piTelex/telex.py

... oder gleich aus dem Verzeichnis systemd nach der dortigen README installieren, dann ist alles geregelt.

byobu und/oder screen sind vsl. nicht standardmäßig installiert (sudo apt install byobu screen).

byobu ist ein Wrapper, der screen etwas einfacher zu bedienen macht (screen-Veteranen wie tasto brauchen das nicht, ich bin aber zu bequem ). F2 für neuen Tab, F3/F4 zum Wechseln.

Grüße


Björn

[FredSonnenrein]

Hallo Björn,

Bei der Filter-Dimensionierung war mir wichtig, dass die jeweils andere Frequenz brauchbar unterdrückt wird.

Interessehalber, hast du das mit Hardware getestet oder hattest du ein konkretes Ziel wie "<-30 dB" o.ä.?

Nö.
Auf der ED1000 Karte ist ja eine brauchbare Gabelschaltung vorhanden, so dass das eigene Sendesignal schon etwa 3 dB unter dem Empfangssignal ist, am AD-Wandler also schon überwiegend das vom Fernschreiber gesendete Signal anliegt.
Und dass dann ein Filter 1. Ordnung schon -23 dB bringt, hat vollkommen gereicht.

Ich hatte dann noch per Excel die Berechnung simuliert und dann den Filter-Code noch auf dem AVR-Simulator getestet (ob die Rechenleistung reicht).

Beides mit Erfolg, dann war es zur ED1000 Firmware für den Atmel nicht mehr weit.

Viele Grüße,

Fred

[Z80User]

Hallo Guten Morgen,

seit ca. einer Woche kommen bei uns keine Fernschreiben mehr auf dem Drucker an .
Die Verbindung kommt zustande, der Text wird auch auf dem PiTelex Bildschirm angezeigt, jedoch springt der Drucker nicht an. Wenn wir jedoch auf dem FSG einen Anruf zum KLKL Verzeichnis tätigen, funktioniert alles ganz normal. Die Textausgabe erfolgt auf PiTelex und dem Drucker.

Ich habe zuvor vielleicht einen Fehler gemacht. Ich habe 2 Dateien für die Konfiguration, welche ich abwechselnd benutze. Darin werden die Anmeldedaten für unsere beiden FS gespeichet. Je nach verwendetem Gerät benenne ich die eine oder Andere Datei nach telex.json um. PiTelex war hier warscheinlich noch am laufen

Was mich wundert , das der Start des Druckers anscheinend garnicht erkannt wird. Funktionierte aber zuvor auch.

Hier der Log einer Lokal ausgelösten Verbindung zum KLKL Verzeichniss, der Drucker springt sofort an:

Code: Alles auswählen

2022-07-17 10:09:58,160 piTelex.txDevITelexClient [INFO]: connecting to Teilnehmerliste KLKL =a (telex.telephontechnik.d>
2022-07-17 10:09:58,240 piTelex.txDevITelexCommon [INFO]: Sending direct dial: '0'
2022-07-17 10:09:58,247 piTelex.txDevITelexClient [INFO]: connected
2022-07-17 10:09:58,252 piTelex.txDevITelexCommon [INFO]: Connection hint: i-Telex connection
2022-07-17 10:09:58,257 piTelex.txDevITelexCommon [INFO]: State transition: ST.DISCON=>ST.CON_INIT
2022-07-17 10:09:58,610 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_INIT=>ST.CON_TP_REQ
2022-07-17 10:09:58,617 piTelex.txDevMCP [INFO]: Printer start timer enabled
2022-07-17 10:10:03,620 piTelex.txDevMCP [WARNING]: Printer start attempt timed out, feedback simulation enabled
2022-07-17 10:10:03,722 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_TP_REQ=>ST.CON_TP_RUN
2022-07-17 10:10:03,730 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_TP_RUN=>ST.CON_FULL
2022-07-17 10:10:05,942 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 42, reset to 57
2022-07-17 10:10:06,975 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 48, reset to 60
2022-07-17 10:10:07,494 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 52, reset to 60
2022-07-17 10:10:08,019 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 55, reset to 60

Hier eine von außen eingehende Verbindung, wird alles korrekt auf PiTelex angezeigt, der Drucker bleibt aus...

Code: Alles auswählen

2022-07-17 10:01:28,863 piTelex.txDevITelexSrv [INFO]: 62.75.158.246:49404 has connected
2022-07-17 10:01:28,870 piTelex.txDevITelexCommon [INFO]: Connection hint: auto-detect enabled
2022-07-17 10:01:28,873 piTelex.txDevITelexCommon [INFO]: State transition: ST.DISCON=>ST.CON_INIT
2022-07-17 10:01:29,014 piTelex.txDevITelexCommon [INFO]: Detected ASCII connection
2022-07-17 10:01:29,017 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_INIT=>ST.CON_TP_REQ
2022-07-17 10:01:29,024 piTelex.txDevMCP [INFO]: Printer start timer enabled
2022-07-17 10:01:34,061 piTelex.txDevMCP [WARNING]: Printer start attempt timed out, feedback simulation enabled
2022-07-17 10:01:34,115 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_TP_REQ=>ST.CON_TP_RUN
2022-07-17 10:01:34,304 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as -25, reset to 1
2022-07-17 10:01:34,415 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_TP_RUN=>ST.CON_FULL
2022-07-17 10:01:34,828 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as -23, reset to 39
2022-07-17 10:01:35,348 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as -21, reset to 43
2022-07-17 10:01:36,387 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as -16, reset to 50
2022-07-17 10:01:37,434 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as -11, reset to 57

Nebenbei noch eine Frage zum Kennungsgeber. Ich habe den Eindruck, das bei der Abfrage des Kennungsgebers sowohl der KG der FS ausgelesen wird und PiTelex auch den simulierten ausgibt. Bei manchen anrufen ist unsere Kennung nicht nicht mehr lesbar. Kann man den in PiTelex abschalten? ist da die Zeile

Code: Alles auswählen

"wru_id": "4197113 advo d",

verantwortlich?


Wäre super, wenn mir jemand helfen könnte - ich möchte lieber nicht wissen, wer mir in dieser Zeit geschrieben hat Es scheint ja hier auch keine Fehlermeldung auf der Gegenseite zu geben.

Viele Grüße,
Horst

[Z80User]

Gibt es in irgend einer Datei noch einen tieferen Log, in dem man sehen könnte was da wirklich geschieht? Denke, den Fernschreiber kann man wirklich ausschließen, da ja ausgehende Verbindungen funktionieren.

Gruß,
Horst

[Z80User]

Hallo nochmal,

am PiTelex kann es nicht liegen. Habe eben mit unserem T100 einen weiteren Versuch gemacht. Nachrichten kommen einwandfrei an. Ich habe dabei leider festgestellt, das ich bei den letzten Versuchen die Schleifenspannung auf 50V reduziert habe. Das hat wohl nicht gelangt, um den Drucker zu starten. Arbeite jetzt wieder mit 85V - Klappt perfekt.

Viele Grüße,
Hiorst

[BjoernS]

Moin Horst,

bin mir nicht sicher, was jetzt noch aktuell ist, ich antworte einfach mal auf alles

Ich habe zuvor vielleicht einen Fehler gemacht. Ich habe 2 Dateien für die Konfiguration, welche ich abwechselnd benutze. Darin werden die Anmeldedaten für unsere beiden FS gespeichet. Je nach verwendetem Gerät benenne ich die eine oder Andere Datei nach telex.json um. PiTelex war hier warscheinlich noch am laufen

Das hat nur temporäre Auswirkungen. Dabei ein Hinweis auf Rolfs exzellente Überarbeitung der Doku, einfach mit -c <dateiname> starten.

Was mich wundert , das der Start des Druckers anscheinend garnicht erkannt wird. Funktionierte aber zuvor auch.
[...]

Code: Alles auswählen

2022-07-17 10:09:58,617 piTelex.txDevMCP [INFO]: Printer start timer enabled
2022-07-17 10:10:03,620 piTelex.txDevMCP [WARNING]: Printer start attempt timed out, feedback simulation enabled
2022-07-17 10:10:03,722 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_TP_REQ=>ST.CON_TP_RUN
2022-07-17 10:10:03,730 piTelex.txDevITelexCommon [INFO]: State transition: ST.CON_TP_RUN=>ST.CON_FULL
2022-07-17 10:10:05,942 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 42, reset to 57
2022-07-17 10:10:06,975 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 48, reset to 60
2022-07-17 10:10:07,494 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 52, reset to 60
2022-07-17 10:10:08,019 piTelex.txDevITelexCommon [INFO]: Acknowledge counter calculated as 55, reset to 60

Das funktionierte zuvor auch, da die Rückmeldesimulation eingeschaltet ist ("continue_with_no_printer" = true). Das bedeutet, selbst wenn der FS nicht anläuft, soll piTelex weitermachen, inkl. Rückmeldung "gedruckter" Zeichen durch das Hauptmodul MCP (für das i-Telex-Acknowledge-Telegramm). Ist die Option aus, wird die Verbindung bei nicht anlaufendem FS getrennt. Eingeschaltet ergibt sie eigentlich nur Sinn mit dem Archivmodul, oder wenn man das Screen-Modul aktiv benutzt, und mit dem Software-Kennungsgeber (siehe unten).

An der Stelle sieht man auch, dass dein FS dann doch anläuft, denn das Hardwaremodul schickt auch Rückmeldekommandos. Das i-Telex-Modul korrigiert den von zwei verschiedenen Absendern gemeldeten Zählstand fortlaufend, damit die Gegenstelle nicht durcheinander kommt.

Hier eine von außen eingehende Verbindung, wird alles korrekt auf PiTelex angezeigt, der Drucker bleibt aus...
[...]

Gleicher Fall wie oben, aus piTelex-Sicht -- deine Hardware erkennt nicht den Start des FS. Vermutlich wird die reduzierte Spannung die Ursache gewesen sein.

Nebenbei noch eine Frage zum Kennungsgeber. Ich habe den Eindruck, das bei der Abfrage des Kennungsgebers sowohl der KG der FS ausgelesen wird und PiTelex auch den simulierten ausgibt. Bei manchen anrufen ist unsere Kennung nicht nicht mehr lesbar. Kann man den in PiTelex abschalten? ist da die Zeile

Code: Alles auswählen

"wru_id": "4197113 advo d",

verantwortlich?

Ja, nochmal der Verweis auf Rolfs exzellente Arbeit:

• Die Option wru ist für den Software-Kennungsgeber. Wird die Option benutzt, macht piTelex folgendes: Wenn ein WerDa eingeht, wartet es auf einen eventuell vorhandenen Hardware-Kennungsgeber. Wenn der nach einer kurzen Zeit nicht reagiert, wird der Software-KG ausgelöst.
• ... außer wru_replace_always ist gesetzt. Dann wird der Software-KG immer -- bei jedem WerDa -- sofort ausgelöst und es rumst, wenn es noch einen in Hardware gibt.

Wer einen Hardwarekennungsgeber hat und die o.g. Simulation nicht benutzt, sollte die Option wru leer lassen!

Bzgl. der Logtiefe, hier gibt's drei Informationsquellen:

1. Zur Fehlersuche ist der schon gezeigte Error-Log gut. Die Module, an denen ich meine Finger hatte, haben i.d.R. eine gute Logtiefe und aus der Meldung kann man auf die Codestelle rückschließen, die dort wichtigen Parameter sollten in der Meldung eingebettet sein. Wenn man's genauer wissen will, kann man folgendes tun: In telex.py den Abschnitt

   Code: Alles auswählen

   # Default log level for all modules
   ERRLOG_LEVEL = logging.INFO
   #ERRLOG_LEVEL = logging.DEBUG

   suchen und das Doppelkreuz am Anfang der logging.DEBUG-Zeile entfernen. Achtung, der Error-Log kann dann je nach verwendeten Modulen relativ schnell wachsen.
2. Die Trace-Datei mit dem Log-Modul aktivieren, also in telex.json den Abschnitt mit "type": "log" finden und aktivieren ("enable" = true). Die Trace-Datei enthält alle Daten und Kommandos (ESC-*), die durch die zentrale Schleife laufen, in der richtigen Reihenfolge. Insbesondere lässt sich hier der Zeitablauf des FS-Anlaufs nachvollziehen.
3. Bei ED1000-Problemen lässt sich recv_debug.log aktivieren, dort werden die erkannten Signalpegel mitgeschrieben (die man dann auswerten kann, siehe Unterverzeichnis ED1000). Achtung, Datei wächst sehr schnell, nur zur Fehlersuche!
4. Auf Netzwerkebene lässt sich mit Wireshark gut arbeiten, Hilfsskripte dazu sind im Verzeichnis tshark (textbasierte Variante für Ferneinsatz, die erzeugten Dateien lassen sich mit der GUI anzeigen). Da ist auch ein Skript dabei, um alles 24/7 aufzuzeichnen.

Benutzt du eigentlich die ExperimentalFeatures-2022-01? Es gab ein Problem bei der Anlauf-Rückmeldung in txDevRPiTTY, das dort behoben ist.

Grüße


Björn

P.S.: Habe grad Probleme mit meinem Laptop, deshalb ist meine piTelex-Arbeit etwas verzögert.

[PA4557]

Ik krijg de Pi versie niet werkend op een pi 4B met 4Gb, ligt dat aan het feit dat deze pi versie niet ondersteund wordt ?

Groeten PA4557

[Z80User]

Hallo Björn,
vielen Dank für diese sehr ausführliche Beschreibung!

Ich habe jetzt mal alles so eingestellt, wie beschrieben. Dann werden wirklich nur Nachrichten empfangen, wenn der Drucker wirklich angelaufen ist - Schon Peinlich sowas!

In der Zeit von 22:00 - 8:00 ist der Fernschreiber per Funk Steckdose ausgeschaltet. Dann sollten in dieser Zeit eingehende Nachrichten abgewiesen werden.

Ich werde jetzt in den nächsten Tagen unseren 2. PiTelex mit ein paar Erweiterungen angehen. Wenn er fertig ist, werde ich hier natürlich berichten.

@Björn, Rolf und alle die da noch am coden sind:
Vielen vielen Dank nochmal für dieses großartige Projekt. Weiter so!

@all
Ich finde es einfach riesig, wie in dieser kurzen Zeit, seit ich im April mit unserem Telex hier angefangen habe immer wieder neue Benutzer und Geräte hinzukommen - Geräte, die nicht auf dem Schrott landen. Einfach großartig!!!

Viele Grüße,
Horst

[BjoernS]

Hi PA4557

Ik krijg de Pi versie niet werkend op een pi 4B met 4Gb, ligt dat aan het feit dat deze pi versie niet ondersteund wordt ?

I've translated your request to English, it'd be great if we could continue so as my Dutch is only very rudimentary.

A Pi 4B with 4 GB RAM should suffice. To further assist you however, we need a few details, like which interface do you employ, what modules do you use, are there any error messages on the console or inside the error log etc. Be sure to check the installation and configuration hints.

Best regards


Björn