Posts by patr1q

    Auch hier nochmal, danke euch allen für Ihre Beiträge.

    Habe auch mittlerweile eine andere RTC besorgt, als die, die ich zu Beginn verwenden wollte, nämlich eine bei der man eine CR2032 Batterie hat.


    Der Ansatz von RTFM in #9, auf andere Pins auszuweichen, hat für mich funktioniert.


    Auf dem Weg dahin hatte ich es auch versucht beide Geräte (Sensor + RTC) an den normalen I2C Pins anzuschließen, das hat aber Probleme gemacht, wie man in meinem anderen Thread nachlesen kann.

    Hi zusammen,


    danke euch für Eure Ratschläge und Beiträge.

    Ich konnte das Problem identifizieren und habe eine Lösung gefunden.


    Bye.









    :P


    Kleiner Scherz. Ich lass euch natürlich auch wissen woran es lag.

    Ich hatte die RTC nicht allein am I2C Bus angeschlossen, sondern noch einen Sensor.

    Man kann ja in der Theorie mehrere Geräte an den I2C Pins anschließen, allerdings lag hier vermutlich irgendwo auf meiner Seite der Fehler.

    (Dazu gab es von mir auch schon einen anderen Thread hier, falls jemand sich für den Background interessiert)


    Nachdem ich keine Lösung für das komische Verhalten der RTC gefunden hatte, dachte ich ich versuche mal den Sensor wegzulassen.

    Und siehe da: es funktionierte direkt. Die Uhrzeit, die ich in die RTC gespeichert habe, blieb zuverlässig erhalten, ohne diese seltsamen Zeit-Änderungen.


    Da ich in dem Projekt aber nicht auf den Sensor verzichten kann, habe ich mir nochmal meinen anderen Thread angeschaut und den Ansatz, den RTFM vorgeschlagen hat, nämlich mit der RTC auf andere Pins auszuweichen, ausprobiert.


    Also dtoverlay=i2c-rtc-gpio,ds3231,i2c_gpio_sda=10,i2c_gpio_scl=9

    Damit konnte ich für die RTC die anderen Pins verwenden und die normalen Pins für den Sensor verwenden.


    Ich habe zwar nicht herausgefunden, was genau an dieser "Reihenschaltung" des Sensors und der RTC falsch war, aber wenn ich jetzt beide Geräte unabhängig voneinander mit unterschiedlichen Pins betreiben kann, ist es umso besser.


    Aber unter'm Strich ist heutzutage tatsächlich nicht mehr viel nötig, um die RTC regulär in Betrieb zu nehmen, wie auch RTFM bereits sagte.

    - Man muss nur das dtoverlay entsprechend konfigurieren (dtoverlay=i2c-rtc,ds3231)

    - und den fake-hwclock.service deinstallieren / entfernen / maskieren.

    - den hwclock.service wieder zu aktivieren ist wohl nicht nötig.


    Einmal die RTC mit sudo hwclock -w mit der (vorher richtig eingestellten) Systemzeit beschreiben und das wars.

    Das System behält nun auch ohne Internetverbindung die Uhrzeit nach Neustarts korrekt bei.

    Linux ist so höflich und sagt auch gleich dazu, warum Deine Eingabe fehlschlug.

    Ja, Linux sagt mir nach sudo systemctl enable hwclock.service, dass ich hwclock nicht aktivieren kann, da hwclock.service masked ist, was ich doch aber im unmittelbar zuvor ausgeführten Kommando sudo systemctl unmask hwclock.service zu ändern versuchte - was auch keinen Fehler oder irgendeinen Output anzeigte.


    Wenn Du nunmehr eine Anleitung aus diesem Forum verwendet haben willst, dann wurde dort aber sicher diskutiert, dass das RTC Modul an die 3,3 V Stromversorgung des Pi anzuschliessen ist, und nicht an 5 V "arduino-like"

    Danke für den Hinweis, aber das ist bei mir bereits an 3,3V verkabelt.

    ok. enable hwclock.service funktioniert nicht, habe möglicherweise was kaputt gemacht.

    Wer weiß, was ich jetzt schon mit diesen ganzen Anleitungen, die ich versucht habe, kaputt gemacht habe.

    Ich werde ein Image aufspielen vom Stand bevor ich mit der RTC rumgerätselt habe und es dann erneut versuchen.


    Update: Habe das Image bereits aufgespielt und direkt damit begonnen fake-hwclock.service zu stoppen, disablen und zu maskieren. Anschließend wollte ich hwclock.service unmasken, enablen und starten. unmask funktioniert ohne Fehler. enable wirft folgenden Fehler: Failed to enable unit: Unit file /lib/systemd/system/hwclock.service is masked. Habe es auf mehreren PI's getestet - verhält sich überall gleich.


    RTFM könntest du eine gängige und aktuelle Anleitung empfehlen?

    Ich habe eigentlich die Anleitung von irgendeinem Thread dieses Forums vom Jahr 2022 genommen, dachte daher die wäre aktuell, aber da war ich möglicherweise zu voreilig.


    LG

    hwclock --test ?

    Da kam folgendes:


    Quote

    RTC richtig angeschlossen

    Ich gehe davon aus.


    Quote

    Batterie funktioniert/Sicherungslasche entfernt, wenn vorhanden

    Ja, schon zweite Batterie getestet, kommt dasselbe bei raus.


    Quote

    richtiges dtoverlay installiert

    Ja ich habe folgendes:

    Code
    dtparam=i2c_arm=on
    dtoverlay=i2c-rtc,ds3231


    Quote

    fake-hwclock disabled /masked

    Ja habe ich entsprechend der Anleitung (siehe #1) removed u. disabled.


    Quote

    kein overlay-Filesystem aktiviert

    Was genau ist damit gemeint? Ich kann damit nichts anfangen. Ich habe zumindest wissentlich nichts getan.


    Quote

    Neustart nach "halt" (statt reboot)

    Hat auch leider nichts gebracht :(

    Das hat vermutlich etwas mit der drift-Berechnung zu tun. Siehe < man hwclock >

    Schalte die Verwendung von /etc/adjtime einmal weg, beachte aber den gesamten Hinweis zu --noadjfile.

    Hi, danke für den Tipp, allerdings hat er nicht geholfen.


    Habe es mit


    sudo hwclock --noadjfile --localtime


    versucht. Anschließend konnte ich weiterhin dasselbe Problem-Verhalten feststellen, wie bereits zuvor.

    Auch habe ich es mit


    sudo hwclock -w --noadjfile --localtime


    aber auch das ändert nichts an dem Problem.

    Was ich jedenfalls seltsam finde, ist dass die Uhrzeit, zu der immer in der RTC korrigiert wird immer nur 02:xx Uhr ist. Nach 02:59 geht es wieder mit 02:00 Uhr los.


    Noch eine andere Idee?

    Habe gerade nochmal das Pi neugestartet.

    Das Verhalten tritt auch ohne diesen Fehler auf.


    Also sudo hwclock -w

    -> Setzt die richtige Zeit


    dann sudo hwclock -r

    -> Zeigt die richtige Zeit


    nochmal suddo hwclock -r

    -> Zeigt wieder eine Zeit um die 02:00~ Uhr an


    Also das Verhalten gibt es auch ohne einen Fehler dazwischen. Sehr seltsam.

    Hi zusammen,


    ich habe seltsame Probleme mit einer RTC DS3231 an dem Raspberry PI 4.


    Ich habe alles entsprechend der Anleitung von Set RTC Time | Adding a Real Time Clock to Raspberry Pi | Adafruit Learning System eingestellt (auch wenn es hier eine Differenz in der /lib/udev/hwclock-set zwischen meinem Pi und der Anleitung gibt, aber ich glaube das ist hier (vorerst) nicht von Relevanz.


    Die RTC wird mittels i2cdetect -y 1 unter der Adresse 0x68 gefunden, also dort steht UU, was ja schon mal gut ist.


    Das Problem tritt beim Setzen der Uhrzeit in der RTC bzw. beim Auslesen auf.


    Ich setze die RTC Zeit mithilfe von


    Code
    sudo hwclock -w

    Der Befehl scheint fehlerfrei zu funktionieren.

    Direkt danach versuche ich zu prüfen, was die RTC nun für eine Zeit hat. Dazu nutze ich


    Code
    sudo hwclock -r

    Als Ergebnis erhalte ich dann wie erwartet die aktuelle Zeit. Soweit so gut.


    Versuche ich es dann aber direkt danach noch mal, kommt es mit selbem Befehl zu folgender Ausgabe:

    "hwclock: ioctl(RTC_RD_TIME) to /dev/rtc0 to read the time failed: Die Wartezeit für die Verbindung ist abgelaufen.


    Versuche ich es dann ein weiteres Mal, erhalte ich wieder eine Zeit, aber nicht die korrekte, sondern die aktuelle Zeit minus 9 Stunden.

    Ich vermute es hängt mit dem Fehler zusammen, den ich zuvor bekommen habe.


    Folgend ein Auszug aus der Konsole:


    Habt ihr ein solches Verhalten schonmal gesehen oder eine Idee, woran das liegen könnte?


    Ich freue mich auf Eure Ratschläge!


    Danke & Grüße

    patr1q

    Deine Vermutung ist nicht richtig. Du brauchst einen Treiber, der mit dtoverlay= mitgeladen wird. Hättest Du die README aus #3 gelesen, müsstest Du nicht mehr herumrätseln.


    Servus !

    Hi RTFM danke nochmal - ja ich habe mich mit Plug & Play eventuell etwas falsch ausgedrückt. Damit meinte ich in diesem Sinne eher, dass man bei einer solchen RTC, die eben zum Aufstecken gedacht ist vermutlich keine extra Widerstände benötigt. Habe deinen Eintrag jetzt nochmal gelesen und hatte das zunächst nicht richtig verstanden - sorry.


    Die zwei SMD Widerstände sind fest auf den I2C angelegt.

    Danke auch Dir.



    Ok und nochmal zusammengefasst:

    - Die RTC bringt dann schon Widerstände mit

    - mein Staubsensor und die Verkabelung, die man mir so mitgegeben habe, die aktuell 2 Widerstände beinhaltet, sollte ich nun so nicht noch zusätzlich mit anschließen, sondern nur ohne die Widerstände.


    Ich habe einen Port-Doubler von Joy-IT besorgt.

    Wenn ich diesen nun auf den Raspberry Pi stecke, dann sollte ich hier

    - zuerst die RTC anschließen, da diese dann entsprechend durch die Konfiguration schon die Widerstände mitbringt

    - und dann als nächstes meinen Sensor (OHNE) Widerstände


    verstehe ich das so richtig?


    Danke Euch!

    Hallo, danke Euch für Eure Antworten.


    Also bis zum Zeitpunkt Eurer Antworten habe ich noch nie von Pullup Resistors etc. gehört.

    Wie gesagt ich habe mit Elektrotechnik wirklich nichts am Hut.

    Habe aber einen Artikel gefunden, der das ganze Thema I2C Bus und Pullup Resistors gut erklärt. Heißt jetzt trotzdem nicht, dass ich jetzt Elektrotechniker geworden bin :D


    Also noch mal etwas mehr Hintergrund-Info:

    Den Raspberry Pi habe ich schon fertig (provisorisch) verkabelt mit dem Staub-Sensor so übergeben bekommen, so dass ich in der Lage war das Teil anzuprogrammieren. Da sind wohl auch Pullup Resistors schon mit im Spiel, wenn ich das richtig sehe.



    Keine Sorge, ich erwarte von euch nicht, dass ihr durch das Foto versteht, wie es verkabelt ist, jedenfalls sind dort 2 Teile, die für mich wie Widerstände aussehen.


    Aber wie finde ich heraus, ob die RTC nun integrierte Widerstände hat?

    Da die RTC, die ich hier habe, vermutlich als Plug&Play Gerät vorgesehen ist, da sie nur zum Aufstecken gedacht ist, könnte das durchaus schon mit integrierten Widerständen sein, vermute ich mal.


    Viele Grüße & Danke

    Hallo zusammen,


    ich bins, der neue ;)


    Für ein Projekt stehe ich gerade vor einem Problem. Ich nutze bereits die Pins 3, 4, 5 und 6 für einen Sensor.

    Bei dem Sensor handelt es sich um den SPS30 Sensor von Sensirion zum Messen von Staubpartikeln.

    Jetzt habe ich relativ spät erfahren, dass das Raspberry Pi keine RTC hat, was für das Projekt problematisch ist, da die Uhrzeit eine wichtige Rolle spielt und das Gerät offline betrieben werden soll.


    Leider habe ich keine Ahnung von Elektrotechnik und den GPIO Pins, bin auch relativ neu in der Raspberry Pi und Linux Welt - ich bin nur einfacher Softwareentwickler.

    Daher hoffe ich, Ihr könnt mir hier ein paar gute Ratschläge oder Lösungswege liefern.


    Zum eigentlichen Problem: Die RTC benötigt nun Pins, die z.T. vom Sensor bereits belegt sind.

    Diese braucht nämlich 1, 3, 5, 7 und 9.

    Problem sind hierbei dann die Pins 3 (GPIO 2 (I2C1 SDA)) und 5 (GPIO 3 (I2C1 SCL)).


    Ich weiß, ich weiß, hier im Forum gab es schon eine Vielzahl solcher Themen, allerdings habe ich für mich nicht klar eine Antwort darauf gefunden, ob ich problemlos beide meiner Geräte (Sensor + RTC) mit den Pins 3 und 5 verbinden kann.


    Ich habe gelesen, dass man manche Pins doppelt belegen kann, manche jedoch nicht, und dass es da viel zu berücksichtigen gibt.

    Ich habe auch gelesen, dass man mehrere Geräte an den I2C Pins anschließen kann, vorausgesetzt sie nutzen unterschiedliche Adressen.


    Aus dem Datenblatt vom Sensirion SPS 30 Sensor geht hervor, dass dieser die Adresse 0x69 nutzt, in einem Tutorial zur Einrichtung der RTC habe ich gesehen, dass diese die Adresse 0x68 nutzt. (Klingt für mich eigentlich schon mal gut).


    Hier auch noch der Schaltplan der RTC:


    und vom SPS30 Sensor:



    Denkt ihr, dass das so funktionieren könnte, oder sollte ich irgendwas vorher beachten, um nichts kaputt zu machen?


    Ich freue mich auf Eure Antworten.


    Grüße

    Patrick