Posts by schlizbäda

Hi WildTassie , herzlich willkommen im Forum!

Für einen Audioplayer empfehle ich einen RPi3 (oder höher) bzw. RPizero 2 (ähnliche techn. Daten wie der RPi3, weniger RAM und niedrigerer Takt), Vergleichsliste siehe hier.

Volumio ist ein eigenes Betriebssystem, das als Image heruntergeladen und per Raspberry Pi-Imager auf ein Speichermedium geschrieben ("geflasht") wird.
kodi kann auf RaspberryPi OS per sudo apt install kodi installiert werden oder man verwendet ebenfalls ein fertiges Image wie osmc, libreELEC, xbian etc.

Alternativ unter RPi OS etwas Leichtgewichtiges wie mpd/mpc (music player daemon) oder irgendeinen Kommandozeilen-Audioplayer aus den Vorschlägen auf ubuntuusers.de. Natürlich kann man auch einen grafischen Player wie z.B. audacious oder alsaPlayer oder oder oder ... verwenden.
Beim Alsaplayer kann man die Abspielgeschwindigkeit von Audiodateien ändern, auch ins Negative, dann wird die Audiodatei rückwärts abgespielt.

Werbung:
Ach ja, eine Soundkarte hätte ich im Angebot, mein RPi400extBrd. Da kann man direkt passive Lautsprecherboxen anschließen

Quote from Franjo G

Wird Zeit, dass mal jemand W-Strom erfindet.

Gibt's den nicht schon?
Sieht sehr effektvoll aus, gibt's bei jedem Gewitter und bei uns in der Arbeit im Prüffeld beim Kurzschlusstest unserer 65kV-Netzgeräte. Wenn die geerdete Kurzschlusskugel den HV-Ausgang berührt, kracht's und beim Wegziehen der Kurschlusskugel zieht es saubere Blitze, die akustisch so lustig britzeln

Hast Du schon mal ein anderes HDMI-Kabel ausprobiert? Da gibt es durchaus Qualitätsunterschiede hinsichtlich der Bandbreite (Maximalfrequenz). Höhere Auflösung erfordert u.a. höhere Bandbreite des Kabels.
Läuft es mit diesem Kabel flackerfrei an einem anderen Bildschirm mit FullHD (1080p)?

Quote from peuler

leonloewe Ich würde Dir empfehlen, dass Du Dich mit der Nachfolger-Bibliothek pigpio auseinandersetzt anstatt den Weg mit Wiringpi weiter zu gehen. Wenn ich mir den Verlauf des Threads hier so anschaue, so wirkt das eher verkrampft auf mich.

oder gleich gpiozero.

Quote from maksimilian

Spielt es eine Rolle, dass die neue Micro-SD eine Kapazität von 64 GB (also nicht mehr mit fat32 formatierbar) besitzt ?

Das trifft nur für die Windows-Bordmittel zu.

Der aktuelle RPi-Imager (V1.8.5) sollte jede SD-Karte (auch unter Windows) problemlos bespielen können. Ggf. die aktuelle Version des RPi-Imagers herunterladen und aktualisieren.

Mit 64GB-Karten hatte ich noch nie Probleme, nehme sie aber nur her, wenn ich den Speicherplatz wirklich für Daten/Musik brauche.
Ansonsten hier noch ein paar Links zum Reinlesen in die SD-Problematik, auch wenn manches für Dich nicht zutrifft, da Du u.A. eine namhafte Sandisk Ultra verwendest.

So, die Rev. 2024/09 (2 Nutzen à 6 Stück) habe ich seit Anfang November vorliegen, kam aber aus privaten Gründen leider noch nicht dazu, es ausführlich zu testen. Ich will das aber jetzt dann angehen...

Hallo RealDave98,
willkommen im Forum!

