Projekt piTelex - Vorstellung

[MCMLXXV]

Moin!

Noch ne Frage: Warum braucht man eigentlich für ED1000 ne externe Soundkarte? Der Pi hat doch schon Sound on board?

Der passende Eingang fehlt beim Pi (Mikrofon/Line in). Außer du hast eine reine Empfangsmaschine, wenn du auf die Störungserkennung verzichtest wäre das möglich

Oha - echt? ich dachte echt dass das ein Kombi-Port wäre mit Mikrofon und Ausgang R/L in einem Stecker. Ich wusste echt nicht, dass der Pi keinen Audio-Eingang hat.....

[obrecht]

Ich hätte da mal gern ein anderes Problemchen...

Vor einiger Zeit gab's mal einen BugFix für piTelex, der bewirkte, dass die Fehlerstatus beim Verbindungsaufbau wie 'occ','df','nc' usw. auch tatsächlich am FS abgedruckt wurden. Vorher blieb der FS einfach stumm und piTelex kehrte nach Ablauf eines TimeOuts kommentarlos nach Z->ZZ zurück.
Über diese Komplettierung des Funktionsumfangs war ich sehr erfreut, weil es auch Fehlverbindungen zu erkennen erlaubt.
Seit kurzem (leider weiß ich nicht mehr genau, mit welchem Patch-Stand das auftauchte) tut's diese Funktion bei den Maschinen mit pi-TW39 nicht mehr, sie sind also in den "stummen" Zustand zurückgefallen; bei der Maschine mit pi-V.10 werden die Meldungen aber nach wie vor korrekt gedruckt. Alle Maschinen haben bis auf die unterschiedliche Konfig der Schnittstellen (RPiTTY_FS200_V10 bzw. RPiTTY) dieselbe SW-Version, nämlich 'ExperimentalFeatures-2022-01'.

Hat jemand ähnliche Erfahrungen bzw hat jemand eine Idee, woran das liegen könnte? Schonmal vielen Dank.

[Z80User]

Krass, nur der Inhalt geshreddert oder komplett kaputt? Mir ist das bisher nie passiert, mein Pi ist schon öfters mal unsanft aus der Steckdose gezogen worden ... aber mit Journal-Dateisystem kann eigentlich nicht allzu viel passieren, dachte ich.

Bzgl. des Herunterfahrens gibt es auch eine Systemoption. In /boot/config.txt muss das dtoverlay-Modul gpio-shutdown aktiviert werden (siehe /boot/overlays/README oder hier), dann kann man das Herunterfahren mit einem GPIO-Pin auslösen. Hilfreich dabei ist noch, die grüne LED umzubelegen von "Kartenzugriff" auf "Pi ist am laufen", dann sieht man eindeutig, wann er heruntergefahren ist: "dtparam=act_led_trigger=default-on"

Es gab glaube ich auch ein fertiges Zusatzmodul dafür, finde ich aber nicht mehr.

Grüße


Björn

Hallo,
habe herausgefunden, das die Boot Partition geshreddert wurde. Ich habe das sterben genau 1x live erlebt, Datei /boot/config.txt editiert, keine wesentliche Änderung gemacht und gespeichert. Danach zufällig nochmal geöffnet nichts mehr drin . Ein aufruf von raspi-config schrieb dann genau eine Zeile, die Änderung in die Datei. Nach dem ordnungsgemäßen runterfahren wollte ich die defekte Datei auf dem PC wieder einspielen - gesamte Karte nicht mehr lesbar.

Habe jetzt eine alte 4Gb Karte genommen - konnte den Fehler bis jetzt nicht wieder provozieren.

Mit GPIO Shutdown war ein Super Link - Danke! Ich habe mit dem Raspi schon ewig nichts mehr gemacht. Kannte daher nur die Version mit dem Script, welches im Hintergrund einen Pin Scannt und dann den Shutdown auslöst. Werde noch die ACT LED nach außen führen Ext. ACT LED

Die piTelex LED RT/GN habe ich auch mittlerweile angeschlossen - da sieht man dann schön, was piTelex gerade macht.

Sind dann wenn es fertig ist 5 Status LED's: 5V / rt / gn / SD / STOP

