Beiträge von Achromat

    Hi,

    ich habe ein Kontrollprogramm für eine Maschine auf dem RPI laufen, via mini Touchscreen. Leider kann der Betrachter den Bootvorgang die Himbeeren und das Desktop sehen bevor die Anwendung Chrom im Kiosk (Vollbild) startet, ich würde jetzt einen IO Port definieren mit dem das gestartete Programm den Bildschirm zuschaltet was sehr unschön wäre.

    Frage: Gibt es eine Möglichkeit den Bildschirm erst zu starten nach dem die Anwendung läuft ?

    Danke für Hinweise
    Karsten

    Hi,

    i have build an webserver with pi cam , i have integrate the libcamera in the bull eye case, all older projects are died with camera lost after bull eye, since one year we try to repair the situation so that we can use the older projects in this future.

    An problem an libcamera is not only the max/min values are all wrong given from driver, the Shuttercamera is not able to stop auto exposure.
    Means on light source is dimmed, the camera shutter re adust the sensor and this is not want.

    I have try out stop the auto exposure in the imageaquire loop with that :

    Code
    libcamera::ControlList& controls(request->controls());
     controls.set<int32_t>(libcamera::controls::AeExposureMode, libcamera::controls::AeExposureModeEnum::ExposureShort);

    But no effect, the running project is explained here

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Have anyone an idea how the AutoExposure can be turned off total ? (from trigger the camera we can only dream atm).

    Thanks for any Help in this case.
    Karsten from Berlin

    Hallo,

    letztes Jahr hatte ich ein umfangreiches Projekt zur Cameradarstellung in Bulleye hergelitten, es lief ein eigener Webserver mit Livebild und Motorsteuerung. https://youtu.be/FxZBHJ5FWDg

    Nun kam nach Monaten des Betriebes ein Update weil der PI internet hatte hat er das auch installiert, in dieser Folge sind sämtliche Cameras ausgefallen, der Versuch

    eine Camera zu starten via

    m_CameraManager = std::make_unique<libcamera::CameraManager>();
    m_CameraManager->start();

    Schlägt fehl, das System stürzt ab mit der Meldung

    [0:12:19.176036656] [5699] INFO Camera camera_manager.cpp:284 libcamera v0.1.0+118-563cd78e
    [0:12:19.189253326] [5784] INFO RPI pisp.cpp:653 libpisp version v1.0.4 6e3a53d137f4 14-02-2024 (14:00:12)
    terminate called after throwing an instance of 'std::out_of_range'
    what(): unordered_map::at

    Wir haben versucht vom PC weg zu kommen, und schreiten vom Regen in die Traufe.

    Danke falls jemand eine Ahnung hat warum es nicht mehr funktioniert. Wir wissen es nicht, man hat mit der Katastrophalen "Libcamera" eine ganze Generation von PI's tot gemacht.

    Und die die umgebaut haben, erleiden jetzt schwerste Niederlagen mit dem verfluchten dummen libcamera Unfall.

    Danke für Hinweise
    Karsten aus Berlin

    Hallo,

    aus widrigen Gründen muss ich in meinen Webserver das libcamera Interface als Ersatz für das mmal lib von Brodcom integrieren.

    Dabei stieß ich auf schwere Probleme / Fehler bezüglich der gültigen Parameter Ranges für die Kamera wie saturation,gain,exposure,sharpness usw..

    Ich erlange die Ranges nach dem verbinden der Kamera mit den buffers:

    Wie man sieht musste ich alle Parameter händisch anpassen, damit kein völlige Übersteuerung der Kamera statt findet. Diese Ranges die ich erhalte sind alle samt nicht auf die Kamera übertragbar bezüglich Min/Max

    Die Parameter selber erlange ich über eine Webseite wo der User 100% Slider betätigen kann, diese transformiere ich bei der Benutzereingabe auf den Physikalischen Range der Kamera :

    In der callback Funktion von LibCamera hat man die Möglichkeit an einer Stelle die neuen Werte an die Kamera zu übertragen funktioniert auch soweit :

    Die Frage ist nun, warum erhalte ich falsche Ranges von dem Interface ? Ich habe dazu sogar ein Video her gelitten :

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Die Frage ist wer hat schon Erfahrungen mit dem Parameter setup von libcamera (a pain deep in the ass)

    Danke für Hinweise

    Karsten aus Berlin

    Liebe , sexx(Mit einem x) hier zensiert ! , weinachten--

    Und da stellt sich hier am ende heraus, die 100% Last des threads, kam dadurch zustande das Asynchrone Sock-Reader weiter liefen ohne zu enden , nun reicht auch usleep oder voc_sleep

    Man irrt sich empor.

    Grüße aus Preußen

    K.

    Hi,

    after an long jury , i have found the problem.

    usleep() Dosent give CPU Load back ! and too the vcos_semaphore_wait_timeout give not back CPUZ Load !

    only an sleep(0) give back the 99% load in loops , that was new on pi 5 ?

    thx for help

    Hi,

    i have an rpi5 with passive cooling , in this case i have an socket loop they runs free unblocked, each accept runs with more then 200Khz per loop, so i reduce the cycle time to accept clients with usleep().

    For normal usleep give back the CPU Load and the pi can come to cool down.

    But, the effect is, if an client has become an sock via accept, it runs over many hours thermal normal.

    if the client disconnect, the temperature falling for 5 minutes down, and then they will fast groving without connected clients and this in a reduced wait loop with only 50Hz to wait for new sock clients. (Some usleep is active why heating now ?


    My Accept Loop is under construction and looks like this :

    The question is, why the unblocked Socket runs after period of idle into hight temperature ?

    Without watching he will run empty with sleep into 80C° but it runs normal with 38C° if an client use the socket.

    After discon the socket , the temperature will incrase into termal self destruction, after 60C° The socket stops working vor new clients complettly.

    If i turn on a Fan the situation goe's after some minutes into normal state, what is damming heating nothing is runs SLEEP give not up CPU Load ?

    Thx for any helps same on rpi 3 runs without problems.

    Output of this loop:

    Temp=51.2 strating thermal reduction Ceff=3

    Fps=0.0 [Hz] Rx=0.0 [Kb/s] Tx=0.0 [Mb/s] Temp=51.2 [C] Mem=643.8 [Mb] FrmNotSnd=0 [n/s] AccFrq=25.0 [Hz]

    Temp=51.2 strating thermal reduction Ceff=3

    CWebServer::RunHttp terminated

    thx

    Hi ich programmiere gerade die Pi Camera in einen Mini-Webserver ein, und streame damit jpeg Files die ich im Chrome laufend anzeige.

    Kennt jemand den Streamformat - Header für VLC oder und vor allem IP Cams ? Da wird ein Header hin gesendet und zurück indem die File Size des jpg's im Vorfeld übertragen wird.

    Dazu verwende ich ein 128byte Array das an bestimmten Positionen die Size vor dem jpg ab sendet, der Stream läuft auch mit meinem eigenen Empfängerprogramm das auch Edimax IC1500 damit empfängt. Leider kann die Edimax IP-Kamera(Kein rasperry gerät) nun mein eigenen RPI -Stream nicht lesen.

    Danke für Hinweise , filme dazu habe ich auf Twitch

    Externer Inhalt www.twitch.tv
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Grüße aus Berlin
    Karsten

    Hallo zusammen,

    ich bin recht verzweifelt, denn nach einer langen Jury der Entwicklung kann ich meine erzeugten *.h264 Videos die mir vom MMAL Decoder geliefert werden
    nicht über meinen Server streamen ogg usw funktiniert, die browser unterstützen das Format im Html5 Video Tag nicht.

    Versuche eine kompatiblen Stream zu erzeugen schlugen fehl !

    Kennt jemand eine Möglichkeit ein h246 in einem mp4 einzubetten ? Oder hat jemand eine Lösung gefunden ?

    Hier eine Versuchsserie :

    Externer Inhalt www.twitch.tv
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Vielen Dank für Hinweise

    Karsten aus Berlin

    Hallo ,

    ich habe auf meinem rpi2 Pixel/Jessy und besitze ein LCD Display 3.5 Ich RPi V3.0

    Jetzt gibt es einen Blog der beschreibt wie man das Display zur Ansicht bringt:

    https://marazt.wordpress.com/2016/12/06/set…aspbian-jessie/

    ODER:
    https://iwannabe1337.wordpress.com/2016/03/26/rpi…h-rpi-lcd-v3-0/

    Alle Schritte habe ich durchgeführt, das Display bleibt aber davon unberührt.

    Nach Rückstellung des Parameters aus : /usr/share/X11/xorg.conf.d/99-fbturbo.conf.
    zu fb0 läuft alles wieder normal.

    Frage wie kann man das Display überhaupt verwenden, ich hatte mal ein Image das
    startete dann direkt mit dem Display, das war dann das älte Debian.

    Eigentlich möchte ich das parallel betreiben und Pixelbasierend darauf zugreifen..
    Anstatt den Desktop darauf abzubilden das kann ja nicht der Sinn sein.

    Vielen Dank für Hinweise
    K. aus Berlin.

    Nachtrag Sparmaßnamen erweitert.

    Nach der Festsetzung auf 600Mhz liefen die Systeme störungsfrei, jedoch nach 20 Stunden Dauerbetrieb ist der Akku nicht mehr
    der schärfste.

    Das Blinken war wieder da. Nun konnte durch abschalten des Bluetooth und des HDMI weiter Leistung reduziert/gespart werden,
    so das es nun bis zum ende des Akkus ausreicht.

    sudo nano /etc/modules
    # ic2 markiren ausmarkieren schaltet den Header ab ggf. hier auch noch andere Hardware enthalten

    Spannungsfrei schaltbar ist auch die interne Soundhardware
    In der letzten Zeile der Pixel distribution:
    sudo nano /boot/config.txt
    unten BCM hardware abschalten on durch off ersetzen.

    Seither rödeln de Pi's ungeblinkt. Sogar das erlauben auf 1200 zu kommen funktioniert dann wieder.
    Eine kleine Vox-Steuerung das nur gesendet wird wenn genug Amplitude da ist, spart Unmengen Strom
    der Pi hat an das W-Lan viel Strom zu geben..

    Grüße
    Karsten

    Du der Akku muss ein USB Lade Akku sein mit 5V , dies ist die spec. Es ist rein technischer Aspekt alles läuft wunderbar stabil

    Und jetzt :

    Wenn man den Raspberry dadurch neu startest, indem man nach dem runterfahren den USB Stecker aus der AkkuBank zieht, ohne diese durch den Druckschalter abgestellt zu haben (Down time push),
    wird die Akkubank beim nächsten wieder einstecken des Pi's diesen mit weniger Strom versorgen. Es wurde die Spannungsbegrenzung aktiviert, über den Controller des Akkus.

    Der Akku muss also heruntergefahren werden um spannungslos zu sein, dieser enthält auch eine lade -Id für das Ladegerät.

    Ok dann werde ich mal lieber nichts mehr zu diesem Thema schreiben, für mich war es Bericht über eine lange Fehlerkette, und im Ernst ich hätte sie auch alleine aufgelößt,
    schade das keiner daran nutzen finden kann.

    bis bald

    Du hast ja gar nicht verstanden um was es geht ! Sicher kann man alles kaufen. Es geht so aber auch. Das ist wunderbar, denn der Akku
    muss auch anderen Spezifikationen genügen !

    Du bist einfach sehr unzufrieden mit Dir selber.

    Na ich tippe mal auf den Forumsclown, gibt es überall. Basiert auf ein Aufmerksamkeitsdefizit das ist behandelbar wie alle technischen Probleme.
    Ich kann den Thread nur empfehlen zeigt er wie nach und nach Problemketten sich vertiefen lassen bis hin zum Syndrom.
    feine Grüße
    aus Berlin
    Karsten


    Du hast mich erneut davon überzeugt das es Dir an Erfahrung und Wissen mangelt...

    Ich brauche keine weiteren Regler und keine weiteren Teile eine geniale Lösung
    übrigens glauben ist das Gegenteil von Wissen. (Das muss man sich nämlich erarbeiten)


    Hallo,

    wenn ich den Raspi über Batteriebetrieb laufen lassen müsste, würde ich einen normalen 12 V Akku nehmen. Bei Ebay gibt es Spannungsegler mit einem LM2596S, wo man die Spannung über ein Poti mit Feineinstellung exakt enstellen kann, für 1 € . Die geben bis 3 A sehr stabile Spannung ab. Und weil die Eingangsspannung bis über 30 V steigen kann, ohne das sich die Ausgangsspannung ändert, kann man jeder Zeit ein Ladegerät anhängen.

    Das ist mit Sicherheit preiswerter und stabiler.

    Hallo,

    also der Betrieb mit einem gepulsten Akku der 5V liefert via USB erzeugt Probleme wenn die CPU hochfahren möchte beim PI3
    ist die Grundfrequenz 600Mhz wenn die CPU resourcen braucht, steigt der Stromverbrauch und sie darf bis 1200Mhz hochfahren.

    Beim PI 3 wurde das rumfingern in der Overclocking ausgeblendet.

    Lösung mit der gepulsten Akku Katastrophe ist es, selber die Config für die Maximale Hochfahr-Frequenz zu setzen. Und zwar genau auf die Frequenz
    die immer Standard sein sollt 600Mhz

    Dazu : sudo leafpad /boot/config.txt

    #uncomment to overclock the arm. 700 MHz is the default.
    arm_freq=600

    Eintrag auf 600 und die CPU versucht es nicht mehr hochzuziehen auf 1200 oder auch nur 700 schon das verursacht ein Energieversorgungsproblem
    mit der gepulsten USB-5v-Akku-Spannung. Der ganze Baustein kommt in einen desolaten Zustand, und die Power LED rot zündet sporadisch.

    Soundausgaben oder geregelte Datenströme sind dann nicht mehr gesichert.
    Es gibt keinen Grund den PI mit bis zu 1200 laufen zu lassen am Akku, der Gewinn gegenüber der Abwärme ist gering, liegt bei 10-20%

    Die Störungen beim Hochfahren der CPU von der Grundfreunz 600Mhz erzeugt im externen USB Audiosystem Störgeräche, bis soweit das
    die Linux-System Audiosoftware ALSA den Kontakt zum Device verliert, oder in einem bis zum Reset feststehen Zustand verkommt.
    All das kann also im Akku-Not-Betrieb verhindert werden, und so laufen die PI's auch recht lange, denn sie ziehen immer nur rund 400mA.

    Grüsschen
    Karsten