Seite 19 von 46
Re: Projekt piTelex - Vorstellung
Verfasst: Di 14. Jun 2022, 18:52
von Z80User
Hallo Björn,
wie sieht das bei piTelex generell aus? Ist die Software prinzipiell in der Lage, 2 TW39 Schnittstellen zu bedienen? Ich dachte da gerade mal so an eine Karte auf der Karte und über Jumper einstellbare GPIO Leitungen für TX, RX und RELAIS. GPIO's sind im Prinzip ja genug vorhanden.
Wäre doch schön, wenn man sein Zweitgerät auch noch mit anschließen könnte, ohne gleich den ganzen Aufbau doppelt zu haben - wo es im Moment eh keine bezahlbaren Raspis gibt.
Nebenbei:
Die Software läuft dank Deiner Unterstützung mittlerweile sehr gut auf meinem Raspi B+
. Wir haben mittlerweile sogar die ersten Telex Nachrichten mit einem Lo133 an die Außenwelt gesendet, nachdem der Optokoppler wegen defekt durch Überstrom getauscht wurde. Ist aber erstmal wieder Offline. Der Motorfilter und eine Kriechstrecke nach Erde sind dann doch noch etwas zu viel Risiko. Die Fehler müssen wir am Wochenende noch suchen und hoffentlich auch finden.
Viele Grüße,
Horst
Re: Projekt piTelex - Vorstellung
Verfasst: Mi 15. Jun 2022, 11:50
von BjoernS
Moin Horst,
um mehrere FS an einem Pi zu betreiben, kannst du prinzipiell mehrere piTelex-Instanzen nebeneinander laufen lassen. Wenn du die lokale userlist.csv entsprechend anlegst und zwischen den Instanzen verlinkst, kannst du dir sogar einen lokalen Nummernkreis implementieren, ähnlich der i-Telex-Hardware. Beschränkungen ergeben sich aus zwei Faktoren, EA-Möglichkeiten und CPU-Last.
Die Instanzen sollten natürlich nicht auf dieselben GPIO-Pins zugreifen, d.h. die Konfigurationen sollten konfliktfrei sein.
Die CPU-Last ist meiner Erfahrung nach nur mit ED1000 wesentlich, da dort die FSK-Demodulation gerechnet werden muss (beim Raspi 4B ca. 30% bei aktiver Leitung, allerdings ist da glaube ich noch Optimierungspotential). Einfache GPIO-Operationen bei TW39 erzeugen keine vergleichbare Last.
Freut mich ansonsten zu lesen, dass es bei dir funktioniert
Grüße
Björn
Re: Projekt piTelex - Vorstellung
Verfasst: Mi 15. Jun 2022, 12:04
von tasto
BjoernS hat geschrieben: ↑Mi 15. Jun 2022, 11:50
Die Instanzen sollten natürlich nicht auf dieselben GPIO-Pins zugreifen, d.h. die Konfigurationen sollten konfliktfrei sein.
An welcher Stelle werden eigentlich die genutzten GPIO-Pins konfiguriert?
Re: Projekt piTelex - Vorstellung
Verfasst: Mi 15. Jun 2022, 12:34
von Z80User
Hallo,
wird alles in der Datei 'telex.json' konfiguriert.
Beispiel GPIO 17+27 sind für TX und RX
Code: Alles auswählen
"RPiTTY": {
"type": "RPiTTY",
"enable": true,
"mode": "TW39",
"pin_txd": 17,
"pin_rxd": 27,
"inv_rxd": false,
"pin_relay": 22,
"inv_relay": false,
"pin_online": 0,
"pin_dir": 0,
"pin_number_switch": 6,
"baudrate": 50,
"coding": 0,
"loopback": true
},
Gruß,
Horst
Re: Projekt piTelex - Vorstellung
Verfasst: Mi 15. Jun 2022, 13:02
von obrecht
... wobei die Bezeichnung "pin_*" ungünstig ist, denn es sind nicht die fortlaufenden pin-Nummern des GPIO-Headeres gemeint, sondern die GPIO-Nummern. "gpio_*" wäre sprechender, aber so ist es nun mal. Wenn man's weiß, ist es ja ok.
Re: Projekt piTelex - Vorstellung
Verfasst: Mi 15. Jun 2022, 17:28
von JoeyD
Bjoern,
This begs a question when using
"RPiCtrl": {
"type": "RPiCtrl",
"enable": false,
"pin_number_switch": 0,
"pin_button_1T": 8,
"pin_button_AT": 0,
"pin_button_ST": 0,
"pin_button_LT": 0,
"pin_button_U1": 12,
"pin_button_U2": 16,
"pin_button_U3": 20,
"pin_button_U4": 21,
"pin_LED_A": 0,
"pin_LED_WB": 0,
"pin_LED_WB_A": 9,
"pin_LED_status_R": 23,
"pin_LED_status_G": 24
},
I use this section only for "pin_button_1T". Can I make the UNUSED sections "0" and in a proposed "second instance of PiTelex" reallocate the unused pins?? Example if I make 12,16,20,21,9,23,24 all 0 I can then use them in place of 17,27,22 and 6 in another instance of PiTelex??
This is intriguing and the second instance would this just need to be a "Second User" like say user1@pi-Telex and user2@pi-Telex or does it need to be a seperate directory also \pitelex1 and \pitelex2???
Thanks
Danke
Joe
Z80User hat geschrieben: ↑Mi 15. Jun 2022, 12:34
Hallo,
wird alles in der Datei 'telex.json' konfiguriert.
Beispiel GPIO 17+27 sind für TX und RX
Code: Alles auswählen
"RPiTTY": {
"type": "RPiTTY",
"enable": true,
"mode": "TW39",
"pin_txd": 17,
"pin_rxd": 27,
"inv_rxd": false,
"pin_relay": 22,
"inv_relay": false,
"pin_online": 0,
"pin_dir": 0,
"pin_number_switch": 6,
"baudrate": 50,
"coding": 0,
"loopback": true
},
Gruß,
Horst
Re: Projekt piTelex - Vorstellung
Verfasst: Do 16. Jun 2022, 14:28
von obrecht
Hi Joe,
I think you can. This is what Björn meant with
Die Instanzen sollten natürlich nicht auf dieselben GPIO-Pins zugreifen, d.h. die Konfigurationen sollten konfliktfrei sein.
Pins which are not "occupied" by instance A can be used by instance B.
And telex.py has a config option "-c" to specify the configuration file (default ./telex.json).
You could try to start instance A with e.g.
and instance B with
In my opinion, there's no need for different users; but I think you need to specify separate ports for each process (= A-telex.json and B-telex.json) in order to have a non-conflicting i-Telex config (and, if activated, different logfiles and so on).
Good luck... (hoping that Björn or Jochen won't call me stupid...)
Re: Projekt piTelex - Vorstellung
Verfasst: So 19. Jun 2022, 07:08
von JoeyD
obrecht,
Danke!!!! Das ergebnis war besser als erwartet!
Ich hatte keine Probleme mit der Einrichtung.
This works! I assigned a new port 2345, and I am using
Pins, 16(TX),20(RX),21(Relay) and 9(Dial) it still logs the individual calls for both instances.
The Siemens 68D will be able to make outgoing and incoming calls!!
The machine prints fine locally but I have 1 small problem on transmitting to the called machine but I think the issue is the optocoupler.
When I type the machine prints what I type on the local printer OK, but the called machine has a drop of the 5th bit.
Printing RYRYRY gives RSRSRS on the called machine but the local prints RYRYRY the English word QUICK gives UUICK
This is not a problem with either FS machine but a problem in the Pi-Telex with either pin 20 or the optocoupler.
If I use the Keyboard on the PI the called machine prints fine so its probably the optoisolator or pin 20.
Thanks again!!
Joe
obrecht hat geschrieben: ↑Do 16. Jun 2022, 14:28
Hi Joe,
I think you can. This is what Björn meant with
Die Instanzen sollten natürlich nicht auf dieselben GPIO-Pins zugreifen, d.h. die Konfigurationen sollten konfliktfrei sein.
Pins which are not "occupied" by instance A can be used by instance B.
And telex.py has a config option "-c" to specify the configuration file (default ./telex.json).
You could try to start instance A with e.g.
and instance B with
In my opinion, there's no need for different users; but I think you need to specify separate ports for each process (= A-telex.json and B-telex.json) in order to have a non-conflicting i-Telex config (and, if activated, different logfiles and so on).
Good luck... (hoping that Björn or Jochen won't call me stupid...)
Re: Projekt piTelex - Vorstellung
Verfasst: So 19. Jun 2022, 14:03
von BjoernS
Hi Joey
Happy to hear it works for you!
On a side note, you can just omit those entries in RPiCtrl configuration that you don't need (they all default to 0). So in your config you may use
Code: Alles auswählen
"RPiCtrl": {
"type": "RPiCtrl",
"enable": false,
"pin_button_1T": <your-value>
},
Rolf (obrecht) is correct, you can use the same directory and user, and thanks for the remark that the listening port must be unique. I'd also advise to set up different error log and trace file paths (if used) in both configuration files, otherwise both instances will write to the same files and everything will be mixed up.
Have fun
Björn
Re: Projekt piTelex - Vorstellung
Verfasst: Di 21. Jun 2022, 19:01
von Baderbahn
Guten Abend in die Runde,
gerade habe ich den Pi ohne Bildschirm usw. vom Hauptrechner aus per SSH angesprochen, was auch problemlos klappt.
Alsdann PiTelex gestertet und testweise den Lokalmodus {LT} probiert, mit folgendem Ergebnis:
FS will anlaufen, stoppt aber sofort, im Terminal X-Fach folgende Meldung:
Code: Alles auswählen
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred
Nach einiger Recherche habe ich gefunden, daß das an Buffergrößen liegen könnte, also habe ich da in den ALSA-Config-Files herumgespielt, jedoch ohne Ergebnis.
Mit den Pegeln im ALSA-Mixer habe ich auch gespielt - ebenfalls Ergebnislos...
Hast Du da eine Idee, @BjoernS ?
Vielen Dank und viele Grüße,
Simon