Posts by schlizbäda

    kann hier aber scheinbar keine Dateien mit der Extension . T3000 hochladen :-/

    Das ist ein Problem (oder eine Sicherheitsmaßnahme/Feature) der Forensoftware, dass nicht jede Dateiendung akzeptiert wird. Meist hilft umbenennen in Dateiname.erweiterung.TXT. Man muss dann eben dazuschreiben, dass es z.B. eine Target3001-Datei ist, die nach dem Download wieder umbenannt werden muss.


    Auch die Idee, den Stromlaufplan als "Bild" (Stromlauf.doc) reinzustellen ist gut. Aber noch besser wäre, davon eine pdf-Datei zu erstellen. Geht in Target3001 im Menüpunkt Datei-->PDF erzeugen. Zumindest in Version V20 professional

    Servus Thomas196,


    Die Meldung "Could not tune to frequency" bei Auswahl von Antenne Bayern verwundert mich in keiner Weise! Es ist eher bedenklich, dass diese Warnmeldung nicht auch kommt, wenn man die 3,5mm-Buchse verwendet :lol:


    Spaß beiseite!

    Ich habe auch schon ein bisserl mit DAB+ gebastelt, aber mit dem DAB+-Monkeyboard. Das uGreen-Board steht auch noch auf meiner todo-/habenwill-Liste. Das Monkeyboard hat ebenfalls einen I2S-Masterausgang und den konnte ich problemlos am I2S-Slaveeingang des Hifiberry-MiniAmp anschließen.

    Lese Dich einfach mal in meinen Thread ein, aber Vorsicht! Der ist lang...

    Stromlaufplan HifiBerry MiniAmp

    Stromlaufplan HifiBerry DAC+


    I2S-Verdrahtung zwischen DAB+-Board und HifiBerry


    Vielleicht hilft Dir das als Anregung ja schon mal weiter?



    EDIT:

    Die HifiBerry-Verstärker sind immer I2S-Slaves. Da braucht man auf dem RPi eigentlich gar nichts zu konfigurieren (außer die Standardeinstellungen des entsprechenden HifiBerry-Boards in der config.txt einzufügen, für den MiniAmp z.B. hier beschrieben).

    Die DAB-Boards (egal welche) sind normalerweise I2S-Master.


    EDIT2:

    Problematisch ist bei manchen I2S-Soundkarten (z.B. beim MiniAmp mit dem einfacheren I2S-D/A-Wandler PCM5101A), dass die Lautstärke nicht als Parameter übergeben werden kann. Stattdessen muss die Amplitude über die Binärwerte im Audiostream skaliert werden. Wenn die I2S-Audiodaten nicht vom RPi, sondern von einer autarken anderen Quelle, wie z.B. einem DAB+-Board kommen, dann bleibt die Softwareeinstellung auf dem RPi-Desktop wirkungslos! Hier braucht man dann das Glück, dass die Lautstärke auch am DAB-Board eingestellt werden kann. Dies geht beim Monkeyboard.


    Wird aber ein Chip wie der PCM5122 verwendet, dann stellt der Treiber die Lautstärke z.B. über den separaten I2C-Bus hardwaremäßig am Wandler-IC ein und der Schieberegler am RPi-Desktop funzt einwandfrei. Könnte sein, dass Du mit dem HifiBerry AMP2 diesbezüglich Glück hast.

    Hi Hofei, ich habe mich jetzt auch mal angemeldet.


    Bin mal gespannt, wie gut ich tippen werde, so als reiner Event-Fußballfan, der nur zur EM oder WM aufwacht. :lol:
    Wenn mir einer zehn Vereine aufzählt, von denen heuer nur fünf tatsächlich in der ersten Bundesliga spielen, und ich diese benennen soll, dann kann es schon sein, dass ich da nur zwei Richtige (oder so) habe.

    FC Bayern, Dortmund ... und dann beißt's aus! :stumm:


    EDIT:

    Sorry hyle, dass ich den derzeit Zweitplatzierten RB Leipzig in meiner obigen Aufzählung vergaß :angel: Da half mir https://www.bundesliga.com/de/bundesliga/tabelle auf die Sprünge ;)

    Wenn der MiniAmp wie auf Deinem Foto steckt, ist er richtig drauf.

    Wenn Du die Polung auch nicht mit irgendwelchen Jumperkabeln vertauscht hast, dürfte er nicht defekt sein.


    EDIT:

    Der Pin 1 hat meistens ein quadratisches Lötauge, die anderen Pins sind rund bzw. achteckig


    EDIT2:

    hier noch ein Thread, wie man den MiniAmp "from scratch" installiert. Siehe meine Beiträge #9 und #11. Hat vor einem halbe Jahr noch funktioniert. Und wenn Raspbian Buster Lite nach wie vor direkt mit ALSA arbeitet, sollte es nach wie vor funzen.
    Viel Glück!

    ich hatte das mit dem Pulseaudio auch vermutet. Allerdings wurde das lt. der Website vom Raspian OS nur bei den Desktop Varianten auf PulseAudio geändert. Die Lite Versionen sollen immer noch auf dem Alsa basieren, dafür spricht ja auch, dass es ohne mein Zutun bei einer Neuinstallation vorhanden ist.

    vielen Dank für diesen Hinweis.

    Vielleicht kann ich mit diesem neuen Wissen ja doch noch mal irgendwann etwas Muse zusammenkratzen und meine Anleitung überarbeiten/aktualisieren...

    Ich habe Anfang 2020 auch eine Phoniebox gebaut. Schließlich landete auch ich bei der guten Anleitung von splitti79. Ich habe meine Box nach drei Monaten Rumgetüftel schließlich auch so hingebracht, wie ich sie haben wollte.


    Das damalige Raspbian Buster setzte noch direkt auf ALSA, eine in meinen Augen sehr vernünftige Entscheidung der RPi-Foundation. Irgendwann Herbst bis Ende 2020 wurde Raspbian in Raspberry Pi OS umbenannt und damit gingen einige einschneidende Änderungen des Betriebssystems einher, wie die Umstellung der Linux-Audioverwaltung von ALSA auf das zwar darauf aufsetzende, aber völlig anders zu konfigurierende PulseAudio.

    Dies ist wahrscheinlich der Punkt, an dem eine Problemlösung ansetzen muss: HifiBerry MiniAmp unter PulseAudio, Treiber


    Ich sehe gerade, dass splitti79 seine Homepage komplett neu aufgezogen und aktualisiert hat. :thumbup:

    Ich selbst war auch lange Zeit "fleißig" bei Hilfe zur Phoniebox und habe sogar eine Anleitung verfasst. Aber seit der Umstellung auf PulseAudio funzt sie nicht mehr plug+play. Leider habe ich entgegen meiner Ankündigung im Thread aus Frust bisher noch keine Anpassungen vorgenommen.


    Aber ich vermute das Problem wie gesagt bei PulseAudio. Sorry, dass ich spontan nicht besser helfen kann.



    EDIT:

    und wenn die Box irgendwann funktioniert, von der SD-Karte ein Image ziehen und das auf dem PC sichern (raspiBackup, piShrink). Sollte die Box mal nicht mehr starten, kann man einfach das Image auf eine neue SD flashen und weiter geht's. Evtl. muss man noch ein paar Hörspiele samt ihrer RFID-Karten nachkonfigurieren, die zum Zeitpunkt der Sicherung noch nicht auf der Box installiert waren.

    Dann hat man kein Geschiss mit irgendwelchen Systemumstellungen seitens Raspbian etc.

    mein Credo: Gerade als Neuling auf einem Thema greife ich immer zum Original. Selbst wenn es etwas teurer ist. Aber gerade als Anfänger profitiert man davon. Schnelle Erfolgserlebnisse und keine unnütze/lästige Fehlersuche. Nach ersten Erfahrungen und wenn man sich zu helfen weiß, kann man dann auch zum Chinaklon greifen.

    mit und ohne GUI Version?

    meinst Du "mit oder ohne GUI" bezüglich Raspberry Pi OS?

    Meines Wissens nach ist die Kernelversion bei jeder Variante von Raspberry Pi OS (desktop + recommended software, desktop, lite) gleich.


    Bei Installationen, die hauptsächlich im Hintergrund laufen, was ich bei Deiner Proxy-Geschichte annehme, empfiehlt sich die lite-Version des Betriebssystems ohne GUI. Ein solches System verwaltet man als Administrator über das Terminalfenster bzw. per SSH.

    Hi Dennis89,


    das Interface-Timing auf S28 des Datenblattes interpretiere ich wie folgt:

    1. Damit die Datenübertragung über das Interface überhaupt aktiviert wird, muss der CSX-Pin auf low gezogen werden.

    2. Der Pin D/CX bestimmt, ob die Bits an D[17:0] als Adresse (low) oder als Daten (high) interpretiert werden sollen. Dieser Pin wird erst bedient, wenn CSX sicher auf low ist!

    4. Dann wird an den Datenleitungen D[17:0] das gewünschte Bitmuster angelegt. Mehr oder weniger zeitgleich wird der Pin WRX auf low gezogen

    5. Nach einer kurzen Wartezeit bzw. wenn die Datenleitungen D[17:0] stabil sind, wird WRX von low auf high gesetzt (steigende Flanke). Zu diesem Zeitpunkt liest der Displayprozessor das Bitmuster D[17:0] ein.

    6. Danach können schon die Vorbereitungen für das nächste Bitmuster D[17:0] getroffen werden (Pin D/CX auf Adresse/Daten einstellen, nächstes Bitmuster anlegen).

    7. Am Ende der gesamten Übertragung wird CSX wieder auf high gesetzt. Vielleicht werden dann die Daten am Display zur darstellung gebracht? Dafür habe ich das Datenblatt zu wenig gelesen.


    Wichtig ist allerdings, dass die Bitbreite (8, 9, 16 oder 18 bit) am besten hardwaremäßig über die Pins IM[2:0] konfiguriert ist! Siehe Seite 27 des Datenblattes.


    Zur tatsächlichen Taktrate kann ich jetzt wenig sagen, aber bei einer Displayauflösung von 320x200@60Hz komme ich rechnerisch auf 3,84MHz. Mit den zusätzlichen Bits für die Synchronisation (front porch, sync, back porch, ...) kann man wohl mit 4Mbit/s rechnen.

    Aber das Ganze läuft offenbar nicht mit einem festen Takt, sondern die Daten werden übernommen ("eingelatcht"), wenn am Pin WRX eine steigende Flanke erkannt wird. Dies hat man mit dem Hostcontroller (Master) prinzipiell vollständig in der Hand.

    Beim Lesen vom Display (Touch?) ist der Pin RDX der Taktgeber.

    Stand am 26.04.2021:


    Die Software ravidplay.py spielt die Videodateien ab, die als Kommandozeilenparameter übergeben wurden.

    Die Konfiguration (feste oder Zufallsreihenfolge, Überblendzeiten, Transparenz) für wird derzeit dreistufig hinterlegt:

    1) Defaultwerte aus globalen Konstanten DEFAULT_... im Programm (niedrigste Priorität)
    2) Werte aus allgemeiner Konfigdatei unter ~/.config/ravidplay.py.conf (überbügelt die Defaultwerte)

    3) Werte als Kommandozeilenparameter (überbügelt die beiden obigen Quellen)

    4) geplant: individuelle Konfigdateien für einzelne Videos (gleicher Aufbau wie 2, überbügelt 1 bis 3)


    Und das Beste:

    Ich habe seit ca. 0:20 Uhr einen Dauertest auf einem RPi4B/4GB mit den kurzen Demovideos von Goldjunge laufen. Jetzt um 20:55Uhr läuft die Software immer noch. Kein Absturz oder Aufhänger bezüglich omxplayer, python-omxplayer-wrapper, dbus-Kommunikation, Multithreading von zwei omxplayer-Instanzen.


    EDIT 27.04.2021 -- Dauertest:

    Ich wollte gestern dann noch etwas an der Software machen (Punkt 4: videospezifische Konfigurationsdatei), aber es hat mich nicht mehr gebockt. Dann nochmals ravidplay.py gegen 22:00 Uhr auf dem RPi4 angestoßen. Jetzt nach 24 Stunden läuft es nach wie vor munter. Der RPi4 ist in meinem Argon-One-Gehäuse verbaut: Der Lüfter läuft nicht [gutes Ergebnis] und das Gehäuse ist an der Außenseite vielleicht 5K wärmer als die Umgebung im Keller. Definitiv nicht mehr als 30°C [sehr gutes Ergebnis].
    Da mich das Programmieren auch heute nicht mehr gefreut, lasse ich das Programm einfach weiterlaufen. Mal schauen wie's morgen in der Frühe und nach der Arbeit aussehen wird.

    Anschließend werde ich den neuen ravidplay.py auch auf meinen älteren RPis in einen Dauertest schicken:
    * RPi3B (ohne Plus)

    * RPi2B

    * RPi Zero

    * RPi1B+ (512MB RAM) oder vielleich besser auf meinem RPi 1A+ (256MB RAM, 700MHz -- ja das waren noch Zeiten!)

    Beim RPi1 und RPi0 rechne ich jedoch mit den bekannten Problemen bei der Performanz. Aber es ist ein guter(?) Test, wie stabil die Software auch mit deutlich weniger RAM und nur einem Prozessorkern im Dauerbetrieb klarkommt.