Werde heute Abend eine kleine Platine machen und dann gibt, wenn ich es schaffe ein paar Bilder.

Gruß,
Horst

[BjoernS]

Hallo Rolf!

Vor einiger Zeit gab's mal einen BugFix für piTelex, der bewirkte, dass die Fehlerstatus beim Verbindungsaufbau wie 'occ','df','nc' usw. auch tatsächlich am FS abgedruckt wurden. Vorher blieb der FS einfach stumm und piTelex kehrte nach Ablauf eines TimeOuts kommentarlos nach Z->ZZ zurück.
Über diese Komplettierung des Funktionsumfangs war ich sehr erfreut, weil es auch Fehlverbindungen zu erkennen erlaubt.
Seit kurzem (leider weiß ich nicht mehr genau, mit welchem Patch-Stand das auftauchte) tut's diese Funktion bei den Maschinen mit pi-TW39 nicht mehr, sie sind also in den "stummen" Zustand zurückgefallen; bei der Maschine mit pi-V.10 werden die Meldungen aber nach wie vor korrekt gedruckt. Alle Maschinen haben bis auf die unterschiedliche Konfig der Schnittstellen (RPiTTY_FS200_V10 bzw. RPiTTY) dieselbe SW-Version, nämlich 'ExperimentalFeatures-2022-01'.

Das klingt seltsam, da würde ich gerne mal nachschauen. Kannst du den Fehler reproduzieren und mir den entsprechenden Auszug des Error-Log und von data.log schicken? Das würde mir sehr helfen.

Zur Version: Der Entwicklungszweig ExperimentalFeatures_2022-01 schreitet kontinuierlich voran, der Hash des aktuellen Commits macht es eindeutig. Wenn du per git geklont hast, wird der automatisch beim Start in den Log geschrieben.

Danke und Grüße


Björn

[BjoernS]

Oha - echt? ich dachte echt dass das ein Kombi-Port wäre mit Mikrofon und Ausgang R/L in einem Stecker. Ich wusste echt nicht, dass der Pi keinen Audio-Eingang hat.....

Haben sich viele schon den Mund drüber zerfetzt. Die Entwickler wollten neben Audio L/R lieber ein Komponenten-Videosignal drauflegen. Sehr gut für Retro-Anwendungen.

Grüße


Björn

[BjoernS]

Hallo Dieter!

habe herausgefunden, das die Boot Partition geshreddert wurde. Ich habe das sterben genau 1x live erlebt, Datei /boot/config.txt editiert, keine wesentliche Änderung gemacht und gespeichert. Danach zufällig nochmal geöffnet nichts mehr drin . Ein aufruf von raspi-config schrieb dann genau eine Zeile, die Änderung in die Datei. Nach dem ordnungsgemäßen runterfahren wollte ich die defekte Datei auf dem PC wieder einspielen - gesamte Karte nicht mehr lesbar.

Vermutung: Die Karte war am Ende. Flashkarten können ja nur endlich oft wiederbeschrieben werden. Sie haben dann noch eine kleine Reserve an frischen Speicherzellen, aber wenn die aufgebraucht ist, ist es vorbei. Deshalb benutze ich dafür gerne Sandisk High Endurance (für Langzeit-Videoaufnahmen). Und regelmäßiges Backup per rsync.

Ansonsten bin ich gespannt auf die Bilder

Grüße


Björn

[Z80User]

So und hier wie versprochen die Bilder:

img2.jpg

img1.jpg

img3.jpg

Ich habe mich beim Ausgang für die Stromschleife für Bananenstecker entschieden, da hier gerade für Testzwecke mal schnell ein Multimeter angeschlossen werden kann und ich die Buchsen noch vorrätig hatte.

Zu den LED's:
- Rot und grün werden direkt von piTelex gesteuert und signalisieren den Betrieb A / WB / WBA und C.
- Gelb ist die Power LED mit Heartbeat Funktion nach aussen geschaltet. Sobald der Linux Kern läuft, Blinkt diese.
- Blau ist die HDD Lampe, beim Zugriff auf die SD Karte leuchtet diese
- Weiß ist die HALT Lampe, wenn der Raspi den Halt Zustand erreicht hat, also ordnungsgemäß heruntergefahren wurde, geht diese an.

