Folgende Warnungen sind aufgetreten:
Warning [2] Undefined variable $unreadreports - Line: 34 - File: global.php(961) : eval()'d code PHP 8.2.2 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/global.php(961) : eval()'d code 34 errorHandler->error_callback
/global.php 961 eval
/showthread.php 28 require_once
Warning [2] Undefined property: MyLanguage::$thread_modes - Line: 43 - File: showthread.php(1621) : eval()'d code PHP 8.2.2 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/showthread.php(1621) : eval()'d code 43 errorHandler->error_callback
/showthread.php 1621 eval




Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Uhrzeit merken
#11
Ich habe auch das Image von Christian. Bei mir nimmt der nicht die Zeit vom GPS...
Hast du vielleicht noch ne Internetverbindung?

Dachte auch, dass Christians Image das nicht von alleine macht...

Hab jetzt ein neues GPS Modul. Probier das die Tage nochmal...
Zitieren
#12
Hi Nein ich habe kein Internet. Was ich aber am Anfang hatte, dass es ca 15min gedauert hat bis er die Uhr umgestellt hatte. nach dem ich bei meinem GPS Modul die passende Knopfzelle eingesetzt hatte war auch dieses Problem behoben nun dauert es ca 30s bis die Uhr stimmt. Sprich Motor an raus aus der Garage, dann das Garagentor schliessen bis ich zurück im Auto bin stimmt die Zeit bereits
Raspberry Pi 2 , Pollin 7" Display, PIco USV, Jessie Image
Am Testen Raspberry Pi 3, 7" Orginal Display, Jessie Image
Zitieren
#13
Man muss die ntpd.conf etwas tweaken damit das gut funktioniert. Per Default kann Raspbian schon aber es dauert bis zu 15 Minuten bis via GPS die korrekte Uhrzeit empfangen und an NTPD weitergegeben wird. Außerdem funktioniert das auch nicht mit jedem GPS Modul. Es gibt Module die einfach kein PPS Signal liefern/weitergeben.
Bei USB Modulen ist das idR kein Problem, bei Modulen über GPIO kann es notwendig sein das PPS Signal vom Chip abzugreifen und auf einen bestimmten GPIO zu stecken.
D.h. die entsprechende Zuleitung vom Chip fehlt und muss von Hand angelötet werden. z.B. wie hier: https://raspberry.tips/raspberrypi-tutor...eitserver/
CarPi: RPi 3 mit 7" RPi Touchscreen & PiUSV+, Jessie, Kodi 15.2
Testing: Raspbian Jessie mit Kodi 15.2 - Step by Step
Projekte: SmartHome, Ambilight
Zitieren
#14
Hast du einen Tipp, welche Einstellungen hier in der ntpd.conf weiterhelfen?
Zitieren
#15
heißt dass, dass sich der pi nach dem einschalten immer neu synchronisieren muss via gps?
Wenn sich der Pi die Uhrzeit "merken" soll wie ein pc... was müsste man da machen und vor allem wie viel strom würde das fressen. Hat der Pi nen Standbymodus oder so, wo dann nur die Uhr beibehalten wird? Huh Huh
offtopic... was machen die Leute die ein Tunermodul eingebunden haben. Wenn der Pi runtergefahren ist müssten doch auch alle kanäle verloren gehen oder? Huh Huh Huh
Zitieren
#16
Der Pi selber hat keine Uhr eingebaut. Aber es gibt RTC-Module (RTC=Realtime Clock) zum Nachrüsten. Diese Module haben eine eigene Stromversorgung, meist in Form einer Knopfzelle. Da der Stromverbrauch dabei verschwindend gering ist, reicht die Zelle auch für lange Zeit aus.

Zu deiner offtopic-Frage: Im Gegensatz zur Uhrzeit sind Senderfrequenzen ja feste Größen und können folgerichtig gespeichert und beim Start wieder eingelesen werden. Dafür muss also nicht ständig Strom zur Verfügung stehen. Wink
Zitieren
#17
Ein kleiner Workarround um den CarPi doch noch mit GPS Zeit zu versorgen:

Ich verwende einen RasPi 3 mit "2016-09-23-raspbian-jessie" und dem  "current_carpc.zip" von cbrauweiler.
Als GPS Empfänger verwende ich die USB Maus  "Navilock NL-602U".
Die Maus belegt /dev/ttyACM0 - das muss also in /etc/default/gpsd entsprechend eingetragen sein.

Mir ist aufgefallen, dass der Sync mit dem NTPD ganz gut läuft, wenn die Zeit Differenz nicht zu groß ist (ne Stunde oder so).
Wenn aber der RasPi über Nacht ausgeschaltet war, konnte der NTPD auch nach längerer Zeit (>2h) nicht synchronisieren.

