Posts by Tantal

Nach ausgiebigen Tests kann ich nun bestätigen, dass die Soundkarte wunderbar mit Audacious funktioniert.

Ärgerlich sind immer mal Programmabstürze bzw. Freezes, wenn gerade mal Kodi etwas spinnt oder jemand über ein Stromkabel zum Audiobunker gestolpert ist. Dann reißt das leider oft das ganze System in Mitleidenschaft.

Erfreulicherweise kann ich mich bisher über keine Abstürze im laufenden Betrieb bei Audacious beklagen. Stundenlanger Musikgenuss und Straßenbeschallung sind kein Problem.

Kodi scheint immer mal wieder ein Problem bei Youtube zu haben. Ob das jetzt am Addon oder der Soundkarte liegt, kann ich nicht sagen. Jedenfalls stieg es gleich in der ersten Stunde mit einem freeze bei der USB-Audioausgabe aus.

Filme schaue ich generell nur von BluRay über HDMI, d.h. auch die Audioausgabe darüber.

Verwunderlich sind nur Spannungseinbrüche beim Raspi-Originalnetzteil und Soudausgabe über USB, obwohl alle Kabel ordentlich angeschlossen sind (Display und Raspi separat) und sogar die externe Festplatte mit eigenem Netzteil daherkommt.

Das lässt mich stark an der Stabilität des Systems zweifeln. Notfalls werde ich noch mal meine Relaisschaltung rausbauen und dann verfolgen, wie es weitergeht.

Weiterhin werde ich mal zukünftig ein anderes, viel schwereres (=besseres?) China-Netzteil testen. War teurer als das Original-NT, ich bin aber zuversichtlicher, was die Spannung betrifft.

Wir werden sehen.

Einen schönen 1. Maifeiertag

Was steht denn überhaupt in deiner /boot/config.txt?

Ich habe lediglich:

enable_uart=0
dtparam=audio=on
gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=256
overscan_scale=1
#Rotation für das OneNineDesign-Displaygehäuse
lcd_rotate=2

in meiner Datei stehen und es funktioniert alles wunderbar. Außerdem verwende ich im raspi-config den legacy-Treiber.

Allerdings habe ich nicht das OSMC, sondern das normale Stretch installiert. Ich weiß nicht, ob dort die Dateistruktur dieselbe ist.

Nach einigen Wochen habe ich mir nun noch eine USB-Soundkarte zugelegt.

Jetzt ist wirklich Feierabend, Leute!

Meine Schaltung funktioniert nach wie vor, aber ich rate nun jedem, der mal dasselbe oder Ähnliches wie ich vor hat, tu es mit einem mechanischen Taster.

Die Soundkarte zieht nun noch ein bisschen mehr Saft und ich stelle nun sporadische Abstürze bzw. freezes meines Raspbian fest. Mal nach ner halben Stunde, mal nach 10 Minuten, mal nach 3 Stunden. Da die Stromkurve meines Reed-Relais gegenüber der Temperatur wahrscheinlich eher exponentiell verläuft - obwohl ich keine tatsächliche Stromaufnahme messen konnte -, das Display seinen Tribut fordert, manchmal auch der 5V-Lüfter saugt und das WLAN permanent eingeschaltet ist, nehme ich stark an, dass die Stromzufuhr über den Raspberry an sich hinkt.

Ausdrücklich sei nicht das Netzteil erwähnt, weil ich alles über die Raspberry-Platine laufen lasse.

Ich habe nun ein Micro-USB-Y-Kabel rangetütelt und bisher keinen Absturz mehr festgestellt, werde das aber weiterhin beobachten.

Das alles gibt mir zwar eine ganz schöne Ohrfeige, weil alle Bastelei trotz Minimalistik und Funktionalität umsonst war, aber zumindest weiß ich jetzt, wo der Raspberry an seine Grenzen stößt und ich kann mich evtl. zukünftig mal auf ein anderes Projekt konzentrieren, weil ich nun wieder einige Versorgungspins frei bekomme.

Ich habe nun die ASUS Xonar U3 sehr günstig (gebraucht) bekommen und ich muss sagen, alle Achtung!

Sie funktioniert out of the box. Der Qualitätsunterschied ist schon massiv.

Erstmal stelle ich nun fest, dass der Sound wirklich, wie hier oder in einem anderen Thread mal angesprochen wurde, programmabhängig ausgegeben wird. Ist schon etwas sinnfrei. Schließlich trägt die Soundeinstellung im Raspbian nur zur allgemeinen Verunsicherung bei. D.h. bei Firefox, Kodi, audacious und Konsorten erstmal standardmäßig keinen Ton. Dazu musste ich dann über das USB Device im jeweiligen Programm gehen. Firefox ist auf dem Raspberry und mittlerweile in Windows sowieso das Allerletzte, zumal er m.W. nur mit PulseAudio funktioniert. Ich rate jedem von diesem Browser ab.
In Audacious habe ich noch Probleme. Der Klang wird abgehackt ausgegeben. Muss erst mal erforschen, woran das liegt. Zumal ich kein PCM benötige, was mir Audacious aber scheinbar zwangsweise aufdrängeln will. Macht das die USB-Soundkarte überhaupt mit??? Allein der Datenrate wegen.

