iblue 747A+ / BT747 / DGPS

Hallo,

irgendwie komme ich mit DGPS nicht klar, oder ich habe falsche Vortstellungen …

Exportiere ich die Log-Daten als CSV, so sehe ich über längere Phasen in der Spalte “Valid” “DGPS”.
“DSTA” und “DAGE” bleiben jedoch 0. Hier würde ich irgendwelche Werte erwarten.

Wie sieht es bei euch aus?

Oder liegt es an den Einstellungen von BT747?

Bei mir ist folgendes eingestellt:
Geräteeinstellungen:

  • Nutze SABS / WAAS (EGNOS lässt sich nicht auswählen)
  • Inkl. Test SABS

im Log-Format ist “DSTA” und “DAGE” und natürlich angewählt.

Bei den Filtern ist natürlich auch “DGPS” angewählt.

Viele Grüße
Dieter

Hier gibt es eine kleine Disskusion:
http://www.bt747.org/de/forum/waas-egnos

Mit meinem Garmin (60CSx) habe ich keine signifikanten Verbesserungen mit EGNOS bemerken können.

Eine Anmerkung vorneweg: Ich habe keinen i-blue 747A+, sondern einen QStarz BT-Q1000X. Beide haben aber einen MTK II Chip und sollten in dieser Hinsicht eigentlich gleich funktionieren. Ich nutze auch nicht BT747, sondern ein eigenes Programm, das das MTK-API nutzt. BT747 kann hier aber nicht besser sein, denn mehr als das MTK-API kann BT747 auch nicht nutzen…

(1) Um ueberhaupt DGPS (korrekterweise SBAS != DGPS) nutzen zu koennen, muss man wohl noch den Testbetrieb zulassen, wie Du geschrieben hast (EGNOS sendet wohl immer noch das Testflag). Ich hatte das selbst erst vor kurzem festgestellt. Ob Dein Logger SBAS nutzt, siehst Du am FIX. Wenn Du den NMEA-Satz GGA des i-blue verwendest, ist FIX 1 = SPS (kein DGPS), FIX 2 = DGPS, … Wenn Du den Speicher ausliest, ist Bit 0 = No FIX, Bit 1 = SPS, BIT 2 = DGPS, etc. Ich weiss aber nicht, wie BT747 die Bit-Mask ggf. umsetzt.

(2) Zum Satelliten und zum Alter: Ich habe noch nicht versucht, diese Daten im Speicher zu loggen. Aber ich experimentiere gerade mit den NMEA-Saetzen. Im GGA sind diese Daten auch enthalten. Hier spuckt mein Logger nichts aus, wenn ich keinen SBAS-FIX habe. (Nichts heisst, dass nichts zwischen den beiden Kommata steht.) Habe ich einen SBAS-FIX, so steht im Feld fuer die Satelliten ID der String 0000 und im Feld fuer das Alter ebenfalls der String 0000. Zumindest fuer die Satelliten-ID ist das wohl erlaubt, denn der Wert muss zwischen 0000 und 1023 liegen. Meine Erfahrungen scheinen sich also mit Deinen zu decken. BT747 scheint aus “0000” wohl nur “0” zu machen.

Warum das allerdings so ist, habe ich noch nicht ergruenden koennen. Vielleicht, weil eben doch DGPS != SBAS – nicht hauen, ist nur so eine Idee. Schliesslich sollte es entweder einen Grund geben, oder es liegt ein Bug des MTK-Chips vor… oder gibt es noch eine andere Moeglichkeit?

Ich werde demnaechst weiter mit den NMEA-Saetzen experimentieren. Dadurch sollte ich jedenfalls genauer herausbekommen, wie der MTK in Bezug auf SBAS arbeitet. Aufgefallen ist mir bisher folgendes:

Die Saetze GSV enthalten wohl (mindestens) alle Satelliten, die der Chip aktuell sieht. Darunter sind auch die SBAS Satelliten. Ueber den SNR-Wert kann man feststellen, ob der Satellit aktuell nur sichbar ist (SNR nicht angegeben), oder ob er auch verwendet wird (SNR angegeben). Daneben habe ich immer auch einen Satelliten, zu dem nur die ID angegeben ist, d.h. neben SNR fehlen auch die Angaben zu Elevation und Azimut. Was dieser Eintrag bedeutet, weiss ich noch nicht.

Darueber hinaus ist immer nur ein SBAS-Satellit in den GSV-Saetzen angegeben, d.h. es wird maximal ein SBAS-Satellit verwendet, oder keiner, wenn er zwar sichtbar ist, aber kein SNR angegeben ist.

Welcher SBAS-Satellit in der Liste ist, wechselt haeufig. Meistens habe ich keinen guten SBAS-Empfang (die Experimente mache ich in meiner Wohnung, d.h. der Logger liegt auf der Fensterbank in Hoehe des 50ten Breitengrades). Wenn ich allerdings erst mal einen SBAS-FIX habe, dann bleibt das fuer laengere Zeit bestehen, auch wenn in den GSV-Saetzen kein SBAS-Empfang angegeben ist.

Ich werde demnaechst ein Programm schreiben, dass mir folgende Fragen beantwortet:

(a) Welcher SBAS-Satellit ist gemaess GSV gerade sichtbar, wenn der FIX von SPS auf DGPS umspringt?

(b) Wie lange bleibt der SBAS-FIX bestehen, wenn kein SBAS-Empfang mehr vorliegt?

Das Ganze ist schon spannend, denn die GSV-Saetze weisen (im Wechsel, siehe oben) so ziemlich alle SBAS-Satelliten aus, auch die ueber Brasilien. Letztere aber ohne SNR, also zwar sichtbar, aber nicht verwendet. Mit SNR tauchen meistens so drei bis vier bestimmte auf, darunter auch die drei auf der ESA-Homepage angegebenen (PRN 120, 124 und 126).