Wenn ich jedoch die Adresse 127.127.20.0 in die /etc/ntp.conf eingetragen habe, funktioniert der Sync auf Anhieb.
Leider blockiert mit dieser ".20"-Adresse die Verbindung zur GPS-Maus, so dass Cgps und Navit Probleme haben.

Meine Lösung sieht so aus:
In der /etc/rc.local setze ich die Uhrzeit auf 3:00 nachts
 
Code:
date -s 03:00

Meine /etc/ntp.conf schaut so aus:
Code:
...
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 0.183 refid NMEA

 Damit synchronisiert der NTPD nur, wenn die Zeitdifferenz nicht zu groß ist.
Aber Cgps und Navit laufen einwandfrei.
ntpq -p liefert eine Ausgabe wie:
Code:
    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*SHM(0)          .NMEA.           0 l   10   16  377    0.000  -13.354   5.535
Wobei der * in Spalte 1 den aktiven Sync anzeigt.
Zum schnellen Sync beim Kaltstart habe ich eine weitere ntp1.conf angelegt.
Code:
...
server 127.127.20.0 minpoll 4
fudge 127.127.20.0 time1 0.183 refid NMEAs


Die Idee dahinter ist: Beim Kaltstart soll der ntpd ggf. ein paar mal mit der "falschen" Config laufen um eine schnelle Synchronisation zu erzwingen, und dann normal weiter laufen.
Dazu habe ich ein Skript checkntpd in /root angelegt:
Code:
#!/bin/bash
# checkntpd: testet ob SHM Verbindung hat
# startet ggf. den ntpd mit "falscher" Config

/usr/bin/ntpq -p | grep "*"
if [ $? -eq 1 }; then
   /bin/echo " ==> checkntpd @ `date`" >> /var/log/syslog
   /usr/sbin/service ntp stop
   /bin/sleep 2
   /usr/sbin/ntpd -g -q -c /etc/ntp1.conf
   /bin/sleep 2
   /usr/sbin/service ntp start
fi
Im Skript wird der "echte" NTPD abgeschaltet und ntpd mit dem "falschen" Skript /etc/ntp1.conf gestartet.
Die Optionen -g und -q sorgen dafür, dass auch große Differenzen ausgeglichen werden können und dass sich ntpd nach einem Sync-Versuch wieder beendet.
Das Skript rufe ich aus der root Crontab auf:
Code:
1-6,10,15,20 3 * * * /root/checkntpd > /dev/null 2>&1
Da bei mir die Uhr im Kaltstart immer auf 3 Uhr nachts eingestellt wird, läuft das Skript zunächst jede Minute, dann noch um 3:10, 3:15 und 3:20 falls der GPS Empfang mal sehr schlecht ist (z.B. beim Testen im Haus).
Meistens greift die Synchronisation schon nach der ersten oder zweiten Minute. Dann steht die Uhr auf der realen Zeit und das Skript läuft erst wieder um 3:01 Uhr nachts - da fahr ich aber eher selten  Shy
Eine weitere Änderung ist noch notwendig, damit ntpd auch wirklich die /etc/ntp.conf verwendet.
In /etc/init.d/ntp sind ziemlich am Anfang die Zeilen auszuschalten (# vorsetzen)
Code:
...
#if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
#       NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
#fi
...

Mit diesen Änderungen stellt sich meine Uhr recht schnell ein, auch wenn der CarPC über Nacht ausgeschaltet war.

BTW: ich habe die Option -g beim ntpd mit der echten Config laufen. Da schert sich ntpd seltsamerweise einen Dreck darum.
Zitieren
#18
Hallo, 
Danke für Anleitung.
Beim übernehmen ist mir aufgefallen du als  IP´s  "127.127.28.0"  und "127.127.20.0" verwendest. 
Ist das Absicht ?
Zitieren
#19
Ja, die IPs 127.127.28.0 und 12.127.20.0 lesen aus dem Shared Memory des GPS-Daemon.
Sie sind also korrekt.
Die 127.127.28.0 ist die normale IP um NTPD und GPSD abzugleichen ... sie funktioniert leider nur nicht immer.
Darum das bisschen Skripting ;-)
Zitieren
#20
Bei mir klappt das irgendwie nicht und seit ixh es eingestellt habe ist beim navi die Uhrzeit auch falsch davor hatte das navi die richtige Zeit aber der "homescreen" nicht

Gesendet von meinem SM-N9005 mit Tapatalk

Car pi
Raspberry pi3 Offizielles 7 Zoll Touchscreen

Smart Mirror
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste
RasPiCarProjekt