mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik GPS- statt DCF77-Auswertung (ein bisschen anders)


Autor: Bauform B. (bauformb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Harald W. (wilhelms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Crazy H. (crazy_h)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Wolfgang (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Jacko (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldigung: Das Modul heißt ETEK EB-85A.
(ohne 'S')

Autor: oszi40 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: 123 (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jitterer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Schorsch X. (bastelschorsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt ist meine Antaris-Maus gerade garnicht gut drauf und verliert 
gegen DCF (der auch noch per DSL aus dem Internet kommt) :)
     remote          refid    st t when poll reach  delay  offset  jitter
=========================================================================
-127.127.20.0   .GPS.          2 l   62   64  377   0.000  11.353  24.185
+89.163.241.149 192.53.103.104 2 u  112  128  377  29.437  15.182   6.433
*131.188.3.221  .DCFp.         1 u  113  128  377  29.179   5.551   6.612
+178.63.93.21   192.53.103.103 2 u  111  128  377  37.646   1.126   5.017

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: G. H. (schufti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also in allen ublox Generationen steht wohl die selbe Aussage zum Time 
Pulse:
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...

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald W. (wilhelms)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Crazy H. (crazy_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marc V. (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jacko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michel M. (elec-deniel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und der nächste Rollover am 6. April kommt  ....

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.