Zum Zweiten stelle ich fest, dass die CPU-Last nicht wesentlich höher liegt. Eigentlich überhaupt nicht merklich. Einerseits vielleicht nur wegen der mp3s? Andere Tests mit richtig fetten gerippten WAV oder FLAC Files habe ich noch nicht gemacht. Wie beschrieben, nützen mir diese auch nichts.

Zum Dritten habe ich jetzt einige Probleme mit meinem Raspbian. Aber das hat andere Ursachen, siehe Touchscreen-Thread.

Daher: Vielleicht hat noch jemand eine Idee für Audacious. Ich kam noch nicht dahinter.

MfG Tantal

Das hat selbstverständlich damit zu tun und diese Funktion kenne ich.

... unter der Voraussetzung:

...by ignoring aspect ratio by a certain amount.

Und dieser Betrag ist prozentual einstellbar. Heißt, dein Video wird bspw. an den Seitenrändern insgesamt um 150Pixel beschnitten, damit deine 48Pixel Breite eines Horizontalbalken passgenau in deinem Display verschwinden.

Quote from Tantal

Für mich wäre es keine Lösung das Fenster auf 16:9 stretchen zu lassen oder die Darstellung um den Prozentsatz der Balken zu vergrößern.

Aber das Overlay ist ein gutes Stichwort. Dann werde ich mal versuchen das ebenso im Hintergrund zu händeln.

Quote from Sebbo187

Du könntest deinem Desktophintergrund einfach oben und unten schmale schwarze Balken verpassen und „Menüleiste ausblenden“ in den Desktop Einstellungen des raspberry auswählen... Damit wäre das Problem gelöst.

Klingt zwar verrückt, ist aber wahrscheinlich trotzdem die beste Methode für mich. Hatte auch schon dran gedacht, hoffte aber, dass es noch ne andere Möglichkeit gäbe.

Quote from Hofei

verwendest du den pi für was anderes auch noch? Wenn nein spiel OSMC auf

Eigentlich für alles, wofür mein Desktoprechner zu immobil wäre.

RTFM

21:9, 4:3, 1:1

Quelle: alles

Meine DVDs und BluRays, meine eigenen gerenderten Videos (Actioncam, DSRL, Camcorder), Diashows/Polaroids/Glasplatten/Mittelformat in Filme verpackt, alte digitalisierte Filme usw.

Für mich wäre es keine Lösung das Fenster auf 16:9 stretchen zu lassen oder die Darstellung um den Prozentsatz der Balken zu vergrößern. Andere Methoden habe ich auch noch keine gefunden.

Grundsätzlich interessiert mich dazu, ob Kodi die Schwarzbalken quasi in Echtzeit ins Video rendert oder auch einfach nur ein schwarzes Overlay über den Desktop legt und darüber dann das eigentliche Programmfenster.

Bei Android ist die Implementierung Kodis anscheinend um Welten besser, bzw. sollte man vielleicht für keinerlei Kompromisse einfach RaspBMC installieren.

Ich habe außerdem manchmal den Fehler, dass mein gesamtes Kodifenster transparent wird und aktuelle Hintergrundaktionen vom Raspi anzeigt (wenn sich etwas auf dem Desktop bewegt oder ein Fenster öffnet), obwohl ich noch im Programm bin und nichts weiter tun kann, als es zu schließen. Naja, vielleicht wird das irgendwann in zukünftigen Versionen behoben. Ist jetzt kein Beinbruch.

Danke euch so weit. Ich bastel mir jetzt irgend eine Lösung.

Moin moin an diesem wunderschönen verschneiten Weihnachtsfeiertag!

Nur eine kurze Frage an die Experten hier. Mir ist aufgefallen, dass bei meinem Kodi alle Filme, die nicht im 16:9 aufgenommen wurden, einen transparenten Streifen am oberen und unteren Bildschirmrand produzieren (s. Bild im Anhang).

Wieso?

Ich habe keine explizite Funktion gefunden, um das zu unterbinden. Der Desktop scheint durch, was nicht sein sollte. Eigentlich sollten m.M.n. gewöhnliche schwarze Balken dort sein. Es ist auch nicht so, dass das Kodi-Fenster verkleinert wäre, denn ich habe keinen direkten Zugriff auf den Desktop. Statt Schwarz ist der Hintergrund eben einfach transparent. Merkwürdig!

