Beiträge von Jürgen Böhm

    Ich habe gelesen, dass man ntpdate und ntp nicht gemeinsam laufen lassen kann

    Stimmt, da war etwas, sorry ich habe das schon lange nicht mehr machen müssen.

    Aber Deine Frage war gut, ich habe endlich die Stelle wiedergefunden wo die Erklärung stand:

    https://wiki.hetzner.de/index.…t_synchronisieren_mit_NTP

    Abschnitt: Mit NTP die Zeit manuell synchronisieren.

    Es geht anscheinend auch ohne ntpdate, ich selbst habe es nur ein oder zweimal benutzt.

    Es war einfacher für den Moment die Zeit mit date zu setzen.

    Des Weiteren habe ich mir jetzt auch ein RTC-Modul besorgt

    Welches, ich hoffe nicht eins mit DS1307, mein Hinweis auf Neueinsteiger hatte schon seinen Sinn.

    Du hast hoffentlich auch den I2C-Bus mit raspi-config aktiviert?


    MfG


    Jürgen

    Pause...

    So wie ich das jetzt sehe komme ich um das RTC-Modul nicht herum.

    Doch, kommst Du, mit "ntpdate". Er muss so früh wie möglich gestartet werden aber erst nachdem das Netzwerk läuft.

    Ein passender Ort dazu ist rc.local. "ntpdate" holt von einem externen NTP-Server die Zeit und stellt die RPi-Uhr.

    Kann man mit "date" testen. Es geht nur darum, die 1000(?) Sekunden zu minimieren, damit der NTP-Server sich einschwingen kann.


    Solltest Du die RTC benutzen, so erkennt der NTP-Server sie an dem Eintrag in der /etc/ntp.conf.

    Er schaltet von allein auf die RTC wenn (noch) keine gültige Zeit(quelle) vorhanden ist und schaltet dann selbständig auf die

    nächstbessere Quelle um, siehe die Einstellungen in Beitrag #4.

    Das sind bei GPS ein paar Sekunden, mit DCF77 kann das schonmal ein paar Minuten dauern.


    Vielleicht bis heute Nachmittag.


    MfG


    Jürgen

    ich bekomme ein GPS-Signal angezeigt und auch die aktuelle Uhrzeit über NTP am Pi.

    Wenn ich das nicht gelesen hätte, hätte ich meine Finger von der Tastatur gelassen. Außerdem:

    Code
    1. sudo apt install ntp

    funktioniert immer noch.


    Wie will man sonst einen GPS-Empfänger einbinden?


    MfG


    Jürgen


    Der jetzt die Bettkarte stempelt


    Nachtrag: STF Interessanter Link, werde ich mir morgen etwas näher ansehen.

    Aus https://wiki.ubuntuusers.de/ntpd/

    unter dem Abschnitt: "Problembehebung"

    <Kopie>

    Eine weitere Problemquelle sind zu große Abweichungen zwischen lokaler und Internet-Zeit. Dann wird zuerst der ntp-Dienst beendet:

    Code
    1. sudo service ntp stop

    Nun setzt man die Zeit manuell:

    Code
    1. sudo ntpd -q -g -x -n

    Zum Schluss wird der ntp-Dienst wieder gestartet:

    Code
    1. sudo service ntp start

    Wer besonders vorsichtig sein möchte startet den Rechner nach dieser Prozedur neu, da der auftretende "Zeitsprung" unvorhersehbare Konsequenzen haben kann.

    </Kopie>

    Ich meine, etwas von 1000 Sekunden gelesen zu haben, habe aber die Info nicht mehr wiedergefunden.
    Bei größeren Abweichungen weigert sich der NTP einfach. Nach dem Einsatz einer RealTimeClock war das Problem aber behoben.


    Am einfachsten wäre es für Dich, wenn Du zusätzlich eine RTC einsetzen würdest:

    I²C RTC - Real Time Clock für den Raspberry Pi

    Vielleicht hat Neueinsteiger ja noch eine Platine übrig.


    Vielleicht ist das auch noch lesenswert:

    https://www.meinberg.de/german/info/ntp.htm

    https://www.eecis.udel.edu/~mi…p/html/refclock.html#list

    https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html


    Das sind meine NTP-Einstellungen


    Und das ist eine Ausgabe, wenn man die oberste Zeile eintippt

    raspi02 und raspi12 sind 2 DCF77-NTP-Server die hier zum Test mitlaufen. Alle Uhren haben eine RTC.

    Ich hatte das Tutorial für GPS schon fertig, aber dann funktionierte ein zusätzliches Schmankerl nicht mehr.

    Daher blieb das erstmal zu Hause (und liegen).


    MfG


    Jürgen

    Ich habe gerade die 2018-06-27 noch einmal neu aufgespielt, aber diesmal mit einem RPi3B

    das erste Mal gestartet, dann die SD-Karte auf den 3B+ verpflanzt, läuft.


    Dann noch einmal das 2018-06-27er Image aufgespielt, läuft auch! Auf dem 3B+?


    Irgendwie komme ich mir ein bißchen verarscht vor...

    Oder kann es sein das bei einer bestimmten Charge ein Bit nicht gesetzt wurde,

    das während meiner Experimente dann gesetzt wurde?

    Das das nur bei nagelneuen RPis und diesem Image ein Problem ist?

    Das fand ich mit Hilfe von Tante G: https://www.raspberrypi.org/forums/viewtopic.php?t=58151

    Ob es das ist?


    Für mich ist das Problem erstmal nicht mehr nachvollziehbar. Ich werde es aber im Hinterkopf behalten.


    MfG


    Jürgen

    Edit: Die Finger waren langsamer als der Kopf

    Die 2018-03-13 habe ich nicht getestet, die 2018-04-18 lief, die 2018-06-27 blieb nach den 4 Himbeeren einfach stehen

    und die 2018-10-09 lief wieder einwandfrei.

    Die Prüfsummen von der 2018-06-27 war die gleiche wie auf https://downloads.raspberrypi.…ages/raspbian-2018-06-29/

    angegeben.

    Diese Version hatte ich schon einmal auf einen RPi3B aufgespielt und lief dort einwandfrei, nur mit diesen 3B+ nicht.


    Hier ein paar Tests mit dem Image 2018-10-09:

    Code
    1. sudo apt install inxi

    sysinfo.sh

    Code
    1. > inxi
    2. CPU~Quad core ARMv7 rev 4 (v7l) (-MCP-) speed~600 MHz Kernel~4.14.71-v7+ armv7l Up~10:02 Mem~118.2/927.2MB HDD~NA(-) Procs~124 Client~Shell inxi~2.3.5
    3. > sysinfo.sh
    4. ...
    5. Firmware Version: Sep 21 2018 15:43:17
    6. Copyright (c) 2012 Broadcom
    7. version 07f57128b8491ffdefcdfd13f7b4961b3006d9a9 (clean) (release)
    8. ...

    Gibt es noch eine Möglichkeit etwas nachzusehen um die Unterschiede festzustellen?


    MfG


    Jürgen

    Ja also darf ich das nun dranlassen? Das Pi wird mit einer Webcam streamen und 2 Zeitschaltuhren bedienen, also nichts gross rechnen.

    Klar darfst Du, es ist Dein Gerät. Du darfst damit machen was Du willst.

    Du willst Bilder streamen? Unterschätze nicht die Auslastung eines Rechners, der "nur" Bilder von einer Kamera aufnimmt, wandelt und dann

    an einen anderen Client übermittelt.

    Persönlich hätte ich das Netzteil nicht gekauft.


    Um Dir mal ein kleines Beispiel einer meiner RaspiCAMs zugeben:

    Netzwerk eth0 von 2 Wochen und das sind max. 2 Bilder/sec

    Code
    1. Maximal Mittel Aktuell
    2. Herein 196.0 kB/s (1.6%) 2613.0 B/s (0.0%) 475.0 B/s (0.0%)
    3. Hinaus 781.6 kB/s (6.3%) 45.5 kB/s (0.4%) 13.8 kB/s (0.1%)
    4. Blau/Dunkelgrün Hereinkommender Traffic in Bytes pro Sekunde
    5. Rot/Violet Hinausgehend Traffic in Bytes per Second

    Es handelt sich dabei um eine mäßig befahrende Seitenstraße.

    Die Auslastung läßt sich nicht vergleichen, da es sich um einen RPi1B(rev2) handelt.


    MfG


    Jürgen


    Edit: Ich klinke mich hier mal aus, über Netzteile wurde hier im Forum schon genug geschrieben.

    Und ich habe auch noch etwas anderes zu tun.

    die Unbildung ist unser heutiges größtes Problem aller Orten, abgesehen von der Tatsache das viel gelogen wird nur um zu VERKAUFEN.

    Zum ersten, ein (neuer) Arbeitskollege hat eine miserable Rechtschreibung (Kein Legastheniker!),

    ich empfahl viel zu lesen, vor allen Dingen die Teile, die aus toten Holz und Druckerschwärze gefertigt werden.

    Kommentar von Ihm: "Lesen?". So im nachhinein habe ich mitbekommen, das er sich in Netflix-Serien bestens auskennt

    und eine Playstation zu Hause hat. Und anscheinend "konsumaffin" erzogen wurde, von wen auch immer.


    Zur Werbung halte ich es mittlerweile so, das die Produkte die besonders intensiv beworben werden, bei mir den Status minderwertig

    bekommen und im Regal liegenbleiben. Brüllaffenwerbung gehört definitiv dazu.


    Aber zu den Lade-Netzteilen zurückzukommen, vielleicht sollten wir mal Berichte über Netzteile sammeln die sich (nicht) bewährt haben.

    Vielleicht hat der eine oder andere ein Oszilloskop zu Hause mit dem man z.B. Restwelligkeiten messen kann.

    Erfahrungsberichte würden auch weiterhelfen. Und einen Fragenkatalog aufstellen:

    - Welches Netzteil, Typ, Hersteller, Wo gekauft

    - Wann wurde das Netzteil in Betrieb genommen

    - Welche Verbraucher hängen noch daran (Tastatur, Maus, Sensoren Anzeigen, ...)

    - Gibt es Ausfälle, wenn ja, wie oft

    - ...


    Nicht alle dieser Netzteile sind einfach nur schlecht, einige Medion Netzteile laufen hier seit 2-3 Jahren mit RPi1(Rev 2)

    als 24/7 Kameraüberwachung (Motion) mit USB- bzw. Infrarot-Kameras (Raspberry). Hier habe noch nicht wirklich gutes gefunden,

    okay, das Raspberry-Netzteil vielleicht. Aber ich habe es bei meinen Bestellungen immer wieder vergessen

    und da die Medion-Ladenetzteile bis jetzt funktioneren. Sollte nur ein Medion-Netzteil Schwächen zeigen,

    sind alle entweder im Schrott oder werden ihrer eigentlichen Bestimmung zugeführt.


    Gute Erfahrung habe ich auch mit den Meanwell-Netzteilen gemacht, allerdings sind das auch keine Ladegeräte,

    auch keine Steckernetzteile. Man sollte hier wissen was man tut, wenn man diese Netzteile in Betrieb nimmt.


    Andere Netzteile sind bereits im Elektronikschrott gelandet (z.B. RS-Components), oder aufgrund diverser Berichte hier

    erst garnicht gekauft worden.


    Ein Fazit aber bleibt: USB-Ladegeräte sollten eine Ausnahme bleiben, für ein paar Tests könnte es funktionieren,

    man sollte trotzdem auf den gelben Blitz achten.

    Ansonsten Finger weg, spart euch das Geld, legt etwas mehr Geld auf den Tisch und kauft etwas vernünftiges.

    Merke: Wer (zu) billig kauft, kauft doppelt.


    MfG


    Jürgen


    Edit: Schreibvehler

    Nachtrag: Um das Medion-Netzteil handelt es sich um den Netzadapter MD 84922 PS 5V 2100mA

    Das bedeutet Du hast nicht das ganz neue Image (Release date: 2018-10-09) nochmals heruntergeladen, sondern das vom Juni aufgesetzt?

    Verdammt, seit wann ist das den da? Ich habe jeden Tag nachgesehen, und trotzdem ist mir das entgangen.


    11:46, ich hatte mir das Image gestern vormittag über die Firma geholt nachdem ich mich dazu entschlossen nicht auf eine Lösung zu warten.


    MfG


    Jürgen

    cat /proc/cpuinfo

    Die Seriennummer lasse ich mal weg


    MfG


    Jürgen

    Irgendwie vermisse ich bei obiger Schilderung den Versuch, mittels Aufspielen eines frischen Systems den Pi wiederzubeleben.

    War gestern Abend ein bißchen spät.

    Ich habe nach den ganzen Diskussionen mal selber sehen wollen was da eigentlich los ist.


    Ich habe das Raspian vom Juni mittels dd auf eine 32G-Karte von Samsung gespielt,

    einen HDMI-Monitor drangehängt, eine Bluetooth-Tastatur eingestöpselt sowie ein Netzwerkabel eingesteckt.

    Als Stromquelle diente erstmal ein Ladenetzteil von Medion (was auch hervorragend funktioniert hat).


    Eingeschaltet, der Monitor zeigte das Regenbogenbild und danach die 4 Beeren, das wars.

    Kein flackern der grünen Leuchtdiode, keine Änderung des Bildschirms, Tastatur erzeugte keine Reaktion.


    Dann habe ich ein neues Raspian-Image von Raspian.org geholt und die Prozedur wiederholt, mit dem gleichen Ergebnis.


    Dann folgte die Überlegung ein älteres funktionierendes Image (04/2018) aufzuspielen und dann auf den jetzigen Stand upzugraden.

    Ein weiterer 3B+ läuft hier bereits seit etwa 3 Wochen mit dieser Konstellation (3B auf 3B+) weil ich an dieser Stelle eine bessere Netzverbindung

    und Geschwindigkeit (Nextcloud) brauchte.


    Ich denke mir mal, das das Raspian von 06/2018 ein Problem hat, das mit den folgenden Upgrades behoben wurde.

    Wenn man dieses Raspian auf einen 2B/3B aufspielt, einrichtet und upgraded, wird es dann auch auf einen 3B+ laufen.

    Nur so eine Idee...


    Ein dist-upgrade kommt heute Abend, oder jemand anderes testet das im Laufe des Nachmittags.


    MfG


    Jürgen

    Nachtrag:


    Ich habe gerade auch mal versucht mit einem nagelneuen RPi3B+ und dem Raspian vom Juni zu booten, Fehlanzeige.

    Der bunte Bildschirm tauchte auf, 4 Beeren auf dem Schirm und Feierabend.

    Danach habe ich die Version vom April eingespielt und ich bin immerhin im Desktop gelandet.


    Jetzt gehe ich ins Bett, um 4.00 Uhr ist meine Nacht vorüber.


    MfG


    Jürgen

    So, ich habe mich in den letzten Tagen ein bißchen mit Suchen beschäftigt und bin dabei auf folgende Seite gestossen:

    https://github.com/G6EJD/BME680-Example

    Hier wird ohne die Bosch-Library der IAQ-Wert ermittelt:

    Das ist noch eine unkalibrierte Ausgabe, aber der ESP32 läuft seit einem Tag störungsfrei.

    Das war nicht bei allen Beispielen so.


    Die ESP32- und ESP8266-Bastler unter uns sollten sich mal im Root-Verzeichnis mal etwas umsehen, da gibt es jede Menge zu entdecken:

    https://github.com/G6EJD?tab=repositories


    Achja, ein Schmankerl hab ich bei Adafruit noch gefunden:

    http://playground.arduino.cc/Main/I2cScanner

    Wie man dem Link entnehmen kann, ein I2C-Scanner, der (nur) die belegten I2C-Adressen anzeigt.

    Hat mir hier sehr weitergeholfen.


    MfG


    Jürgen