Der Taster fordert das Herunterfahren per GPIO Leitung an.

Die LED / Taster Funktionen werden in der Datei /boot/config.txt den entsprechenden GPIO Pins zugeordnet. An dieser Stelle nochmal Danke an Björn für den Link

Viele Grüße,
Horst

[obrecht]

Hallo Rolf!

Das klingt seltsam, da würde ich gerne mal nachschauen. Kannst du den Fehler reproduzieren und mir den entsprechenden Auszug des Error-Log und von data.log schicken? Das würde mir sehr helfen.

Zur Version: Der Entwicklungszweig ExperimentalFeatures_2022-01 schreitet kontinuierlich voran, der Hash des aktuellen Commits macht es eindeutig. Wenn du per git geklont hast, wird der automatisch beim Start in den Log geschrieben.

Danke und Grüße


Björn

Hallo Björn,
wegen der ständigen Weiterentwicklung des Zweigs werd ich mal einen komplett frischen clone aufsetzen, meine aktuelle telex.json dazupacken und dann mal testen.
Funzt es, alles gut, ansonsten schick ich dir die Logs.
Danke für deine Bereitschaft zu helfen!

[Z80User]

Falls es interessiert, habe ich hier den Schaltplan für meinen piTelex mal gezeichnet.

ACHTUNG LEBENSGEFAHR! -- DIE SCHALTUNG ARBEITET MIT NETZSPANNUNG!

Die Auslegung des Trafos, des Gleichrichters und des Reglers muss auf jeden Fall mit der Stromaufnahme des verwendeten RaspberryPi abgestimmt werden, desshalb habe ich für die angegebenen Bauteile keine Werte angegeben. Einen 1:1 Nachbau kann ich daher nicht empfehlen.

Die Netzspannung wird über Sicherung und 2-Poligem Netzschalter an den Trafo geführt. Eine der beiden Sekundärwicklungen versorgt über Gleichrichter, Ladeelko und Schaltregler den Raspberry Pi mit 5VDC. Achtung! Ein normaler 7805 Regler würde bei 20V am Eingang nicht lange überleben. Auch ist die Verlustleistung mit P = 15V * 2A = 30W etwas ein klein wenig zu viel. Die 20V am Ladeelko können wahlweise über Jumper JP2 zur Linienspannung hinzu addiert werden. Die zweite Sekundär Wicklung versorgt eine "Delon" Schaltung zur Spannungsvervierfachung. Über JP1 kann wahlweise eine Verdopplung oder vervierfachung ausgewählt werden. Die Widerstände R1/R2 bilden einen Spannungsteiler, damit Fertigungsschwankungen an den Elkos C5/C6 kompensiert werden, wenn nur die Verdopplungs Stufe gewählt ist.

Somit ist es möglich Linienspannungen von 50 - 70 - 100 und 120V zu wählen. Diese wird dann der piTelex Platine zugeführt.

Die LED Ansteuerung über die GPIO's ist, denke ich selbsterklärend. Hier ist es nur wichtig, die Widerstände den verwendeten LED's anzupassen. Den Taster habe ich sicherheitshalber über 100 Ohm an den GPIO gelegt - falls der GPIO als Ausgang definiert wurde, wird dieser nicht gleich beim Druck der Taste zerstört.

Softwareseitig müssen dann in der Datei "telex.json" unter der Rubrik "RPiCtrl" die Status LED's rot / grün den GPIO's 20 und 21 zugeordnet werden.
In der Datei "/boot/config.txt" müssen dann folgende Zeilen eingefügt werde:

Code: Alles auswählen

#GPIO für HALT Anzeige
dtoverlay=gpio-poweroff,gpiopin=24

#GPIO Eingang für manuellen Shutdown
dtoverlay=gpio-shutdown,gpio_pin=25,active_low=1,gpio_pull=up

#Status LEDs an GPIO weiterleiten
dtparam=act_led_gpio=12
dtparam=pwr_led_gpio=16,pwr_led_trigger=heartbeat

Gruß,
Horst

PiTelex.pdf

[WolfHenk]

Für das fertige Raspi-Image kann ich auf meinem Server Speicherplatz zur Verfügung stellen.
Es sind dort noch einige TB frei...