MfG Tantal

Im Anhang einmal die Modelle für den 3D-Druck.

In meinem Fall wurden beide Abdeckungen lasergesintert, allerdings sollten sie per FDM auch problemlos ohne Stütztstrukturen druckbar sein.

Ich weiß nicht, um was es da ging und nehme mir jetzt nicht die Zeit alles anzuschauen. Mag sein, dass die Inhalte ähnlich sind.

Das waren einfach Erfahrungen, die ich die letzte Dekade gemacht habe, weil gerade in dieser Zeit der Ausverkauf von Dt. so richtig losging. Selbst auf dem Land werden namenlose Hinterhofklitschen nach Fernost verschachert, was mich noch mehr bestürzt. Unternehmen die nicht mal 1/2% der Deutschen überhaupt kennen wird. Aber das wird alles zu philosophisch. Handeln statt Reden sollte unsere Devise heißen.

Nichtsdestotrotz ist Hifiberry ein gutes Stichwort. Wenn es denn mal ein DAC werden sollte, dann eher doch das Original.

Ich hatte neulich aktive China-Lautsprecher geordert. Edifier, die u.a. jahrelang für Logitech herstellten und nun mit ihrem know how eigene Boxen unter eigenem Label vertreiben. Die waren günstig und haben gut funktioniert. Für ein fettes Klangerlebnis würde ich mir allerdings zukünftig bessere kaufen, weil jene maximal "durchschnittlich" waren, womit wir wieder beim Thema wären. Günstig aus China heißt hier zwar resolut, aber eben lange nicht perfekt. Da würde ich dann zu etwas hochpreisigeren bekannter Marken greifen, was aber auch nicht heißen muss, dass diese Hardware aus Dt. oder den USA kommt (bspw. Bose oder Teufel).

Ich habe mal vor ein paar Jahren relativ teure Gyroplatinen für meinen Multikopter bestellt, um mir ein Gimbal zu bauen. Als das alles noch nicht so auf dem Stand wie heute war und gerade erst richtig anfing, gab es für den Ausgleich der Flugbewegungen keine richtig gute Hardware - außer eben besagter Selbstbau mit entsprechenden Platinen, die damals nahezu Neuland waren und an denen intensiv entwickelt wurde.

Dafür habe ich einige Hundert Euro investiert. Irgendwann, nachdem ich mich mal verlötet oder eine kurzgeschlossen hatte und das Geld zum Fenster rausgeworfen war, habe ich mich nach Ersatz umgesehen und bin auf billige China-Plagiate gestoßen, die aber exakt dasselbe gemacht haben. Zu einem Zehntel des Preises wohlgemerkt.

Heute würde ich mich über meine eigene Dummheit ärgern. Einerseits fühlt man sich aufrichtig, wenn man das Original kauft. Andererseits finanziert man aber automatisch die Produktpiraterie mit und unterstützt dieses Sch***system, denn immerhin rechnen die Originalhersteller bereits damit ab Markteinführung. Was spräche denn dagegen so eine Platine Made in Germany oder Made in Japan für 50€ auch in Deutschland zu verkaufen oder in Japan??? Stattdessen werden Menschen zu menschenunwürdigen Arbeitsbedingungen geschunden, um dann den zukünftigen "Umsatzverlust" auf den Markteinführungspreis mit aufzuschlagen.

Selbst schuld, sage ich da bloß!

Dort gehen dieselben China-Platinen vielleicht sogar nebenan vom Band und werden vom chinesischen Hersteller ohne QS für ein Zehntel des Preises verkauft. Na und? Wem gebührt jetzt Tadel?

Dem Entwickler, der ganz offensichtlich Made-in-China-Platinen für seinen Preis verkauft? Dem chinesischen Konkurrenten, der das know-how ausnutzt, um zu seinen eigenen Preisen zu verramschen? Oder dem Konsumenten, der vom chinesischen Konkurrenten für Ramschpreise kauft?

Ich erlebe es fast täglich selbst und habe die Chinesen schon oft dafür verflucht. Doch Schuld sind wir selbst, weil keiner von uns den Arsch in der Hose hat, einen Schlussstrich zu ziehen und in Deutschland zu verkaufen, was nach Deutschland gehört. Nämlich das Know-How UND die Produktion.

Ein Gegenbeispiel: Kameraobjektive. Ob diese in Dt., Japan, Schweiz oder China hergestellt sind, ist relativ egal. Denn der Entwicklungsaufwand für hohe Qualität und Abbildungstreue ist enorm. Und man merkt den chinesischen immer noch Schwächen an, obwohl sie preislich nicht um Welten zu denen aus Japan oder Dt. auseinanderliegen - mal abgesehen von Edelmarken wie Zeiss. Klar sind die Stundenlöhne niedriger, aber das fehlende Know-How spiegelt sich auch in der Produktqualität wider. Und so kommt eins zum anderen.