Ich hoffe, auf diese Weise herauszubekommen, wie verlaesslich die SBAS-Korrektur ist: Wenn ein anderer als die drei genannten Satelliten fuer den SBAS-FIX verwendet wird, sollte das eher zu einer Verschlechterung der Daten beitragen.

EDIT: Du kannst die Daten der GSV-Saetze auch im Logger speichern und anschliessend auslesen. Dann kannst Du dieselben Analysen machen, wie ich mit den NMEA-Saetzen. Kostet halt viel Speicherplatz, denn dann werden in jedem Datensatz alle Satellitendaten abgelegt… Ich weiss auch nicht, wie der BT747 damit umgeht. Schliesslich hat man hier eine 1:N Beziehung: Ein Datensatz mit UTC, LAT, LON, … und N Satellitendaten.

Noch ein EDIT: In einer Dokumentation steht zum Alter der DGPS-Daten in den GGA Saetzen: “Age of Differential GPS data, time in seconds since last SC104 type 1 or 9 update, null field when DGPS is not used”

Leider verstehe ich nicht genug von SBAS, aber vielleicht liegt wegen SBAS != DGPS wirklich der Hase im Pfeffer: Wenn die SBAS-Korrekturen nicht auf Basis von SC104 (vgl auch RTCM) erfolgen, muesste nach dieser Aussage das Feld fuer das Alter streng genommen wirklich keine Daten enthalten.

@Seelze
Merci für den Link.
Auch dort wird zwar ein DGPS-Fix erkannt, DSTA und DAGE bleiben aber auch dort 0.

@Schlauchboot
Merci für die umfangreichen Infos.

In meinen als CSV exportierten Loggerdaten sehe ich den DGPS-Fix (normal SPS vielfach aber auch über längere Zeit auch DGPS).

Du betrachtest deine Daten wohl im NMEA-Format - welchen Viewer verwendest du?

Anzahl DGPS-SATs und Alter …
BT747 schreibt im CVS-Export in beide Felder konstant eine 0 rein - egal, SPS- oder DGPS-Fix.

Die würde die Aussage zahlreicher User bestätigen, die von keiner Verbesserung mit DGPS berichten.
Wenn einige von Positionssprüngen berichten, so widerspricht sich dies eigentlich - wenn DGPS nicht ausgewertet wird, kann sich auch nichts verschlechtern. Sei dahingestellt, wie gründlich die Positionsbestimmung beobachtet wurde - es gibt viele Gründe, die Positionssprünge auslösen konnen.

Auch sind diese Berichte aus der Zeit, in der sich die EGNOS-SATs noch in der Testphase befanden…

Mhm - Werden die Daten im Logger wirklich im NMEA-Format gespeichert?
Beim i-blue 747A+ habe ich es immer so verstanden, dass intern in einem eigenen Format gespeichert wird. BT747 zieht diese Daten 1:1 ab und legt diese in einer BIN-Datei im PC ab. Der Export als GPX, CSV, NMEA etc. erfolgt offline aus dieser BIN-Datei.

Stimmt eigentlich die Aussage noch, dass die EGNOS Sats horizontnah im Süden zu finden sind?

Kippst du bei deinen Experimenten die Antenne leicht nach Süden?

Viele Grüße
Dieter

Hallo Dieter,

viele bunte Missverstaendnisse…

Wie ich schon schrieb, verwende ich ein eigenes Programm. Das beherrscht so ziemlich das komplette MTK-API, d.h. ich kann sowohl die NMEA-Saetze lesen, als auch den Speicher auswerten. Die NMEA-Saetze verwende ich eigentlich nur aktuell fuer die SBAS-Experimente. Da ist mir der Weg ueber den Speicher zu umstaendlich. Das geht leichter am Schreibtisch… :wink: Wobei ich am Schreibtisch naturgemaess nur ganz bestimmte Fragen untersuchen kann.

Meine Tracks zeichne ich schon im Speicher auf und lese sie zu Hause aus…

Ich glaube, hier sind Deine Schlussfolgerungen viel zu schnell! (Und wohl auch zu negativ.)

(A) Zunaechst noch einmal eine kleine Korrektur zu meiner eigenen Aussage: In den Datensaetzen (egal, ob im NMEA oder im Speicher) wird die ID der (DGPS/SBAS) Referenzstation angegeben. Doch was ist damit gemeint? Genauer, welchen Wert erwarten wir hier eigentlich? Ich behaupte: Keine Satelliten-ID, entgegen meiner eigenen Formulierung:

Urspruenglich bezog sich das Ganze auf das marine RTCM. Dort gab es Referenzstationen, die zwei Funktionen inne hatten: (i) Sie kannten ihre Position genau und haben auf sich bezogene Korrekturdaten berechnet. Die Verwendbarkeit dieser individuellen Korrekturdaten nimmt mit der Entfernung zu der Referenzstation ab. (ii) Sie haben diese Korrekturdaten per Funk ausgesendet.