Ich habe vor einiger Zeit mal mit einem DAB+-Radio, basierend auf dem MonkeyBoard begonnen. Es hat auch funktioniert und dabei habe ich Einiges über Antennenphysik etc. gelernt. Leider habe ich es dann nicht mehr so fertiggestellt, dass es den notwendigen WAF für's Wohnzimmer hat. Wird aber u.U. reaktiviert, wenn ich wieder mehr Zeit habe...

Softwareseitig habe ich es modular aufgebaut, eine Art Server bzw. Daemon, der über stdin/stdout gesteuert wird und über das Linux-Bordmittel Named Pipes/FIFO von beinahe belibigen externen Programmen gesteuert werden kann. Auch ich hatte die Idee, das UGreen DAB-Board (und evtl. weitere) modular in die Software einzubinden.

Du kannst Dich ja mal reinlesen. Bei Fragen stehe ich gerne zur Verfügung.
Das Ganze ist aber noch in einem ziemlichen Anfangsstadium. Es funzt mit dem MonkeyBoard, ist aber derzeit eher ein proof of concept. Es liegt auf https://github.com/schlizbaeda/DABradio

EDIT:
Die Sache mit dem fake-I2S-Audioplayback ist ganz trivial:
Ich verwendete die I2S-Soundkarte HiFiBerry DAC+, die über I2C aktiviert ("eingeschaltet") werden muss. Da ich mich damals (und heute) nicht genügend mit Linuxtreibern auskenne, war das meine Behelfslösung, die I2S-Soundkarte zu aktivieren. Dann schalte ich per Relais die vier I2S-Leitungen des RPi von der Soundkarte weg und die I2S-Kontakte vom DAB-Monkeyboard drauf. Nichts wirklich Tiefgreifendes.
Für Dich hätte dieses Vorgehen evtl. den Vorteil einfach per Relais zwischen DAB und Bluetooth umzuschalten.

Die Sache, die I2S-Soundkarte direkt anzuschalten anstelle über eine absolut unschöne Fake-Audioausgabe, werde ich auch noch lösen, zumal das auch für mein RPi400extBrd interessant ist. Das fehlerkorrigierte RPi400extBrd Rev 2024/09 ist verfügbar.

Ich gehe davon aus, dass bei Ubuntu 24.04.1 LTS eben ausschließlich Wayland vorinstalliert ist und X11 mittlerweile rausgeflogen ist, im Gegensatz zum offiziellen Raspberry Pi OS. Deswegen funzt logischerweise auch die Umstellung mittels raspi-config nicht out of the box. Ob es mit "einfachem" Nachinstallieren von raspi-config und/oder X11 getan ist, bezweifle ich ebenfalls.

Deine Anleitung ist wohl nur für Raspberry Pi OS gedacht.

Da müsste man auf Linuxebene eine Art globale Callback-Funktion für die grafischen Steuerelemente mit Textfunktion einrichten, die auf das Aktivierungsereignis reagiert und das Programm für die Touchtastatur startet (z.B. matchbox-keyboard). Aber wie man das global für alle Programme einrichtet, weiß ich nicht. Vielleicht über udev?

Gut dass es jetzt wieder funzt.

Aber die Meldung "Read-only file system" lässt ganz stark darauf schließen, dass das System selbst seine Partition auf read-only gesetzt hat, um weiteren Schaden abzuwenden. Mir fallen dazu zwei mögliche Gründe ein:

1. wie fred0815 bereits anmerkte, eine SD-Karte, die aufgrud vieler Schreibzugriffe langsam aber sicher ihr Lebensende erreichen wird und schon begonnen hat, einzelne Fehler zu produzieren.
2. nicht sauberes Herunterfahren des RPi, z.B. Versorgung im laufenden Betrieb einfach kappen/ausschalten.
   Das geht 99 mal gut, beim 100. Mal wird ein Schreibvorgang nicht vollständig abgeschlossen und das Dateisystem ist korrupt. Daraus können Datenverlust und ein nicht mehr bootbares System resultieren!
   (den "großen" PC schaltet man das ja auch nicht einfach aus, ohne ihn vorher herunterzufahren)