Ich habe mit Klon-Baugruppen noch keine schlechten Erfahrungen gemacht, eher das Gegenteil. Manchmal liefen diese sogar besser als die originalen.

Auf jeden Fall danke ich dir für die Erklärung dazu. Dann kann ich ja beruhigt meinem Vorhaben entgegensehen, was Software und Hardware betrifft.

Hiho,

wer hat Interesse an einem Gehäuse-Mod für den 3D Druckbereich?

Ich habe mir für das OneNineDesign-Gehäuse für den Touch TFT und den Raspi 3 B+ eine Rückenblende erstellt, die einen Lüfter für die Kühlung aufnimmt und an deren Rückseite sich nochmals eine 2,5" HDD oder SSD verschrauben lässt. (s. Bilder im Anhang)

Die Verschraubung müsste allerdings aus Platzgründen mit kleinen Adapterblechen oder Kunsstoffstreifen realisiert werden. Auf diese werden dann einfach 4 Sechskant-Abstandshalter aus Messing oder Polyamid verschraubt und das Ganze kann dann von innen her durch den Gehäusedeckel angeschraubt werden. Ich dachte, aus Platzgründen wäre die Anbringung einer SSD auf der Rückseite viel besser, als dass sie anderswo herumschlampert.

Der Deckel mit dem "T" ist als Verblendung für den Lüfter gedacht, wäre aber optional. Andernfalls hat man eben das offene Luftgitter.

Aktuell verwende ich einen Lüfter mit Lochabstand von 25mm im Quadrat, vorher 24mm. Daher ist der ursprgl. Deckel auch für 24mm Abstand ausgelegt. Die Anschraublöcher für ein zweites Modell zu ändern wäre aber kein Problem.

In den Fotos ist v1 zu sehen. Diese habe ich anschließend noch etwas optimiert.

Evtl. sollten Fertigungstoleranzen beachtet werden, die die Zentrierungen beeinflussen können. Bei mir wölbt sich der Deckel leicht nach außen, weil er irgendwo auf Spannung sitzt. Allerdings spreche ich von wenigen Zehntel Millimetern.

MfG Tantal

Danke erst mal fürs Licht im Dunkel.

Dass die Software auch den entsprechenden Ausgang unterstützen muss, wusste ich nicht. Ich dachte, dass das über das Betriebssystem an sich funktioniert und dann je nach eingestelltem Ausgang.

Ich verwende Audacious, weil das meinem geliebten Winamp am nächsten kommt. Ich kennen keinen Player, der nahezu so perfekt ist wie Winamp. Das nutze ich seit 17 Jahren ausschließlich, weil alle anderen viel zu aufgeblasen sind oder sich sehr umständlich bedienen lassen. Winamp und in diesem Falle Audacious mit dem Winamp Skin vereinen pure Minimalistik mit einer sehr benutzerfreundlichen und gut zu bedienenden Oberfläche. Und das Beste an Allem, ich habe sogar einen Fader, auch wenn er bei Weitem nicht so gut ist wie der in Winamp.

Womit ich schon bei der Musik wäre. Ich bin kein Erbsenzähler. Ich habe teure Beyerdynamic Kopfhörer, die mir leider nichts bringen. Ich habe auch eine Onkyo aus analogen Zeiten, die mir leider nichts bringt. Ich habe eine teure Soundkarte, die mir leider nichts bringt. Ersteres, weil ich den "Unterschied" von Highend-96kHz-PCM-Sound über vergoldete 6,3mm Klinke sowie XLR-Stecker gegenüber einem zu 320kb/s gesampeltem MP3 über 3,5mm Klinke nicht hören kann, Zweiteres weil ich nicht die Räumlichkeiten und das Interieur habe, um den Klang der Boxen vollkommen auszukosten, Letzteres weil eine interne Soundkarte eigentlich immer Quatsch ist, wie ich leidvoll feststellen musste.

Daher lasse ich die Kirche im Dorf und sage zu meinem Anwendungszweck einfach: MP3s oder komprimierte Musik. Und die prinzipiell nur über Aktivboxen oder mit Vorverstärker. Fertig.

Eine Hifiberry DAC fällt mit diesen Argumenten bei mir dann leider schon mal flach, weil ich nicht mehr genügend freie Pins zur Verfügung habe. Wenn es jedoch mit USB-Soundkarten dann keine großen Probleme geben sollte, werde ich wahrscheinlich diese Lösung vorziehen.

@schlizbäda

