Posts by McDotter

    Hi nochmals,


    ich besitze zudem noch 2 alte Asus eeePC 1001H, aufgerüstet auf 2GB RAM, aber ohne Datenträger - wenn jemand meint, sie/er würde sich ne alte 160er HDD dazu wünchen, ich kann ja mal sehen, was in meinen Schubladen so herum gammelt und sich noch komplett wipen lässt...


    Netzteil gehört dazu, und der Zahn der Zeit war äußert gnädig zu ihnen (keine mir bekannten Defekte); vor Abgabe würde ich sie natürlich nochmals testen

    Hallo,


    eben ist mein Blick auf zwei Uralt-Laserdrucker gefallen, die ich definitiv nicht mehr nutze, sie aber zu entsorgen wäre "ne Schande", sollten sie irgendwo ein neues Zuhause finden können. Von daher die Frage: hat wer Interesse an einem Brother HL-2070N (SW-Laserdrucker, LAN & USB) oder einem Samsung SCX-4100 (S/W Multifunktionslaserdrucker, USB)?

    Bei beiden Laserdruckern dürfte die Trommel und der Toner auswechslungswürdig sein.


    Für einen Funktionscheck wäre ich sogar bereit, ein altes XP auf einem eePC aufzuspielen, um die Drucker zu testen, sofern ich die Treiber noch irgendwo auftreiben kann.

    Für die, die im Zweifel doch mal einen Lüfter benötigen: ich habe dieses Gehäuse.

    Ich hab das Ding da auch - mit den beiden Lüftern, und ich finde, die sind zumindest bei mir Quatsch. Denn sie sind laut, laut und nochmals laut.

    Aber wie picollo schon gescrieben hat, ohen die Lüfter geht es auch. :bravo2:



    [...]

    Ich nutze ein Argonone m.2 Gehäuse für meine Raspberry Pi4 2GB mit Raspios bullseye lite (64-bit). Das script für die Lüftersteuerung habe ich installiert. Argon empfiehlt die Option 2 der Konfiguration zu nutzen mit 55C = 10%, 60C = 55%, 65C = 100%. Im Normalbetrieb erreiche ich eine Temperatur von ca. 43C. Da würde der Lüfter erst gar nicht anlaufen. Ich wollte jetzt die Option 3 (Custom) nutzen mit 40C = 30%, 50C = 70% 65C = 100%. Wenn nun die Temperatur die 40C überschreitet, wird der Lüfter aber mit voller Leistung angesteuert. Sinkt die Temperatur unter 40C, schaltet der Lüfter ab. So war das nicht gedacht.

    Tipp von mir, der einen ArgonOne Artic HAT besitzt, der iirc ja auch im (auf einem ArmorCase aufgesteckt - YEAH! Voll unnötig, aber geil):

    40C = 5% oder 10%

    50C = 20%

    60C = 50%


    30% können schnell den Eindruck erwecken, dass der Venti auf Volllast läuft. Wenn sich mein Setup von der Effizient her nicht dramatisch von deinem unterscheidet, dann kommste mit 10% in der Regel gut aus, und dann ist da ja noch die 20%-Stufe.

    Und egal, wie intensiv ich mein Setup einem Streßtest unterzogen hab, mehr als 50C schaff ich nicht.

    Hi TG002,


    kenn ich - da stimmte bei mir die Auflösung nicht. In dem Fall war es:

    ### User modification für LCD 10,1" 1024x600

    max_usb_current=1

    hdmi_group=2

    hdmi_mode=87

    hdmi_cvt 1024 600 60 6 0 0 0

    hdmi_drive=1

    hdmi_force_hotplug=1


    800x480 ist ebenso wie 1024x600 KEINE Standardauflösung und wird normalerweise von Raspberry Pi OS (oder ARMbian, oder Ubuntu) NICHT out of the box unterstützt. Bei ARMbian (für das Tinkerboard S) fahr ich teilweise sogar blind, bis ein Script die Auflösung beim AutoLogin einstellt...


    vielleicht hilft die einer oder beide Ergänzungen: max_usb_current=1 und/oder hdmi_force_hotplug=1



    Was ich auch kenne, ist, wenn die Stromversorgung zu wenig Saft liefert, dass die Farben falsch dargestellt werden.

    Ich verstehe den TO zu 100%.

    Es ist echt nervig, wenn man sich nen Datenträger (hier SSD) unter einer älteren Version eingerichtet, /home auf eine eigene Partition ausgelagert, dann diverse Verzeichnisse liebevoll angelegt, gefüllt, verlinkt, das System/den User final eingerichtet und, und, und ... hat und dann, mit ner neuen Version, muss man das alles noch mal von vorne machen???


    Da ich auf allen Systemen Ubuntu Mate betreibe (auch auf den RPi4's) und auf den Raspis es das gleiche Dilemma ist wie auch mit Raspberry Pi OS - bei den PCs es aber schon beim Partitionieren ganz einfach ist, nur die Systempartition zu formatieren/aktualisieren, die ausgelagerte /home aber nur eingebunden werden muss - und beim Raspi bei allen mir bekannten Wegen (dd bewußt jetzt ignoriert, siehe Kommentar von rasp-Berlin) es eigentlich immer(!) auf "komplett Platt machen und alles neu aufsetzen" hinausläuft, wäre auch ich sehr an den Luxus einer individuellen Partitionierung und selektivem Auspielen der beiden Partitionen /boot und /root (oder wie immer die in den einzelnen Distros heißen) sehr interessiert.


    Was ich bisher so (anfangs vielleicht noch erfolgreich) probiert hatte bzw. noch ausprobieren/optimieren wollte:

    Bei kleinen SSDs geht es ja noch, wenn man vorher von der ausgelagerten ( :gk1: Idee: vor dem Image verkleinern? ist aber schon wieder von hinten über die Brust ins Auge...) /home ein Image zieht, die SSD dann mit dem Imager neu bespielt und vor dem ersten Booten mühsam /root wunschgemäß vergrößert, /home zurück speichert, (Idee: dann wieder Größe anpasst) und in der fstab einträgt, damit sie dann beim ersten Booten eingebunden ist, wenn man dann den User anlegt (bzw. in früheren Versionen von Raspberry Pi OS "umzieht").

    Das ist eine umständliche Lösung für kleine Datenträger (ich sag mal so bis 120GB - die Schmerzgrenze ist aber sicher sehr indiviuell gelegen), aber ab ner gewissen Größe zu zeitaufwändig.


    Alternativ
    kann man das neue System erst mal auf nen USB aufspielen, die beiden angelegten Partitionen als Image sichern und dann auf die SSD neu aussetzen - das große Problem dabei ist aber, dass man da in Probleme bei den Partitionsgrößen rennt (und da geht es um Sektoren, wenn ich mir das richtig zusammen gereimt habe). Ist man also schon wieder schnell nass.

    Theoretisch könnte man sich dieses Vorgehen von Anfang an angewöhnen (also bevor man eine /home überhaupt zum ersten Mal ausgelagert hat) immer den gleichen USB (mit der optimalen Größe für /boot und /root) und SSD nehmen, nach dem Neu-Bespielen des USB jedemal händisch die Größe von /root maximieren (aber es gibt keine Garantie, dass bei künftigen Versionen dieses Vorgehen erfolgreich bleibt, denn wenn sich die Größe von /boot ändert, kann alles für den Eimer gewesen sein...)

    Ah, und /home müsste man wohl besser als Primäre Partition (statt erweiterte) einrichten - und es wäre sinnvoll, etwas ungenutzen Platz zwischen /boot, /root "vorne" und /home "hinten" zu lassen, dann wäre eine Größenänderung bei den beiden ersten wohl nicht weiter tragisch.


    Alle meine (halbgaren) Lösungen und Ideen verlangen aber eine gewisse Grundkenntnis der Datenträgerverwaltung - Neulingen rate ich wegen den Gefahren durch Fehler, die man normalerweise macht, dringend ab. (Bei USBs ist ein totalverlust vielleicht noch zu verschmerzen, bei SSds finde ich, hört der Spaß aber echt auf - und das kann echt passieren, wenn es dumm läuft)


    Wenn endlich Ubuntu Mate 22.04 für den RPi4 rauskommt, werde ich den Ansatz mal testen (indem ich mal hin und her wechsle zwischen Mate und Raspi OS.

    Kann ja dann berichten, ob das "Geschwurbels" (eine saubere Lösung sieht definitiv anders aus) erfolgreich war.

    Hallo an der_verwalter und TG002


    für euch beide die gleichen Fragen:


    1.) was passiert denn, wenn du dem Display eine eigene Stromversorgung gönnst?

    2.) hast du in der config.txt Befehle zur Einstellung der Auflösung des Displays angegeben?


    kann mir gut vorstellen, dass 1.) das Problem löst.

    Das Thema Fernbedienungen unter Kodi ist so ein Thema für sich - z.B. ist IR anstecken und einfach Fernbedienung nutzen nicht in jedem Fall "out of the box" so wie man es erwartet.

    Kodi kennt ein paar Fernbedienungen (weitere über Repos) und mappt deren Tasten auf die interne Codierung um.


    Heißt, nicht jede Fernbedienung liefert den Code für eine Taste, die Kodi automatisch zuordnen kann. Da gilt es dann, selbst Hand anzulegen und zu optimieren.

    Zur Zeit kursieren im Netz etliche Meldungen, dass die Grafikeinheit auf dem RPi4 auf den WLan Kanälen 1,2,3 auf dem 2,4GHz Störungen ausgibt (Interferenzen), wenn die Bildschirmauflösung 1920x1080 oder höher beträgt.

    Problem tritt bei niederigeren Auflösungen nicht auf, ebenso wenig, wenn das onboard-WLan durch ein mittels Kabel weiter entferntem USB-WLan ersetzt wird.

    Im 5GHz-Bereich, so wird berichtet, kommt es nicht! zu Störungen.

    Sicherlich eine überflüssige Frage, aber schaden tut die frage nun auch wiederum nicht:

    hattest du nach der Installation auch die Aktualisierungsverwaltung gestartet und dann unter Anwendungen und Aktualisierungen / Zusätzliche Treiber nachgesehen, ob dir ein propietärer Treiber angeboten wird? Ist auf meinen Laptops notwendig, weil die WLan-Mudule oft nicht (mehr) out-of-the-box funzen...

    Statt den Kernelringbuffer mit dmesg -c zu löschen, könnte man auch dmesg -wH verwenden ( dann mit Strg+C abbrechen ).

    Von Interesse ist auch die Info mit fdisk -l bzw. lsusb -v -d vendor:id manche Sticks zeigen nach unzeitigen Entfernen auch nur die Größe vom Flashram des Controller bzw. 0MB, dann hilft evtl. nur noch ein zum Controller passendes Produktionstool, dafür muß man aber dessen Typ & den verbauten Flashspeicher kennen.

    Afairc war die Speichergröße unauffällig ausgewiesen. 0MB oder so wären mir ins Auge gesprungen.

    Hallo und allen ein gutes Neues Jahr.


    habe mir (mal wieder) einen USB-Stick (zum Glück noch keine SSD) an einem HUB final zerschossen:@ weil ich während eines Schreibvorgangs einen weitere USB-Stick angeschlossen (soweit ja noch okay) und dann (das war dann "die Bombe") angeschaltet hatte.

    (für eine klare Beschreibung der Konfiguration: HUB am USB3-Port eines RPi4, Datenträger am HUB mit externer Stromversorgung; jeder USB-Anschluß am HUB einzeln an-/abschaltzbar; RPi4 mit original Netzteil versorgt)


    Bei dem besagten USB-Hub handelt es sich um einen USB3-Hub mit 7 einzeln schaltbaren USB-Anschlüssen mit der Option einer externen Stromversorgung.

    Es war auch nicht das erste Mal, dass ich mir einen USB-Stick zerschossen habe, und es funktioniert sowohl am PC, Laptop oder eben am Raspi.


    Ich bin 100% sicher, dass es definitv am Einschalten eines USB-Anschlusses während eines Schreibvorgangs auf einem anderen USB-Stick liegt (und dann das zu beschreibende USB-Gerät die Grätsche macht), unabhängig davon, ob der Hub eine externe Stromversorgung (5V 4A) hat oder über USB3 am PC mit (ausreichend) Strom versorgt wird.

    Da ein aktiver USB-Hub am Raspi seinen Reiz hat, will man ein bis mehrere Datenträger nutzen, ohne den Raspi zu überfordern, wollte ich hier berichten, dass dies auch schief gehen kann.

    Mein Modell (SE-USB3-HUB-317i, Conrad Electronic SE) ist ein 6+1 USB3-Hub (1x Charge-USB) (jeder USB-Anschluss mit Schalter) für max. 5V 4A externe Stromversorgung.


    WÜnsche euch keine solche Erfahrungen.

    Hi an Alle,


    falls sich jemand von euch für das FLIRC 2nd Gen USB Infrarot IR Adapter Dongle (siehe Foto) interessiert, hier meine Erfahrungen.

    Link zu BerryBase (Shop)


    Das Fasziniernde an dem Teil ist, dass es sich im Gegensatz zu den "klassischen" IR-Empfänger im System (PC- oder ARM-Plattform, diverse OS) als ein HID-Device anmeldet und die Knöpfe der IR-Fernbedienung "übersetzt" und als Tastendruck weiter meldet. Das ist zumindest zukunftssicher (zumal irda in neueren Kernelversionen nicht mehr enthalten ist).

    Konfiguriert wird der Dongle an einem PC/Raspi und kann danach ohne Installation von Software an jedem beliebigen Gerät als HID eingesetzt werden.

    Der "Haken" kann (nicht muss!) bei der Konfiguration lauern, sofern man keine vordefinierte Fernebdienung einsetzt.

    Insgesamt ist das Dongle sehr mächtig, da ht der Hersteller eine Menge einfliessen lassen.


    Und hier steig ich dann mal mit meinen Erfahrungen (auf eine x64-Laptop mit Ubuntu Mate 20.10 gemacht) ein.


    Das Konfigurationstool kann man als ZIP herunter laden - zu finden auf der Webseite des Herstellers unter

    https://flirc.tv/support/flirc-usb


    von dort gibt es mehrere Wege der Installation der Flirc-Tools


    als Paketquelle curl apt.flirc.tv/install.sh | sudo bash


    oder die generischen Links für 32bit oder 64bit


    Wichtig ist das "Kleingedruckte" ganz unten: es sind evtl. weitere Bibliotheken zu installieren:

    libhidapi-hidraw0 libqt5core5a libqt5network5 libqt5xml5 libqt5xmlpatterns5 libhid qt5-qtbase qt5-qtsvg hidapi

    interne Notiz: qt5-qtbase qt5-qtsvg sind nicht verfügbar, habe statt dessen qt5-default installiert


    bei Installation als Paketquelle ist folgende Regel bereits angelegt - falls nicht - oder bei manueller Installation - kopiere

    99-flirc.rules rules

    nach

    /etc/udev/rules.d/

    Note from Website: optionally copy flirc_util and flirc to /usr/local/bin/


    Danach sollten die beiden Programme Flirc (grafische Oberfläche) und flirc_util (Kommandozeilen-Tool) auf dem System verfügbar sein.

    Mit Flirc kann man Presets für die zu verwendende Fernbedienung auswählen und deren Tasten zuordnen, die Firmware aktualisieren oder im Debug-Mode die gesendeten Codes anzeigen lassen.

    Mit flirc-util kann man (Keyboard)Tasten bestimmen, die man in der Konsole händisch zuordnet. Anbei die Befehle, die flirc_util laut Hilfe versteht:

    delete Delete next remote button flirc sees from saved database
    delete_index Delete button at index displayed in `flirc_util settings`
    device_log Displays the log on the device
    dfu Kick in or out of Device Firmware Upgrade mode
    format Remove all saved buttons from flirc
    help Show this help. Also try `help <command>`
    interkey_delay set the interkey delay
    loadconfig Load configuration file from disk to flirc
    mode Enable or disable a usb mode
    noise_canceler Noise canceler to prevent phantom presses
    normal Put flirc in normal user mode
    profiles enable or disable built in profiles
    rb set settings for remote buddy configuration
    record Record infrared buttons and link them to HID keys
    record_api Advanced button recording
    record_lp Record a long pres key
    record_macro Record a macro key
    rom_table enable or disable a give rom table
    saveconfig Save configuration file to disk
    script run a command script
    sendir Send a packet over the IR transmitter
    settings Displays all the devices current settings
    shell enter into shell mode
    sleep_detect Turns on sleep/suspend detection
    unit_test Performs a self test
    upgrade Uploads new firmware image to flirc hardware
    version print the version
    wait Waits for the device to be plugged in (used for scripting)


    Error:

    leider verlangt das cmd-Tool flirc_util beim ersten Aufruf eine veraltete Lib, aber das kann über folgenden Sym-Link behoben werden

    # bei mir wird libreadline.so.8 vorgefunden - Version kann/wird sich künftig ändern, also evtl. Anpassung erforderlich.

    # folgende Befehle ausführen (evtl. nach Kernel-Update neu erforderlich???)

    danach hat das Tool bei mir seinen Dienst verrichtet.

    cd /lib/x86_64-linux-gnu/

    ls librea*

    sudo ln -s libreadline.so.8 libreadline.so.6


    Aber: die eingebaute Hilfe von flirc_util passte nicht zur aktuellen Firmware... :wallbash:

    so brach das Zuordnen der "vor"-Taste der Fernbedienung der Taste Keyboard-Taste "fastforward" über den Befehl

    flirc_util record fastforward

    mit einem Fehler ab - die Hilfe war nicht aktuell, es hätte

    flirc_util record fast_forward

    heißen müssen.

    Da die Software zum Glück auf github hinterlegt ist, hier eine Quellenangabe, wo man sich die neusten Daten/Infos holt:

    ### Supportd keywords for Flirc

    # https://github.com/flirc/sdk/b…cli/src/cmds/flirc_cmds.c


    Diese Zuordnungen (als Keyboard-Tasten) waren Anfang April 21 möglich:

    return

    enter

    escape

    backspace

    delete

    tab

    space

    F[1-12]

    a-z, 1-0

    printscreen

    scroll

    pause

    insert

    home

    pageup

    pagedown

    end

    right

    left

    down

    up

    suspend

    wake

    eject

    vol_up

    vol_down

    mute

    play/pause

    stop

    fast_forward

    rewind

    next_track

    prev_track


    das gibt dann schon eine Reihe an Möglichkeiten... :angel:


    In der Konsole kann man die Befehle auch als Batch eingeben, die man sich vorher in einem Texteditor zusammen gezimmert hat, um in einem Schwung z.B. eine Auswahl an Tasten zuzuweisen, da das Tool erst den Tastendruck der Fernbedienung abwartet, bevor es den nächsten Befehl abarbeitet.

    Nachteil wäre dabei, wenn man sich in der Reihenfolge verhaspelt...



    Probleme mit der Fernbedienung:

    Reproduzierbar musste ich an der einzurichtenden Fernbedienung zweimal die eine oder andere Taste drücken.

    Lauf dem Forum des Herstellers liegt das an der Fernbedienung, nicht am Dongle.

    Ich hatte mehrere Fernbedienungen (teilweise 10 Jahre alt), bei denen das auftrat - jede mit anderen Tasten, die nicht auf Anhieb erkannt wurden.

    Da das Problem nicht über die Tasten gewandert ist, sondern stets bei einer bestimmten Taste hing, geh ich mal davon aus, dass das nicht falsch ist.



    Fazit:

    Ich finde den Dongle mächtig, und eine interessante Alternative zur DIY-IR mit LIRC, aber beide Wege verlangen Handarbeit, wenn man für den Flirc keine vordefinierte Fernbedienung sein eigen nennt.

    Viele Informationen muss man sich zusammen suchen, deswegen habe ich den Text hier geschrieben. ;(

    Hi Berlon,
    melde mich etwas spät, aber ich war lange Zeit nicht mehr im Forum aktiv.

    Hatte auch das gleiche (oder ein sehr ähnliches) Problem wie du: der "blöde" Controller 152d:0579 von JMicron Technology Corp. wollte ums Verrecken nicht laufen... (allerdings an einer 128GB(!) Intenso...) - mit oder ohne usb-storage.quirks=152d:1579:u als ersten EIntrag in der bootline.txt


    War dann aber das Programm, mit dem ich die SSD bespielt hatte, was die Partitionen nicht korrekt aufgesetzt hatte (die Boardmittel von Ubuntu: Laufwerksverwaltung).

    Ich weiß es nicht mehr so genau, entweder hat es mit dem SD-Card-Kopierer von Raspberry Pi OS oder dem Raspberry Pi Imager for Ubuntu (https://downloads.raspberrypi.…ager/imager_1.4_amd64.deb) funktioniert - aber: da hatte ich zudem den USB-Stick und die SSD an einem aktiven USB3-Hub angeschlossen, und einige Sachen hintereinander ausprobiert (in der Session konnte ich gleich 3 SSD erfolgreich einrichten - allein schon ein USB-Stick und eine SDD am RPi4 macht Power-Probleme... und ne SSD zieht schon fast alles, was der Raspi über USB an Saft zur Verfügung stellen kann... mit "lsusb -v" kannst du dir die "maxPower" für die Devices anzeigen lassen)

    Während das Schreiben von Laufwerksabbildern immer meldete, ich hätte das USB-Stick-Image korrekt aufgespielt (mit USD-Stick hatte das Booten von USB hervorragend funktioniert), meldete GParted gar keine Partitionierung zurück - so könntest du z.B. überprüfen, ob du das gleiche Problem wie ich hast.


    Du hattest zwar geschrieben, du wärst nach der Anleitung vorgegangen, aber genau beschrieben, wie du vorgegangen bist, stand nicht dabei. Von daher ist es auch nicht klar, ob du die Anleitung Wort für Wort befolgt hast, oder "nur" im Großen und Ganzen.


    Hoffe, das hilft dir weiter

    Erstens:

    Malz1902 kannst du mal deine cmdline.txr posten? Vielleicht hat sich die geändert? (ein vergessesen "2" hinter /dev/sda kann echt nerven...)


    Zweitens:
    Hi STF

    schön, dass du dir den Link reingezogen hast. Aber, und ich hab bewußt geschrieben: "durchwühlen" - ich meinte das auch nicht ohne Grund so. :angel: (ich glaub, ich hab gestern über zwei Stunden wegen meinem Bootproblem gegoogelt, und die meisten Infos aus der Ecke gezogen (zu RPi gibt es ja leider nur wenige wirklich kompetente Quellen).

    Im Großen und Ganzen geht es in dem Thread und seinen Links auf andere Posts um Probleme, die besonders beim Übertakten einzelner RP4 auftraten und den Fixes an diverses Teilen der Firmware, um das wieder in den Griff zu kriegen.

    Und irgendwo in den vielen Beträgen erklärt einer von den Jungs ("jamesh", Raspberry Pi Engineer & Forum Moderator)

    in:

    (https://www.raspberrypi.org/fo…65a2c17708a7a389#p1599805)

    Quote

    This will be independant of revision or age. All chips come out of the fab with slightly different properties. There's a bell curve of those properties, a few are very close to the edges of the curve, and looks like the power management strategy is slightly too aggressive for those devices right at the limits. This applies to all the chips on the board, not just the SoC, and it could be a combination. Unfortunate we didn't see anything in testing, but this likely means it's very rare. Note, these are my personal thoughts on the matter, not an official Pi statement, and I may well be wrong!


    ich nehm das mal als eine sehr seriöse Quelle.


    Und aus den ganzen Threads heraus kann man ableiten, dass die Jungs in der Firmwareentwicklung nach bestem Wissen und Gewissen auch mal eine raushauen, bei der ein (im Sinne von im ppm-Bereich oder so) RP4 nicht mehr mitmacht - ob übertaktet oder nicht...

    Dann zieht man eben ein neues Image und setzt neu auf oder investiert ein vielfaches an Zeit für eine exakte Fehleranalyse (je nach Aufwand der bereits durchgeführten Anpassungen der eigenen Raspi-Installation).

    Ich persönlich setz meine Systeme gerne mal neu auf und hab dann Ruhe.

    In meinem Fall war das die Lösung (nicht die cmdline.txt, bei mir ging nix mehr, weder SD noch SD/USB).