Bei SBAS ist das anders. Bei EGNOS gibt es nicht die eine Referenzstation. EGNOS hat (glaube ich) etwa zehn ueber Europa verteilte auf dem Boden befindliche Referenzstationen, die die Korrekturen ausrechnen. Uebertragen werden jedoch nicht auf einzelne Referenzstationen bezogene Korrekturdaten, sondern interpolierende Korrekturdaten, die fuer das ganze Gebiet gelten (vgl. z.B. http://de.wikipedia.org/wiki/European_Geostationary_Navigation_Overlay_Service, Kapitel Hintergrund). Das ist ad (i).

Ausgestrahlt werden die Signale jedoch nicht von den Referenzstationen, sondern von Satelliten, und zwar von dreien, die dieselben EGNOS-Korrekturdaten ausstrahlen. Das war ad(ii). Relevant ist hier also eigentlich nicht der Satellit, von dem man die Daten empfaengt, sondern das System (EGNOS, WAAS, …), dessen Daten man erhaelt. Ich nehme an, dass diese Systeme auch ihre ID haben, die man wohl eher als Referenzangabe erwarten sollte. Irgendwo habe ich im Zusammenhang von EGNOS auch den Begriff Virtuelle Referenzstation gelesen. Das wuerde dazu passen.

Hypothese: Wir erwarten im Feld DSTA im Falle von SBAS die ID einer so genannten virtuellen Referenzstation namens EGNOS – keine Satelliten-ID.

Gleiches sollte fuer die NMEA-Saetze gelten. Doch bleibt die Frage offen, wie diese Nummer aussieht.

(B) EGNOS ist noch formal im Testbetrieb, doch ist das wirklich nur eine formale Geschichte, das System ist dem Test entwachsen. Auf http://www.egnos-pro.esa.int/index.html steht z.B.

Irgendwo habe ich gelesen, dass das Testflag wegfallen wird, sobald die Zertifizierung erfolgt ist, geplant in 2010.

Fazit: Das Testflag sollte keine Schlussfolgerung mehr ueber die Qualitaet des Systems erlauben.

(C) Die Frage, ob und wenn ja welche Verbesserung SBAS liefert, ist nicht leicht zu beantworten. Auf gar keinen Fall kann man in dieser Hinsicht irgendeinen Schluss aus dem Vorhandensein oder nicht-Vorhandensein irgendwelcher Werte in den Feldern DSTA und DAGE (analog in den NMEA-Saetzen) ziehen – oder dem Vorhandensein des Testflags.

Auf http://www.naviuser.at/forum/index.php habe ich einmal einen Forumsbeitrag zu einem Experiment gefunden. Dort hat sich jemand die Koordinaten eines Punktes auf einem Berg (cm-Genauigkeit) von dem Landesvermessungsamt gekauft. Dann hat er mit zwei Loggern nebeneinander auf dem Berg die stationaere Position dieses Punktes ueber einen Zeitraum aufgezeichnet. Aus diesen beiden Zickzacklinien um den stationaeren Punkt kann man Mittelwerte und Standardabweichungen berechnen. Dann kann man die beiden Mittelwerte mit den gekauften genauen Koordinaten und die beiden Standardabweichungen miteinander vergleichen. Daraus kann man dann eine Aussage ueber die Guete von SBAS ableiten. Einfacher geht das wohl nicht… Leider erinnere ich mich nicht mehr an das Ergebnis dieser Untersuchung… ;-(((

(D) Schuss ins Blaue: Vielleicht wird als ID solange 0000 angegeben, wie das Testflag noch vorhanden ist. ;-))))

Meine Aussage war missverstaendlich, sie betraf nicht das Format, sondern den Inhalt. GSV liefert zu jedem sichtbaren Satelliten die Satelliten-ID, die Elevation, den Azimut und den SNR-Wert. Wird der Satellit verwendet, ist ein SNR angegeben. Ist der Satellit nur in Sicht, aber nicht verwendet, wird kein SNR angegeben. Diese Daten kann der Logger auch im Speicher ablegen, in den Feldern SID, ELE, AZI und SNR. Ist schon richtig, dass das im Speicher binaer abgelegt wird, aber das hat ja keinen Einfluss auf die Daten… ;-)))

(A) In der Sprache der NMEA-Saetze werden zu einem GGA-Satz (mit UTC, Position, Hoehe, FIX, …) mehrere GSV-Saetze verschickt, und zwar genau so viele, dass die Daten aller sichtbaren Satelliten uebertragen werden.

(B) In der Sprache des Speichers werden die Daten in sogenannten Records binaer abgelegt. Jeder Record enthaelt (bei entsprechender Programmierung) je einen Wert fuer UTC, Position, Hoehe, FIX, … und soviele Wiederholungen von Satellitendaten, dass die Daten zu allen sichtbaren Satelliten in einem Record abgelegt sind.

Inhaltlich entsprechen (A) und (B) einander. Vom Format her nicht.

Ja, ich kippe leicht, aber das scheint nicht notwendig zu sein. Die Hoehe scheint – wenn ich mich recht erinnere – zwischen 15 und 31 Grad zu liegen. Haengt vom Satelliten ab. Well, mein Fenster ist im ersten Stock, da kann ich schon recht nahe am Horizont liegende Objekte sehen. Aber ohne maschinelle Auswertung, nur von Ansehen der NMEA-Saetze, kann ich nichts Quantitatives sagen.

mhm - die EGNOS-Korrekturen sollten sich theoretisch auch “offline”, d.h. im nachhinein verrechnenen lassen.

Die ESA stellt hierzu einen Server zur Verfügung http://www.egnos-pro.esa.int/ems/index.html

Der Vorteil wäre, dass man die Wirkung der Korrektur objektiv bewerten könnte.

Im Gegensatz hierzu sind zwei Aufzeichnungen (einmal mit aktivierten DGPS, einmal ohne) nie objektiv vergleichbar, da sich die Aufzeichnungsbedingungen schon leicht geändert haben)

Viele Grüße
Dieter

Das Experiment könnt Ihr doch ganz einfach wiederholen. Legt den Logger je 24 h (um mal mit Ionosphäreneinfluß und mal ohne zu erfassen) an einen Ort mit gutem Sat-Empfang und vergleicht die aufgezeichneten Tracks (mit / ohne EGNOS). Eine Sollkoordinate ist meines Erachtens nicht wichtig für die Aussage, ob die EGNOS Korrekturdaten was bringen.

Dieses Post-Processing hatte ich mal eine Zeit lang verfolgt:

(1) Man braucht einen Logger, der die Pseudo-Range Daten aller verwendeten Satelliten speichert und rausrückt. Das tun Consumer-Geräte eher nicht bis wenig. Geräte von Trimble etc. sind aber jenseits meines Budgets…

(2) Man braucht viel Wissen → man muss viel Zeit in die Lektüre von Büchern und Standards stecken. Beide sind nicht billig, insbesondere die Standards werden die Geldbörse arg belasten.

(3) Um das Ganze verdauen zu können, braucht man schon einen gewissen mathematischen Unterbau.