Ich gehe stark davon aus, dass in DollaTek und wie sie alle heißen dieselbe Hardware steckt wie in Hifiberry. Man müsst's eben auf einen Versuch ankommen lassen, ich bin jedoch was das betrifft die letzten Jahre schlauer geworden und schrecke auch nicht mehr vor Billig-Hardware zurück.

Danke einstweilen. Ich werde mich bald entscheiden und wenn dann die Feiertage rum sind, ist im neuen Jahr hoffentlich auch irgendwann meine Audiolösung da.

MfG Tantal

War ja auch nur spaßig gemeint. Sicher ist eine Versinnbildlichung immer etwas wert.

MfG Tantal

Hiho Leute,

ich stehe nun vor einer Gewissensfrage.

Nachdem ich am WE etwas Weihnachtsmusik für ne größere Runde gespielt habe und diese teilweise eher wie Schwermetall klang, ihr wisst schon, kratzende E-Gitarren und Todesheulen, musste ich mit Enttäuschung feststellen, dass das nicht die Musik, sondern der Stereosound des Raspi war. Mit reichlich Alkohol zu ertragen, ohne diesen bluten einem da eher die Ohren.

Nun entschloss ich mich zu einer Audiolösung, die die Klangqualität etwas heben soll. Da ich niemand bin, der von sich behauptet, die Klangqualität zwischen einem Klingeldraht und 6mm² Vollkupferleitung ausmachen zu können, darf es ruhig etwas Billiges sein, jedoch nichts "Schlechtes".

Ich habe seit Jahren eine teure Soundkarte in meinem PC, merkte aber recht schnell, dass manches Signal nicht durch den verarbeitenden Prozessor, sondern eher durch elektromagnetische Einstreuung anderer Geräte wie Grafikkarten oder TV-Karten zunichtegemacht wird. Daher wäre es mir relativ schnuppe, welche Lösung ich nun für den Raspi nutze, wenn da nicht das GPIO- und Platzproblem wäre.

1. DAC-Soundkarte - DollaTek PIFI Digi DAC+:

Ich nehme an, dass dann meine GPIO-Leiste belegt ist und meine TFT-LCD-Steuerung und meine Lüftersteuerung nicht mehr so verwendbar sind. Ich habe immerhin beide 3,3V- und einen 5V-Pin und einen I2C-Pin belegt, dazu noch einige Massepins. Oder gibt es Lösungen dieser Sound-Steckkarten, die all diese Pins wieder freigeben und trotzdem funktionieren?

2. USB-Soundkarte - ASUS Xonar U3:

Evtl. die kompakteste externe Methode, jedoch schätze ich, dass das Teil ganz schön viel Strom vom Raspi benötigt und den Datenstrom auch für andere angeschlossene Geräte ziemlich behindern wird. Liege ich da richtig?

3. HDMI - Neoteck HDMI Audio Konverter:

Vielleicht der beste Kompromiss aus freien GPIO-Pins, Datendurchsatz und Kompaktheit, obwohl ein zusätzliches Netzteil benötigt wird. Dazu interessiert mich, ob das Audiosignal tatsächlich besser wird, denn immerhin muss es doch auch vom Raspi erst verarbeitet werden? Oder gibt mir dann so eine Box bei Passthrough ein rauschfreies, qualitativ hochwertigeres Signal als der Raspi selbst aus?

Ich hatte das mal bei einem BluRay Film mit Passthrough probiert. Das lief nur über den Beamer bei mir und dieser konnte wahrscheinlich kein Signal verarbeiten. Also rauschte und kratzte die Aufnahme nur ganz extrem.

Vielleicht könnt ihr da etwas Licht ins Dunkel bringen.

In erster Linie wäre ich für Kompaktheit meines Raspi-Systems. Jedoch sollte das nicht mit einem fetten Leistungsverlust einhergehen oder meine bisherigen Anschlüsse (TFT-Touchscreen und 3 Relaisschaltungen) ins Nirvana befördern.

MfG Tantal

jar

Dann hast du meinen Nachtrag weiter unten überlesen. Mein LCD hängt nun dauerhaft an GND der GPIO-Leiste, weil es sich wegen DSI technisch anders gar nicht bewerkstelligen ließ - außer ich hätte das DSI-Kabel aufgeschnitten und umgelötet.

Deinen Vergleich mit der Seilbahn zweifle ich hier an. Denn wenn ich was gelernt habe, dann dass Mikroelektronik nahezu nichts mit Elektrik zu tun hat

Wenn die Lehrpläne unserer inkompetenten, überbezahlten und selbstherrlichen Politiker vor 20 Jahren Raum für solcherlei Experimente im Physikunterricht gelassen hätten, statt Kindern unnütze Zahlen einzuhämmern, hätte ich mich vielleicht hier an dieser Stelle wieder mit Freude dran erinnert. So kann ich nur abschätzig drüber lächeln. Krass ist, wie schnell man die Grundlagen wieder ausblendet, weil sie bis dato nie Relevanz besaßen.

