Posts by schlizbäda

    Wieso das? Auf der /boot Partition werden doch automatisch keine Daten geschrieben.

    Dann macht es aber auch nichts aus, wenn man die Partition tatsächlich readonly mountet.


    Wie gesagt, ein (aufgemotzter) Bewegungsmelder ist in meinen Augen eine typische Anwendung, bei der keine Daten geschrieben werden müssen. Es stellt sich eher die Frage, ob es dafür überhaupt einen RPi braucht oder ob ein µC reichen würde. Hier ist es offenbar ein Recycling eines vorhandenen RPi1 und von daher grundsätzlich eine sinnvolle Anwendung.

    Oder wenn es die Anwendung zulässt, Raspbian in eine Readonly-Installation umwandeln:

    Die /boot-Partition (FAT32) auf readonly setzen.

    Die Systempartition (ext4) als Overlay-Dateisystem konfigurieren d.h. die benötigten Dateien werden in eine RAM-Disk kopiert und der Inhalt der SD-Karte wird beim plötzlichen Ausschalten nicht mehr inkonsistent. Allerdings gehen alle Dateiänderungen sowohl beim Ausschalten als auch beim regulären Herunterfahren verloren.

    Beide Optionen kann man in raspi-config unter Advanced Options einstellen.

    Kann es sein das mein pi kaputt ist? Ich bekomm ja keine Fehlermeldung.

    Oder falsch angeschlossen? Hab ich irgendetwas übersehen?

    Pi kaputt? nein

    falsch angeschlossen? ja!

    Was übersehen? ja: die berühmt-berüchtigten Pegelwandler zwischen RPi und WS2801


    Steht ja im Datenblatt des WS2801 so schön drin:

    Seite 2: "Electrical Characteristics"
    * Power Supply Voltage Range (Vcc): 3,3V ... 5,5V

    * Input Voltage Level:

    hi: 0,8*Vdd ... Vdd

    lo: GND ... 0,2*Vdd


    Laut den Fotos betreibst Du den WS2801-Streifen (vermutlich) an einem Meanwell-Netzteil mit (vermutlich) 5V Ausgangsspannung (und den RPi über µUSB).

    0,8*Vcc (bzw. Vdd -- weiß nicht, warum die Chinesen im Datenblatt so inkonsequent sind) sind 4V. Mit 3,3V an den GPIOs des RPi erreichst Du die notwendigen 4V nicht. Der WS2801 "sieht" somit immer low. Daher kann am LED-Streifen nix passieren!

    Lese Dich hier im Forum zum Thema "Pegelwandler" ein. Beiträge dazu gibt's in Hülle und Fülle.

    Tja, die Lösung wäre evtl. auch für andere interessant gewesen ....

    bezüglich matchbox-keyboard erlaube ich mir, diesen Thread aufzublasen und auf meine Erfahrungen zu verweisen:


    Installation z.B. https://ozzmaker.com/virtual-keyboard-for-the-raspberry-pi/ -- ich weiß aber nicht, ob es noch andere Anleitungen gibt.

    Vor einem Jahr habe ich in diesem Thread Hilfestellung geleistet.

    ich verwende diese virtuelle Tastatur auch bei meinem yamuplay, siehe hier, Abschnitt "Sonstiges" (ziemlich unten).

    lese ich das richtig,

    dass im Quellcode die Bestandteile, die für das geplante Netzwerk-Tracking zuständig sind, per Default inaktiv sind?


    Ich könnte mir da im C-/C++-Code irgendwelche #ifdef's vorstellen, z.B. sowas:

    Code
    #define TRACKING FALSE
    
    #ifdef TRACKING
        <Tracking-Code>
    #endif

    Dann könnte man sich mit audacious wieder anfreunden...

    EDIT:

    Diese Aussage ziehe ich hiermit zurück, da war ja noch das:

    Abwarten welcher Fork nutzbar sein wird. Einer, tenacity, hat leider gerade seinen Maintainer verloren.

    Das was mit cookiengineer gemacht wird, geht ja gar nicht!


    Quelle der Policy-Änderungen:

    https://github.com/audacity/audacity/discussions/1353

    Überschrift "Building from source"

    Zur festen Einstellung der Bildschirmauflösung siehe auf der Seite der RPi-Foundation die Themen Raspberrry Pi Documentation - HDMI config und video options in config.txt.


    Grundsätzlich ist die Erkennung von "exotischen" Bildschirm-/Displayauflösungen über die vom Anzeigegerät über HDMI zurückgelieferten EDID am RPi nicht so prickelnd. Das kann jeder PC mit handelsüblichen Grafikkarten besser. Bei einem Display mit 800x480 hatte ich vor einiger Zeit das Problem, dass der RPi beim Booten eine Auflösung von 640x480 eingestellt hat. Rechts waren dann 160 Pixelspalten entweder schwarz oder mit farbigen vertikalen Streifen. Auch bei mir hat ein PC die Auflösung 800x480 jedoch problemlos geschluckt.


    Richtig gut hingegen eignet sich der RPi, in der /boot/config.txt die richtige Auflösung für solche Displays fest einzustellen. Dann funktioniert es problemlos und beim Booten muss der Monitor nicht einmal an der HDMI-Buchse des RPi angesteckt sein.


    Probiere mal folgende Einträge in der /boot/config.txt:

    Code
    hdmi_ignore_edid=0xa5000080
    hdmi_force_hotplug=1
    hdmi_group=2
    hdmi_mode=87
    hdmi_cvt=1920 480 60 3 0 0 0

    hdmi_ignore_edid: Auslesen der (optimalen) Bildschirmauflösung beim Booten nicht durchführen

    hdmi_force_hotplug: Beim Booten den HDMI-Ausgang des RPi auch aktivieren, wenn kein HDMI-Gerät dranhängt

    hdmi_group=2 / hdmi_mode=87: Videodaten werden manuell festgelegt.

    hdmi_cvt=... Konfiguration der Bildschirmauflösung: X Y fps (die hinteren Werte sind nicht so wichtig)


    fps ist die Bildwiederholrate (im Beispiel 60Hz)


    Wenn dies noch nicht fruchtet, kann man die Videoausgabe auch detaillierter konfigurieren. Anstelle von hdmi_cvt=... verwendet man den Eintrag hdmi_timings=...

    Dazu muss man aber die technischen Daten des Displays kennen, insbesondere die Länge des Blankings (Austastlücke für die Bildsynchronisation). Wobei manche Displays hier relativ tolerant sind und eine große Streuung der Werte vertragen.

    Probiere auf gut Glück mal diese Werte

    Code
    hdmi_timings=1920 0 50 28 50    480 0 20 5 20   0 0 0 60 0 64512000 3

    von mir nicht getestet ;)


    Siehe auch diesen Thread von mir zu dieser Thematik...

    EDIT: und diesen Thread im Forum der RPi-Foundation offtopic!
    EDIT2: oder in Meine Tipps und Mitwirkungen den Abschnitt HDMI


    EDIT:
    RTFM war schneller

    echt schade um dieses Projekt!

    Erst gestern habe ich es mal wieder per sudo apt install audacity auf meinen Ubuntu-Rechner heruntergeladen, da kurzfristig benötigt. Version 2.3.3. Ich weiß nicht, ob diese Version auch schon "verseucht" ist...

    Das Buch "Rapberry pi-das umfassende Handbuch" von Rheinwerk Computing. Das Buch ist etwas alt (2016).

    Dieses Buch habe ich auch, sogar zweimal, in Auflage 1 (2014, bis RPi B+) und Auflage 6 (2020, bis RPi 4)

    Es ist ansich sehr empfehlenswert!


    Bezüglich des Flashens unter Windows schreibt der Autor in der 1. Auflage von 2014 allerdings:

    Quote

    Unabhängig davon, ob Sie unter Windows, OS X, oder Linux arbeiten, sollten Sie auf jeden Fall zuerst die SD-Karte Formatieren. Theoretisch wäre das gar nicht notwendig: beim Schreiben der Image-Datei werden ohnedies die Partitionstabelle und alle auf der SD-Karte befindlichen Dateisysteme überschrieben. In der Praxis hat sich aber gezeigt, dass Image-Writer viel seltener Probleme verursachen, wenn die SD-Karte leer und frisch formatiert ist.

    Dazu kann man stehen, wie man will, Stichwort: unnützer Verschleiß der Flash-Speicherzellen auf der SD-Karte durch unnötiges Formatieren.

    Aus eigener Erfahrung kann ich aber berichten, dass mir zu Anfang meiner RPi-Zeit (2015) unter Windows 7 genau das passiert ist, dass das Schreiben des Images mit win32diskimager auf einer bereits für den RPi beschriebenen SD-Karte fehlschlug. Nach dem Formatieren der SD-Karte lief es jedoch problemlos. Ich führe das auf die zwei Partitionen der Raspbian-SD-Karte zurück, von denen die ext4-Partition am Windows-PC mit reinen Bordmitteln nicht richtig verarbeitet wird.

    Nach dem Umstieg am PC auf Linux (2016) und Flashen mittels dd ist mir so etwas nie mehr untergekommen. Wohl aber, dass beim Entfernen der SD-Karte aus dem PC nach Ende von dd das Image korrupt war. Abhilfe: nach dem Kommando dd das Kommando sync ausführen. Aber formatieren musste ich unter Linux nie.


    Fazit:

    Egal welches Betriebssystem und/oder Programm man verwendet, es gibt überall spezifische Fallstricke. Der Raspberry Pi Imager der RPi-Foundation ist jedoch so programmiert, dass man die SD-Karte vorher nicht zu formatieren braucht. Unter Win10 verwende ich nur noch diese Software.

    Nimm tatsächlich den Raspberry Pi Imager für Dein Betriebssystem (Ubuntu, Windows, Mac OS) und beschreibe damit die SD-Karte. Bei der Auswahl des RPi-Betriebssystems ist erste Option das aktuelle Raspberry Pi OS (Desktop-Version). Die aktuelle Version wird beim Installationsvorgang von der Homepage heruntergeladen und auf die SD-Karte geflasht. Warten bis der Imager komplett fertig ist und die neu geflashte Karte in den RPi stecken.


    Den RPi vor dem Einschalten am Bildschirm (HDMI) anschließen und mit dem Original-Netzteil betreiben. Nach spätestens einer Minute sollte das RPi hochgefahren sein und der Desktop auf dem Bildschirm erscheinen.


    Viel Glück!

    Ich habe mit dem OnOffSHIM bei meiner Phoniebox auch Probleme gehabt:

    Beitrag #27

    Beitrag #31

    Beitrag #34

    Es war so, dass bei zu langem Betätigen des OnOffSHIM-Tasters während des Ausschaltens keine wirkliche Abschaltung stattfand. Erst ein Relais (Beitrag #34) konnte das Problem lösen. Das Problem habe ich auch in meinem (ansonsten derzeit leider veralteten) Pamphlet beschrieben.

    Und wenn man sich dann noch an den grundlegenden und vorgeschriebenen Funktionsumfang eine Autos erinnert, komme ich mit der 100 µA Rechnung irgendwie ins Straucheln !

    Du kommst damit möglicherweise schon ins Straucheln, der Rest kapiert's.


    Dein eingeschaltetes Stand-/Parklicht ist schlichtweg kein Standby-Betrieb. Es läuft auch nicht

    knappe 180 Stunden

    wie von Dir für sowas in dieser Leistungsklasse vorgerechnet, sondern vielleicht mal 8-10 Stunden.


    ...und was hat die (Nicht-)Einbindung eines Stromverbrauchers in das interne Bussystem des Fahrzeugs mit der Kapazität der Autobatterie zu tun? Im übrigen hat der Unilink-Bus (siehe auch hier) in Car-Hifi-Komponenten von Sony nichts mit dem internen CAN-Bus moderner Fahrzeuge zu tun.

    Man merkt mit jedem Beitrag von KadK einmal mehr: Viel Gelaber, nix dahinter.


    Ansonsten: Eat this ><))))°>

    Nur komisch, dass Zubehörkomponenten im Automotive-Bereich im Standby nicht mehr als 100µA ziehen dürfen. Solche Vorgaben seitens der Automobilindustrie kommen ja nicht von ungefähr.


    EDIT - Schwank aus meiner jugend
    Ich hatte mal einen Sony-Radio mit CD-Wechsler und DSP verbaut. Ansich richtig geil, aber dieses Gebilde zuzelte mir innerhalb von 3 Tagen die Batterie so weit leer, dass der Motor nicht mehr ansprang. Ein Nachmessen zeigte, dass das Radio auch im ausgeschalteten Zustand >100mA zog. Der Grund war, dass die Power-Off-Kommandos über den proprietären Sony-Unilink-Bus von den peripheren Komponenten anscheinend nicht immer richtig verstanden und verarbeitet wurden. Daraufhin habe ich das Zeug schweren Herzens ausgebaut, aber von da ab war Schluss mit leeren Autobatterien.

    Das Ganze wäre mir evtl. gar nicht aufgefallen, hätte ich das Auto jeden Tag gebraucht und wäre die Batterie dadurch immer geladen worden.

    ...und auch bei der Polizei wurden die Displays im Gehäuse so verbaut, dass sie (eigentlich) auf dem Kopf stehen und die Bildausgabe um 180° gedreht werden muss, denn der dünnere schwarze Rand ist unten. Dann ist das Bild (wie bei meinen Raspiblastern) vom Blickwinkel her besser.

    In der /boot/config.txt braucht man dann die Zeile

    Code: config.txt
    lcd_rotate=2