Lediglich Voraussetzung (3) wäre bei mir erfüllt. Daher habe ich dieses Projekt erst einmal eingestellt… :-((((

Wie waere es mit zwei identischen Loggern zeitgleich nebeneinander, einmal mit aktivierten DGPS und einmal ohne?

Gruss
Torsten

@Schlauchboot
ich sehe, dass sich die Rechnerei aufwendiger gestaltet, als erwartet :wink:

@de_muur
so etwas ähnliches haben andere auch schon getestet - es ist aber auch bekannt, das sich die Logger gegenseitig beeinflussen, wenn ein Mindestabstand nicht eingehalten wird.

Zumal wir hier noch etwas daran zweifeln, dass die aktuellen Logger die DGPS-Infos überhaupt richtig auswählen.

Eine rein mathematische Korrektur würde erst mal zeigen, was man eigentlich erwarten kann, bzw. unter welchen Umständen die Korrektur deutlich wird.

Viele Grüße
Dieter

PS: In einem Flyer der ESA http://www.egnos-pro.esa.int/br227_EGNOS_2004.pdf heißt es:
“The EGNOS space segment is composed of three geostationary satellites:
two Inmarsat-3 satellites (AOR-E and IOR-W) and ESA’s Artemis
satellite. EGNOS users should be able to track at least two of
them.”

Demnach sollten immer zwei EGNOS-SATs in use sein …

… noch mal edit …

@schlauchboot
Ich habe mir gerade auch mal die NMEA GGA-Sätze angesehen … sehen genauso aus, wie bei dir …
Allerdings wird die “2” für DGPS-Fix auch unter ziemlich miesen “Sichtbedingungen” angezeigt, was eigentlich recht unwahrscheinlich ist.

Ohne den Testmode habe ich auch keinen DGPS-Fix - hätte aber auch hier im Zimmer keine ideale Sicht nach Süden.

Habe gestern abend mal die NMEA-Saetze eine Weile angesehen. Wetterbedingung: Starke Bewoeklung und Regen. FIX = 1, d.h. kein DGPS waehrend der ganzen Zeit.

Heute abend ist der Himmel recht klar, leichte Wolkenschleier. Nach ein paar Minuten FIX = 2. Seit ueber einer Stunde (so lange pruefe ich das ganze) sehe ich konstant den Satelliten ID = 37: ARTEMIS (PRN 124); Position 21,5°O - Afrika. (Quelle: http://de.wikipedia.org/wiki/European_Geostationary_Navigation_Overlay_Service) Mein Logger steht uebrigens mit einer Neigung von etwa 45 Grad. Ohne Kompass kann ich die Ausrichtung in Bezug auf Sueden nicht ermitteln, ist etwa SSO oder so.

Angaben des Loggers zu diesem Satelliten:

Elevation: erst 39, dann 38
Azimut: 161
SNR schwankt zwischen 30 und 36.

Elevation kann ich fuer einen geostationaeren Satelliten auf Basis meiner Position und des Azimut ausrechnen. Dazu habe ich die Formeln auf http://de.wikipedia.org/wiki/Geostation%C3%A4rer_Satellit (ungeprueft) und hoffentlich richtig verwendet.

Wenn ich meine Werte stur in die Formeln einsetze, erhalte ich fuer die Elevation 30,54 Grad, was stark von den angezeigten 38 Grad abweicht.

Welcher Fehler hier typischerweise zu erwarten ist, weiss ich allerdings nicht.

Darueber hinaus sieht mein Logger neun weitere Satelliten mit einer Elevation zwischen 10 und 80 Grad: 30, 12, 29, 2, 14, 31, 4, 9 und 27. Schon ganz gut fuer einen Blick aus dem Fenster. Die SNR ist fast immer bei allen neun Satelliten angegeben. Nur kurz verschwindet sie bei einem einzelnen Sat. Entsprechend sagt GGA, dass 9 (8) Satelliten verwendet werden.

Genau das will ich ja etwas quantitativer fassen. So gute Bedingugnen, wie oben beschrieben, habe ich nicht immer. Manchmal ist ein SBAS Satellit immer nur fuer kurze Zeit, oder auch laenger gar nicht mehr sichbar. Die Frage ist hier, wie lange der Logger die einmal erhaltenen Korrekturdaten verwendet, bis er wieder von FIX = 2 auf FIX = 1 zurueckspringt. Ich weiss auch nicht, wie schnell die Korrekturdaten altern.

Die zweite Frage ist, wie lange der Logger einen SBAS Satelliten stabil sehen koennen muss, bis er von FIX=1 auf FIX=2 umspringt. Irgendwo habe ich mal was von 2 Minuten gelesen. Das sieht bei mir manchmal aehnlich aus – ist aber nur eine gefuehlte Aussage, keine quantitative.

P.S. waehrend des Schreibens dieses Beitrags habe ich Nummer 37 auch verloren. Jetzt zeigt der Logger immer nur fuer kurze Zeit 33, 44, 37, 39, … im Wechsel an, aber alle ohne SNR, d.h. eigentlich nicht verwendet. Der FIX ist immer noch 2. Klar, dass er nicht sofort zurueckspringt, denn sooo schnell altern die Korrekturdaten auch wieder nicht.

EDIT: Jetzt, also zwischen 60 und 90 Minuten spaeter bin ich wieder bei FIX = 1. Allerdings habe ich die Satelliten in der Zwischenzeit nicht beobachtet. Der Wert ist daher eine obere Grenze.

Cool: Waehrend ich dies geschrieben habe, bin ich wieder von FIX = 1 auf FIX = 2 zurueck. Der Logger sieht stabil ID = 39: Inmarsat IOR-W (PRN 126; zurzeit Testsystem); Position 25,0°O - Afrika.

Er sagt

Azimut = 158
Elevation = 30

Mit 158 Grad gerechnet wuerde ich fuer meine Position eine Elevation von 29,95 Grad erwarten. Angezeigt werden 30 Grad.

Noch ein EDIT: Habe den Formelsalat noch einmal korrigiert – hoffentlich sind die Aussagen zur Elevation nun richtig.

Noch ein paar weitere Informationen:

Der Satellit Artemis http://de.wikipedia.org/wiki/Artemis_%28Satellit%29 ID=37, PRN124 hat eine Inklination von 5 Grad, d.h. er wird nicht mehr mit konstannter Elevation beobachtet, sondern auf einer etwa 8-foermigen Bahn. Daher aendert sich die Elevation im laufe des Tages. Diesen Effekt konnte ich heute beobachten. Dies wuerde erklaeren, dass der Logger gestern Abend einen Wert von 38 ausgewiesen hat. Ohne Inklination wuerde man 30 erwarten. Mit Inklination schwankt der Wert um die 30.

SBAS-Korrekturdaten sind http://mars.hg.tuwien.ac.at/Bibliography/Bachelor/2009_Bachelor_Hohensinn.pdf

  • Satellitenuhernfehler (altern schnell)

  • Satellitenuhrendrift und Ephemeridenfehler (altern langsam)

  • Ionosphaerenkorrekturen (altern ???)

Ich habe nur kurz durch den zitierten Artikel geblaettert und nichts dazu gefunden, was schnell bzw. langsam dabei heisst. Zu den Veraenderungen der Ionosphaereneffekte gibt es ein paar Bilder in der genannten Quelle.

Jenachdem, welche Daten der Logger beruecksichtigt (die Ionosphaereneffekte scheinen wohl den groessten Einfluss zu haben), ist es durchaus plausibel, dass der Logger die einmal empfangenen Korrekturen auch nach dem Verlust des Kontaktes zu einem SBAS-Satelliten noch eine bestimmte Zeit (z.B. eine Stunde oder ae.) verwendet.

Die verschiedenen Korrekturen werden ueber verschiedene Nachrichten uebermittelt. Unklar ist mir noch, wie lange der Transfer welcher Nachrichten dauert und mit welcher Frequenz sie wiederholt werden. Es kann ja sein, dass der Logger einmal alle Korrekturen empfangen will, bevor er von FIX=1 auf FIX=2 springt, danach aber immer wieder nur die Aktualisierung der schnell-veraenderlichen Daten braucht, um den FIX=2 zu behalten. Das wuerde bedeuten, dass er am Anfang laenger Kontakt zu einem SBAS-Satelliten braucht, bis er auf FIX-2 springt, als er zwischendurch braucht, um FIX=2 zu behalten. Letztlich haengt das aber auch davon ab, welche Korrekturdaten der Logger ueberhaupt beruecksichtigt. Das weiss ich leider auch nicht. Um das genauer zu ergruenden, muss man das Verhalten des Loggers, insbesondere den Wechsel zwischen FIX=1 und FIX=2 laenger mit quantitativen Auswertungen beobachten.

Ich habe heute mal damit angefangen und bin auf folgende Hypothesen gestossen:

Hypothese 1: Der Logger weiss, welche SBAS-Satelliten es gibt und sucht mit einer Periode von etwa 2-3 Minuten, Kontakt zu einem Satelliten zu erhalten. Das sieht dann etwa so aus: (in der Liste wird immer ein Eintrag protokolliert, wenn sich FIX, Satelliten-ID oder SNR aendert)


GGA: 111555.000; 1; -1; 0; 0; 0
GSV: 111556.000; 1; 37; 31; 163; 0
GSV: 111633.000; 1; 33; 31; 158; 0
GSV: 111643.000; 1; 39; 28; 159; 0
GSV: 111652.000; 1; 44; 12; 116; 0
GSV: 111702.000; 1; 37; 31; 163; 0
GSV: 111720.000; 1; 33; 31; 158; 0
GSV: 111729.000; 1; 39; 28; 159; 0
GSV: 111738.000; 1; 44; 12; 116; 0
GSV: 111747.000; 1; 34; 0; 0; 0
GSV: 111753.000; 1; 36; 0; 0; 0
GSV: 111800.000; 1; 38; 0; 0; 0
GSV: 111806.000; 1; 40; 0; 0; 0
GSV: 111812.000; 1; 41; 0; 0; 0
GSV: 111819.000; 1; 43; 0; 0; 0
GSV: 111825.000; 1; 45; 0; 0; 0
GSV: 111831.000; 1; 46; 0; 0; 0
GSV: 111838.000; 1; 49; 0; 0; 0
GSV: 111845.000; 1; 37; 31; 163; 0
GSV: 111903.000; 1; 33; 31; 158; 0
GSV: 111912.000; 1; 39; 28; 159; 0
GSV: 111921.000; 1; 44; 12; 116; 0
GSV: 111930.000; 1; 34; 0; 0; 0
GSV: 111936.000; 1; 36; 0; 0; 0
GSV: 111942.000; 1; 38; 0; 0; 0
GSV: 111949.000; 1; 40; 0; 0; 0
GSV: 111955.000; 1; 41; 0; 0; 0
GSV: 112002.000; 1; 43; 0; 0; 0
GSV: 112008.000; 1; 45; 0; 0; 0
GSV: 112014.000; 1; 46; 0; 0; 0
GSV: 112021.000; 1; 49; 0; 0; 0
GSV: 112028.000; 1; 51; 0; 0; 0
GSV: 112035.000; 1; 42; 0; 0; 0
GSV: 112042.000; 1; 50; 0; 0; 0
GSV: 112048.000; 1; 48; 0; 0; 0
GSV: 112055.000; 1; 35; 0; 0; 0
GSV: 112101.000; 1; 47; 0; 0; 0
GSV: 112108.000; 1; 37; 31; 163; 0
GSV: 112145.000; 1; 33; 31; 158; 0
GSV: 112155.000; 1; 39; 28; 159; 0
GSV: 112204.000; 1; 44; 12; 116; 0
GSV: 112214.000; 1; 37; 31; 163; 0
GSV: 112232.000; 1; 33; 31; 158; 0
GSV: 112241.000; 1; 39; 28; 159; 0
GSV: 112250.000; 1; 44; 12; 116; 0
GSV: 112300.000; 1; 34; 0; 0; 0

Angezeigt werden NMEA-Satz, Uhrzeit (UTC), FIX, Satelliten-ID, Elevation, Azimut, SNR. Ach ja, protokolliert habe ich auch nur Satelliten mit einer ID > 32.

SNR = 0 bedeutet dabei, dass der Satellit nicht verwendet wird. Hier wird also kein SBAS-Satellit verwendet, daher bleibt der FIX die ganze Zeit auf 1. Die erste Zeile bezeichnet den Anfang, d.h. dem Programm liegt keine Information ueber einen SBAS-Satelliten vor.

Die Zeilen ohne Elevation und Azimut koennten bedeuten, dass dies SBAS-Satelliten sind, die Korrekturen aussenden, die fuer meine Position irrelevant sind – zumindest die Ionosphaerenkorrekturen betreffend. Vielleicht werden sie aber auch nur gesucht und gar nicht gesehen.

Hypothese 2: Ein intialer Kontakt von mindestens 14 Sekunden reicht nicht, um genuegend Korrekturdaten zu einem Wechsel von FIX=1 auf FIX=2 zu erreichen:

GSV: 120343.000; 1; 47; 0; 0; 0
GSV: 120351.000; 1; 37; 31; 163; 0
GSV: 120353.000; 1; 37; 31; 163; 29
GSV: 120354.000; 1; 37; 31; 163; 28
GSV: 120355.000; 1; 37; 31; 163; 29
GSV: 120357.000; 1; 37; 31; 163; 0
GSV: 120409.000; 1; 33; 31; 158; 0
GSV: 120419.000; 1; 39; 28; 159; 0
GSV: 120428.000; 1; 44; 12; 116; 0
GSV: 120437.000; 1; 37; 31; 163; 0
GSV: 120443.000; 1; 37; 31; 163; 28
GSV: 120447.000; 1; 37; 31; 163; 29
GSV: 120451.000; 1; 37; 31; 163; 28
GSV: 120457.000; 1; 33; 31; 158; 0
GSV: 120506.000; 1; 39; 28; 159; 0
GSV: 120515.000; 1; 44; 12; 116; 0
GSV: 120525.000; 1; 34; 0; 0; 0

Hier sieht man auch, dass die fuer mich relevanten SBAS-Satellieten bei einer fuer meine Position erwarteten Elevation von etwa 30 erwartet werden.

Hypothese 3: Der Kontakt von mindestens 58 Sekunden zu einem SBAS-Satelliten reicht aus, um den FIX=2 zu erreichen:

GSV: 121519.000; 1; 49; 0; 0; 0
GSV: 121525.000; 1; 37; 31; 163; 0
GSV: 121528.000; 1; 37; 31; 163; 33
GSV: 121529.000; 1; 37; 31; 163; 34
GSV: 121532.000; 1; 37; 31; 163; 33
GSV: 121533.000; 1; 37; 31; 163; 34
GSV: 121552.000; 1; 37; 31; 163; 33
GSV: 121553.000; 1; 37; 31; 163; 34
GSV: 121617.000; 1; 37; 34; 163; 33
GGA: 121626.000; 2; 37; 34; 163; 33
GSV: 121628.000; 2; 37; 34; 163; 34
GSV: 121644.000; 2; 37; 34; 163; 33
GSV: 121653.000; 2; 37; 34; 163; 34
GSV: 121740.000; 2; 37; 34; 163; 33
GSV: 121748.000; 2; 37; 34; 163; 32
GSV: 121751.000; 2; 37; 34; 163; 33

Hier sieht man auch, dass die Elevation von 31 auf 34 springt. Das koennte eine ueber den SBAS-Satelliten empfangene Bahnkorrektur des SBAS-Satelliten selbst sein – siehe oben zu Inklination. Daraus wuerde folgen, dass der Logger auch Bahnkorrekturen beruecksichtigt – wohl nicht nur fuer den SBAS-Satelliten, sondern auch fuer die GPS-Satelliten. Habe ich aber nicht ausgewertet. Die Elevation der Nummer 37 ist dann weiter gestiegen, bis auf aktuell 38:

GSV: 143606.000; 2; 45; 0; 0; 0
GSV: 143613.000; 2; 46; 0; 0; 0
GSV: 143620.000; 2; 49; 0; 0; 0
GSV: 143626.000; 2; 37; 38; 162; 0
GSV: 143644.000; 2; 33; 31; 158; 0

Der FIX=2 hat sich die ganze Zeit ueber nicht geaendert, obwohl ich irgendwann den bis dahin permanenten Kontakt zur Nummer 37 verloren habe:

GSV: 125812.000; 2; 37; 35; 162; 29
GSV: 125824.000; 2; 37; 35; 162; 28
GSV: 130041.000; 2; 33; 31; 158; 0
GSV: 130050.000; 2; 39; 28; 159; 0
GSV: 130055.000; 2; 39; 28; 159; 28
GSV: 130056.000; 2; 39; 28; 159; 27
GSV: 130057.000; 2; 39; 28; 159; 28
GSV: 130058.000; 2; 39; 28; 159; 27
GSV: 130059.000; 2; 39; 28; 159; 28
GSV: 130106.000; 2; 39; 28; 159; 0
GSV: 130112.000; 2; 39; 28; 159; 28
GSV: 130114.000; 2; 39; 28; 159; 27
GSV: 130116.000; 2; 39; 28; 159; 28
GSV: 130122.000; 2; 39; 28; 159; 0
GSV: 130123.000; 2; 39; 28; 159; 28
GSV: 130124.000; 2; 39; 28; 159; 0
GSV: 130125.000; 2; 44; 12; 116; 0
GSV: 130134.000; 2; 34; 0; 0; 0
GSV: 130140.000; 2; 36; 0; 0; 0

Zwischendurch gab es immer wieder kurz kontakt zu verschiedenen SBAS=Satelliten, wie hier ueber 2 bzw. 14 Sekunden zu Nummer 39.


GSV: 135545.000; 2; 47; 0; 0; 0
GSV: 135551.000; 2; 37; 37; 162; 0
GSV: 135628.000; 2; 33; 31; 158; 0
GSV: 135638.000; 2; 39; 28; 159; 0
GSV: 135644.000; 2; 39; 28; 159; 28
GSV: 135646.000; 2; 39; 28; 159; 0
GSV: 135654.000; 2; 44; 12; 116; 0
GSV: 135704.000; 2; 37; 37; 162; 0
GSV: 135722.000; 2; 33; 31; 158; 0
GSV: 135732.000; 2; 39; 28; 159; 0
GSV: 135737.000; 2; 39; 28; 159; 28
GSV: 135751.000; 2; 44; 12; 116; 0
GSV: 135800.000; 2; 34; 0; 0; 0

Fuer weitere Hypothesen reichen diese Daten nicht. Durch eine laengere systematische Auswertung kann man aber sicher noch mehr der oben aufgeworfenen Fragen beantworten.

@schlauchboot,

interessante Beobachtungen :-))))

Ich habe meine NMEA-Aufzeichnung von gestern auch noch mal angesehen.

In den GSV-Sätzen kann ich ebenfalls die drei EGNOS-SATs sehen:

Inmarsat AOR-E (PRN 120; ID 33)
ARTEMIS (PRN 124; ID 37)
Inmarsat IOR-W (PRN 126; ID 39)

Obwohl lt. GGA-Satz ein DGPS-Fix vorliegt ((2), ist bei den EGNOS-Sats die SNR stets leer/0.

Ich werde es aber nochmal genauer, bzw. länger beobachten.

Mit welchem Programm zeichnest du die NMEA-Sätze auf, bzw. betrachtest du diese?

Im Rohformat lassen sie sich die Datensätze nur unbequem lesen, besonders die GSV-Sätze …

In einem anderen Forum hat jemand berichtet, dass er erst 1 bis 2 Minuten nach dem DGPS-Fix eine Korrektur feststellen konnte.

Viele Grüße
Dieter

Finde ich auch, je so mehr, umso laenger mein Logger Daten im Zeitablauf aufzeichnet. Im Moment weiss ich noch nicht, ob das Ergebnis meinen Daumen rauf oder runter zeigen lassen wird/muss… Schau mal hier rein: http://www.essp-sas.eu/docs/printed_documents/guide_egnos_2009_va_hd_bat3.pdf Dort steht genaueres zu meinen Vermutungen. So braucht ein Datensatz eine Sekunde fuer die Uebertragung. In 60 Sekunden kann der Logger also 60 Datensaetze empfangen. Zudem steht dort auch was zur Frequenz, mit der Daten uebertragen werden, und zu deren Alterung. Ich hatte leider noch keine Zeit es genauer zu lesen.

Mein Logger hat heute dreimal ueber laengere Zeit (etwa groesser 30 Minuten) Kontakt zu einem SBAS-Satelliten gehabt. Das wuerde heissen, er hat dreimal groessere Datenmengen empfangen. Das koennten (von der Menge her) vielleicht die Daten des Ionosphaerengrids sein. Leider gibt es wohl keine allgemeingueltigen Aussagen ueber die Alterung dieser Daten. Diese Angaben werden ebenfalls uebertragen, in Nachrichtentyp 10… (vgl. die angegebene Quelle). Wenn man nun die EGNOS-Daten via Internet auswerten koennte, haette man eine Moeglichkeit, die Funktion des Loggers zu pruefen: Laed er z.B. – sofern gerade Empfang moeglich ist – die Ionosphaerendaten jedesmal nach, wenn sie nicht mehr verlaesslich sind? Halte ich fuer gut moeglich.

Sollte er fuer den Empfang der Ionosphaerendaten aber wirklich so lange brauchen (das sollte man anhand der angegebenen Quelle ausrechnen koennen), waere mit der Angabe FIX=2 jedoch Vorsicht geboten: Der Logger hat den FIX ja nach ca. 60 Nachrichten von 1 auf 2 gesetzt, das waere dann ohne den Empfang der Ionosphaerendaten. Sobald ich Zeit habe, werde ich mir das mal genauer ansehen.

Und wie gesagt, dazwischen gibt es immer mal kurzen Kontakt, so zum Empfang von 5 bis 10 Nachrichten…

Hrmmmrmm… selbstgestrickt, hatte ich schon zweimal gesagt… ;-)))) Ich kann Dir mein Programm leider (noch) nicht anbieten, denn es soll mal was groesseres werden und ist noch nicht fertig. Die NMEA-Sache ist aktuell nur provisorisch eingebaut und in Arbeit. Die Experimente dienen auch dazu, herauszufinden, welche Angaben wie ausgewertet und angezeigt werden sollten – damit man nicht in Daten ersaeuft, aber das Wesentliche sieht.