Meine Displayschaltung funktioniert jetzt fast genau so, wie ich sie haben wollte. Mein Skript, das über tvservice den Status von HDMI abfragt, habe ich nun noch um die Schaltung des GPIO03 erweitert. Wobei es eigentlich zwei Skripte sind, weil eins für den Reboot zuständig ist, das andere wiederum einfach die Spannung vom LCD wegnimmt.

Muss mal sehen, ob ich noch die Umschaltung des Pins auf seinen Standardwert gebacken bekomme, sodass das LCD nach einem evtl. Reboot wieder funktioniert. Allerdings wird die Häufigkeit dieses Falls gen 0 tendieren.

In dem Sinne euch allen eine besinnliche Weihnachtszeit und gutes Einläuten des neuen Jahres.

Zuallererst habe ich nun nach einem Weg gesucht, die GPIOs standardmäßig umzustellen und habe eine heiße Spur gefunden. Das Zauberwort heißt device tree.

Das Device Tree Overlay in der /boot/config.txt funktioniert ja in meinem Fall nicht, weil lt. der offiziellen Raspi Dokumentation die config.txt erst viel zu spät geladen wird. Ich habe eine Lösung benötigt, die eher greift, irgendwo, bevor die GPU angesprochen wird. Und das könnte evtl. direkt über die dt-blob.bin funktionieren. Da muss man evtl. nicht mal über den Kernel gehen, sondern kann über den Device Tree regeln, welchen Status und Wert der jeweilige GPIO haben soll. Blöderweise habe ich NOOBS und dort vergeblich versucht, mir irgendwo her die Datei dt-blob.dts zu extrahieren. Angeblich wäre sie lt. der RPI Dokumentation bei NOOBS ausschließlich in der Recovery-Partition, doch ich habe sie nirgends finden können

Also nach langer Suche für mich irrelevant und frustrierend.

Ich bin nun trotzdem einen Schritt weiter. So ganz verstehe ich die Logik nicht, aber vielleicht wisst ihr da noch mehr.

Ich habe nun noch mal rumexperimentiert und nutze den GPIO03 für die Schaltspannung meines Relais. Dieser steht ja standardmäßig vom Kernel auf Input High. Ich konnte ihn über die Konsole nicht auf 0 stellen und bekam eine Fehlermeldung, dass die Operation nicht erlaubt sei, obwohl als SU ausgeführt .

Jetzt habe ich ihn mal probehalber auf Output, also das Gegenteil, gestellt, weil er ja bei Input bereits Spannung liefert und tatsächlich habe ich nun Zugriff auf seinen Status mit diesem Befehl. Ich darf ihn als SuperUser über echo "0" > /sys/class/gpio/gpio3/value nicht schalten (hat das mit dem hard wiring auf input 1 zu tun???), jedoch über echo "out" > /sys/class/gpio/gpio3/direction Und das Seltsame ist, dass meine Relaisspannung mit der Umstellung nun sofort weg ist, also genau so, wie ich es haben wollte. Damit muss ich mir nun nur noch mein script anpassen, damit das LCD beim Hochfahren vollständig abgeschaltet wird. Erste Tests sahen verdammt vielversprechend aus, jetzt muss ich als Noob nur noch irgend eine universelle Abfrage für HDMI-Displays in mein skript schreiben. Evtl. über best. Statusmeldungen von tvservice.

Etwas komisch finde ich allerdings, dass das LCD beim Reboot aus bleibt. Um es einzuschalten, muss ich erst den Raspi komplett vom Strom trennen. Scheint so, als würde der GPIO03 seinen eingestellten Status dann trotzdem beibehalten und erst nach einer Stromlosphase auf seinen Standard resetten. Wie auch immer. Das finetuning kann nun erfolgen. Ich werde die Schaltung mal zwecks Stromaufnahme im Auge behalten. Sollte das Relais den GPIO auf Dauer tatsächlich überlasten, dann muss ich trotzdem auf einen Schalter umschwenken.

Noch mal von meiner Seite was. Ich habe nun erfolglos alles mehrere Male durchgespielt.

Dabei habe ich herausgefunden, dass der Serial-Menüpunkt im raspi-config  nichts weiter tut als den Eintrag enable_uart=0 bzw. enable_uart=1, je nachdem eben, in der /boot/config.txt zu setzen. Genau so verhält sich dann auch meine kleine Status-LED. Erst an, dann aus, im BS wieder an oder eben aus, je nach Einstellung. Weil zwischenzeitlich beim Booten irgend eine Datenabfolge gesendet wird.

