EGNOS senden die jetzt oder nicht ?

  • Nur mal als kleiner Hinweis an alle EGNOS-Freaks. Auf der ESA-Website kann man sich das Programm SISNetlab herunterladen (Achtung - massives Klumpentool -> 83MB!), welches die gesendeten und gespeicherten EGNOS-Messages herunterlädt und grafisch darstellt. Das Lustige ist nun, daß dieses Progi der ESA die MT0/2 Geschichte auf PRN120 und 126 selbst nicht versteht.


    Wenn man sich beispielsweise die Messages der letzten Stunde (h18.ems) ansieht, dann fehlen die Fast-Corrections (vorher auf den Button "UDRE" klicken) für die ersten 13 GPS-SVs in der Grafik, wenn man die Sats 120 oder 126 als Quelle auswählt. Wählt man die Messages von PRN 124 für diese Zeit aus, dann erscheinen die FC (Fast-Corrections) als rote Linien für PRN 1, 2, 5, 6 ,7, 10 in der Grafik. Fast alle diese SVs standen oder stehen noch sichtbar am Himmel.


    Danke nochmal an Charly, für den Hinweis auf dieses nette "Spielzeug" der ESA.



    bfn hevo2


    PS: Ah - jetzt ist Charly da! Dann warte ich mal noch etwas mit dem "ins Bett gehen"....

  • Zitat

    Original von hevo2




    PS: Wo ist eigentlich "Ober-EGNOS-Fan" Charly heute? Sic - wenn man mal jemanden braucht, der mal schnell 'ne Maus aus dem Fenster hält... ;)


    Wandern. Col des Bagnelles - Haicot.


    War sehr schön, und von dem, was Ihr hier austauscht verstehe ich momentan nur Bahnhof.... :gap


    Muss ich mal sehen, SirfTech zu laden und schauen, ob eine meiner BT-Mäuse damit zurecht kommt. Ob das allerdings diese Wo noch klappt, kann ich nicht versprechen.


    Hallo hevo2,


    ich müsste Dich rel. dringend mal sehen. Diese Wo ist allerdings schlecht. Ich muss mal etwas mit "sichtbaren" Beispielen aufgenordet werden, im Gegenzug kannst Du Dir die Infos die die CR4 liefert ansehen. Wäre ja schön, wenn ANTARIS und SiRF vergleichbare Daten liefern würden.


    Und keine Ursache für das "Spielzeug"... :]

  • Zitat

    Original von karomue
    War sehr schön, und von dem, was Ihr hier austauscht verstehe ich momentan nur Bahnhof.... :gap


    Das ist eigentlich ganz einfach zu verstehen, wenn man sich auf die dahinterstehende Logik einläßt. Ich unternehme jetzt mal den armseeligen Versuch einer Erklärung.


    MT0 war damals beim Test von WAAS in den USA eigentlich nur dazu bestimmt, den Testbetrieb des ganzen Systems zu signalisieren, also den Usern zu sagen: "Vertraue den Daten nicht, solange du auch MT0 empfängst!"


    Für die FCs (letztmalig ausgeschrieben: Fast-Corrections) sind MT2-5 zuständig. Jede dieser Messages beeinhaltet FCs für 13 SVs. MT2 also von PRN 1-13, MT3 für PRN 14-27 usw. MT5 wird praktisch nicht gesendet, da die GPS-PRNs nur bis 31 reichen und damit durch MT4 abgedeckt sind.


    Die Übertragung erfolgt mit 250 Bit/s, d. h., daß das Senden einer einzigen Message eine Sekunde dauert.


    Das ganze System lebt nun von der kontinuierlichen Wiederholung aller definierten Messages innerhalb einer bestimmten Zeit. Manche Messages müssen öfter gesendet werden (MT2-5), manche nur selten MT 1 (PRN-Mask - die ändert sich selten).


    Nun, wenn sich das System im Testbetrieb befindet, dann muß auch immer MT0 mit untergebracht werden. MT0 enthält aber eigentlich "Nichts" (alles Nullen wie bei PRN124). Die Übertragung dieses "Nichts" kostet aber eine wertvolle Sekunde.


    Es liegt also nahe, MT0 zwar zu senden, um damit allen Usern den Testbetrieb zu signalisieren, man kann diese Message aber auch mit dem Inhalt von MT2 "vollpacken" (und damit die FCs für PRN1-13 übertragen). Dafür kann man sich dann das separate senden von MT2 sparen (was wiederum eine Sekunde dauern würde) und schlägt damit zwei Fliegen mit einer Klappe: Signalisierung des Testbetriebs und FCs für die ersten 13 SVs.


    Ist eigentlich ganz einfach, nur leider "vermissen" dann einige Empfänger MT2 und können die Korrekturen der ersten 13 GPS-SVs aus MT0 nicht extrahieren. Genauso wie das ESA-Tool, welches mit FCs in MT0 auch nix anfangen kann.


    So ungefähr läuft der EGNOS-Hase im Moment. Weiterführende Hinweise dringend erbeten! Ich weiß auch nur das, was man sich mühsam im Net zusammensuchen muß und mache mir einen "Reim" drauf!



    Zu MT0/2 siehe auch die (mageren) Ausführungen vom Mai 06 in
    http://esamultimedia.esa.int/d…20FAQ%2017%20May%2006.pdf


    Wenn ich das richtig verstehe, dann muß MT2 irgendwann (spätestens nach Ende des Testbetriebs von EGNOS) wieder gesendet werden, sonst empfangen unvorbereitete Empfänger keine FCs für die ersten 13 SVs.




    Zitat

    Original von karomue
    ich müsste Dich rel. dringend mal sehen. Diese Wo ist allerdings schlecht.


    He he he, Schatz! :D Am Wochenende? Muß ja nicht der Lenzenberg sein. *zwinker - zwinker*



    Guts Nächtle
    hevo2

  • Code
    1. ARTEMIS (PRN 124; ID 37)
    2. Inmarsat AOR-E (PRN 120; ID 33)
    3. Inmarsat IOR-W (PRN 126; ID 39)


    verstehe ich das richtig, wenn ich einen der drei satelliten sehe, dann wird auch das referenzsignal verarbeitet und zur korrektur herangezogen? also ich sehe direkt ob egnos benutzt wird oder nicht?


    ich habe den holux236, da ist ein programm dabei (gpsviewer), da muß man erst egnos aktivieren. wird das egnos-signal auch in anderen gps-programmen verwendet auch wenn diese programme kein extra "egnos-einschalten"-button haben? ich verstehe nicht warum man in gpsviewer erst egnos aktivieren muß, warum ist das nicht schon von der grundeinstellung aktiviert, und ist egnos dann beim aus- und wiedereinschalten der gps-maus, wieder deaktiviert? ich werde daraus irgendwie nicht schlau.


    sorry, wenn ich im falschen bereich gepostet hab, aber ich brauche beruflich möglichst genaue koordinaten und weiß nie 100%ig ob ich ein korrektursignal empfange oder nicht.

  • mit dem einschalten von egnos ist es bei meinem 236 nicht getan, ich muss auch noch mit sirftech sbas auswählen ( lies mal eine seite vorne dran)


    das das von haus aus nicht an ist, macht schon sinn, solange der nutzen auf der erde nicht bewiesen und das system im testbetrieb ist, lass ich das auch mal aus. bedenke das system in erster linie für die luftfahrt gemacht wurde.


    die dgps korrekturdaten werden erst mit einbezogen wenn beim fix dgps dabei steht !



    sulzi

  • um mal am thema von gestern abend weiter zu machen
    ich hänge jetzt am 126er mit einem dgps fix


    und die korrektur zeigt folgendes an:


    sv cor age
    7 -7 2
    9 -8 2
    14 -6 2
    6 -4 2
    2 -5 2
    1 -5 2


    edit1: die satnummern gehen bis 30 aber er scheint nur bis 14 zu korrigieren
    edit2: kommando zurück, ab und zu, aber eher selten komen noch mehr korrekturwerte für ein paar zyklen
    edit3: mittlerweile wird auch er sv25 stabil korrigiert



    4 -7 1
    9 -10 1
    6 -4 1
    2 -5 1
    25 -5 1
    1 -4 1



    ich kann das aber nur mit sirftech auslesen, am notebook mit sirfdemo, zeigt er auf dem messagekanal bzw in dem dgps messagefenster nichts an, weil es der 29er statt der 27er kanal ist.


    edit4:
    ich habe festgestellt, das er nur 6 korrekturwerte liefert, obwohl 12 sats in view und 10 in use waren. mann müsste das jetzt mal an den gesendeten messages spiegeln.



    sulzi

  • Hallo sulzi!


    So wie es aussieht versteht (d)ein SiRFIII MT0/2. Das stimmt mich schon mal froh.


    Zitat


    ich habe festgestellt, das er nur 6 korrekturwerte liefert, obwohl 12 sats in view und 10 in use waren. mann müsste das jetzt mal an den gesendeten messages spiegeln.


    Einen ähnlichen Verdacht hatte ich auch schon. Was Egnos zu einem gewissen Zeitpunkt gesendet hat, lässt sich feststellen. Was zu diesem Zeitpunkt im Logfile steht bzw. durch SirfDemo oder SirfTech angezeigt wurde, kann man auch extrahieren. Das Problem ist also von meiner Seite her auch be- und erkannt, es ist aber einfach noch zu früh, um eine Theorie in die Welt zu setzen, da ich mir erst ein paar kleine Werkzeuge basteln muß, denn ein Logfile im Sirf-Format im Hexeditor anzugucken, ist nicht besonders fruchtbringend.



    bfn hevo2

  • Hallo


    auch wenn es im Moment eigentlich nix neues zu EGNOS zu berichten gibt, so denkt die ESA doch an uns und verkürzt/süßt uns die die Zeit des Wartens mit neuer Software.



    Seit einigen Tagen (offenbar aber seit dem 11.12.06, denn zu diesem Zeitpunkt wurde die entsprechende Website angelegt/aktualisiert) gibt es ein neues Klumpentool (Download: 9,8MB; auf der Festplatte gut 40MB) zum Spielen: "SBAS TeACHER".


    Komischerweise taucht dieser Begriff noch nicht in den Newsgroups bei Google auf


    http://news.google.de/news?q=%22sbas+teacher%22


    was aber IMHO nicht weiter verwunderlich ist, da der Link darauf auf der ESA-Website etwa versteckt ist. Aber okay - hier ist er:


    http://esamultimedia.esa.int/d…asteacher/sbasteacher.htm



    Was macht das Tool?


    Nun - das steht auf der Website. ;)


    Was aber viel wichtiger ist - zumindest für die absoluten "SBAS-Freaks", ist die Tatsache, daß man damit den heute offiziell gültigen (und ansonsten kostenintensiven) WAAS/EGNOS-Standard praktisch "frei Haus" bekommt.


    Dazu muß man sich nur ein EMS-File (siehe SisNetlab weiter oben) vom ESA-Server schnappen und etwas mit diesen Zahlenkolonnen spielen. Natürlich muß dabei die CRC am Ende der Zahlenkolonne stimmen, wenn man die Message per Hand ändert.


    Dieses alte PDF (dessen Namen ich gerade vergessen habe), welches irgendwo im Net rumgeistert und der Vorgänger des "RTCA/DO-229C"-Standards ist, kann man damit zu den Akten legen. EDIT: dieses alte PDF dient heute also nur noch dazu, um sich überhaupt (und kostenfrei) in die Materie einzulesen und die Zusammenhänge zu verstehen. Wenn man dieses PDF durchgearbeitet hat, versteht man auch die Internas des "SBAS TeACHER" - also die neuen oder abgeänderten Messages, die von EGNOS gesendet werden.



    Viel Spaß
    hevo2

  • Hi, Hevo2,
    ich habe den TeACHER ausprobiert; was micht kirre gemacht hat, war dies CRC, es gedauert, bis ich dahinter gestiegen bin.
    Allein der Fox hat gezickt, so dass ich mit dem IE die FTP-Seiten öffnen musste.


    Die letzten 64 Zeichen des Datensatzes in den Teacher kopieren, und er dekodiert. Sobald die CRC nicht stimmt, ist der Hintergrund der Eingabezeile rötlich.


    Da man auch encodieren kann, wäre es bestimmt interessant, einen selbst erstellten Datensatz an ein GPS zu senden.


    Hevo, die Korrekturdaten, die die Egnos-Satelliten aussenden, kommen die von den einzelnen Bodensationen, z.B. von Darmstadt?


    Es war für mich recht interessant, mit dem Teacher einige Datensätze zu lesen und auch mit dem Encoder zu spielen, aber solange ich die praktischen Auswirkungen nicht von meinem GPS-Gerät ablesen kann, belasse ich ich es jetzt bei nicht mehr so grauen Theorie.


    Ich hoffe, dass Du zu gegebener Zeit mal einen Abriss über Deine praktischen Erfahrungen zu den "Auswertungen" der EMS-Files zum Besten gibst.



    Gruß
    Günther

  • Hallo Günther!


    Ich muß sagen, daß ich es richtig gut finde, wie du dich "dahinterklemmst". Deine Postings (ich hab mir einige angesehen) lassen erkennen, daß du schon sehr viele Websites gelesen hast und halt versuchst, "Eins und Eins" zusammenzuzählen. Das einzige was ich wirklich nicht mag ist, wenn man wissentlich (aus Faulheit) 312 mHz, anstatt 312 MHz schreibt. Zwischen beiden Frequenzen besteht ein gewaltiger Unterschied.


    Ehrlich gesagt - ich versuche auch nur all die Puzzleteile zu einem Bild zusammenzufügen - ich bin also auch nicht unbedingt schlauer.


    Leider fehlt mir im Moment auch etwas die Zeit für das Hobby "GPS". An einen "Abriss" über die ganze EGNOS-Geschichte oder einer "Erkärung" des SiRF-Protokolls, wie vor einiger Zeit von Bab/Charly vorgeschlagen, ist nicht zu denken. Ich weiß wirklich nicht, wie ich das machen soll.


    Ich gebe dir aber mal einen Link, der dir hoffentlich etwas weiterhilft:


    http://www.google.de/search?q=…heric+pierce+point+%22+mt


    Schon das erste PDF aus Dänemark beantwortet (hoffentlich) die Frage, "wie die Daten aus Darmstadt" in Egnos eingehen. Dieser "Ionospheric Pierce Point" ist dazu der Schlüssel.


    Have fun!


    bfn hevo

  • Hi,
    ich habe am 7.3. EGNOS-Signale empfangen, mein Garmin ist mit 3 Korrektursignalen (D's im Anzeigebalken) für ca. 5 Min. in den 2-D-Differenzial-Modus gegangen. Ein 4. Signal tauchte nicht auf, der Satellit Nr. 33 (Garmin) hatte gute Pegel.
    Auffällig war, das bei 2 Signalen der Accuracywert auf 2 m ging, bei 3 Signalen dann 25 m zeigte.


    Ich glaube nicht, das EGNOS jemals brauchbare Werte liefern wird. Die werden testen, bis GALILEO kommt, und ich wette, bevor GALILEO läuft, hat China sein GPS-System schon längst gestartet.


    Gruß
    Günther

  • Hallo Günther und alle anderen EGNOS-Fans!



    Charly hat es letztens in einem anderen Thread etwas bedauert, daß seine eigenen EGNOS-Beobachtungen etwas ins Hintertreffen geraten sind. Ich schließe mich da einfach an, denn es gab in den letzten Monaten eigentlich nichts wirklich wichtiges zu berichten. Und wir sind ja auch nicht die Einzigen, die auf EGNOS warten und "aufpassen". Ich verweise jetzt einfach mal auf den Artikel


    http://www.gpspassion.com/fr/articles.asp?id=185


    die Diskussion


    http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=54188


    und die durchaus niederschmetternden Ergebnisse aus dem letzten Sommer. Diese Ergbnisse haben wir hier im Forum aber auch schon gesehen.



    Wenn das Wetter mitspielt, werde ich in den nächsten Wochen meinen SS3 (SiRF Star III) aber auch wieder öfters "in den Wind" halten und auf EGNOS-Jagd gehen.



    Sodele - das war nur Vorgeplänkel. Der eigentliche Grund dieses Postings ist ein anderer. Günther schrieb


    Zitat


    ...mein Garmin ist mit 3 Korrektursignalen (D's im Anzeigebalken) für ca. 5 Min. in den 2-D-Differenzial-Modus gegangen. Ein 4. Signal tauchte nicht auf, der Satellit Nr. 33 (Garmin) hatte gute Pegel.
    Auffällig war, das bei 2 Signalen der Accuracywert auf 2 m ging, bei 3 Signalen dann 25 m zeigte.


    Ich kenne mich mit Garmins nicht weiter aus, weiß aber, daß ein "D" im Pegelbalken eines Sats auf eine Korrektur der Pseudorange durch SBAS hinweist. Garmins sind aber wirklich nicht mein "Fachgebiet".


    Ich denke, daß ich mich mit SS3 etwas besser auskenne und will in diesem Zusammenhang auf mögliche SBAS-Probleme bei SS3 aufmerksam machen.


    Wenn SS3-User in der Vergangenheit SBAS eingeschaltet haben, dann geschah das, indem man zunächst "Testing" beim SBAS zugelassen hat. Genaugenommen war das schonmal falsch - wir waren aber alle froh, daß der Receiver überhaupt in den DGPS-Mode gegangen ist.



    Das ist aber noch nicht alles. Damit der Empfänger nach DGPS schaltet haben wir bei MID 138 (DGPS-Control) "Auto" gewählt. Laut "SiRF Binary-Protocol" bedeutet das:


    "Auto = use corrections when available"


    "Besser" wäre eigentlich


    "Exclusive = include into navigation solution only SVs with corrections"



    Falls der "kleine" Unterschied noch nicht klar ist, hier die entsprechende Stelle aus der "Bedienungsanleitung" von SiRFDemo (SiRFfDemo_User_Guide.pdf):


    Zitat


    Automatic - Use differential corrections when they are available, otherwise compute a non-differential solution. (See the Note that follows.)


    Exclusive - Only compute a differential solution. When no corrections are available, no solution is output.



    Und hier ist die "Note that follows":


    Zitat


    Note For a differential position to be calculated, there must be pseudorange corrections for every pseudorange used in the solution. When pseudoranges are without corrections and the GDOP improves by two by using all pseudoranges, the solution does not use available corrections.


    Sinngemäß übersetzt:
    Wenn eine DGPS-Position berechnet werden soll, müssen PR-Korrekturen für alle in der Solution benutzten PRs vorliegen. Sollte es PR ohne Korrektur geben und sollte sich GDOP bei Benutzung aller PRs verdoppeln (ich hoffe, daß ist richtig übersetzt), werden für die Solution keine Korrekturen benutzt.


    Wer kann, möge das bitte besser übersetzen.


    Ich habe das "Exclusive" bisher nur einmal ausprobiert und sofort war der Fix weg. Rein von der Theorie ist es natürlich besser, nur korrigierte Sats in den Fix einzubeziehen. Nur muß EGNOS dann "mitspielen" und auch die Daten liefern...


    Wir testen und warten also weiterhin.



    bfn hevo2