Wenn Du programmieren kannst, ist eine Aufbereitung aber nicht so schwer… (Kannst Du Java programmieren?)

Jep! Mein provisorisches Programm filtert ja auch schon etwas,

@schlauchboot

für mich gibt es derzeit folgende Ungereimtheiten.

  1. DGPS-Fix ohne SNR der EGNOS-Sats
    Ich habe in meinem NMEA-Log einen DGPS-Fix ohne SNR der EGNOS-Sats.
    Nach allgemeiner Logik sollte ein Fix nur mit Satelliten in use möglich sein - ohne SNR sollten die Satelliten aber nicht in use sein.

  2. Lt. Wikipedia hat nur der Inmarsat IOR-W (PRN 126; ID 39) das Testflag. Beim Empfang von Inmarsat AOR-E (PRN 120; ID 33) oder ARTEMIS (PRN 124; ID 37) sollte der MTK-Logger aber auch ohne aktivierte Testflag-Auswertung mal einen DGPS-Fix zeigen.
    Ich habe noch keinen DGPS-Fix beobachtet.

Vielleicht unterscheiden sich die Satelliten auch in der Wiederholungsrate der spezifischen Korrekturdaten entsprechend ihrer regionalen Position.
Womit eine längere Beobachtungsdauer nötig wäre.

  1. Warum sieht man nie einen Wert für “DSTA” und “DAGE”?
    Grundsätzlich könnte das Testflag der Anlass sein - bei ID 33 und 37 kann dies aber nicht der Anlass sein.

