schönen Nachmittag miteinander, statt per DCF77- nimmt man heute ja GPS-Empfänger. Bei DCF77 hat mich schon immer gestört, dass es praktisch keine Anzeige für Feldstärke und/oder Empfangsqualität gibt. Mit GPS ist es umgekehrt, ich bekomme zuviele Daten. Wie bringt man die am geschicktesten auf eine Anzeige? PDOP oder GDOP sieht gut aus, aber warum? Nach einem Kaltstart werden die langsam immer besser, was aber nicht sein kann, weil Wikipedia sagt, dass das (nur) Geometriefehler sind. Würde eine ungünstige Konstellation aus 4 Satelliten überhaupt auch die Zeit verschlechtern? Ich brauche keine Position, möchte aber die Empfangsqualität(?) wissen. Es gibt von jeden Satelliten Signal/Noise Werte, aber da müsste ich erstmal rausfinden, welche benutzt werden. Und dann? Einfach den Mittelwert nehmen? Oder gibt es etwas einfacheres? Noch eine Bonusfrage: Mal angenommen, der Empfänger liefert heute die richtige UTC und demnächst eine aus der Vergangenheit. Dann muss ich doch keinen neuen kaufen sondern addiere einfach 7*24*60*60 Sekunden und kann ihn noch 1024 Wochen benutzen, oder?
Bauform B. schrieb: > Bei DCF77 hat mich schon immer gestört, dass es praktisch keine Anzeige > für Feldstärke und/oder Empfangsqualität gibt. Die Anzeige der Feldstärke macht bei DCF-Empfängern auch wenig Sinn, da Empangsstörungen nur selten an zuwenig Feldstärke, sondern meist an lokalen Störquellen liegt. "Empfangsqualität" dagegen lässt sich nur schwer definieren, weil diese mit den Aufwand bei der Dekodierung verknüpft ist.
Harald W. schrieb: > Bauform B. schrieb: > >> Bei DCF77 hat mich schon immer gestört, dass es praktisch keine Anzeige >> für Feldstärke und/oder Empfangsqualität gibt. > > Die Anzeige der Feldstärke macht bei DCF-Empfängern auch wenig Sinn, > da Empangsstörungen nur selten an zuwenig Feldstärke, sondern meist > an lokalen Störquellen liegt. "Empfangsqualität" dagegen lässt sich > nur schwer definieren, weil diese mit den Aufwand bei der Dekodierung > verknüpft ist. Wenn dann wäre ein gutes Maß der Anteil von gültigen und ungültigen/gar nicht empfangen Telegrammen pro Stunde.
Auf die GPS Zeit hat die Anzahl der empfangenen Satelltien keinen Einfluss, einer reicht schon. Die Qualität der anderen GPS Daten korreliert aber recht gut mit der Satellitenzahl, sollte auch schon als Kriterium gelten können. Jedenfalls ist bei null Sats klar, das auch die Zeit nicht gültig ist.
Matthias S. schrieb: > Auf die GPS Zeit hat die Anzahl der empfangenen Satelltien keinen > Einfluss, einer reicht schon. Das ist falsch. Die GPS Zeit steht in Verbindung mit einem 3D-Fix. Man hat entweder beides oder gar nichts. Somit sind 4 Satelliten Minimum.
Cyblord -. schrieb: > Das ist falsch. Oder es hängt vom Receiver ab, der erst dann überhaupt Daten liefert. Ich habe hier jedenfalls einen, der schon bei einem Satelliten die Zeit liefert. ('Scorpion' Chipsatz / Blaupunkt).
Matthias S. schrieb: > Cyblord -. schrieb: >> Das ist falsch. > > Oder es hängt vom Receiver ab, der erst dann überhaupt Daten liefert. > Ich habe hier jedenfalls einen, der schon bei einem Satelliten die Zeit > liefert. ('Scorpion' Chipsatz / Blaupunkt). GPS Empfänger haben meist eine normale eingebaute Echtzeituhr. Die GPS-Zeit wird aber im Zuge der Positionsermittlung erst berechnet. Deshalb werden auch 4 statt 3 Satelliten benötigt. Hätte der GPS Empfänger eine Atomuhr an Bord würden 3 Satelliten für ein 3D-Fix reichen.
Cyblord -. schrieb: > Deshalb werden auch 4 statt 3 Satelliten benötigt. Hätte der GPS > Empfänger eine Atomuhr an Bord würden 3 Satelliten für ein 3D-Fix > reichen. Gut, dann ist ja die Anzahl der empfangenen Satelliten ein gutes 'magisches Auge' - ab 4 Satelliten ists dann brauchbar.
Bauform B. schrieb: > Noch eine Bonusfrage: Mal angenommen, der Empfänger liefert heute die > richtige UTC und demnächst eine aus der Vergangenheit. Dann muss ich > doch keinen neuen kaufen sondern addiere einfach 7*24*60*60 Sekunden und > kann ihn noch 1024 Wochen benutzen, oder? Wieso sollte er das tun? Wenn, dann zeigt er bereits jetzt das falsche Datum. Die Uhrzeit ist immer UTC. Diesen GPS-week-rollover bzw. das daraus resultierende falsche Datum interessiert nur, wenn du auch ein Datum anzeigen lassen willst und mit den Koordinaten automatisch die richtige Sommerzeitkorrektur durchführen willst. Achja und du mußt 7168 Tage addieren.
Die GPS-Signale sind etwas kompliziert. Jeder Satellit sende den "Almanach" (die Information, wann welcher Satellit wo aktiv ist) und seine genauen Bahndaten (die "Ephemeriden"). Damit reicht auch das Signal eines Satelliten, um die Uhrzeit zu erhalten, aber nicht um den als eine Art "Zeitnormal" nutzbaren Sekundenpuls. Für eine Positionsbestimmung braucht man "normalerweise" 4 Satelliten. Der Empfänger muss nämlich 4 Unbekannte berechnen, nämlich den Längen- und den Breitengrad, die Höhe des Empfängers und die Zeitkorrektur, da die Genauigkeit der Zeitbasis im GPS-Empfänger für eine Ortung nicht ausreicht. Die Satelliten befinden sich nämlich 20.000 bis 25.000 km über der Erde. Für die Positionsberechnung wird die Laufzeit der Signale ausgewertet. Erfolgt diese mit einer Zeitbasis, deren Takt eine Genauigkeit von 1% hat, wäre die Position nur 20 bis 25 km genau möglich. In ähnlicher Weise kann man ermitteln, wie genau die Zeitbasis sein muss, um eine vorgegebenen Positionsgenauigkeit zu erhalten. Da selbst temperaturkompensierte Oszillatoren die notwendige Genauigkeit nicht liefern, braucht man den 4. Satelliten zur Zeitkorrektur. Damit kann man dann die Position berechnen - wenn die aus den Satelliten gewonnene Information "mathematisch unabhängig" ist. (Die Bedingung "mathematisch unabhängig" kann man sich so vorstellen: Ein Stativ mit 3 Beinen steht "normalerweise" sicher. Stehen aber alle 3 Beine in einer Linie, kippt das Ganze. Je weiter die Beine auseinander stehen, desto sicherer steht das Stativ. So ähnlich ist das beim GPS. Je weiter die Satelliten auseinander stehen, desto genauer lässt sich die Position berechen. Die von den Satelliten "aufgespannte Fläche" sollte möglichst groß sein. Dann wird der PDOP-Wert klein, was einer genaueren Position entspricht. "PDOP" bedeutet ungefähr "Verwässerung der Position". Wenn man nun so eine Position bekommen hat und damit die Höhe bekannt ist, reichen auch 3 Satelliten, um eine Position zu berechen. Dann darf sich die Höhe aber nicht ändern, sonst stimmt die Position nicht mehr. Diese Position (mit "alter" Höhe) ist ein sogenannter 2D-FIX. Dann wird die Genauigkeit der Position statt über den "PDOP"-Wert über den "HDOP"-Wert angegeben. Das "H" vor dem "DOP" sagt, dass die Höhe nicht erneut berechnet werden konnte. Das "magische Auge" müsste also sinnvoll von den DOP-Werten abgeleitet werden.
Matthias S. schrieb: > Auf die GPS Zeit hat die Anzahl der empfangenen Satelltien keinen > Einfluss, einer reicht schon. Woher weiß der Empfänger dann, wie weit er vom Satellit weg ist, um die Laufzeit des Signals zu kompensieren?
https://www.u-blox.com/en/product/u-center Das Bild oben rechts im u-center, ist doch das perfekte "Magische Auge ins All". Rote und Grüne Satelliten, das ist sogar Zeitgemäß.
Rolf M. schrieb: > Matthias S. schrieb: >> Auf die GPS Zeit hat die Anzahl der empfangenen Satelltien keinen >> Einfluss, einer reicht schon. > > Woher weiß der Empfänger dann, wie weit er vom Satellit weg ist, um die > Laufzeit des Signals zu kompensieren? Bei einer Uhr wären die paar ms (ok sagen wir mal 80-100) doch egal.
Die 4 Satelliten braucht es fuer die Zeitaufloesung von ns, fuer die Postion. Die absolute Zeit auf eine Sekunde genau stimmt auch schon mit einem Satelliten alleine.
Bauform B. schrieb: > Nach einem Kaltstart werden die langsam immer besser, was aber nicht > sein kann, weil Wikipedia sagt, dass das (nur) Geometriefehler sind. Natürlich werden die nach einem Kaltstart besser, allerdings nicht langsam, sondern schrittweise. Nach einem Kaltstart wird dein Empfänger sich wahrscheinlich erstmal auf 3 Satelliten stürzen und gucken, dass er deren Signale sauber zu fassen hat. Daraus rechnet er einen 2D-Fix (mit der letzten bekannten Höhe?) aus. Erst wenn er diese Position hat, nimmt er weitere Satelliten dazu und kann damit den Positionsfehler weiter verbessern, i.e. die Geometriefehler werden durch Auswertung von mehr Satelliten kleiner.
Bauform B. schrieb: > Noch eine Bonusfrage: Mal angenommen, der Empfänger liefert heute die > richtige UTC und demnächst eine aus der Vergangenheit. "Demnächst" ist noch eine ganze Weile hin. Wenn er heute die richtige UTC ausrechnet, kannst du dich darauf verlassen, dass er das auch noch bis einschließlich 19. November 2038 tut. Am 20. September wird es dann kritisch.
Crazy H. schrieb: > Rolf M. schrieb: >> Matthias S. schrieb: >>> Auf die GPS Zeit hat die Anzahl der empfangenen Satelltien keinen >>> Einfluss, einer reicht schon. >> >> Woher weiß der Empfänger dann, wie weit er vom Satellit weg ist, um die >> Laufzeit des Signals zu kompensieren? > > Bei einer Uhr wären die paar ms (ok sagen wir mal 80-100) doch egal. 100 ms Abweichung bekommt man aber auch ohne GPS hin. Und ich hab diese Aussage so interpretiert, dass er die Zeit schon sehr genau will: Bauform B. schrieb: > Würde eine ungünstige Konstellation aus 4 Satelliten überhaupt auch die Zeit verschlechtern?
Wenn er überhaupt ne Zeit bekommt. Das klappt zuverlässig und genau nur im Freien und ist kein wirklicher Ersatz für den Langwellenfunk.
Rolf M. schrieb: > Woher weiß der Empfänger dann, wie weit er vom Satellit weg ist, um die > Laufzeit des Signals zu kompensieren? Das kann er doch einfach ausrechnen. Er rechnet die Position des Empfängers auf der Erde aus und kann damit dann den Abstand zum Satelliten bestimmen.
> addiere einfach 7*24*60*60 Sekunden
Damit hast du 1024 Wochen gewonnen.
Danach dann einfach: 2*7*24*60*60 dazuaddieren.
Usw. usf.
Die Navigationsfunktion ist lustigerweise von diesem
Fehler ueberhaupt nicht betroffen.
Cyblord -. schrieb: > Wenn dann wäre ein gutes Maß der Anteil von gültigen und ungültigen/gar > nicht empfangen Telegrammen pro Stunde. Ein schönes Beispiel für theoretisch perfekt und praktisch naja. Matthias S. schrieb: > Gut, dann ist ja die Anzahl der empfangenen Satelliten ein gutes > 'magisches Auge' - ab 4 Satelliten ists dann brauchbar. Null Aufwand für etwas, was jeder sofort versteht - sehr verdächtig ;) Crazy H. schrieb: > Bauform B. schrieb: >> Mal angenommen, der Empfänger liefert heute die richtige UTC >> und demnächst eine aus der Vergangenheit. > Wieso sollte er das tun? Wenn, dann zeigt er bereits jetzt das falsche > Datum. Warum sollte er das tun? Manche Empfänger können richtig rechnen. Aber 1024 Wochen später wird es zweideutig. Auf jeden Fall danke für die 7168 Tage! Günni schrieb: > Das "magische Auge" müsste also sinnvoll > von den DOP-Werten abgeleitet werden. Das wäre naheliegend, aber mal angenommen, wir sehen 3 Satelliten im Dreieck über uns. S/N ist gut und HDOP knapp bei 1.0. Jetzt bewegen die sich so blöd, dass das Dreieck immer flacher wird. HDOP wird deutlich schlechter obwohl S/N praktisch gleich bleibt. Nicht mag :( pegel schrieb: > https://www.u-blox.com/en/product/u-center > > Das Bild oben rechts im u-center, ist doch das perfekte > "Magische Auge ins All". > > Rote und Grüne Satelliten, das ist sogar Zeitgemäß. Nett :) Mit meiner einen RGB-LED kann ich noch nicht ganz mithalten... Wolfgang schrieb: > Nach einem Kaltstart wird dein Empfänger sich wahrscheinlich erstmal auf > 3 Satelliten stürzen und gucken, dass er deren Signale sauber zu fassen > hat. Daraus rechnet er einen 2D-Fix (mit der letzten bekannten Höhe?) > aus. Erst wenn er diese Position hat, nimmt er weitere Satelliten dazu > und kann damit den Positionsfehler weiter verbessern, i.e. die > Geometriefehler werden durch Auswertung von mehr Satelliten kleiner. Überzeugend, danke. Es gibt doch für alles eine natürliche Erklärung. Wolfgang schrieb: > Bauform B. schrieb: >> Noch eine Bonusfrage: Mal angenommen, der Empfänger liefert heute die >> richtige UTC und demnächst eine aus der Vergangenheit. > "Demnächst" ist noch eine ganze Weile hin. Wenn er heute die richtige > UTC ausrechnet, kannst du dich darauf verlassen, dass er das auch noch > bis einschließlich 19. November 2038 tut. Ich fürchte, nicht; die Gebrauchsanweisung zum ublox-7 sagt
1 | GPS week rollover number; GPS week numbers will be set correctly |
2 | from this week up to 1024 weeks after this week. Default: 1691 |
In der Firmware sind also nicht die höchsten Bits der Woche, sondern ein Offset gespeichert - oder wie soll ich das verstehen? Vor allem kann es bei einem anderen Empfänger natürlich anders sein. Joggel E. schrieb: > Die 4 Satelliten braucht es fuer die Zeitaufloesung von ns, fuer > die Postion. Die absolute Zeit auf eine Sekunde genau stimmt > auch schon mit einem Satelliten alleine. Das deckt sich mit meinen Beobachtungen. Allerdings sind die Zeiten in den NMEA-Sätzen noch lange nach dem 3D-Fix falsch. Erst, wenn die aktuelle Anzahl der Schaltsekunden bekannt ist, gibt es die richtige UTC. Das dauert mindestens 12 Minuten. Richtig übel ist aber, dass bis dahin alle Flags "valid" anzeigen, obwohl die Zeit um mehrere Sekunden daneben ist. Für ein sinnvolles Flag muss man einen der privaten ublox-Sätze auswerten. Rolf M. schrieb: >> Bei einer Uhr wären die paar ms (ok sagen wir mal 80-100) doch egal. > > 100 ms Abweichung bekommt man aber auch ohne GPS hin. Und ich hab > diese Aussage so interpretiert, dass er die Zeit schon sehr genau will: Jein, ich bekomme zwar das PPS-Signal, aber meine Hardware geht trotzdem kaum genauer als ±2 ms. Der aktuelle Anlass war allerdings der Schaltsekunden-Fehler von 2000 ms. Das muss dann doch nicht sein. batman schrieb: > Wenn er überhaupt ne Zeit bekommt. Das klappt zuverlässig und > genau nur im Freien und ist kein wirklicher Ersatz für den > Langwellenfunk. Stimmt, das Sommerzeit-Bit fehlt. Aber UTC bekomme ich hier auf dem Tisch, 3 Meter von der Dachkante entfernt, durch eine schmale Balkontür, problemlos. Ein anderer Empfänger läuft unter einem Netzwerkschrank in der Zimmerecke, 4 bis 5 Meter vom Fenster.
Bauform B. schrieb: > Jein, ich bekomme zwar das PPS-Signal, aber meine Hardware geht trotzdem > kaum genauer als ±2 ms. Der aktuelle Anlass war allerdings der > Schaltsekunden-Fehler von 2000 ms. Das muss dann doch nicht sein. Falsche Hardware! Was verwendest du?
Voodoo schrieb: > Bauform B. schrieb: >> Jein, ich bekomme zwar das PPS-Signal, aber meine Hardware geht trotzdem >> kaum genauer als ±2 ms. Der aktuelle Anlass war allerdings der >> Schaltsekunden-Fehler von 2000 ms. Das muss dann doch nicht sein. > > Falsche Hardware! Was verwendest du? Nö, schlechte Firmware oder schlechtes Pflichtenheft oder gute alte Tradition. Der Empfänger bekommt die Anzahl der Schaltsekunden vom Satelliten, geht ja kaum anders. Allerdings hat dieses Datenbyte nicht gerade Priorität und wird nur alle 12 bis 30(?) Minuten gesendet. In der Zwischenzeit dürften die NMEA-Sätze mit Zeit oder Datum nicht gültig sein - sind sie beim ublox-7 aber. Der ublox-7 verwendet einen Default von 16 Sekunden, bis er erfährt, wieviele es wirklich sind (z.Zt. 18). Deshalb vermute ich, dass das NMEA-seitig gewollt ist, und man einen faulen Kompromiss versucht hat.
Das Rollover-Problem musste ich voriges Jahr lösen, da mein Gerät mit dem alten GPS-Modul sonst noch sehr nützlich ist. Das Problem betrifft einzig und allein die Datumsanzeige, lässt sich aber auf die Addition von 20 Jahren und dem Abzug von 137 Tagen reduzieren. Das ist mit etwas Kalenderrechnung (Monatslängentabelle + Schaltjahresregeln) lösbar. Ansonsten: Die DCF-Laufzeit bringt Fehler von einigen ms (Bodenwelle) und abhängig von der Tageszeit einigen 10 ms bei Raumwellen- überlagerung. Dazu kommen noch modellabhängige und Empfangspegel- abhängige Flankenverschleifungen des Zeit-Pulses. Also muss man immer mit 100 ms Unsicherheit rechnen. Ein einzelner GPS-Satellit ist 20.000 ... 30.000 km entfernt. Das ergibt einen Zeitfehler von etwa 67...100 ms, von dem man 83 ms abziehen könnte, um noch +/- 17 ms Unsicherheit zu haben. Aber was der Empfänger im Zwischenzustand liefert, bis er mit 4...5 Satelliten vielleicht auf 1 ms genau wird, ist nicht nachvollziehbar. Fazit: Bei DCF kann man Fehler von 100 ms haben, bei GPS ist es bei schlechtem Empfang manchmal noch schlechter: Ich kenne GPS-Empfänger, die auch mal 1..2 Sekunden daneben liegen, bevor sie nicht 5 Satelliten fest im Blick haben! Meldet der GPS-Empfänger aber im GPGSA-Satz einen 3-D-Fix (und gibt vielleicht ein PPS-Signal aus) sollte das Zeitsignal ordentlich konstruierter Modelle Fehler unter 1 ms haben.
Jakob schrieb: > Das Problem betrifft einzig und allein die Datumsanzeige, lässt > sich aber auf die Addition von 20 Jahren und dem Abzug von 137 > Tagen reduzieren. Es betrifft auch nicht die Wochentage, also Sonntags wird trotz Fehler nicht geweckt :) > Das ist mit etwas Kalenderrechnung (Monatslängentabelle + > Schaltjahresregeln) lösbar. Normalerweise zählt man ja intern nur Sekunden, insofern muss man nur 619315200 addieren. > Ein einzelner GPS-Satellit ist 20.000 ... 30.000 km entfernt. > Das ergibt einen Zeitfehler von etwa 67...100 ms, von dem man > 83 ms abziehen könnte, um noch +/- 17 ms Unsicherheit zu haben. In dem Zustand wird die Ausgabe immer als "ungültig" markiert. > Aber was der Empfänger im Zwischenzustand liefert, bis er mit > 4...5 Satelliten vielleicht auf 1 ms genau wird, ist nicht > nachvollziehbar. Doch, bis dahin ist immer noch alles klar geregelt, spannend wird es danach. Die Position ist dann bekannt und zwangsläufig auch die GPS-Zeit. Die stimmt dann auch auf besser als 1 us, oft besser als 100 ns. Also ist aus der Sicht der Navigation alles bestens. Nur die Umrechnung von GPS-Zeit auf UTC ist noch nicht möglich. > Ich kenne GPS-Empfänger, die auch mal 1..2 Sekunden daneben > liegen, bevor sie nicht 5 Satelliten fest im Blick haben! Ja, das ist genau das, was ich gerade gemerkt habe. Nur, es kommt nicht auf die Anzahl der Satelliten an, man muss einfach abwarten, bis alle Daten runter geladen sind. Und das dauert. > Meldet der GPS-Empfänger aber im GPGSA-Satz einen 3-D-Fix > (und gibt vielleicht ein PPS-Signal aus) sollte das Zeitsignal > ordentlich konstruierter Modelle Fehler unter 1 ms haben. Schön wär's. Aber ganz so schlimm ist es nicht. Die Position stimmt ja wirklich und das PPS-Signal ist überhaupt nicht betroffen, das ist an die GPS-Zeit gekoppelt. Außerdem ist UTC immer um ganze Sekunden (±1 us oder so) daneben.
Der Zeit-Fehler durch dem Empfänger erstmal unbekannte Schaltsekunden ist mir als PROBLEM noch nicht so bewusst geworden. Wenn selbst die ublox-Module (systembedingt) ähnliches Fehlverhalten, wie meine billigeren NAVILOCK-Module liefern, muss ich ja garnicht so traurig über meinen Geiz sein. :-) Aber für's schnellere Verständnis: Der unbekannte Leap-Second- Offset bringt keine 1000 ... 2000 ms Fehler, sondern einen simplen ganzzahligen Sekundenfehler. Der anfängliche Fehler hängt dann wohl einfach vom Erstellungsdatum der Firmware ab. Mit jeder folgenden Schaltsekunde dürfte der sich unvermeidlich ganzzahlig vergrößern. Gute Nacht, schöne Ostern!
Jakob schrieb: > Aber für's schnellere Verständnis: Der unbekannte Leap-Second- > Offset bringt keine 1000 ... 2000 ms Fehler, sondern einen > simplen ganzzahligen Sekundenfehler. Ja, genau, nicht 1000 bis 2000, sondern 1000 oder 2000. > Der anfängliche Fehler hängt dann wohl einfach vom > Erstellungsdatum der Firmware ab. > Mit jeder folgenden Schaltsekunde dürfte der sich unvermeidlich > ganzzahlig vergrößern. Davon kann man ausgehen. > Wenn selbst die ublox-Module (systembedingt) ähnliches > Fehlverhalten, wie meine billigeren NAVILOCK-Module liefern, > muss ich ja garnicht so traurig über meinen Geiz sein. :-) Vielleicht steht Navilock drauf und es ist ublox drin? Ansonsten verstärkt sich der Verdacht, dass das so sein muss.
> Es betrifft auch nicht die Wochentage, also Sonntags wird trotz Fehler > nicht geweckt :) Das ist klar, weil es ja um den Überlauf vom 10-Bit-Wochenzähler kommt. Aber einem einfach gestricktem Geist wie mir, ist (schaltsekunden- unabhängige) Tagesrechnung naheliegender, als Sekundenrechnung, die auch nicht ohne Kalenderrechnung auskommen wird. Besonders, weil das gelieferte Datum vom GPS-Empfänger auch nur aus der Wochenzahl + Tag in der Woche mit Kalenderrechnung und vorgegebenem Startdatum ermittelt wird.
Jakob schrieb: > Aber einem einfach gestricktem Geist wie mir, ist (schaltsekunden- > unabhängige) Tagesrechnung naheliegender, als Sekundenrechnung, > die auch nicht ohne Kalenderrechnung auskommen wird. Naheliegender sicher. Sobald man aber mehr macht, als das Datum nur anzuzeigen, sind Sekunden viel einfacher. Da man sowieso für die Anzeige umrechnen muss, kann man bei der Gelegenheit einfach 3600 Sekunden addieren und hat die Sommerzeit -- ohne die Uhr umzustellen. Das alleine ist es absolut wert, es gibt dabei nämlich keine Zweideutigkeit mehr. Zeitzonen gehen genauso einfach (von den politischen Problemen mal abgesehen). > Besonders, weil das gelieferte Datum vom GPS-Empfänger auch nur > aus der Wochenzahl + Tag in der Woche mit Kalenderrechnung und > vorgegebenem Startdatum ermittelt wird. Die ublox Module liefern bei Bedarf auch die GPS-Zeit, also Woche und Millisekunde der Woche. Damit geht's ohne Kalender. Aber für die allermeisten RTC-Chips braucht man die Umrechnung ja auch :(
Wolfgang schrieb: > Rolf M. schrieb: >> Woher weiß der Empfänger dann, wie weit er vom Satellit weg ist, um die >> Laufzeit des Signals zu kompensieren? > > Das kann er doch einfach ausrechnen. Er rechnet die Position des > Empfängers auf der Erde aus und kann damit dann den Abstand zum > Satelliten bestimmen. Hmpf… hier nochmal der von mir zitierte Satz, auf den sich meine Antwort bezieht: Matthias S. schrieb: > Auf die GPS Zeit hat die Anzahl der empfangenen Satelltien keinen > Einfluss, einer reicht schon. Also wie rechnet der GPS-Empfänger mit nur einem Satelliten seine Position aus, um den Abstand zu kennen, um damit die Laufzeit des Signals zu kompensieren?
Ich habe aber irgendwo mal gelesen, daß die Uhren aller Satelliten übers Jahr um die 10s falsch gehen und diese dann 1x/Jahr wieder gestellt werden. Stimmt das?
Crazy H. schrieb: > Ich habe aber irgendwo mal gelesen, daß die Uhren aller Satelliten übers > Jahr um die 10s falsch gehen und diese dann 1x/Jahr wieder gestellt > werden. Stimmt das? Eigentlich ist eine Angabe "pro Jahr" sinnlos, weil die Uhren der Satelliten ständig überwacht werden und bei Bedarf korrigiert werden. Solange dabei nichts schief geht, bleibt der Fehler kleiner als ±20 ns - egal, ob über Tage oder Jahre. Dazu kommt der Fehler von UTC(USNO), der aber auch langfristig nicht größer wird oder per Definition sogar Null ist. Weil, was ist denn die "richtige" Zeit? Praktisch, also im wirklichen Leben, ist es die GPS-Zeit, also UTC(USNO). Theoretisch, also vom Namen her, sollte es UTC sein, der gewichtete Mittelwert von vielen Instituten wie USNO oder PTB. Aber wie kommt dann TAI ins Spiel? Ach so, das kann schon sein, dass du sowas gelesen hast. Vielleicht hat jemand geschrieben: "Meine RTC ist so gut, die muss ich nur einmal im Jahr per GPS stellen. Das letzte Jahr war sie nur um 10 Sekunden daneben". Das kann mit einer temperaturkompensierten und abgeglichenen RTC schon mal passieren.
Rolf M. schrieb: > Woher weiß der Empfänger dann, wie weit er vom Satellit weg ist, um die > Laufzeit des Signals zu kompensieren? Indem ich ihm sage, wo er angeschraubt ist und dass er sich wirklich nicht bewegt, egal, was das Antennensignal meint.
GPS ist ein sehr komplexes Thema und da ist viel Halbwissen im Umlauf
(auch in den Beiträgen oben). Bei den GPS-Signalen handelt es sich um
künstliches Rauschen, welches durch rückgekoppelte Schieberegister
erzeugt wird / werden kann. Dabei ist jedem Satelliten eine eigene
Codefolge zugeordnet, an der die Satelliten auch unterschieden werden.
Die Codefolgen sind alle gleich lang und haben einen gemeinsamen
Startpunkt, bei dem alle Bits des Schieberegisters auf 1 sind ("all
One"). Die Empfänger synchronisieren sich nun auf die Bitfolge der
einzelnen empfangenen Satelliten und je nachdem, ob der Empfänger etwas
näher an einem Satelliten oder etwas weiter davon ist, ist im Empfänger
der "all One" Zustand für jedes Schieberegister verschieden. So kann der
Empfänger den Laufzeit- bzw. Entfernungsunterschied zu den einzelnen
Satelliten erkennen und daraus (nicht aus der absoluten Laufzeit) die
Position berechnen.
Der sehr genaue "Sekundenpuls" kann aus dem zeitlichen Abstand der "all
One"- Zustände ermittelt werden und auch dafür würde der Empfang eines
Satelliten ausreichen. ABER: Der Empfänger muss sich ja auf das
Satellitensignal synchronisieren, was mit einer Regelschleife (Costas
Loop o.ä.) geschieht. Die Genauigkeit mit der diese Synchronisation
klappt hängt aber von der (Kurzzeit-)Stabilität des Empfängeroszillators
ab. Rauschen oder Jitter auf dem Oszillatorsignal macht die Genauigkeit
zunichte. Und dann muss der Sekundenpuls auch noch ausgegeben werden.
Dabei sind schon die Anstiegszeit des Ausgangs und das Rauschen auf der
Flanke bestimmend für die Reproduzierbarkeit.
Das NMEA-Protokoll mit dem die Uhrzeit ausgegeben wird, ist ja ein
serielles Protokoll ohne "echte" Zeitmarke. Da kann man die UTC-Uhrzeit
zwar sekundengenau bekommen, mehr ist da aber auch nicht herauszuholen,
weil das Füllen des Transmit-Buffers und der Bittakt nicht mit hoher
Genauigkeit möglich sind. Deshalb ist der Vergleich mit dem DCF77 auch
problematisch, da auch der DCF77 entweder als Zeit- oder als
Frequenznormal genutzt werden kann. Das ist beim GPS ähnlich, wenn auch
die Art der Auswertung etwas unterschiedlich ist.
Wer detaillierte Angaben zum GPS haben möchte, kommt um die Quelle
https://www.gps.gov nicht herum. Da gab es vor ein paar Jahren eine sehr
anschauliche Zusammenfassung (natürlich in Englisch), aber inzwischen
wurden die einzelnen Themen auf diverse Unterkapitel verteilt, wie z.B.
https://www.gps.gov/multimedia/tutorials/trilateration/ .
Diese Unterlagen wurden für Schulungszwecke veröffentlicht und sind
deshalb frei zugänglich.
Bei GPS Timing-Empfängern genügt aber in der Tat ein einzelner Sat, da man die genaue Position durch den Survey-in zuvor ermittelt oder auch manuell eingeben kann, d.h. von den 4 Unbekannten (x, y, z, t) werden auf einen Schlag 3 eliminiert. Zum Spass habe ich übrigens mit der Gopro kürzlich ein Video gemacht vom GPS Sekundenpuls: https://hb9fsx.ch/files/gpsdo/GOPR2919.MP4 das grüne Signal ist das 1PPS Signal meines GPSDO, rot sind die 10MHz. Der 1PPS-Ausgang des Timing-Modules ist das gelbe Signal; die PLL regelt die 10MHz so, dass der eigene Sekundenpuls im Mittel mit demjenigen von GPS übereinstimmt. Das blaue Signal im Video ist von einem extenen eBay GPSDO. Das Video ist ein Zeitraffer über 2 Stunden. Eigentlich noch witzig, wie der GPS-Sekundenpuls wie wahnsinnig wackelt, und man damit trotzdem was regeln kann. Das Wackeln rührt nicht nur von atmosphärischen Effekten her, sondern ist letzten Endes auch ein Quantisierungsfehler, da die CPU im Empfänger mit einem freiaufenden TCXO betrieben wird, bei uBlox glaube ich 48MHz. Damit kann die Software im Empfänger den Puls systembedingt nur an einem auf 20ns genau aufgelösten Zeitpunkt ausgeben. Da die Software aber den "richtigen" Zeitpunkt genauer kennt, kann man bei einem Timing-Empfänger sich diesen Quantisierungsfehler in ps Auflösung ausgeben lassen.
Angehängte Dateien:
-
DCF_Empfang.jpg
62 KB
Bauform B. schrieb: > Bei DCF77 hat mich > schon immer gestört, dass es praktisch keine Anzeige für Feldstärke > und/oder Empfangsqualität gibt. Mein alter Funkwecker von Conrad zeigt die Empfangsqualität mit einer Banlkenanzeige an.
Ich sollte mich vielleicht doch noch mal zu Wort melden, um ein paar noch bestehende Unklarheiten auszuräumen. Das GPS-System ist sehr komplex und ich habe mich bisher auf das beschränkt, was ich für notwendig hielt. Speziell beim PPS-Puls muss man daran denken, dass die Satelliten nicht geostationär sind, sondern sich um die Erde bewegen. Etwa alle 12 Stunden kommen sie wieder vorbei. Für die Signale bedeutet das, dass die Dopplerverschiebung berücksichtigt werden muss. Nähert sich der Satellit dem Empfängerstandort, wird die Zeit zwischen den allONE- Zuständen entsprechend kürzer, entfernt er sich, wird die Zeit länger. Nur wenn der Satellit ziemlich genau über dem Empfänger steht, "stimmt" diese Zeit. Sehr einfache Empfänger mitteln deshalb die Zeiten nach dem Motto: "statistisch gesehen kommen so viele Satelliten auf mich zu wie von mir wegfliegen". Das ist natürlich Pfusch und liefert sehr ungenaue Ergebnisse. Den Anteil der Dopplerverschiebung muss man herausrechnen. Dazu verwendet man die (letzte bekannte) Position des Empfängers und die Bahndaten, die der Satellit mit überträgt. Und dann stimmt der PPS-Impuls auch wenn nur ein Satellit empfangen wird - jedenfalls solange der Empfänger seine Position beibehält. Wenn der Empfänger sich bewegt, muss auch das berücksichtigt werden. Dann brauche ich so viel Satelliten, dass eine Position korrekt berechnet werden kann. Und da die Position bei kleinerem PDOP-Wert genauer wird, hat dieser auch Einfluss auf die PPS-Genauigkeit. (Zur Erinnerung: Der PDOP-Wert errechnet sich daraus, welche Satelliten gerade empfangen werden können und wie diese im Raum zueinander stehen.)
Joggel E. schrieb: > Die absolute Zeit auf eine Sekunde genau stimmt auch schon mit > einem Satelliten alleine. Kein Wunder. Die Satelliten umrunden die Erde in einer Höhe von rund 20200km. Egal wo sich der Benutzer auf der Erdoberfläche befindet, ist die Entfernung zu jedem Satelliten weit unter 300000 Kilometern, insbesondere auch die Entfernungsunsicherheit. Damit ist der mögliche Zeitfehler weit unter einer Laufzeitsekunde. Einzig die UTC-Anzeige am Empfänger kann noch um ganze Schaltsekungen falsch sein, weil er die entsprechenden Almanachdaten noch nicht empfangen hat. Dann steht man dumm da, weil der Empfänger darauf baut, dass er diese Differenz zwischen UTC und GPS-Zeit mitgeteilt bekommt. Das hat aber nichts mit dem noch unbekannten Empfängerort zu tun.
Schön, dass hier gute Erklärungen zusammenkommen, die einem die Probleme beim Extrahieren einer möglichst genauen Zeitangabe, oder Referenzfrequenz aus dem GPS-Signal nahebringen. Aber die simple Tatsache, dass der Empfänger erst den UTC-Offset (Schaltsekunden) übermittelt bekommen und verdaut (!) haben muss, hat mir echt eine Rätselei um komische Zeit-Offsets erklärt. Danke Bauform B. ! Für Astrofotografie habe ich mir aus einem GPS-Modul und einem µC gebaut, was mir im Sternenpark (Batteriebetrieb) die lokale Sternzeit und den Polaris-Offset liefert: Das GPS-Modul (60 mA) soll natürlich so schnell, wie möglich abgeschaltet werden, weil alles Weitere am selben Ort nur noch eine Zeitfrage (6 mA / 26 mA) ohne/mit Display-Beleuchtung ist. - Der 2D...3D-Fix reicht offensichtlich nicht als Abschaltkriterium für Sekundengenauigkeit. Gibt es hier jemand, der ohne Klugscheißerei (RTFM...) sagen kann, wie lange man für den UTC-Offset zeitlich drauflegen müsste? Wenn nicht, geht die Astrofoto-Welt mit < 10 s Fehler aber auch nicht unter...
Jakob schrieb: > - Der 2D...3D-Fix reicht offensichtlich nicht als Abschaltkriterium für > Sekundengenauigkeit. Gibt es hier jemand, der ohne Klugscheißerei > (RTFM...) sagen kann, wie lange man für den UTC-Offset zeitlich > drauflegen müsste? zumindest die uBlox-Module sagen dir doch in einem der Telegramme, ob die UTC-Zeitangabe gültig ist? dafür kannst du NMEA aber nicht verwenden sondern das binäre UBX Protokoll.
Jakob schrieb: > Gibt es hier jemand, der ohne Klugscheißerei (RTFM...) sagen kann, > wie lange man für den UTC-Offset zeitlich drauflegen müsste? Das kommt drauf an, was du mit deiner Frage meinst. Geht es dir um den aktuellen Offset oder geht es dir um die Übertragungszeit für den Datensatz vom Satelliten?
Bauform B. schrieb: > Rolf M. schrieb: >> Woher weiß der Empfänger dann, wie weit er vom Satellit weg ist, um die >> Laufzeit des Signals zu kompensieren? > > Indem ich ihm sage, wo er angeschraubt ist und dass er sich wirklich > nicht bewegt, egal, was das Antennensignal meint. "Die Laufzeit des Signals" - lol... Übertragen wird meistens mit 9600B, Zeit wird aus NMEA-Sätzen berechnet, da dauert das Ganze schon über 60ms. Mit GGA hat man zwar FIX und die Anzahl der Satelliten, aber auch das hilft nicht besonders viel. Mit 10 Sätzen/sec und NMEA kann man sowieso nicht genauer als 100ms sein, wozu die ganze Aufregung? GPS-Empfänger selbst sind natürlich erheblich genauer, aber die NMEA-Sätze, welche GPS-Empfänger rausschicken, haben einen (möglichen) Fehler von +/- 50ms. Deswegen wird mit GPS nur der (eventuell) vorhandene RTC-Fehler beim uC korrigiert, die ev. Abweichung berechnet und in Rechnung genommen. Das Gute daran ist, dass die GPS-Abweichung sowohl nach einem Tag als auch nach einem Jahr dasselbe bleibt.
Marc V. schrieb: > "Die Laufzeit des Signals" - lol... > Übertragen wird meistens mit 9600B, Zeit wird aus NMEA-Sätzen > berechnet, da dauert das Ganze schon über 60ms. Die Übertragungsrate über NMEA0183 hat mit der Laufzeit überhaupt nichts zu tun. Per NMEA wird nur der Timestamp geschickt, der Sekundenpuls kommt unabhängig davon. Lol
Ich möchte haben: Position und UTC, möglichst auf Zeit- und Winkelsekunde genau. Ich kann mit meinem NAVILOCK-Modul keine uBlox-Telegramme auswerten. Wäre doch auch Mist, wenn man seine Software ohne Not an ein bestimmtes GPS-Modul hängen muss. Mit welcher Rate wird der Schaltsekunden-Offset übertragen? Wenn ich diese Zeit mit etwas Aufschlag an den bestätigten 3-D-Fix ranhänge, sollte es doch reichen... Wie gesagt: Auch 10 s Offset sind nur Schönheitsfehler ohne Auswirkung, wenn man zufällig die sekundengenaue Zeit aus anderer Quelle vor Augen hat. Ich dachte ja nur, jemand könnte das ohne Gelaber mal schnell und nachvollziehbar "aus dem Ärmel" beantworten. Ansonsten: Schönes Osterfest!
Wolfgang schrieb: > Die Übertragungsrate über NMEA0183 hat mit der Laufzeit überhaupt nichts > zu tun. Per NMEA wird nur der Timestamp geschickt, der Sekundenpuls > kommt unabhängig davon. Der TO sprach von GPS-Sätzen auswerten, nicht von Sekundenpuls. Aber ja, in einem hast du Recht - der Sekundenpuls ist erheblich genauer, obwohl selbst PPS einen Fehler von einigen ms pro Tag haben kann und das addiert sich dann zu einem Fehler von einigen Sekunden pro Jahr. Bei GPS-Sätzen bleibt der Fehler aber immer gleich, weil die Zeit dauernd von Satelliten korrigiert wird, klar?
Jakob schrieb: > Mit welcher Rate wird der Schaltsekunden-Offset übertragen? > Wenn ich diese Zeit mit etwas Aufschlag an den bestätigten > 3-D-Fix ranhänge, sollte es doch reichen... Ja, vor allem im Freien mit klarer Sicht bis zum Rand des Universums. Die Schaltsekunden werden alle 12.5 Minuten übertragen. Eigentlich kannst du den richtigen Moment eindeutig erkennen, die Zeit ändert sich von einem Satz zum nächsten um mehr als eine Sekunde. Ab da wäre die Zeit korrekt. Leider könnte es passieren, dass der 3D-Fix erst danach zustande kommt - geht also nicht. Ich würde mich mehr auf meine RTC verlassen. Die hat ja gefälligst eine Temperaturkompensation und lässt sich trimmen. Damit sollte die Drift in der Gegend von 0.1s/d sein. Solange es Strom aus der Steckdose gibt könnte die dauernd am GPS hängen. Oben auf dem Berg liefert dann die RTC die Sekunden und der GPS-Empfänger mit dem PPS die Mikrosekunden. Der PPS ist ja praktisch sofort (spätestens nach dem 3D-Fix) genau genug. Die RTC kann auch eine Art PPS erzeugen, man kann die Drift also sehr gut beobachten. Ach ja: Das Problem tritt nur bei einem Kaltstart auf, der Empfänger könnte eine Backup-Versorgung haben... Jakob schrieb: > Ich kann mit meinem NAVILOCK-Modul keine uBlox-Telegramme auswerten. Bist du sicher? Es gibt solche und solche https://www.reichelt.de/gps-nl-82022mp-u-blox-neo-m8u-navilock-62755-p199685.html?&trstct=pos_13&nbc=1 Marc V. schrieb: > Bei GPS-Sätzen bleibt der Fehler aber immer gleich, weil die Zeit > dauernd von Satelliten korrigiert wird, klar? Kommt drauf an, was du unter "gleich" verstehst. Der Offset zur echten Sekunde ändert sich ständig, abhängig davon, wie viel der Empfänger rechnen muss, mehr gute Satelliten = größerer Offset. Es mag Empfänger geben, die das kompensieren, aber es gibt auf jeden Fall welche, bei denen es auffällt. Dazu kommt, dass die Länge der Datensätze nicht konstant ist. Mein ublox7 liefert nur einen Datensatz mit konstanter Länge. Trotzdem schwankt der Offset um ±8ms (vom PPS bis ich den Satz auswerten kann).
Hier gibt's ne schöne Animation: https://upload.wikimedia.org/wikipedia/commons/2/27/GPS24goldenSML.gif und hier die Bahnen der unterschiedlichen Systeme: https://upload.wikimedia.org/wikipedia/commons/b/b4/Comparison_satellite_navigation_orbits.svg
Bauform B. schrieb: > Es gibt von jeden Satelliten Signal/Noise Werte, aber da müsste ich > erstmal rausfinden, welche benutzt werden. Und dann? Mit diesen Infos kannst du praktisch nichts anfangen. Die einzig nützliche Info ist: Empfängst du von genug Satelliten ein ausreichend gutes Signal? 5 cm weiter kann die Situation schon ganz anders aussehen.
Jakob schrieb: > Mit welcher Rate wird der Schaltsekunden-Offset übertragen? Das ist für die Uhrzeitgenauigkeit ziemlich egal, weil der Empfänger nur einmal diese Information empfangen haben muss um auf dem Laufenden zu sein. Genauso wie seine Uhrzeit mit einer RTC aktuell hält, ist es sinnvoll, die aktuelle Information über die Anzahl der Schaltsekunden im NV-RAM abzulegen. Neue Schaltsekunden für eine Aktualisierung dieses Wertes werden immer rechtzeitig in den vom GPS-Satelliten gesendeten Daten angekündigt. Am 6. Januar 1980 wurde die GPS-Zeit als identisch mit UTC definiert, d.h. Differenz 0s. Bis heute hat die UTC 18 Schaltsekunden aufgesammelt. https://de.wikipedia.org/wiki/GPS-Zeit Der Datensatz mit den Umrechnungsinformationen von GPS-Zeit in UTC wird vom GPS in Page 18 vom Subframe 4 übertragen, d.h. wegen des zyklisch rotierenden Dateninhalts im Subframe 4 (insgesamt 25 Pages) müssten die Daten alle 750s gesendet werden, falls ich mich jetzt nicht verrechnet habe ;-)
chris schrieb: > und hier die Bahnen der unterschiedlichen Systeme: > https://upload.wikimedia.org/wikipedia/commons/b/b4/Comparison_satellite_navigation_orbits.svg In der Graphik sind die Orbits das Beidou Systems unterschlagen. (Höhe 21500 bzw. 35800 km, Umlaufzeit 12.9h bzw. 24h)
Marc V. schrieb: > Aber ja, in einem hast du Recht - der Sekundenpuls ist erheblich > genauer, obwohl selbst PPS einen Fehler von einigen ms pro Tag haben > kann und das addiert sich dann zu einem Fehler von einigen Sekunden > pro Jahr. Wo hast du denn das aufgeschnappt? Der 1PPS hängt fest an der Aussendung der Datensätze und damit an der Atomuhr des Satelliten dran. Sobald der Empfänger einen sauberen Fix hat, kann er die Laufzeit kompensieren. Da addiert sich nichts auf, schon gar nicht "einige Sekunden", jedenfall wenn bei der Implementation im Empfänger nicht grob geschlampt wurde.
Manche Hersteller von Navigationsgeräten verbauen TMC-Empfänger. Aus dessen Daten müsste man doch die genaue Zeit bekommen?
Wolfgang schrieb: > Jakob schrieb: >> Mit welcher Rate wird der Schaltsekunden-Offset übertragen? > > Das ist für die Uhrzeitgenauigkeit ziemlich egal, weil der > Empfänger nur einmal diese Information empfangen haben muss > um auf dem Laufenden zu sein. Mir, und anscheinend auch Jakob, geht es vor allem um den Kaltstart, da ist das überhaupt nicht egal. Stefan ⛄ F. schrieb: > Bauform B. schrieb: >> Es gibt von jeden Satelliten Signal/Noise Werte, aber da müsste ich >> erstmal rausfinden, welche benutzt werden. Und dann? > > Mit diesen Infos kannst du praktisch nichts anfangen. > > Die einzig nützliche Info ist: Empfängst du von genug Satelliten ein > ausreichend gutes Signal? Naja, und woher bekomme ich einen Wert für "ausreichend gut"? Das wären doch genau die dB aus dem GSA-Satz? Aber das Thema hat sich eigentlich erledigt. Der Empfänger ist so empfindlich, dass er mitten im Zimmer, unter einer Keksdose (dänische Butterkekse) versteckt, auch noch funktioniert (z.B. 223s bis zum 3D-Fix). Insofern reicht eine LED "PPS vorhanden". René H. schrieb: > Manche Hersteller von Navigationsgeräten verbauen TMC-Empfänger. Aus > dessen Daten müsste man doch die genaue Zeit bekommen? Von allen anderen Diensten weiß man, dass die schon mal um Minuten daneben liegen. Warum sollte das bei TMC besser sein? Nimm eine gute RTC.
Bauform B. schrieb: > Von allen anderen Diensten weiß man, dass die schon mal um Minuten > daneben liegen. Warum sollte das bei TMC besser sein? TMC ist m.W. ein "Ableger" vom alten RDS, und RDS liefert eigentlich "immer" die exakte Zeit, die Nanosekunden mal nicht berücksichtigt.
Bauform B. schrieb: > Naja, und woher bekomme ich einen Wert für "ausreichend gut"? Das wären > doch genau die dB aus dem GSA-Satz? Nein eben nicht. Der Empfangspegel sagt das nicht aus. Es ergibt sich eher aus der Differenz von Signalpegel zum Störpegel. Aber auch da kommt es sehr stark auf die konkreten Störungen an. Zum Beispiel zeigt mein Smartphone zu hause und im Büro immer nur minimale Empfangsstärke an (1 von 5). Dennoch überträgt es sowohl Sprache als auch Daten tadellos mit der erwarteten Bitrate.
Stefan ⛄ F. schrieb: > Bauform B. schrieb: >> Naja, und woher bekomme ich einen Wert für "ausreichend gut"? Das wären >> doch genau die dB aus dem GSA-Satz? > > Nein eben nicht. Der Empfangspegel sagt das nicht aus. Es ergibt sich > eher aus der Differenz von Signalpegel zum Störpegel. Aber auch da kommt > es sehr stark auf die konkreten Störungen an. Na gut, erstmal muss es GSV statt GSA heißen. Und was dBHz sind, weiß ich auch nicht. Aber was bedeutet denn das?
1 | $xxGSV,numMsg,msgNum,numSV,{,sv,elv,az,cno}*cs<CR><LF>
|
2 | cno [dBHz] Carrier to Noise Ratio (Signal Strength) |
Bauform B. schrieb: > Carrier to Noise Ratio Ich denke das ist das von mir gemeinte Verhältnis zwischen Nutz-Signal und Stör-Signal.
Bauform B. schrieb: > Aber was bedeutet denn das? Was genau meinst du? Steht doch alles da oder verstehst du die Angabe für den Rauschabstand nicht?
Wolfgang schrieb: > Marc V. schrieb: >> Aber ja, in einem hast du Recht - der Sekundenpuls ist erheblich >> genauer, obwohl selbst PPS einen Fehler von einigen ms pro Tag haben >> kann und das addiert sich dann zu einem Fehler von einigen Sekunden >> pro Jahr. > > Wo hast du denn das aufgeschnappt? Genau da, wo du und die anderen es auch getan haben. Oder warst du an der Entwicklung der GPS massgeblich beteiligt und weisst etwas, das wir nicht wissen? > Der 1PPS hängt fest an der Aussendung der Datensätze und damit an der > Atomuhr des Satelliten dran. Da hängt nix an nix dran. 15-20ns Fehler pro Sekunde sind bei PPS durchaus üblich, den Rest kannst du dir selbst ausrechnen.
Marc V. schrieb: >> Der 1PPS hängt fest an der Aussendung der Datensätze und damit an der >> Atomuhr des Satelliten dran. > > Da hängt nix an nix dran. > 15-20ns Fehler pro Sekunde sind bei PPS durchaus üblich, den Rest > kannst du dir selbst ausrechnen. Du verwechselst Kurzzeit- und Langzeitstabilität bzw. Jitter und Drift.
Bauform B. schrieb: > Du verwechselst Kurzzeit- und Langzeitstabilität bzw. Jitter und Drift. Nein, ich sprach von PPS als Taktsignal, vielleicht hab ich mich falsch ausgedrückt, sorry. Synchronisation mit PPS wird diesen Fehler natürlich nicht akkumulieren.
Marc V. schrieb: > Da hängt nix an nix dran. > 15-20ns Fehler pro Sekunde sind bei PPS durchaus üblich, den Rest > kannst du dir selbst ausrechnen. 15-20ns ist größenordnungsmäßig die Grundgenauigkeit vom GPS SPS. Viel genauer kriegt der Empfänger das Signal und damit seine xyzt-Koordinate im Raum nicht zu fassen, insbesondere da die Satellitenposition auch nicht beliebig genau ist. 15-20ns ist ansonsten ganz was anderes, als die von dir oben genannten "einigen ms pro Tag", die sich angeblich zu "einigen Sekunden pro Jahr" aufaddieren können sollen. Marc V. schrieb: > Genau da, wo du und die anderen es auch getan haben. > Oder warst du an der Entwicklung der GPS massgeblich beteiligt und > weisst etwas, das wir nicht wissen? Was hat das mit der Entwicklung des GPS zu tun. Wie der Empfänger das 1PPS-Signal aus dem Datentakt des vom Satelliten empfangenen Datenstroms ableitet und mit der berechneten Entfernung korrigiert, ist einzig Sache des Empfänger-Chips.
Jakob schrieb: > Wie gesagt: Auch 10 s Offset sind nur Schönheitsfehler ohne > Auswirkung, wenn man zufällig die sekundengenaue Zeit aus anderer > Quelle vor Augen hat. Ja, diesen Schönheitsfehler kenne ich von meinem Fernseher bei Beginn der 20H-Nachrichten auch. Früher waren Fernseher immer eine Quelle für atomuhrgenaue Zeitinformation.
Harald W. schrieb: > Jakob schrieb: > >> Wie gesagt: Auch 10 s Offset sind nur Schönheitsfehler ohne >> Auswirkung, wenn man zufällig die sekundengenaue Zeit aus anderer >> Quelle vor Augen hat. > > Ja, diesen Schönheitsfehler kenne ich von meinem Fernseher bei Beginn > der 20H-Nachrichten auch. Früher waren Fernseher immer eine Quelle für > atomuhrgenaue Zeitinformation. Oder der Klassiker an Silvester, wenn in jeder Wohnung zu einer anderen Zeit gejubelt wird, weil sie alle nach dem Fernseher gehen, der heute oft sein Bild per Online-Stream holt. Übrigens: Bauform B. schrieb: > Magisches Auge für GPS-Empfänger Hat schon mal jemand darüber nachgedacht, für eine derartige Anzeige ein echtes magisches Auge zu verwenden (also die die Anzeigröhre)? Das Röhrenradio meiner Oma hatte so eins zur Anzeige der Empfangsstärke, und ich war damals total fasziniert davon.
Rolf M. schrieb: > Hat schon mal jemand darüber nachgedacht, für eine derartige Anzeige ein > echtes magisches Auge zu verwenden (also die die Anzeigröhre)? Das > Röhrenradio meiner Oma hatte so eins zur Anzeige der Empfangsstärke, und > ich war damals total fasziniert davon. Meinst Du jetzt ein "echtes" Auge oder nur den später üblichen "magischen Srich"?
Von zwei Leuten kamen jetzt 12,5 Minuten = 750 s als Zykluszeit für die Übermittlung des Schaltsekunden-Offset. Muss ich wohl mit rechnen. Für Batteriebetrieb ist mir das zu lange. - Aber gut, bis der mögliche Offset bei mir von derzeit 2 auf noch tolerierbare 10 s anwächst, dürften > 8 Jahre vergehen.
Jakob schrieb: > Muss ich wohl mit rechnen. Du Ungläubiger zweifelst an Fakten aus dem Internet? Nimm dieses (pdf)!
Hab es gleich mal selbst getestet! 2 mal Kaltstart eines alten ETEK EB-85A. Der ist von 2007 und kennt daher 4 Schaltsekunden nicht. Zum Week-Rollover 2019 musste ich der Datumsanzeige auch Krücken verpassen... Korrektur um -4 s erfolgte um 15:46:07 bzw. um 15:58:37. Das bestätigt die 12,5 Minuten! Trotzdem Danke für die PDF. :-)
Harald W. schrieb: > Meinst Du jetzt ein "echtes" Auge oder nur den später üblichen > "magischen Srich"? Also so richtig wie ein Auge hat es nicht ausgesehen, aber war auch nicht nur ein Strich. Sowas wie hier: https://www.sm5cbw.se/tubes/htm/em80.htm
Rolf M. schrieb: > Sowas wie hier: https://www.sm5cbw.se/tubes/htm/em80.htm Ich meinte eine solche Röhre: http://www.tubecollection.de/ura/images/6E5_Anim-2.gif
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.