Nebenan geht's um DCF77-Feinheiten und deshalb sollten wir mit den GPS-Feinheiten evt. hierher umziehen. Auslöser für die Mischung war wohl ich Beitrag "Re: DCF77 Auswertung (ein bisschen anders)" auf dieses Foto hin Beitrag "Re: DCF77 Auswertung (ein bisschen anders)" und dann Beitrag "Re: DCF77 Auswertung (ein bisschen anders)" Beitrag "Re: DCF77 Auswertung (ein bisschen anders)" Beitrag "Re: DCF77 Auswertung (ein bisschen anders)" Beitrag "Re: DCF77 Auswertung (ein bisschen anders)" und dann! Beitrag "Re: DCF77 Auswertung (ein bisschen anders)" > 900ss D. schrieb: > > Der Status hier hat aber noch nichts mit dem Positionfix zu tun. Die > > Position kann noch ungültig sein obwohl der Status auf 'A' steht. Die > > Zeit in dem RMC-Datensatz ist dann aber gültig. > > Das kann nicht sein. Woher soll der Empfänger die genaue Zeit kennen, > wenn er nicht weiss, wo er ist? > > Eine Aussage über die Genauigkeit liefert erst der TDOP- bzw. GDOP-Wert. > Insofern ist für die Bewertung der Genauigkeit eher der GSA-Sentence > geeignet. Naja, was heißt "genau", verglichen mit DCF? Da trennen uns doch 3 bis 4 Größenordnungen. Sobald der Empfänger die Zeit von einem Satelliten empfangen hat, ist er doch schon besser als jeder (AM-)DCF-Empfänger. Es wäre natürlich wünschenswert, wenn er 3 oder mehr Zeiten zur Überprüfung nutzen würde. Aber seine Position hat er trotzdem nicht wenn die Satelliten ungünstig stehen. Allerdings sollte der RMC Status solange nicht 'A' sein. Wieweit kann man der Zeit unter den Umständen trauen? "Das Internet" schreibt irgendwo, dass mehrere Sekunden Abweichung möglich sind. Das ist plausibel, wenn die Schaltsekunden gemeint sind, also die Differenz GPS-Zeit zu UTC. Gibt ein Empfänger tatsächlich GPS statt UTC aus oder wie?
Bauform B. schrieb: > Das kann nicht sein. Woher soll der Empfänger die genaue Zeit kennen, > wenn er nicht weiss, wo er ist? > > Eine Aussage über die Genauigkeit liefert erst der TDOP- bzw. GDOP-Wert. > Insofern ist für die Bewertung der Genauigkeit eher der GSA-Sentence > geeignet. Ich meine mich zu erinnern, dass der Status im RMC vor dem FIX-Status ok war. Ich warte (glaube ich) 3x RMC Status 'A' ab, dann erst nehme ich die Uhrzeit. Der Satellit sendet die GPS-Zeit und die aktuelle Differenz zur UTC. Der GPS-Empfänger macht daraus dann UTC, die dann auch z.B. im RMC- Datensatz geliefert wird. Da der Satellit die Uhrzeit schon sendet, reicht der Empfang von einem Satellit für die Uhrzeit aus, aber noch nicht zur Positionsbestimmung. Die Uhrzeit selbst ist dann auch noch nicht Laufzeitkorrigiert .
:
Bearbeitet durch User
Zu dem Zeitpunkt, wo die Uhrzeit im NMEA-Output auftaucht, ist das sowieso schon alles Vergangenheit. Zwischen 1PPS-Signal und Anfang der Sentence-Ausgabe vergeht immer einige Zeit, beim EM406 bspw. rund 270ms zum RMC oder 250ms zum ZDA. Für eine Wanduhr mag das ok sein, aber manchmal hat man es doch gerne genauer ;-)
Wolfgang schrieb: > Zwischen 1PPS-Signal und Anfang der Sentence-Ausgabe vergeht immer > einige Zeit, beim EM406 bspw. rund 270ms zum RMC oder 250ms zum ZDA. > > Für eine Wanduhr mag das ok sein, aber manchmal hat man es doch gerne > genauer ;-) Ja, bei DCF77-Uhren ist die Abweichung typisch kleiner 0,1s.
Ich meine mal gelesen zu haben, daß die Zeit der GPS-Empfänger bzw. der Uhren in den GPS-Satelliten übers Jahr um 10s falsch geht und ein mal pro Jahr gestellt wird. Da aber alle Uhren gleich falsch gehen, spielt das für die Positionsbestimmung keine Rolle. Bei 20200km Höhe haben wir eine Signallaufzeit von 67ms. Für eine Uhr ok.
Crazy H. schrieb: > Ich meine mal gelesen zu haben, daß die Zeit der GPS-Empfänger bzw. der > Uhren in den GPS-Satelliten übers Jahr um 10s falsch geht und ein mal > pro Jahr gestellt wird. Dazu wäre allerdings eine vertrauenswürdige Quellenangabe nicht so schlecht. Warum sollten die Atomuhren auf den GPS-Satelliten schlechter sein, als ein guter Quarzoszillator?
Crazy H. schrieb:
> Ich meine mal gelesen zu haben...
Dabei kommt (wie hier) oft Müll raus!
Die Satellitenuhren gehen über die Jahre zur Zeit sogar um 18 s
"falsch"!
Die machen einfach die Schaltsekunden nicht mit, aber sie kennen
die UTC-Abweichung und senden einen Korrekturwert aus.
Bei Empfang von 4 Satelliten ist es NULL Problem für das GPS-Modul
die GPS-Zeit (mit Schaltsekunden UND Laufzeit) auf wenige µs genau
bereitzustellen. - Sie geben auch UTC aus.
Machen aber viele günstige Module, auch solche mit PPS nicht so
toll, selbst wenn man auf > 4 Satelliten und gute PDOP-Werte wartet.
Beim NaviLock EM-406A sind es immer wieder mal unerklärliche
+/- 1..2 s.
Beim ETEK EBS-85A bin ich recht zufrieden.
Man muss natürlich, um auf ms-Genauigkeit, oder mehr zu kommen,
einen Offset für die serielle Datenübertragung und Dekodierung
relativ zum Sekundenbeginn einbeziehen.
Also mit dem PPS-Puls an INT0 oder Input-Capture den schon
abgelaufenen Sekundenbruchteil bis zum dekodierten Zeittelegramm
aus dem RMC-/ZDA-Telegramm erfassen.
Ohne PPS muss man hoffen, dass die sekündlichen Telegrammabfolgen
pünktlich zum Sekundenbeginn starten und die Zeit bis zur Dekodierung
des RMC-Telegramms rückwärts berechnen. Geht vielleicht im allerbesten
Fall auf wenige ms genau.
Entschuldigung: Das Modul heißt ETEK EB-85A. (ohne 'S')
Jacko schrieb: > und die Zeit bis zur Dekodierung des RMC-Telegramms rückwärts berechnen Wird immer GENAU die gleiche Rechenzeit für die CPU-Befehle benötigt? Kleine Differenzen würde ich da auch erwarten.
Oh man, ... Wie viel Ahnung habt ihr von GPS wirklich? Die Uhrzeiten der Satelliten driften wegen Einstein und seiner Relativitäts Theorie weg. Die schwerkraft ist geringer. Darum vergeht die Zeit langsamer. Schwerkraft technisch gesehen ist die Erde keine Kugel sonder eher eine Kartoffel. Damit ist der drift für jeden Satelliten unterschiedlich, da er auf unterschiedlichen Bahnen um die Kartoffel kreisen. GPS selber zu dekorieren halt ich für extrem ambitioniert. GPS war/ist ein militärisches Signal wenn du nicht weißt was du suchst, wirst du das signal nicht finden. Alle Satelliten senden auf der gleichen Frequenz. Die Signal Stärke liegt unterhalb des rauschens. Nur wenn du weißt welcher Satelliten gerade über dir ist, und du das zugehörige Codierpartnern kennst, kannst du aus dem rauschen überhaupt was decodieren. Gruss
Ich meine mal gelesen zu haben (bei UBLOX) das die einigermaßen guten Empfänger im "3DFix" das PPS Signal mit allen optimierungen auf 20ns genau einloggen. (Vorher geht das auch nicht an) Dazu kann man sich über das UBX Protokoll bei UBlox Die Millis und eine berechnete Abweichung des PPS Pulses in ns abfragen. (und noch viel mehr) Dann gibt es noch die etwas teurere NEO N Serie welche extra für Zeitkritische Messungen konzipiert wurde.
:
Bearbeitet durch User
oszi40 schrieb: > Wird immer GENAU die gleiche Rechenzeit für die CPU-Befehle benötigt? Mit der Rechenzeit käme man bei einem CPU-Takt von z.B. 8 MHz auf wenige µs Unsicherheit. Die GPS-Telegramme (Sentences) können aber variable Länge haben, womit man bei 9600 Bd schon gut 1 ms pro Byte länger/kürzer kommt. Daher mein Vorschlag, wenn vorhanden, auch den PPS-Puls zeitlich zu erfassen. 123 (Gast) schrieb: > GPS selber zu deko..... Thema verfehlt, 6! Hier geht's um die bestmögliche Auswertung der Ausgabedaten von GPS-Modulen.
Philipp K. schrieb: > Ich meine mal gelesen zu haben (bei UBLOX) das die einigermaßen guten > Empfänger im "3DFix" das PPS Signal mit allen optimierungen auf 20ns > genau einloggen. (Vorher geht das auch nicht an) Im Datenbalt werden 100 ns max. Beschrieben. Ich habe bisher nur den Jitter gegen eine andere Zeit Quelle getestet und komme dort bei guten Bedingungen immer auf deutlich unter 100 ns.
oszi40 schrieb: > Jacko schrieb: >> und die Zeit bis zur Dekodierung des RMC-Telegramms rückwärts berechnen > > Wird immer GENAU die gleiche Rechenzeit für die CPU-Befehle benötigt? > Kleine Differenzen würde ich da auch erwarten. Ich würde auch größere erwarten, immerhin berechnet der Empfänger in der Zeit die Position und der PPS wird per Hardware erzeugt. Praktisch sieht es nicht soo schlecht aus, jedenfalls, was ein ntpd daraus macht. Hier füttere ich einen ntpd mit dem $GPRMC-Satz aus einer Antaris-Maus. Die gibt diesen Satz als ersten aus, also entfällt der Jitter durch unterschiedlich lange Sätze. Laut "ntpq -p" bleibt er unter 10ms. Der Offset (gegen pool.ntp.org) ist ca. 150ms. An einem anderen Rechner hängt eine etwas neuere u-blox Maus, da ist der Offset nur 38ms und der Jitter scheint auch besser zu sein. Während ich das hier schreibe, war er unter 4ms.
Ich würde das so sehen: das pps Signal ist bei gutem Empfang das Maß der Dinge und im Bereich von 20-50ns genau, welche Zeit das dann ist wird im seriellen Datensatz angezeigt. Nur ist mir entfallen, ob es die Sekunde vor oder nach dem pps Signal darstellt. Weiß das jemand ?
Das ist natürlich nicht genormt. Beim u-blox 7 kommt erst der PPS, dann der Text dazu. Beim u-blox 8 ist es umgekehrt. siehe "Receiver Description Including Protocol Specification".
:
Bearbeitet durch User
Jetzt ist meine Antaris-Maus gerade garnicht gut drauf und verliert gegen DCF (der auch noch per DSL aus dem Internet kommt) :)
1 | remote refid st t when poll reach delay offset jitter |
2 | ========================================================================= |
3 | -127.127.20.0 .GPS. 2 l 62 64 377 0.000 11.353 24.185 |
4 | +89.163.241.149 192.53.103.104 2 u 112 128 377 29.437 15.182 6.433 |
5 | *131.188.3.221 .DCFp. 1 u 113 128 377 29.179 5.551 6.612 |
6 | +178.63.93.21 192.53.103.103 2 u 111 128 377 37.646 1.126 5.017 |
123 schrieb: > Die Uhrzeiten der Satelliten driften wegen Einstein und seiner > Relativitäts Theorie weg. Die schwerkraft ist geringer. Darum vergeht > die Zeit langsamer. Das ist richtig. Im Realen macht die Zeitdilatation durch Schwerkraftdifferenz in 300 km Höhe etwa 1ms/Jahr aus...
Schorsch X. schrieb: > Nur ist mir entfallen, ob es die Sekunde vor oder nach dem pps Signal > darstellt. > Weiß das jemand ? Beim NaviLock EM-406A kommt auch erst der 1PPS und dann die Daten.
Schorsch X. schrieb: > im Bereich von 20-50ns genau 123 schrieb: > Die Uhrzeiten der Satelliten driften wegen Einstein und seiner > Relativitäts Theorie weg. Die Schwerkraft Von der Sat-Bahn her gesehen sind immer Abweichungen auch durch andere Planeten und Gravitation zu erwarten. Bei Astra z.B. werden die Bahnkorrekturen wegen sparsamen Umgang mit Treibstoff erst bei einer Differenz >100km gestartet. Sowas wirkt sich natürlich auch auf Signallaufzeiten etwas aus. Wer da an Nanosekunden-Genauigkeit glaubt, wird wohl korrigieren müssen?
also in allen ublox Generationen steht wohl die selbe Aussage zum Time Pulse:
1 | The time pulse function can be configured using the CFG-TP5 message. The TIM-TP message provides time information for the next pulse, time source and the quantization error of the output pin. |
alles andere wäre doch unsinnig...
123 schrieb: > Die Uhrzeiten der Satelliten driften wegen Einstein und seiner > Relativitäts Theorie weg. Falsch. Sie driftet nicht weg, sondern hin. Als das GPS konzipiert wurde, war die Relativitätstheorie bereits bekannt und sowohl Schwerefeld als auch Geschwindigkeiten der Satelliten wurde im Systemkonzept berücksichtigt. Bei einem GPS-Satelliten, der am Boden steht, geht die Zeit falsch.
Wolfgang schrieb: > Bei einem GPS-Satelliten, der am Boden steht, geht die Zeit falsch. Da die Cäsiumuhren von Deutschland und den USA auch in unterschied- lichen Höhen über NN stehen, müssen bei Uhrenvergleichen auch dort bereits Korrekturfaktoren benutzt werden. Bei künftigen, genaueren Uhren gibt es bereis meßbare Unterschiede, je nachdem, ob die Uhr auf dem Fußboden oder auf dem Labortisch steht.
Jacko schrieb: > Entschuldigung: Das Modul heißt ETEK EB-85A. > (ohne 'S') der ist ja auch schon uralt ..... und das mit dem Müll nehm ich persönlich :-D
Wolfgang schrieb: > Bei einem GPS-Satelliten, der am Boden steht, geht die Zeit falsch. Genau. Und die ganze (ziemlich nutzlose) Diskussion über den Fehler im ns Bereich ist überflüssig, da der PPS-Interrupt mindestens um +/- 1 Takt ungenau ist - bei 16MHz sind es schon 62,5ns. Jitterer schrieb: > Im Datenbalt werden 100 ns max. Beschrieben. Ich habe bisher nur den > Jitter gegen eine andere Zeit Quelle getestet und komme dort bei guten > Bedingungen immer auf deutlich unter 100 ns. Der Fehler von mindestens +/- 1 Takt bleibt trotzdem, deswegen ist es auch witzlos, GPS für so etwas missbrauchen zu wollen. Frage an alle Spezialisten die schon Jitter unter 100ns gemessen haben (wollen): Wozu das alles und womit und wie habt ihr das gemessen ? Wozu wird das gebraucht ? Was muss jede Sekunde nur einmal mit GPS-ns Genauigkeit geschaltet werden, da schon nach dem ersten Einschalten in dieser Sekunde eigene Quarzungenauigkeiten ins Spiel kommen ? Schorsch X. schrieb: > Nur ist mir entfallen, ob es die Sekunde vor oder nach dem pps Signal > darstellt. > Weiß das jemand ? Nach PPS, nur ist die Zeit zwischen aufsteigender PPS Flanke und Datensatzbegin absolut ungenau und ohne jegliche Bedeutung. Ausserdem kann es passieren, dass PPS zwar kommt, aber der Datensatz unmittelbar danach trotzdem nicht voll gültig ist ("V").
:
Bearbeitet durch User
Crazy H. (crazy_h) schrieb: > der ist ja auch schon uralt ..... > und das mit dem Müll nehm ich persönlich :-D Kann ich doch nix für, dass das alte ETEK EB-85A (vor ein paar Jahren recht günstiger Preis) bessere Firmware hat, als das neuere (voriges Jahr recht günstig) NaviLock EM-406A. Die +/-1..2 s-Macke habe ich bei 2 Exemplaren feststellen müssen. Und dass deine "mal gelesene" Erinnerung nicht so recht stimmt, hast du wohl selbst erkannt. - Nimm's also nicht übel! Marc V. (Firma: Vescomp) (logarithmus) schrieb: > ... (ziemlich nutzlose) Diskussion über den Fehler im > ns Bereich ist überflüssig Da stimme ich zu! Außerhalb der Synchronisation von wide-field Radio-Astronomie, oder bei der Inbetriebhaltung von GPS-Satelliten, brauchen nur wenige Menschen mehr als einige ms-Genauigkeit für ihre Uhr. Auch die Börsen-Scalper agieren nur sekundengenau. Mit NTPv4 kommt ihr Business-Computer ja bestenfalls auf +/-10 ms. Die ns-Genauigkeit wird man auch nicht für einige 100 EU amateurmäßig zur Anwendung bringen! Da mag das Datenblatt viel versprechen.
Jacko schrieb: > Die ns-Genauigkeit wird man auch nicht für einige 100 EU > amateurmäßig zur Anwendung bringen! > Da mag das Datenblatt viel versprechen. Also die PPS benutze ich schonmal zum messen von nem Crystal oder einer TCXO oder so.. wiederholt auf eine Sekunde macht natürlich keinen Sinn.. zwischen den Pulsen zu messen kann einen schon weiterbringen.
Philipp K. (philipp_k59) schrieb: > Also die PPS benutze ich schonmal zum messen von nem Crystal oder > einer TCXO oder so. Genau das war auch meine Erwartung, als die ersten Module mit PPS erschwinglich wurden. Bei mäßigen bis guten DOP-Werten komme ich mit einem günstigen GPS-Modul auf 10^-7, was schon mal reicht, 10 MHz auf 1..2 Hz abzugleichen. Frequenzreferenz +/-50 ns/s ist aber auch eine GANZ andere Baustelle, als eine Uhr mit < +/-10 ns Offset zu utc! Wenn Tor-auf und Tor-zu beim Frequenzzähler gleichmäßig verschoben sind, ist das unerheblich. Bei der Uhr ist das eine Verschiebung!
Jacko schrieb: > Frequenzreferenz +/-50 ns/s ist aber auch eine GANZ andere Baustelle, > als eine Uhr mit < +/-10 ns Offset zu utc! Bei solchen Zeitmaßstäben muss man sich schon überlegen, was eine Uhr überhaupt mit UTC zu tun hat. Es sollte jedem klar sein, dass ein Tag mehr als 86400.00000 Sekunden hat und UTC nur ein künstlicher Raster ist, der allenfalls halbwegs dazu passt und immer wieder durch Schaltsekunden nachgezogen werden muss.
... und der nächste Rollover am 6. April kommt ....
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.