Der Raspi soll in der v3 seinen echten UART fürs Blutwurst geschaltet haben, wohingegen der UART für GPIO14 nur emuliert wird (wenn man Aussagen anderer Leute Glauben schenken darf). Er steht zwar von Anfang an auf Spannung, lässt sich dann aber auch nicht weiter beim Booten kontrollieren, weil ja die config.txt erst später geladen wird.

Ich glaube, ich bin jetzt so ziemlich am Ende mit meinen Möglichkeiten. Wie bereits geschrieben, hat der GPIO03 ständig Saft bei mir. Ich brauche I²C nicht.

Evtl. könnte mir ja jemand erklären, ob der Anschluss GPIO 03 auf irgend eine Art einfach nur abschaltbar ist. Das wäre super und mehr bräuchte ich gar nicht.

Den Kernel und die Schutzfunktion, die die GPIOs auf Input low setzt, kann ich selbstverständlich nicht umprogrammieren. Vielleicht kommt ja irgendwann mal ein aufgebohrtes Raspbian, was einen output high für frei programmierbare GPIOs von Anfang an erlaubt.

Bis hierhin erst mal ein dickes Danke für eure, leider erfolglosen, Bemühungen! Werde ich wohl doch den Weg über einen einfachen Kippschalter in der Zuleitung gehen, wenn es sonst keine Möglichkeit mehr gibt.

Ich habe jetzt mehrfach den Beamer nebst Touch-LCD angeschlossenen gehabt und es nervt wirklich, wenn der Raum abgedunkelt ist und man etwas zeigen oder erklären möchte und ständig aus der Ecke des Raspi ein grelles Leuchten kommt, als ob jmd. auf seinem Smartie spielt.

Ich habe jetzt noch mal mehrfach Messungen durchgeführt. Ich habe die serielle Schnittstelle extra deaktiviert. War sicher ein guter Tipp, brachte aber leider keinen Erfolg.

Beide Male, nach Aktivierung und Deaktivierung schwankt die Spannung extrem zwischen 380mV und 3,3V. Für die ersten 3 Sekunden bekomme ich in jedem Fall ein Bild, d.h. von Anfang an ist Spannung da. Danach fällt die Spannung wieder ab und schwankt bis zum Erscheinen des BS erheblich. Fast so, als würden dauerhaft beim Booten Daten gesendet. Seltsam, dass das in beiden Fällen auftritt, auch wenn Serial und das Anmeldeinterface deaktiviert ist.

@Outlaw

Der Eintrag in der config.txt bezweckt zwar die Schaltung der Pins ordnungsgemäß, aber eben leider auch erst nach bzw. im Bootvorgang, wenn der Kernel schon geladen ist. An dieser Stelle ist dann das Display schon durch und wird nicht mehr erkannt. War ein Versuch, aber leider erfolglos. Wie gesagt, denke ich, dass solcherlei Befehle aus best. Dateien heraus hier nicht richtig zielführend sein werden, weil wahrscheinlich die Pins standardmäßig vom Kernel alle auf Input geschaltet werden.

So genau kenne ich mich mit dem eigentlichen Bootvorgang nicht aus, meine aber, dass die Pins bereits beim Herunterfahren oder evtl. physikalisch schaltungstechnisch invertiert sein müssten, dass sie beim Hochfahren von Anfang an Strom geben. Ist eben wie ein Sicherheitsaspekt des RasPi, dass man sich nicht schnell mal irgend was Angeschlossenes beim Hochfahren zerschießt.

Das würde m.M.n. auch erklären, dass z.B. GPIO 03 auf "in" geschaltet ist, aber trotzdem Strom fließt. Vielleicht ist in diesem Fall einfach der Schaltkreis auf dem Board anders gepolt? Dazu habe ich aber nichts gefunden.

Eine ganze dumme Idee ist mir eben noch in den Sinn gekommen. Knallhart könnte man ja das Display die ersten 10 Sekunden per NiMH-Akkupaket betreiben. Dazu bräuchte man allerdings ein zweite Relaissteuerung, wofür dann wahrscheinlich zu wenige 3,3V Pins vorhanden sein werden. Ist dann der entsprechende GPIO initialisiert, schaltet das erste Relais einfach auf Netzspannung um und trennt das Display dann vom Akku. Wahrscheinlich gäbe es da aber entspr. Schaltzeiten oder Spannungsschwankungen zu beachten, die ich absolut nicht abschätzen kann.

Dasselbe Problem hatte ich mal bei einem alten ZTE Smartphone von mir. Einfach so, nicht runtergefallen, nicht angestoßen usw. Das Display war einfach im Eimer. Leider! Habe es dann entsorgt.

Quote from VeryPrivat