Über “DAGE” grübelst du ja gerade nach …

“DSTA” sollte bei einer SNR > 0 mindestens eine 1 zeigen.

Es wäre interessant zu erfahren, wie sich andere Logger, z.B. mit SIRFIII verhalten.


Als nächstes möchte ich mal beobachten, ob die EGNOS-SATs in der Anzahl der ausgewiesenen Satelliten “in view”, bzw. “in use” enthalten sind.

Hattest du schon mal 2 EGNOS-SATs gleichzeitig in use?
Wenn ich den Auszug aus deinen Aufzeichnungen richtig interpretiere - nicht.

Merci - für den Link - werde mal darin stöbern - wird aber angsesichts der 106 Seiten dauern :wink:

Viele Grüße
Dieter

Habe ich bisher nicht beobachtet. Verlaesslich quantitativ kann ich das erst mit meiner gestern provisorisch implementierten Protokollierung sagen. Wobei man hier schon vorsichtig vorgehen muss: Wenn der Logger ca. 1 Minute bis zum FIX=2 braucht, wenn er einen SBAS-Satelliten empfaengt, muss man die Protokollierung anwerfen, und den Logger erst dann in eine Position bringen, die den SBAS-Empfang ermoeglicht – sonst hat man den vielleicht gerade verpasst…

