Hallo, für ein Projekt, in dem Meßdaten verschiedener stationär uwie auch ortsveränderlich angeordneter Quellen offline zusammengeführt werden sollen, möchte ich die absolute Uhrzeit in Millisekunden verwenden als gemeinsamen Parameter. Dazu sollen alle Meßeinrichtungen je einen (möglichst preiswerten) GPS-Empfänger bekommen, aus dem die Zeit etwa im 10ms-Raster mit einer Genauigkeit von einer Millisekunde ausgelesen und zusammen mit den Meßdaten aufgezeichnet wird. Ich suche nun nach geeigneten GPS-Empfängern und nach Informationen darüber, wie ich eben diese Zeitinformation mindestens mit 1 ms Auflösung auslesen kann. Hat sich schon mal jemand mit einem ähnlichen Problem befaßt. Ich bin für jeden Hinweis dankbar. Viele Grüße Ingo.
Könnten NEO8-M passen (Datenblatt schauen) kostenungünstig aber für diese Anwendung optimiert NEO8-N
IMHO haben einige GPS Empfänger eine 1Hz Zeitbasis - glaube nicht, dass Du 1 ms direkt rausbekommst. Man könnte ggfs eine eigene RTC mittels dem 1Hz Signal kalibrieren und dann die 1ms aus der RTC bekommen.
Schon viele haben sich damit befasst: Stichwort GPSDO GPS Disciplined Oscillator. Üblicherweise halt eher für xxxkHz bis 10..20..50MHz, aber geht auch für nur 10 Hz. Eine Bastelvariante könnte sein: mit dem 1PPS Signal vom GPS-Rx ein "Pulse Train" von 10 Impulsen à 0.999ms lostreten; damit hast dann zwar innerhalb jeder Sekunde Jitter, aber alle 10 ist's Sekundengenau synchronisiert. Das lässt sich sowohl in HW als auch in SW implementieren. Die Profivariante ist XNTP, was aber an jedem Messknoten ein vernünftiges (klein-)BS voraussetzt.
Hallo! Eine solche genaue Synchronisierung ist möglich, erfordert aber etwas mehr Aufwand. Ist aber kein Hexenwerk und wenn du Linux verwendest, sind alle relevanten Teile bereits vorhanden. Geeignete GPS-Empfänger empfangen und geben das 1PPS-Signal der Satelliten aus. Damit ist eine hochgenaue Synchronisierung deiner Uhren auf die Sekundenmarke der absoluten GPS-Zeit (die z.B. über die NMEA-Nachrichten ausgegeben wird) möglich. Mit diesem 1PPS und der absoluten Zeit hast du einen sehr genauen absoluten Zeittaktgeber, mit dem sich praktischerweise ein NTP-Server (ntpd) hochgenau synchronsieren kann. Der Clou dabei ist, dass der NTP-Server ja eine Software-PLL am Laufen hat, die dir dann eine hochgenaue Zeit zur Verfügung stellt. 1ms ist für einen NTP-Server leicht möglich (Achtung: Nicht unter Windows), es bedarf aber sicher einiges an Feintuning, damit du dein System wirklich stabil am Laufen hast. Linux bietet dir eigentlich alles an, was du brauchst. Einspringspunkt ist z.B. das hier: https://weberblog.net/ntp-server-via-gps-on-a-raspberry-pi/ Wenn du aber nach "NTP Linux PPS GPS" o.ä. suchst, wirst du schnell fündig.
Das geht so nicht. Die GPS-Satelliten senden die UTC-Zeit als Datentelegramm. Die Übertragungsrate beträgt 50 Bit pro Sekunde - wenn mein Gedächtnis mich nicht im Stich lässt. Die so empfangene Uhrzeit ist sehr langzeitstabil - mehr aber auch nicht. Als eine Art Frequenznormal geben viele GPS-Empfänger einen Sekundenpuls PPS aus. Für den Empfang der Daten muss der Empfänger mit dem Satelliten synchronisiert sein. Diese Synchronisation liefert die Basis für die Erzeugung dieses Pulses und hat die Genauigkeit der GPS-Zeitbasis. Mit einer PLL-Schaltung kann man mit diesem Puls natürlich hochgenaue Frequenzen erzeugen. Das könnte natürlich auch ein GPS-Empfänger machen, der dann als hochgenauer Frequenzsynthesizer auf den Markt gebracht hat. Aber das ist dann eine spezielle Anwendung des GPS.
Eventuell kann man von denen etwas lernen: http://de.blitzortung.org/cover_your_area.php "Mit Hilfe von GPS Empfängern werden die Ankunftszeiten der Signale mikrosekundengenau registriert und über das Internet zu unserem zentralen Server gesendet." Ähnliche Genauigkeit braucht das hier: https://dk8ok.org/2018/07/25/direction-finding-first-experiences/ https://www.rtl-sdr.com/understanding-direction-finding-on-the-kiwisdr/ KiwiSDR Net TDoA Direction Finding mit Internet-Kurzwellenempfängern können weltweit Sender angepeilt werde, ebenfalls über die Laufzeit.
:
Bearbeitet durch User
Günni schrieb: > Das geht so nicht. Die GPS-Satelliten senden die UTC-Zeit als > Datentelegramm. Die Übertragungsrate beträgt 50 Bit pro Sekunde - wenn > mein Gedächtnis mich nicht im Stich lässt. Was geht so nicht? Natürlich geht das. Und mit der Datenübertragungsgeschwindigkeit der Satellitsignale hat das sowieso nichts zu tun. Das NMEA-Telegramm ist nur die Ansage "Beim nächsten Ton des Zeitzeichens ist es ...". Der Zeitpunkt wird durch den Puls am 1PPS-Ausgang festgelegt und dürfte besser als 100ns sein.
Das Problem ist ja nicht neu. Hab persönlich aber keine Erfahrung mit der Hardware. Im EVU-Bereich wird vom Schutz eine Netzstörung an mehreren weit auseinander liegenden stationären Geräten aufgezeichnet und vor Ort mit einem Zeitstempel versehen. Für den Zeitstempel wird über GPS (früher DCF) eine Absolutzeit als Referenz ermittelt. Zeitauflösung besser als 1 ms. Hersteller von Schutzgeräten und Netzleittechnik ansprechen. Es gibt ein kommerzielles Blitzortungssystem für die Versicherungen und das EVU. Mehrere stationäre Empfänger erfassen ein Blitzereignis als elektromagnetischen Impuls. Über die Laufzeit der Impulse kann man den Blitzort ermitteln. Auch hier wird für die Empfänger eine genaue Absolutzeit benötigt. Zeitauflösung besser als 1 Mikrosekunde. In der Industrie werden aber keine "preiswerten" Zeitnormale eingesetzt. Grüße von petawatt
:
Bearbeitet durch User
Vielen Dank für die schnelle Reaktion. Das Stichwort pps-Signal war sehr wichtig für mich. Möglicherweise werde ich zumindest teilweise auf die feine Auflösung beim Aufzeichnen der Zeit verzichten und nur die sehr präzise Sekunde zusammen mit dem zeitlichen Abstand zur nächsten Messung aufzeichnen. Das Interpolieren kann ich dann offline machen, wenn die Daten verarbeitet werden. Da ist ohnehin auf ein gemeinsames Raster zu interpolieren, da die Meßgeräte (LIDAR, verschiedene Kameras und Ortssensoren) unterschiedliche Abtastraten haben. Bisher hatte ich mit GPS-Sensoren noch nichts zu tun. In meinem Fall ist die Ortsinformation des GPS ohne Bedeutung, da die Meßgeräte von einem Schienensystem geführt werden und nur der Ort auf der einen Dimension des Schienenweges erfaßt werden muß. VG Ingo.
:
Bearbeitet durch User
Ingo T. schrieb: > Da ist ohnehin auf ein gemeinsames Raster zu > interpolieren, da die Meßgeräte (LIDAR, verschiedene Kameras und > Ortssensoren) unterschiedliche Abtastraten haben. Welche Lidare verwendest du? Manche Lidare, die ich kennen gelernt habe, haben eine NMEA-Schnittstelle (seriell) und einen 1PPS-Input.
Ja, das LIDAR hat das bereits dabei - da brauche ich mich nicht drum kümmern. Das Teil wird von einem Kollegen von mir betreut/genutzt - ich betreue nur einen Teil der Infrastruktur (ist Bestandteil eines Forschungs-/Experimentalsystems in einer gartenbaulichen Versuchsanlage). Neben dem LIDAR gibt es aber das Transportsystem, daß den Ort zusammen mit der genauen Zeit aufzeichnen soll, um später die LIDAR-Daten dem Meßort zuordnen zu können. Eine (sonst notwendigerweise drahtlose) Datenverbindung zwischen LIDAR-Rechner und orstfestem Antriebsrechner ist aber momentan wegen der Größe der Anlage erstmal nicht vorgesehen. VG Ingo.
:
Bearbeitet durch User
PPS ist richtig, aber die Aussage "Beim nächsten PPS ist es ..." stimmt bei keinem der NMEA-Sätze! Selbst der nur für Zeit und Datum zuständige GPZDA-Satz sagt: "Beim letzten PPS (falls vorhanden) war es...". Und - das habe ich erst in den letzten Wochen gelernt: Es kann nach dem Einschalten 12,5 Minuten und länger dauern bis der GPS-Empfänger von GPS-Zeit auf UTC korrigiert wird. Das kann ein Sprung von mehreren Sekunden sein. Ansonsten ist es doch pillepalle, bei einem quarzgetakteten µC, eine Uhr mit ms-Auflösung zu programmieren, die vom PPS synchronisiert wird. Bei miesen 100 ppm Quarzgenauigkeit bist du ohne Klimmzüge auf 0,1 ms genau. Mit etwas Nachführung hast du einen Jitter von 0,01 ms... Tiny-µC + EM406A + Hühnerfutter < 50 EU.
Jacko schrieb: > Bei miesen 100 ppm Quarzgenauigkeit bist du ohne Klimmzüge auf 0,1 ms > genau. Mit etwas Nachführung hast du einen Jitter von 0,01 ms... Nicht zu vergessen das ganze kann man dann noch bei 1-2ppm mit nem DS3231 bei Signalverlust genau halten.....
Jacko schrieb: > Und - das habe ich erst in den letzten Wochen gelernt: Es kann nach > dem Einschalten 12,5 Minuten und länger dauern bis der GPS-Empfänger > von GPS-Zeit auf UTC korrigiert wird. Das kann ein Sprung von mehreren > Sekunden sein. Rechenzeit und Cache? Man muß auf jeden Fall die Plausibilität ausreichend prüfen, bevor man diese Daten als zuverlässige weiter geben kann! Sonst kann der 72. Februar 25:62 Uhr die ganzen Messwerte durcheinander bringen.
@ Philipp K Kann man machen, (wie denn? - über die 32 kHz?) muss aber der TO entscheiden. Ach und: Sind das 32 kHz, oder 32 KHz Die muss man aber noch aufwändig mit dem µC verwursten. @ oszi40 Wir sind hier nicht bei DCF! Ordentliche GPS-Empfänger liefern selten so abwegige Zeiten, wie Anfänger-DCF-Dekodierungen. Sogar den Week-Overflow haben die meisten GPS-Modul-Hersteller mittlerweile aus dem Sparprogramm rausgenommen.
oszi40 schrieb: > Jacko schrieb: >> Und - das habe ich erst in den letzten Wochen gelernt: Es kann nach >> dem Einschalten 12,5 Minuten und länger dauern bis der GPS-Empfänger >> von GPS-Zeit auf UTC korrigiert wird. Das kann ein Sprung von mehreren >> Sekunden sein. > > Rechenzeit und Cache? Vermutlich liegt es daran: GPS führt im Unterschied zu UTC keine Schaltsekunden aus, sondern zählt stattdessen einfach fortlaufend weiter. D.h. bei jeder Schaltsekunde die UTC einfügt, ändert sich der Offset zwischen der GPS-Zeit und UTC um eine Sekunde. Der jeweils aktuell gültige Offset wird ebenfalls über GPS mitgesendet (das ist nötig da die Schaltsekunden nach Bedarf eingefügt werden und dies unregelmäßig ist, daher kann man den Offset nicht per Formel berechnen, allenfalls für die Vergangenheit wenn man die Tabelle der bisherigen Schaltsekunden parat hat). Wenn ich mich recht erinnere dauert es ca 12 Minuten, um den kompletten Satz an Zusatzinfos zu übertragen. Vermutlich ist der UTC-Offset ein Teil davon, würde jedenfalls Jackos Erkenntnis erklären. Nachtrag: @Ingo T., Gedanke zum loggen: am besten wäre denke ich, den GPS-Timestamp sowie den Offset getrennt aufzuzeichnen und erst offline umzurechnen. Da Schaltsekunden nur am 1. Januar oder 1. Juli auftreten können, lässt sich dann leicht im Nachhinein die Zeit überbrücken wo der Offset noch nicht empfangen worden ist...
:
Bearbeitet durch User
Hallo, vielen Dank für den Hinweis auf die Schaltsekunden, ein Thema, mit dem ich mich bisher nicht beschäftigt habe. Daß GPS-Zeit und UTC diesbezüglich voneinander abweichen war mir nicht klar. Wenn ich die Zeit zusammen mit den Meßwerten kontinuierlich aufzeichne, dann fallen bei der Offline stattfindenden Datenzuammenführung Sprünge um ganze Sekunden sicher auf und lassen sich problemlos (automatisch) korrigieren. Andererseits ist angesichts der ohnehin niedrigen maximalen Geschwindigkeit mener Meßsysteme von 2 Metern/Minute (=3,3cm/s, ein Umlauf (200m) dauert >=100 Minuten) eine (Vorab-)Wartezeit von 12 Minuten auch kein Problem. Ggf. können GPS und zugeordneter Controller dauerhaft mit Strom versorgt bleiben. Die mobile Stromversorgung ist ausreichend überdimensioniert. VG Ingo.
Jacko schrieb: > Selbst der nur für Zeit und > Datum zuständige GPZDA-Satz sagt: "Beim letzten PPS (falls vorhanden) > war es...". Na gut, so genau hatte ich das nicht mehr im Kopf. > Und - das habe ich erst in den letzten Wochen gelernt: Es kann nach > dem Einschalten 12,5 Minuten und länger dauern bis der GPS-Empfänger > von GPS-Zeit auf UTC korrigiert wird. Das kann ein Sprung von mehreren > Sekunden sein. Das allerdings liegt an der niedrigen Datenübertragungsgeschwindigkeit vom Satelliten zum Nutzer. Nach dem Kaltstart des Empfängers müssen die Allmanachdaten irgendwoher kommen. Wenn die von den Satelliten empfangen werden müssen, dauert das eben die 12,5 Minuten und wenn der Empfang nicht glatt geht, eben länger. Erst wenn ein gültiger Satellitenfix möglich ist, kann die Empfängeruhr mit GPS-Zeit synchronisiert werden. Vorher kann sie nur als normale quartzgesteuerte Uhr laufen und sammelt entsprechend Fehler auf. Mathias A. schrieb: > Vermutlich ist der UTC-Offset ein Teil davon Ist es, steht in der Doku zu den gesendeten GPS-Datenblöcken. Das ändert aber nichts daran, dass ohne GPS-Daten die Empfängeruhr schlicht und einfach weg driftet.
Ingo T. schrieb: > Ja, das LIDAR hat das bereits dabei - da brauche ich mich nicht drum > kümmern. Das Teil wird von einem Kollegen von mir betreut/genutzt - ich > betreue nur einen Teil der Infrastruktur (ist Bestandteil eines > Forschungs-/Experimentalsystems in einer gartenbaulichen > Versuchsanlage). Neben dem LIDAR gibt es aber das Transportsystem, daß > den Ort zusammen mit der genauen Zeit aufzeichnen soll, um später die > LIDAR-Daten dem Meßort zuordnen zu können. Eine (sonst notwendigerweise > drahtlose) Datenverbindung zwischen LIDAR-Rechner und orstfestem > Antriebsrechner ist aber momentan wegen der Größe der Anlage erstmal > nicht vorgesehen. Ein 360° Lidar braucht prinzipbedingt schon eine hochgenaue Umdrehungsfrequenz und hat meist auch einen sehr genauen Winkelencoder. Aus Kenntniss der Umdrehungsfrequenz und mit Auswertung des Winkelencoders, solltest du auch eine sehr genaue relative Synchronisierung hinbekommen. Jacko schrieb: > PPS ist richtig, aber die Aussage "Beim nächsten PPS ist es ..." > stimmt bei keinem der NMEA-Sätze! Selbst der nur für Zeit und > Datum zuständige GPZDA-Satz sagt: "Beim letzten PPS (falls vorhanden) > war es...". Ja und nein. Was man weiß ist, dass beim PPS-Puls genau(!) eine Sekunde in der absoluten Zeit war/ist. Daher nutzt man da eben auch meist einen NTP-Server. Da wird zunächst der Timestamp vom GPS mit dem PPS-Signal verknüpft und damit wird dann die interne PLL gefüttert.
Ingo T. schrieb: > Vielen Dank für die schnelle Reaktion. Das Stichwort pps-Signal war sehr > wichtig für mich. Möglicherweise werde ich zumindest teilweise auf die > feine Auflösung beim Aufzeichnen der Zeit verzichten und nur die sehr > präzise Sekunde zusammen mit dem zeitlichen Abstand zur nächsten Messung > aufzeichnen. Wenn ich meine Wander - App zu Hause mal eine halbe Stunde liegen lasse und tracke, dann sehe ich nicht einen Punkt, sondern der Punkt wandert des öfteren 10 m weit. Meinst Du wirklich das die Zeitangabe wirklich so genau ist, daß Du sie verwenden kannst? mfg Klaus
H. K. schrieb: > Ja und nein. > Was man weiß ist, dass beim PPS-Puls genau(!) eine Sekunde in der > absoluten Zeit war/ist. Der per NMEA geschickte Timestamp verrät einem sogar, welche Sekunde es genau war. Und mit einem Timer schafft es auch ein ATtiny, aus diesen 1-Sekunden Synchronisationspulsen einen höher aufgelösten, ausreichend genauen Zeitraster zu erzeugen.
Klaus R. schrieb: > Meinst Du wirklich das die Zeitangabe wirklich so > genau ist, daß Du sie verwenden kannst? Dann rechne mal aus, welchen Zeitfehler ein Positionsfehler von 10 Metern bedeutet. Nach Adam Riese kommt man da auf etwa 33 Nanosekunden. Nutzt deine App EGNOS und hat sie freie Horizontsicht? Sonst hat sie wahrscheinlich deutlich mit schlechtem Empfang, i.e. ungünstiger Verteilung der ausgewerteten Satelliten über den Himmmel, verrauschten Signalen und Mehrwegempfang zu kämpfen.
@Klaus: Ich verwende ja nicht die Ortsinformation des GPS. Meine Meßsysteme bewegen sich an einem Kettenförderer. Der Antrieb besitzt einen inkrementalen Winkelgeber, der zusammen mit einem Startsensor den Meßort errechenbar macht und dieser Meßort soll dann zusammen mit der präzisen Absolutzeit aufgezeichnet werden. Die Meßwerte der einzelnen Sensoren werden ebenfalls zusammen mit der Absolutzeit aufgezeichnet. Am Ende werden offline über die Absolutzeit die Meßwerte den Meßorten zugeordnet. VG Ingo.
Ingo T. schrieb: > Wenn ich die Zeit zusammen mit den Meßwerten kontinuierlich aufzeichne, > dann fallen bei der Offline stattfindenden Datenzuammenführung Sprünge > um ganze Sekunden sicher auf und lassen sich problemlos (automatisch) > korrigieren. Du kannst wahrscheinlich überhaupt nur die GPS-Zeit aufzeichnen. Auf die Art gibt keine Unstetigkeiten. Es kommt ja vor allem drauf an, dass alle die gleiche Zeit benutzen. Man muss allerdings immer die Empfänger-Statusbits auswerten, kurz nach einem Kaltstart ist das PPS-Signal nicht stabil. Es kann auch Aussetzer geben wenn der Empfang zu schlecht wird. > Ggf. können GPS und zugeordneter Controller > dauerhaft mit Strom versorgt bleiben. Manche Empfänger haben einen Anschluss für eine 3V-Knopfzelle, das reicht auch für ein paar Stunden.
Wolfgang schrieb: > Dann rechne mal aus, welchen Zeitfehler ein Positionsfehler von 10 > Metern bedeutet. Nach Adam Riese kommt man da auf etwa 33 Nanosekunden. Die Amerikaner bauen im GPS Signal eine künstliche Ungenauigkeit ein, die das Militär wieder herausrechnet. Stört das nicht das Zeitsignal? Oder wie machen die das? mfg Klaus
Klaus R. schrieb: > Wenn ich meine Wander - App zu Hause mal eine halbe Stunde liegen lasse > und tracke, dann sehe ich nicht einen Punkt, sondern der Punkt wandert > des öfteren 10 m weit. Meinst Du wirklich das die Zeitangabe wirklich so > genau ist, daß Du sie verwenden kannst? Das kannst du leicht selber nachrechnen. Licht (genauso wie Funkwellen in Luft) legt 300.000km pro Sekunde zurück. Deine 10m Ortsbweichung sind dann wieviele Sekunden Zeitabweichung? Wie verhält sich dieser Fehler zum geforderten 1ms Zeitraster?
Klaus R. schrieb: > Die Amerikaner bauen im GPS Signal eine künstliche Ungenauigkeit ein, > die das Militär wieder herausrechnet. Stört das nicht das Zeitsignal? > Oder wie machen die das? > mfg Klaus Zum einen stecken die nicht 20 Jahre in der Vergangenheit
Klaus R. schrieb: > Die Amerikaner bauen im GPS Signal eine künstliche Ungenauigkeit ein, Wurde aus Angst vor Galileo aber wieder aufgegeben. Die aktuelle Ungenauigkeit von GPS hängt von der Satellitenkonstellation und den sich ständig ändernden Ausbreitungsbedingungen für Funkwellen ab. Für Genauigkeiten von 1 ms aber ohne Bedeutung. Grüße von petawatt
:
Bearbeitet durch User
Ingo T. schrieb: > Dazu sollen alle Meßeinrichtungen je einen > (möglichst preiswerten) GPS-Empfänger bekommen, aus dem die Zeit etwa im > 10ms-Raster mit einer Genauigkeit von einer Millisekunde ausgelesen und > zusammen mit den Meßdaten aufgezeichnet wird. Der NMEA0183 Datensatz GLL hat das Format $--GLL,llll.ll,a,yyyyy.yy,a,hhmmss.ss,a,m,*hh<CR><LF> Bei U-blox im Protokoll steht z.B.: UTC time is used in many NMEA and UBX messages. In NMEA messages it is always reported rounded to the nearest hundredth of a second. Consequently, it is normally reported with two decimal places (e.g. 124923.52). rgds
Klaus R. schrieb: > Die Amerikaner bauen im GPS Signal eine künstliche Ungenauigkeit ein Selective Availability wurde vor ziemlich genau 20 Jahren abgeschaltet. https://www.gps.gov/systems/gps/modernization/sa/data/ Und die zusätzliche Verbessung beim PPS (Precice Positioning Service, nicht zu verwechseln mit den 1PPS-Zeitimpulsen) hat andere Gründe, u.a. die Nutzung der L2 Frequenz.
Bauform B. schrieb: > Du kannst wahrscheinlich überhaupt nur die GPS-Zeit aufzeichnen. An die GPS-Zeit kommt man in normalen GPS-Empfängern überhaupt nicht ran. Über das User-Frontend, also z.B. über die NMEA-Datensätze wird immer UTC ausgegeben.
6a66 schrieb: > UTC time is used in many NMEA and UBX messages. In NMEA messages it is > always reported rounded to the nearest hundredth of a second. Das reichst doch, die 1pps Flanke kommt zu jeder vollen Sekunde +/- xxx ns. Damit kalibriert und synct man dann einen ms Timer (bzw hier 10 ms Takt).
Der: https://www.u-blox.com/en/product/max-m8-series?lang=de 8 Tacken. PPS, Uhrzeit. 100ns geht ohne Klimmzug. Been there, done that. Cheers Detlef
Detlef _. schrieb: > PPS, Uhrzeit. 100ns geht ohne Klimmzug. Been there, done that. Wie hast du die 100ns geprüft - nur so aus Interesse?
An die GPS-Zeit kommt man per NMEA-Satz nicht ran. Die üblichen GPS-Empfänger liefern bevor sie den UTC-GPS-Offset empfangen haben (ich kann nach Tests bestätigen, dass der exakt alle 12,5 Minuten empfangen werden kann) eine "Zwischenzeit". Einfacherweise mit den zur Entstehung der Firmware bekannten Schaltsekunden. Ich habe 2 verschiedene GPS-Module. Eines ist von 2007 und startet mit 4 s Vorlauf das Neuere startet mit 2 s Vorlauf. (das passte 2012-2014) Würde "echte" GPS-Zeit ausgegeben, hätte man derzeit einen Vorlauf von 18 s. Man könnte warten, bis ein Sekundensprung stattgefunden hat, wenn aber aus dem Super-Elko doch noch ein Warmstart hingelegt wird, kann man wiederum ewig warten... Einfach und sicher: 12,5 Minuten sauberen Empfang abwarten. Mag sein, dass speziell für Zeitmessung gebaute Empfänger nachvollziehbarer arbeiten - die gibt es aber nicht für < 50 EU.
Jacko schrieb: > Man könnte warten, bis ein Sekundensprung stattgefunden hat, > wenn aber aus dem Super-Elko doch noch ein Warmstart hingelegt > wird, kann man wiederum ewig warten... > > Einfach und sicher: 12,5 Minuten sauberen Empfang abwarten. Eigentlich sollte die Zeit stimmen, sobald der Empfänger im GPGSA-Sentence einen gültigen Fix meldet. Zur Sicherheit kann man dort auch den DOP-Werten auswerten, um ungünstige Empfangsbedingungen und damit die Gefahr größerer Datenfehler zu erkennen.
Detlef _. schrieb: > Been there, done that. Wo bist du nochmal gewesen? Und was hast du dort gemacht? ;-)
Wolfgang schrieb: > Detlef _. schrieb: >> PPS, Uhrzeit. 100ns geht ohne Klimmzug. Been there, done that. > > Wie hast du die 100ns geprüft - nur so aus Interesse? Garnicht, gebe ich zu. Die PPS sind zu 10^-8 gespect, entspricht 10ns und mehr als eine Zehnerpotenz verliere ich nicht. Guaranteed by design. Wenn ichs hätte prüfen müssen dann hätte ich die Frequenz gegen mein Rubidium Normal gemessen, das hat auch 10^-8, eine Sekunde in 3 Jahren :))) . Cheers Detlef
Wolfgang schrieb > Eigentlich sollte die Zeit stimmen, sobald der Empfänger im > GPGSA-Sentence einen gültigen Fix meldet. Mit 4..5 Satelliten stimmt dann die GPS-Zeit - die nützt aber nix, wenn sie später auf UTC gesetzt wird. Bei unbekanntem UTC-Offset (kommt nur alle 12,5 Minuten) nützt auch ein super-DOP nix. Wer lesen kann, ist manchmal im Vorteil...
Jacko schrieb: > An die GPS-Zeit kommt man per NMEA-Satz nicht ran. > Die üblichen GPS-Empfänger liefern bevor sie den UTC-GPS-Offset > empfangen haben (ich kann nach Tests bestätigen, dass der exakt > alle 12,5 Minuten empfangen werden kann) eine "Zwischenzeit". > Einfacherweise mit den zur Entstehung der Firmware bekannten > Schaltsekunden. Kann man nicht einfach loggen und im postprozess angleichen? Pps (und oft auch NMEA) kommen doch 1x pro Sekunde (bei einigen Empfängern sogar ohne Satelliten). Sobald UTC stabil ist zählt man die Sekunden zurück und hat seine "offizielle" Startzeit? Dafür wird der Empfänger halt so lange laufen gelassen bis UTC stabil ist. Das gleiche gilt für die seltenen Schaltsekunden.
Hab nie gesagt, dass man nicht rückwärtsrechnen kann... Die Schaltsekunden sind (18 in 40 Jahren) so selten, dass man sie auch nachlesen kann: Bulletin C vom IERS. Eine dadurch versaute Zeitmessung lässt sich auch nachträglich korrigieren... Aber der GPS-Empfänger weiß bei Kaltstart einfach nicht, wieviele es aktuell sind. Das erfährt er nur alle 12,5 Minuten. Ist das so schwer zu raffen? Warum muss ich mich hier 100 mal wiederholen? Einfach mal aufmerksam lesen!!!
Deswegen nimmt man einen vernünftigen Empfänger mit Dokumentation und benutzt die GPS-Zeit oder notfalls ein UTC-ist-gültig-Status-Bit. Ob der NMEA-Status die Info hergibt, steht im Handbuch. Im Zweifelsfall tut er das nicht.
Jacko schrieb: > Mit 4..5 Satelliten stimmt dann die GPS-Zeit - die nützt aber nix, > wenn sie später auf UTC gesetzt wird. Bei unbekanntem UTC-Offset So unbekannt ist der UTC-Offset nicht, da er sich nur alle paar Jahre mal ändert. Ein halbwegs sinnvoll programmierter GPS-Empfänger merkt sich den Wert im NVRAM und liegt damit beim nächsten Einschalten mit großer Wahrscheinlichkeit richtig. Man muss nicht immer eine Kaltstart des Empfängers durchführen.
>> Klaus R. schrieb: >> Die Amerikaner bauen im GPS Signal eine künstliche Ungenauigkeit ein, > >Wurde aus Angst vor Galileo aber wieder aufgegeben. Nein Bill Clinton hat die Verschwimmung aufgegeben, als klar wurde, dass zuviele oeffentliche Systeme, auch amerikanische Systeme, wie zB die Luftfahrt dran haengen.
:
Bearbeitet durch User
Joggel E. schrieb: > Bill Clinton hat die Verschwimmung aufgegeben In seinem Golfkreig waren zu wenig militärische GPS-Geräte verfügbar. Deshalb wird er wohl diese gewollte Ungenauigkeit aufgegeben haben, da seine Leute auch zivile nutzen mußten. Wenn ich richtig gelesen habe, sollte es aber im Hintergrund einige Knebelverträge zw. GPS und Galileo geben? Deswegen scheint mir ein Navi welches zusätzlich GLONASS und Beidou benutzen kann, durchaus zukunftsorientiert zu sein. Man weiß im Ernstfall bloß nicht wer lügt.
Konnte man nicht mit den neueren UBLOX-Empfängern den "PPS" bis in den MHz-Bereich per Programmierung bringen? Daraus ließ sich doch eine genügend stabile Zeitbasis zur Synchronisierung der Sensordaten per "Uhrzeit" generieren!
Ich benutze den ublox NEO M8T. Der hat einen PPS Ausgang UND einen Ext2 Pulse Ausgang. Auf dem Ext2. Kann ich eine beliebige zu GPS synchrone Frequenz ausgeben. Zb 100kHz oder 1Mhz. Damit gehe ich auf den Zähleingang eines Timers im uC. Der PPS geht auf den gleichen Counter auf eien Capture. Damit erhält man die Referenz. Die Zeitinformation des PPS kommt irgendwann später. Mit dieser Methode spart man sich die externe PLL. Hth, Adib.
Danke, mir war doch so das die ublox Module das relativ unproblimatisch konnten. Gruß Thommi
@adib: Das hört sich sehr interessant an. Genau eine solche Lösung kann ich mir für mein Problem vorstellen. Kannst Du ein konkretes Modul basierend auf dem "ublox NEO M8T" empfehlen? Kannst Du mich ggf. per Email anschreiben? (über die entsprechende Forenfunktion) Vielen Dank Ingo.
Ingo T. schrieb: > Kannst Du ein konkretes Modul > basierend auf dem "ublox NEO M8T" empfehlen? > Kannst Du mich ggf. per Email anschreiben? Das ist gemein, ich wüsste auch gerne mehr :(
So, dank des Tips von adib (Ublox Neo M8T) bin ich nun etwas weiter. Auf Seite 15 dieses Dokuments: https://www.u-blox.com/en/docs/UBX-15025193 findet man Informationen über Eingänge für externen Interrupt bei den Ublox M8T Receivern. Löst man einen Interrupt aus, so merkt ein interner Timer sich nanosekundengenau den Zeitpunkt der auslösenden Flanke - siehe Seite 385 dieses Dokuments: https://www.u-blox.com/en/docs/UBX-13003221 Nun habe ich mir ein Exemplar dieses Empfängers inklusive passender Antenne bestellt: https://www.gnss.store/gnss-gps-modules/77-incase-pin-series-neo-m8t-time-raw-receiver-board-rtk-ready.html ... und werde mal erste Versuche damit unternehmen. Leider kann man den Interrupt scheinbar nur so oft aufrufen, wie das NMEA-Protokoll ausgelesen werden kann. Lieber wäre mir eine Lösung, die nicht das gesamte Protokoll ausliest sondern nur die benötigte Zeitinformation und das eben z.B. 100 mal oder mehr in der Sekunde. Aber ggf. kann ich das ja mit einem externen Timer relaisieren. Jedenfalls komme ich so der Lösung hoffentlich erstmal näher. In einem Q/A-Thread ( https://www.ardusimple.com/question/extint/?ans-page=3 ) habe ich gelesen, daß Fotografen genau diese Möglichkeit der genauen Zeitermittlung mit dem ExtInt-Eingang eines GPS-Moduls nutzen. Für weitere Tips bin ich sehr dankbar. Gruß Ingo.
So, ich bin wieder ein Stück weiter. Ich habe inzwischen einen GPS-Empfänger mit Ublox Neo M8T Chip. Den kann ich mit der kostenlosen Software "u-center" von U-Blox konfigurieren. Ich habe alle NMEA-Meldungen augeschaltet, die Rate auf 10Hz eingestellt und die Übertragungsgeschwindigkeit auf dem seriellen Port auf 230400 Baud eingestellt. Wenn ich nun die Interruptleitungen mit Impulsen beschicke wird mir ein binäres Zeittelegramm ausgegeben, welches nanosekundengenau die Zeiten von Hin- und Rückflanke des entsprechenden Eingangs ausgegeben. Blöderweise ist das Ausgabeformat etwas gewöhnungsbedürftig. Es wird die Zahl ganzer Wochen seit dem 6.01.1980 sowie die der Sekunden (und Milli- und Nanosekunden) seit Ende der letzten ganzen Woche seit dem 6.01.1980 ausgegeben. Dafür habe ich mir nun ein Programm geschrieben, um ein vollständiges Zeittelegramm (für UTC)zu errechnen. Der GPS-Empfänger soll nun genutzt werden, um (mehrmals täglich) die RTC am Arduino genau zu stellen. Dazu wird die Verzögerung zwischen dem Triggern des GPS-Moduls und der RTC-Zeit bestimmt und die RTC-Zeit so korrigiert, daß diese Verzögerung berücksichtigt wird. VG Ingo.
Ingo T. (ingotron) schrieb: > Ich habe alle NMEA-Meldungen augeschaltet, die Rate auf 10Hz > eingestellt und die Übertragungsgeschwindigkeit auf dem seriellen > Port auf 230400 Baud eingestellt. Wenn ich nun die Interruptleitungen > mit Impulsen beschicke wird mir ein binäres Zeittelegramm ausgegeben, > welches nanosekundengenau die Zeiten von Hin- und Rückflanke des > entsprechenden Eingangs ausgegeben. Blöderweise ist das Ausgabeformat > etwas gewöhnungsbedürftig. Irgendwie erinnert mich das an "Des Kaisers neue Kleider", was natürlich wieder alle bildungsfeindlichen Kreise diskriminiert, die dieses Aha-Erlebnis mangels Lesekompetenz nicht haben... Trotzdem meine dumme Frage: Womit verifizierst du diese ns-Genauigkeit? Viele "Stellen hinterm Komma" auszugeben, ist "Auflösung", aber noch lange keine "Genauigkeit". Du meinst, diese gewünschte zeitliche Genauigkeit mit der Nicht- Abfrage von allem, was ein GPS ausmacht, zu erkaufen... Wie kommst du darauf? Versprechen die das etwa im Datenblatt? Bringen Standard-Meldungen das Timing durcheinander? Die 230400 Baud sollen doch nicht etwa Konflikte zwischen verschiedenen Abfragen einfach per Speed unwahrscheinlich machen? - Sie machen die Konflikte aber nicht UNMÖGLICH... Aber ... naja: Wer nicht so viel grübelt, schläft besser ein! Gute Nacht.
Hallo Jacko, was die "Nanosekundengenauigkeit" angeht, gibt es Informationen zu deren Abhängigkeit von der Anzahl der empfangenen Sateliten. Ansonsten hat die Genauigkeit nichts mit der Übertragungsrate o.ä. zu tun, denn das Zeittelegram bezieht sich auf die Interruptflanke an einem der externen Eingänge des GPS-Empfängers. Ansonsten verlasse ich mich zugegebenermaßen auf Herstellerangaben. Mir genügt für meine Aufgabe eine Genauigkeit im Bereich einiger zehn Millisekunden. Ansonsten enthält das Protokoll des Zeitstempels des Interrupteingangs einen Parameter "Accuracy estimate", der die "erwartete" Genauigkeit in Nanosekunden mit 4 Byte kodiert angibt. VG Ingo. PS: Ich hoffe mal stark, Du wähntest mich nicht in der Rolle des Kaisers. das wäre der Ehre zuviel...
:
Bearbeitet durch User
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.