Diese Sachen bitte im Auge behalten, bevor's zu spät ist.
Und regelmäßige Backups erstellen!

oh, das habe ich übersehen

(Das ändert aber nichts an meiner obigen grundsätzlichen Erklärung)

Wenn man das Overlay-FS über raspi-config aktiviert, so wirkt sich das nur auf die ext4-Partition root aus. Der Witz am Overlay-FS ist, dass die Partition auf dem persistenten Speichermedium (SD-Karte etc.) read-only ist und nur am Anfang beim Booten eingelesen wird und als RAM-Disk gespiegelt wird. Alle Änderungen an den Dateien des Overlay-FS (und nur die) werden in der RAM-Disk abgelegt und sind daher nach einem Neustart wieder weg. Um den RAM-Speicher nicht mehr als notwendig zu "verschwenden", werden eben nur tatsächliche Änderungen in der gespiegelten RAM-Disk gespeichert. Für das System und die Anwenderprogramme sieht ein Overlay-FS weitestgehend aus wie ein "normales" RW-Dateisystem ohne die Einschränkungen eines einfachen read-only-Dateisystems (fehlschlagende Schreibzugriffe etc.).
Wie oben ausgeführt, nutzt man ein Overlay-FS u.a. dazu, korrupte Dateisysteme bei plötzlichem Wegfall der Spannungsversorgung zu verhindern.

Die Bootpartition ist FAT32 und sie kann unabhängig von den Overlay-Einstellungen der root-Partition als "ganz normales" read-only-FS gemountet werden, da hier im laufenden Betrieb i.d.R. keine Schreibzugriffe mehr notwendig sind (außer man ändert die config.txt)

Die Ausgaben oben sollten daher richtig sein...

Dazu fällt mir nur der alte Spruch ein:

Schuster bleib bei deinen Leisten.

Dass nach so einer Aktion ausgerechnet das Netzteil kaputt geht, wundert mich jetzt auch...

Der Rest (Kamera, AI-HAT) funzt noch, oder?

Dann war es ja nochmal Glück im Unglück: Neues Netzteil besorgen und zwar ein für den RPi5 zertifiziertes! Ein Ladegerät ("Ladekabel") sorgt auf Dauer nur für Kummer.

Edit: Hat das defekte Netzteil eine Sicherung, so dass nur die geflogen ist und das Netzgerät eigentlich noch funktioniert?

Wahrscheinlich meint achim 9876 , dass bei READ-Zugriffen das niederwertigste Bit im Adressbyte gesetzt sein muss und bei WRITE-Zugriffen gelöscht. Nur die 7 höherwertigen Bits bestimmen die eigentliche Adresse des Bausteins, das niederwertigste Bit hingegen den Zugriffsmodus (R/W).

Wenn eine I2C-Adresse angegeben ist, wird in der Regel (Ausnahmen existieren!) der Wert der 7 oberen Bits als 7-Bit-Wert angegeben, d.h. als Wert zwischen 0 und 127 (0x00 - 0x7F).
EDIT:
Es stehen tatsächlich nur 128-16=112 I2C-Knoten auf dem Bus zur Verfügung, da 16 Adressen für Sonderfälle reserviert sind. Die sind bei der Ausgabe von i2cdetect entsprechend gekennzeichnet.

Quote from framp

Momentan befinde ich mich in China

Du arme Sau!

(Wenn ich da (beruflich) hin müsste, ließe ich mein Smartphone zu Hause und nähme ein neues/zurückgesetztes billiges mit, komplett ohne persönliche Daten. Da dürfen sie dann ruhig den chinesischen Staatstrojaner installieren... Der Laptop wäre verschlüsselt und ein Klon der Festplatte (=backup) läge zu Hause für den Fall, dass der mitgenommene Laptop wegen nicht freigegebener Verschlüsselung dann beschlagnahmt würde)