Kann ich bestaetigen. Ich habe im Oktober oder November letzten Jahres (also nach dem 01.10.2009) drei (!!!) Tracks mit FIX= 2 draussen aufgezeichnet, seitdem hatte ich Monate lang nur noch FIX=1, bis vor kurzem. Da ich bis vor kurzem nicht wusste, dass man das Testflag zulassen muss, habe ich die Zeit davor ohne Testflag empfangen. Die drei Tracks waren also ohne Testflag empfangen. Seit ich den Logger umgestellt habe, bekomme ich fast immer FIX=2.

Im der zuletzt zitierten Quelle steht was dazu, welche Indizien(!) es im NMEA0183 (davon reden wir hier ja) gibt, die auf einen EGNOS-Empfang hindeuten. Seite 90ff. Nach der Quelle erhaelt man erst mit NMEA 2.3 verlaessliche Informationen ueber die Verwendung von EGNOS. Ich uebertrage das mal auf die im Speicher abgelegte Information, denn im Speicher wird meines Erachtens nach nicht mehr und nicht weniger Information abgelegt, als der Logger auch via NMEA herausrueckt. Inhaltlich sollte das Aequivalent sein. Wenn es eine EGNOS spezifische Information in DSTA/DAGE bzw. aequivalent im NMEA0183 gaebe, wuerde ich in dem Kapitel auf Seite 90ff eine Aussage dazu erwarten – die fehlt aber. Im Umkehrschluss wuerde ich sagen, dass in den Feldern keine sinnvolle Information zu erwarten ist. Sonst waere das Dokument jedenfalls unvollstaendig…