GND wegschalten - besonders wenn 5V Versorgung im Spiel sind ist keine gute Idee. ...

Richtig. Habe mich auch umentschieden. Mein Display hängt nun standardmäßig immer an GND.

Der Eingang vom (Relais)Schließer hängt direkt an der 5V-Spannungsversorgung und schleift beim Schließen einfach nur zum Display durch. Damit treten Verluste auf, die vernachlässigbar sind.

Zuerst wollte ich per PNP-Transistor, wenn ich es irgendwie hinbekommen hätte, direkt auf 5V durchschalten. Jedoch rieten mir mehrere Leute unabhängig voneinander davon ab, weil ein PNP-MOSFET einiges an Strom verschlingen kann, was ich mir beim Raspi nicht leisten kann. Daher bin ich auf ein quasi verlustfreies Mini-Reedrelais umgestiegen.

Die Schaltspannung für den Reed-Schalter kommt direkt vom 3,3V Pin. Ich habe auch noch keine Überlast, sprich Abstürze oder Aufhänger am Raspi mit 500mA feststellen können, wobei ich bisher nicht genau sagen kann, ob mein Reedschalter tatsächlich auch 0,5A verschlingt. Das ist wahrscheinlich auch stark temperaturabhängig, inwiefern die Magnetspule dann Saft benötigt.

Komisch ist bei der Spannungsversorgung des Displays, dass bereits der 5V Pin nur noch 4,96V liefert. Naja, aber daran kann ich wahrscheinlich nichts mehr rütteln. Habe die Spannung am Netzteil damals gemessen und die war höher. Sollten Probleme auftreten, muss ich trotzdem das Display direkt ans Stromkabel hängen.

Quote from Outlaw

Das soll im aktuellen Image (Raspbian) in der config.txt voreinstellbar sein.

Diesbezüglich muss ich nochmal richtig, richtig tief nachlesen und nachbohren, wenn das wirklich so sein sollte. Habe bisher absolut keine Information dazu. Es wäre aber eine ganz fette Sache, wenn es tatsächlich ginge.

Quote from Rasp-Berlin

Das Problem mit dem Abschalten, besser dem Anschalten, während der PI schon läuft, ist, dass das Display dann nicht richtig initialisiert wird.

Dazu habe ich vor wenigen Tagen glücklicherweise in irgend einem RasPi-Forum einen Entwicklerbeitrag gelesen.

Fazit: Es geht nicht

Das Display selbst wird scheinbar ohne Zutun weiterer Komponenten direkt von der GPU angesteuert und pulsweitenmoduliert, wie ich dem Beitrag entnehmen konnte. Wird die Verbindung dann nur einmal unterbrochen, kann es im Betrieb nie wieder von der GPU geschaltet werden. Den genauen Grund weiß ich nicht mehr. Aber es soll bereits gehörige Probleme im Vorfeld gegeben haben, um überhaupt die HG-Beleuchtung entsprechend dem bl_power-Befehl ab- und zuzuschalten. War ja vor 2(?) Jahren noch gar nicht möglich.

Daher fällt Punkt 3 komplett weg. Auch nicht so schlimm.

Quote from hyle

Hallo,

zu 1. Versuche mal Pin 8 (GPIO14).

Hatte ich bereits gestern probiert. Leider erfolglos. Ich denke sogar, der GPIO schwankte sehr stark. Wenn ich mich recht erinnere (habe gestern mehrfach schnell zwischen Tür und Angel nachgemessen) lag er beim Initialisieren vor dem Booten bei 3,3V, ging dann runter auf 1,3V, dann wieder für einige Sekunden rauf auf 3,3V, dann wieder runter auf 2,3V im Betriebssystem - wohlgemerkt mit angeschlossener Platine. Eigenartig.

Ich habe jetzt mehrere Bootvorgänge mit unterschiedlicher Verkabelung (um Störeinstreuungen durch meine Lüftersteuerung oder naheliegende Kabel zu verhindern) mit dem GPIO 02 durchgeführt. Er liefert bei mir immer standardmäßig 3,3V von Anfang an. D.h. das Bild ist da. Ich bräuchte nun nur noch eine Möglichkeit diesen Pin im Linux abzuschalten. Weil er scheinbar für I2C verwendet wird, geht das anscheinend nicht wirklich!? Zumindest wird mir immer der Zugriff selbst als root verweigert. Im BS steht er allerdings auf "input" "high", was mich sehr, sehr wundert. Dürfte er dann überhaupt meine Platine durchschalten? Sie hat einen eingebauten 10K Pulldown-Widerstand. Ich dachte zuerst an Schwankungen, sodass das Linux ihn nicht genau zuordnen kann, schließe sie aber in Anbetracht des Widerstandes nun aus.