rtl_433 Programm mit Nooelec NESDR (rtl2832) - Treiberproblem

  • Hallo, Freunde der günstigen 433-MHz-Raumthermometer!


    Ich habe mir das Programm rtl_433 von github heruntergeladen (https://github.com/merbanan/rtl_433) um damit Daten aus dem 433MHz Frequenzband auszulesen (ich habe ein altes Thermometer von einem Discounter). Das funktioniert eigentlich ganz gut, nur nach ca. 6-12 h Betrieb sucht anscheinend der Kernel immer nach einem neuen Treiber, den er dann attacht, wobei der Datenstrom abbricht/das Programm beendet.


    ich habe schon, wie unter github und verschiedensten Tutorials empfohlen, einige Treiber geblacklistet. Momentan sieht meine Datei

    Code: /etc/modprobe.d/raspi-blacklist.conf
    1. blacklist dvb_usb_rtl28xxu
    2. blacklist dvb_usb_v2
    3. blacklist rtl_2830
    4. blacklist rtl2830
    5. blacklist rtl_2832
    6. blacklist rtl2832
    7. blacklist rtl2832U
    8. blacklist r820t

    so aus. Der Befehl

    Code: rtl_test -t
    1. Found 1 device(s):
    2. 0: Realtek, RTL2838UHIDIR, SN: 00000001
    3. Using device 0: Generic RTL2832U OEM
    4. usb_claim_interface error -6
    5. Failed to open rtlsdr device #0.

    liefert das obige Output, nachdem das Programm neu gestartet worden ist. So läuft es erst einmal. Ich erwarte allerdings, dass es wieder abstürzt. Warum hat sich der Name des Chimps zu "RTL2338" geändert? Muss ich diesen Treiber auch noch blacklisten?


    Habe ich zu viele/zu wenige Treiber geblacklistet? Gibt es noch irgendetwas, was ich tun muss, außer die raspi-blacklist.conf zu bearbeiten und zu rebooten, dass meine Konfiguration erkannt wird? Die Datei gehört root:root.


    Vielen Dank im Voraus!


    jgoep(:


    PS: Bevor einer fragt: Ich habe die Suchfunktion zum Thema "rtl_sdr" und "treiber" befragt, aber leider nichts gefunden. Man verzeihe mir, wenn es einen ähnlichen Beitrag schon gibt und gebe mir den Link.

  • Servus jgoep ,


    sucht anscheinend der Kernel immer nach einem neuen Treiber, den er dann attacht, wobei der Datenstrom abbricht/das Programm beendet.

    also das habe ich weder malgehört noch gelesen und schon gar nicht erlebt. Wieso sollte der Kernel das tun?

    Was bringt Dich zu dieser Annahme?


    Mit SDR haben wir imho hier nicht viel zu tun ... und mein beschränktes Wissen ist da auch schnell erschöpft.


    Hast Du mal Log-Ausgaben von so einer Situation?

    cu,

    -ds-

  • Es war schon zwei Jahre her dass ich mit rtl_433 gespielt habe, aber bei mir lief es jeden Fall laenger als zwei Tage ununterbrochen.


    Ich kann nicht recht glauben, dass der Kernel ohne Veranlassund den Treiber tauscht. Eher wurde ein Programm geladen das einen TV- oder Radioempfaenger sucht und sich den Stick unter den Nagel reisst.


    Passiert das auch wenn der Pi nicht angeruehrt wird?

    Einmal editiert, zuletzt von Tell ()

  • Gibt es noch irgendetwas, was ich tun muss, außer die raspi-blacklist.conf zu bearbeiten

    Das ist mir auch noch an keinem RPi/OrangePi/Odroid/BananaPi untergekommen. Linux ist schließlich kein Windows. Was in diesem Fall vielleicht die Ursache sein könnte: Welches Netzteil verwendest Du und was hängt noch alles am Pi?


    Grüße, STF

    "And now for something completely different."


    Hofeis guide to: Wie frage ich nach Hilfe? *** Mein nagelneuer Raspberry Pi 3B+ zeigt nur ein buntes Bild. (Ab)Hilfe.

  • Vielen Dank für eure zahlreichen Anregungen!

    Wieso sollte der Kernel das tun?

    Was bringt Dich zu dieser Annahme?

    Das habe ich mir irgendwie so zusammengereimt, weil es verschiedene Tutorials auf diversen Foren gab, die alle einen verschiedenen Treiber blockieren ließen, also habe ich angenommen, nur noch nicht den richtigen Treiber geblacklistet zu haben. :conf:


    Ansonsten laufen auf dem Pi noch ein Apache-Server, ein OpenVPN-Server und ein stündlicher Cronjob, der aber nichts mit externer Hardware zu tun hat. /var/log/syslog zeigt aber meiner Meinung nach keinen Zusammenhang mit diesen oder anderen Diensten,


    Die Ausgabe von dem Befehl "rtl-test -t" nachdem rtl_433 das letzte mal aufgegeben hat war:


    Die unteren beiden Zeilen sind also noch mit hinzugekommen, ich weiß aber nicht so recht, was ich damit anfangen soll..


    Leider logge ich nur stout von dem rtl_433-Programm, nicht die Fehler, aber sollten die nicht in syslog auflaufen?


    Das ist mir auch noch an keinem RPi/OrangePi/Odroid/BananaPi untergekommen. Linux ist schließlich kein Windows. Was in diesem Fall vielleicht die Ursache sein könnte: Welches Netzteil verwendest Du und was hängt noch alles am Pi?


    Grüße, STF

    Ich habe jetzt einmal ein Labornetzteil angeschlossen, bis jetzt hatte ich ein 10 W-Netzteil von OTB (bei Amazon gekauft). Jetzt habe ich den Pi gestartet und er braucht recht konstant 0,6A*5,1V=3,06W


    Vielen Dank und schönen Abend,


    jgoep

  • Hi jgoep ,

    Das habe ich mir irgendwie so zusammengereimt, weil es verschiedene Tutorials auf diversen Foren gab, die alle einen verschiedenen Treiber blockieren ließen, also habe ich angenommen, nur noch nicht den richtigen Treiber geblacklistet zu haben. :conf:

    Also ich weiss nicht so recht ... Tuts hin oder her ... hast Du mal versucht, gar nichts auf die Blacklist zu setzen?

    "Normalerweise" sollte das mho nicht nötig sein. Evtl. hast Du zuviel ausgeklammert.

    Das mit dem Labornetzteil ist eine gute Sache ... wird sich zeigen, ob das was gebracht hat ( Netzteil ist quasi die Fehlerursache Nr. 1 ).


    cu,

    -ds-

  • Hallo dreamshader ,

    Also ich weiss nicht so recht ... Tuts hin oder her ... hast Du mal versucht, gar nichts auf die Blacklist zu setzen?

    "Normalerweise" sollte das mho nicht nötig sein. Evtl. hast Du zuviel ausgeklammert.

    Das kann natürlich auch sein. Wenn das Labornetzteil keine Lösung bringt, werde ich blacklistmäßig mal alles auf Null setzen. Und dann logge ich im nächsten Versuch auch mal denn Error-Output von rtl_433, vielleicht ist das ja auch aufschlussreich, aber erst mal versuche ich, ob das Netzteil vielleicht schon die Lösung war.


    Bis dann, (:


    jgoep

  • Moin jgoep,


    nachfolgender Auszug ist von der GitHub-Seite.

    Zitat

    Troubleshooting


    If you see this error:

    Code
    1. Kernel driver is active, or device is claimed by second instance of librtlsdr.
    2. In the first case, please either detach or blacklist the kernel module
    3. (dvb_usb_rtl28xxu), or enable automatic detaching at compile time.

    Ich versteh es so, das das blacklisten nur für die Compilezeit gilt.


    Auf Grund deines Logauszuges, vermute ich mal das das Programm nicht funktioniert.


    Lösche alle Einträge von der schwarzen List und dann starte dein Programm neu. Eigentlich darf die E4000-Meldung nicht kommen.


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"

  • Moin Bernd666 !


    Es funktioniert zunächst schon, für etwa 6 bis 12 Stunden, dann aber bekomme ich keine Daten mehr. Werde das versuchen!


    LG,

    jgoep

  • Moin jgoep,


    das kann ich nicht sagen, aber in dem errorlog steht no E4000 tuner found! aborting.


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"

  • Moin!


    Vielleicht hilft folgende PDF-Datei ja, das Verständnis für SDR mit USB-Stick zu verbessern. Es ist zwar schon älter, aber inhaltlich immer noch passend.


    Ich habe es in einem Extra-Beitrag gepackt, damit es auch noch Leute mitbekommen die den Vorherigen schon gelesen haben.

    Ich bitte um Vergebung....


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"

  • Guten Morgen!


    Zunächst einmal hatte ich alle cups-Pakete deinstalliert, weil ich dachte, dass das Problem immer im Zusammenhang mit den folgenden Fehlern auftrat:

    Der Raspi lief dann gestern am Labornetzgerät mit konstanter Leistung vorerst problemlos. Da ich nie eine Leistungsaufnahme > 3W beobachtet hatte, habe ich ihn schließlich wieder an mein 10 W-USB-Netzteil angeschlossen, denn der laute Lüfter des Labornetzgeräts hatte mir schon zwei schlaflose Nächte bereitet...:D

    Gestern lief er dann 13 Stunden, bis die Anwendung wieder abgestürzt ist... RTL_433 gibt mir immer noch keinen Fehler auf stderr aus.

    Ich werde jedoch trotzdem noch einmal das Labornetzgerät als Spannungsquelle verwenden müssen, weil ich seit heute morgen komische Kernel-Fehler bekomme... :conf:

    Außerdem zeigt sich eine Übereinstimmung zwischen den Abstürzen und meinem exim4-Error-Log (es liegt noch ein Mediawiki mit Mail-Dienst auf meinem Webserver). Gleichzeitig läuft per Cronjob auch noch ein anderes shell- und python-Script von mir, also würde ich doch wieder auf das Netzteil als Ursache tippen... Danach fing das auch an mit den Kernel-Fehlern. Immer nach dem Cronjob! Also steigt da wohl die Stromaufnahme rapide an... Ich werde das zu den üblichen Cronjob-Zeiten jetzt mal speziell im Auge behalten.


    Schönen Tag,


    jgoep(:

  • Moin jgoep,


    was soll man nun schreiben...


    Hast du deine Blacklist irgendwie bereinigt?

    Schön das es noch diverse ungenannte Programme/Scripte gibt. Schon mal mit deaktivieren versucht? Und nur das EINE Programm laufen lassen?


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"