Ich meine mich ein einen aehnlichen Negativbericht mit SIRF zu erinnern, aus 2005… Hatte ich irgendwie mit Gurgel gefunden.

Im GGA werden bei mir die SAT in use ausgewiesen, auch wenn in einigen Beschreibungen view steht. Genauer: Die Anzahl der Sateliten mit ID <= 32 und mit SNR ungleich 0 / space wird bei mir in den GGA angegeben.

Beim Blick auf die am Bildschirm scrollenden NMEA habe ich maximal einen SAT mit ID > 32 und mit SNR ungleich 0 / space gesehen. Das ist aber keine belastbare Aussage. Meine gestern implementierte Protokollierung erlaubt hierzu leider keine Aussage. Da muss ich das Programm noch etwas erweitern…

Noch ein Nachtrag zu dem Punkt FIX=2 ohne SBAS-Satellit:

Gerade habe ich folgendes protokolliert:

GSV: null; -1; 37; 37; 161; 0
GSV: null; -1; 37; 37; 161; 33
GSV: null; -1; 37; 37; 161; 34
GSV: null; -1; 37; 37; 161; 33
GSV: null; -1; 37; 37; 161; 34
GSV: null; -1; 37; 37; 161; 33
GGA: 194153.000; 1; 37; 37; 161; 33
GGA: 194214.000; 2; 37; 37; 161; 33

Der Logger hat nach dem Einschalten ca. 2 Minuten mehrere Satelliten ganz ohne FIX beobachtet. Dabei war auch die Nummer 37. Daher zunaechst zwei Minuten lang auch kein GGA, weshalb die protokollierten Werte am Anfang keine Zeit haben (so funktioniert mein Programm halt…). Dann ging dafuer aber alles ganz schnell: Er ging innerhalb von 21 Sekunden ueber FIX=1 zum FIX=2. Er sollte also schon im Zustand NO FIX SBAS-Daten empfangen und ausgewertet haben. Vielleicht erklaert das Deine Beobachtung mit FIX=2 ohne SBAS… Allerdings dauert der SBAS-Kontakt bei mir an.

Geloeschtes Duplikat zu #20

Dazu habe ich nun was gefunden: http://www.usglobalsat.com/downloads/NMEA_commands.pdf. Auf Seite 1-2 wird in Bezug auf GGA als Wert fuer die Referenzstation 0000 angegeben.