siehe hier

Hi Gnom, ich weiß du schlägst es nicht ganz ernst gemeint vor, aber diese Verdongelung mit Wibu, Hasp und Konsorten ist genau das, was vermieden werden sollte: Vermeintlicher(!) "Schutz" des geistigen Eigentums. Damit der Schutz auch bei (unabsichtlich) als open-source designten Programmiersprachen aus der .net-Familie (Bytecode für JIT-Compiler, ein anderes Wort für Interpreter) funzt, muss nach dem Kompilieren noch ein Programm drüberlaufen, das "security by obfuscaty" (ebenfalls keine echte Sicherheit) umsetzt - suuper!

Gute Software zeichnet sich dadurch aus, dass jeder reinschauen kann, was im Code wirklich passiert. Aber gerade in der Industrie greift diese Unsitte mit diesen Kopierschutz-Dongeln um sich. Dabei ist die Software meist nur Teil des Gesamtproduktes. Als Hersteller verkauft man sie mit der Hardware und nur zusammen damit kann man die Software sinnvoll verwenden.

Ich musste auch mal auf Anweisung meines Chefs "meine" Software dongleschützen. Die wäre komplex genug gewesen, damit Geld über Service an der Software zu verdienen. Aber nein, da haben wir uns lieber selbst ausgebremst, indem wir wegen des Dongles keine weiteren Installationen zuließen.

Das beste Beispiel sind Verschlüsselungsalgorithmen: Nur wenn sie open-source sind, kann man ihre Integrität (Sicherheit) garantieren, insbesondere dass keine Backdoors eingebaut sind. Die mathematische Komplexität des Algorithmus stellt sicher, dass verschlüsselte Daten ohne Kenntnis des (sicheren) Passwortes nicht in vernünftiger Zeit geknackt werden können.

Wenn eine derartige Anforderung auftaucht, würde ich mein gesamtes Geschäftsmodell anpassen:

1. Die Software unter einer freien Softwarelizenz wie GNU GPL v3 (oder neuer) veröffentlichen, so dass die eigentliche Software von jedermann heruntergeladen und genutzt werden kann. Die Urheberrechte bleiben bei dir, du erteilt aber jedem die Lizenz (das Recht), die Software zu nutzen (sowie zu erweitern, zu verbessern und weiterzugeben)

2. Eine detaillierte Doku ebenfalls komplett frei zur Verfügung stellen, idealerweise als Bestandteil des Softwarepaketes.

3. Als Schöpfer/Erfinder der Software bist du der, der sich damit mit Abstand am besten auskennt. Dieses "Wissen" kann man dann gegen Geld als Dienstleistung an die Interessenten verkaufen, die sich die Eigeninbetriebnahme nicht zutrauen oder zeitlich nicht antun wollen.

Natürlich muss dafür die Software eine gewisse Komplexität aufweisen und es schützt nicht davor, dass eine dritte Partei den Punkt 3 ebenfalls für Geld anbietet, das darf sie nämlich laut GPLv3. Aber das ist wiederum kostenlose Werbung für deine Software, da ja die Urheberrechte bei dir bleiben. Die GPLv3 schließt über das sogenannte Copyleft aus, dass Dritte unbefugt deinen Code in ein "closed-source"-Projekt einbinden. Wenn sie das (legal) tun wollen, müssen sie ihre Erweiterung unter freien Zugang zum angepassten Quellcode (übrigens ihrer gesamten Software!) stellen, wovon am Ende (auch) du wieder profitieren kannst.

Das ganze GNU/Linux funktioniert so, es ist unter GPLv2 lizensiert, der Urheber des Linuxkernels ist Linus Torvalds, die Urheberschaft der Dienstprogramme, Oberfläche etc. liegt bei der FSF um Richard Stallman. Und deswegen lebt GNU/Linux und wird immer besser. Auch Konzerne wie Microsoft und Google haben das mittlerweile für sich erkannt...