ZitatOriginal von peterpu
also, heut abend stell ich die Log-Files hier rein - versprochen.
Ich kann aber nur am Fenster aufnehmen, ich hoffe, das wird trotzdem ausagefähig.
<lach>
Hallo Peter,
Dir als altem Hasen empfehle ich jetzt nicht FirstStep zu lesen. ;D
Du weißt selbst, worauf es ankommt.
sodele !
Hiermit löse ich mein Versprechen ein: 
ich hab jetzt mal 4 Logfiles mit verschiedenen Winkeln aufgenommen: 0/ 7,5/ 50/ 90 Grad
Alle sind ca. 30 sec lang und im Abstand von je 1 MInute aufgenommen. Sicht war nur nach Westen, 3 Sats in Use.
Wenn der Fix zu schlecht zum Auswerten ist, mach ich die Logs morgen abend nochmal im freien Feld.
So, und jetzt ran an's Auswerten
Es hat sich aber wieder bestätigt, dass es bei Winkeln deutlich über 7,5 Grad nicht mehr zum Fix kommt. Ich vermute, dass es in der Praxis nicht viel bringt, diesen Wert von 7,5 Grad zu ändern.
Uff! Sottele zurück.
Hallo Peter und alle Interessierten,
es ist in der Tat etwas schwierig, ich kann aber jetzt nicht unbedingt behaupten, dass die Fenster-logs zu schlecht sind. Wenn Du die Zeit hast, vielleicht doch noch mal im freien Feld.
Grob:
Nur bei 0° Werden Daten als valid gekennzeichnet. 3D-Fix, 4 Sat in use
Bei allen anderen Winkeln sind Daten invalid, 7,5°=3 in use, 50° und 90° = 0 in use.
Fein:
Bei 7,5° werden die Sat 04, 07 und 13 mit SigStärken > 0 angegeben, das sind auch die, die als sat in use for fix angegeben sind. Alle Elev.-Winkel sind über 7,5°
Jetzt wird es für mich unverständlich: bei 50° Daten invalid, in use 0, 4 sat werden mit SigStärken angezeigt, davon ist aber nur 1 über Elev. 50°.
Gleiches gilt für 90°.
Es ist vielleicht auch deswegen schwierig kann, muss nicht an der Fenstermessung liegen weil einzelne Sat weiter gewandert sind, dass Pegel auf 0 geht (evtl. halt hinter dem Fenster verschwunden)
Noch was fiel mir auf: bei 0° ist die Höhe - wie bekannt bei nur 4 sat rel. stark schwankend. Bei 50° - nächstes log in der Zeitachse ist sie konst 0, bei den folgenden konst. 341,5 m. Du hast übrigens eine der Mäuse, die die Geoid-Höhe mit 48 m mitliefert.
Wie gesagt, wenn es möglich ist, logs ohne Abdeckung zu erstellen, wäre eine Fehlerquelle weniger.
Ich habe eine Excel-Tab angehängt mit allen 4 Auswertungen untereinander.
Die xDOP-Genauigkeitswerte sind bei 0° wohl real. Bei den anderen stehen sie auf max Ungenauigkeit = 50, mit Ausnahme von 7,5°, da steht VDOP auf 20. Und auch das könnte bei log mit mehr sat sich ändern, weil zumindest bei 7,5° genügend sat für die Verarbeitung vorhanden sein sollten.
Mal sehen ob ich es schaffe, möchte jetzt doch noch den Elev.-Winkel der sats mit in mein Makro aufnehmen. Die Tab wird dadurch leider noch mal 12 Spalten länger und ebenso noch unübersichtlicher, die Auswertung wäre aber etwas leichter.
Soweit erst mal für heute.
Ach, noch was; meine Vernutung, dass die SigStärken der sat, die aus der ElevationsMask herausfallen, auf 0 gesetzt werden. Vielleicht wird jetzt die invalid-Kennung für das Verwerfen der Daten herangezogen (GGA vermutlich oder GSA)
Charly, vielen Dank für die Auswertung, klasse gemacht.
Ich vermute auch, dass die schlechte Empfangslage das ganze etwa vermurkst hat.
Ich fahr heut abend eine viertel Stunde früher los und mach die Logs nochmal mit guter Sicht.
(Und wenn du zum Treffen kommst, können wir's gleich dort auswerten :gap )
so, hier nochmal 5 neue Logs mit gutem Empfang. Ich hab die Winkelabstände etwas verkleinert, die Winkel stehen im Dateinamen.
Charly, vielleicht kannst du nochmal ...?
Hallo Peter,
ja sicher. Kommt. Kann aber Abend werden. Hoffe dass ich es heute noch schaffe.
PS: Das hatte ich u.a. befürchtet, dass es gestern spät zu schneien anfängt. Sorry, das wollte ich mir bei der Entfernung Nachts nicht mehr antun.
Und am 24.3. wird es auch nicht klappen. Hauptsache, es war schön bei Euch.
Es wundert nur etwas, es gibt doch inzwischen auch weiter südlich einige Navis, obk aus der Ortenau z.B. Man könnte - Beteiligung vorausgesetzt - ja auch mal weiter hierher was machen...
Hallo,
Elevations-Auswertung ein erster Versuch.
Anbei das Excel-Arbeitsblatt, diesmal mit 6 Tabellen, den 5, wie sie mit meinem GPSLog inzwischen erzeugt werden und einem Versuch der Auswertung.
Zu GPSLog: dieses Makro wurde von mir geschrieben, um den Inhalt der NMEA-Zeilen ein wenig zusammenzufassen, damit nicht immer in jeder Zeile für die Auswertung abgezählt werden muss. Diese Zusammenfassung steht in der Spalte U bis CG, davon in AU bis CD die Sat in Use, jeweils mit prn-Nr; Elevationswinkel und Signalstärke. Die Winkel sind für die Sat, die im Fix verwendet werden, blassrot, die Sig.-Stärken grün. Soweit sollte das erst einmal genügen.
Die Auswertetabelle stellt noch einmal einen Extrakt dar. Verwendet habe ich die Vereinfachung ist hier wohl zulassig die jeweils erste Zeile der Einzelauswertungen. So ist bei den Winkeln 0 30° zu sehen, welche Sat in die Berechnung aufgenommen sind, warum der 9. (14/28/29) bei 7,5° nicht aufgenommen ist, kann ich nur vermuten: der bisherigen Erfahrung nach, muss die Signalstärke im Schnitt über 30 liegen. Und dieser liegt halt drunter.
Bei 30° sieht man nun recht schön, was die ElavationsMask offensichtlich tut: Die Sat 7,8,10 und 11 (das ist jetzt die Durchzählung in Reihe 4) liegen im Winkel unter 30°. Damit werden sie nicht in Use genommen. Der 9er liegt zwar bei 31°, aber mit einer Sig.-Stärke von nur 16, damit unterhalb der normal auszuwertenden Stärke.
Bei den Winkeln 60° und 90° gibt es nicht mehr genügen Sat für einen Fix. Bei 90° ist das wohl von ´vornherein klar, 90° ist damit ein wohl als unzulässig zu bezeichnender Wert. Bei 60° ist nu noch der 1. (27/73/40) mit 73° innerhalb der Winkel Maske.
Soweit mal der Versuch einer Auswertung. Diskussion erwünscht.
Hallo Charly, vielen Dank!
Ich bin mir absolut sicher, dass diese Interpretation zutrifft.
Der entscheidende Sprung kommt von 30 auf 60 Grad. Das hat man schon beim Aufnehmen in VisualGPSCE erkennen können.
Übrigens kann man auch die kritische Empfangsstärke, bis zu der ein Sat verwendet werden soll, in der RBT einstellen.
Das dürfte aber in der Praxis genausowenig bringen wie die Veränderung des Elevationswinkels.
Resüme ist für mich eigentlich, dass Signale, die nichts taugen, besser ausgeblendet werden.
Somit dürften die Standardeinstellungen für 99 % der User das Optimum darstellen.
Charly, noch eine Anmerkung zur RBT:
Der Geoid-Faktor wird zwar mitgeliefert, wie du richtig bemerkt hast - aber erstaunlicherweise nicht ausgewertet. Die Höhenanzeige in den üblichen Programmmen ist um die bekannten 48 Meter zu hoch.
Das kann ich mir auch noch nicht erklären, bei anderen Mäusen funktioniert das ?
Hallo "Miterforscher" der Sirf-Chips und Herstellerabänderungen
@peterpu: Auch die Holux 230 liefert mit Sirf-Demo ausgelesen den Geoid-Faktor, unter NMEA werden die Höhenangaben glaube ich auch nicht korrigiert.
@hamba: Auf der Sirf-Homepage kann man sich nach unverbindlichem registrieren auch eine PDF-Datei, in der die NMEA-Befehle zum (bescheidenen) Umprogrammieren der NMEA-Ausgaben beschrieben sind runterladen.
@all
Ich stimme Peterpu voll zu, dass die Parameteränderungen für die meisten nichts bringt. Sirf wird sie schon für den typischen Anwender mit oft eingeschränkter Sicht optimiert haben.
Die Elevation-Mask groß zu ändern, kann nicht viel bringen. Setzt man Sie zu hoch, verschenkt man gut sichtbare Satelliten, setzt man sie auf 0 (gehen eigentlich auch negative Werte ? - fällt mir gerade ein), wird die Genauigkeit eher schlechter, da die sehr tief stehenden Satelliten stärker gebeugt und durch Iono- und Tropospähre beeinflusst werden.
Gleiches gilt für die Empfangsstärke. Setzt man Sie herab, wird der Empfänger mehr Fehler beim Tracken machen wie auch eher reflektierte (Mulitpath) Signale mit entsprechender Verfälschung einfangen. Das ist ja auch das Grundproblem aller Xtrac-Empfänger: Physik und Geometrie können auch damit nicht überlistet werden und der Empfang von reflektierten Signalen muss unweigerlich zu deutlichen Positionssprüngen führen. Um das zu "kaschieren" wird dann statistisch "gesmootht" mit dem Ergebnis des Nachlaufens. Ein sicherer Algorithmus, der bemerkt, ob gute oder schlechte Sichtbedingungen sind und quasi automatisch zwischen ST/XT - Modus umschaltet, ist wohl noch nicht implementiert. Das Nachlaufen zeigen die Xtrax Versionen ja auch bei guten Empfangsbedingungen.
MfG R.
p.s.: Empfängt wer von Euch auch den Egnos Satelliten 120 ? Bei mir wird der Status dann auch richtigerweise mit NMEA-Software auf DGPS-Fix gesetzt auch das "Alter" der DGPS-Meldung angezeigt, einzig bei Sirf-Demo werden die PRN-Korrekturwerte im entsprechenden Fenster aber nicht engezeigt.
@rene
ich habe mich auch mal bei SiRF für die Tech. Library registriert. Brauchbares habe ich dort aber nicht gerade im Überfluss gefunden. Die meisten Dokumente beziehen sich auf den SiRFstarI Chip und stammen aus dem letzten Jahrtausend. In Richtung Umprogrammieren über NMEA-Protokoll habe ich allerdings nichts gefunden. Oder hast Du Dich als Entwickler registriert. Dazu muss man aber doch, so wie ich das verstanden habe, entweder ein SDK oder EVK erworben haben oder aber über einen Support Vertrag verfügen.
Wie ich in meinem letzten Posting geschrieben habe, ist meine SoC+ defaultmäßig auf eine PowerMask von 12dBHz eingestellt. Ein derart niedriger Wert lässt sich aber mit der Version 3.41 von SiRFDemo nicht einstellen. So dass ich nicht prüfen kann, was meine defekte SoC macht, wenn ich diese ebenfalls auf diesen Wert einstelle (Default der SoC ist 28dBHz). Allerdings ist wohl davon auszugehen, dass das High Sensitive Feature mehr ist als nur ein extrem niedriger PowerMask Wert.
Dafür hat meine SoC+ aber keinen DGPS (SBAS) Support. Wenn ich die DGPSsource über SiRFDemo auf SBAS einstelle, antwortet meine SoC+ jedenfalls mit einem reject *gr*. Ist das vielleicht ein Tribut an das High Sensitive Feature der SoC+ ??
Meine defekte SoC dagegen hat mit DGPS kein Problem. Ich empfange hier (Nähe Frankfurt/Main) zumindest heute Abend - den Satelliten 131 und bekomme damit einen DGPS-Fix. Sendet meine SoC auf dem SiRF-Protokoll, dann liefert SiRFDemo mit diesem Satelliten auch die entsprechenden Korrekturdaten für die einzelnen GPS-Satelliten.
Bis denn
Hamba
@rene,
auch so hätte ich fast vergessen.
Aus den Reaktionen auf meine Postings (hier) zu dem Thema Abdriften und Nachlauf hier im Forum schließe ich eigentlich, dass ich der einzige bin, der mit der SoC+ diese Probleme hat. Ich habe auch keine Reaktion von anderen Forumsmitgliedern auf mein Posting gesehen, die einen anderen GPS-Receiver mit dem SiRFstarIIe/LP Chip verwenden und ähnliche Probleme haben wie ich.
Auch in dem Forum der PocketGPSWolrd (hier) wird von Dave berichtet, dass z.B. seine Geschwindigkeitsanzeige des GPS beim abrupten Anhalten sofort auf Null geht und kein Nachlaufen vorhanden ist. Also auch dort gibt es offensichtlich viele, die das Problem nicht haben.
Es scheint aus meiner Sicht also kein Grundproblem mit der High Sensitive oder XTrack Technologie zu geben.
Oder habe ich nur den Überblick verloren ?
Gute Nacht und träumt was schönes
Hamba
Hallo Hamba
das Nachlaufen wurde hier sehr oft berichtet, insbesondere mit der Rikaline X7, die ich auch kurz hatte, bevor ich sie wegen der vielen Macken gegen die Holux tauschte (Bei der X7 hinkte die V-Ausgabe so hinterher, dass, wenn eine Ampel vor mir auf Rot umsprang, die Geschwindigkeitsanzeige der Maus etwa dann bei Null "ankam", wenn man wieder losfuhr, weil die Ampel zwischenzeitlich wieder Grün zeigte).
Das SDK habe ich nicht und mich auch nur für die Tech.Libr. registriert. Ich schicke dir die 3 PDF-Files in Dein Postfach (was hoffentlich geht).
Danke für das Ausprobieren des DGPS-SBAS. Dabei fällt mir auf, ich habe Sirfdemo 3.40. Wo gibt es die 3.41 ?
Gruss R.
Hallo Rene,
tjo, die meisten haben aber wohl das Nachlaufen nur aufgrund von langsamen Speicherkarten im Zusammenhang mit dem TTN2. Seit dem Umstieg auf eine andere Speicherkarte waren diese Probleme bei den betreffenden GPSlern dann weg. However.
Besten Dank auch für Deine PN. Die von Dir beschriebenen Dokumente hatte ich, ohne mich vorher zu registrieren, auch bereits von SiRF herunter geladen. Diese Dokumente sind recht interessant und betreffenden die aktuellen Chips. Ich hatte Dein Posting aber so verstanden, als hättest Du nach der Registrierung in der Tech. Library noch weitere interessante Dokumente gefunden.
Die SiRFDemo Version 3.41 habe ich hier im Internet gefunden.
Ich habe bei meiner SoC+ inzwischen auch mal Track Smoothing enabled. Einen Unterschied konnte ich aber im Vergleich zum ausgeschalteten Zustand nicht finden. Ist nicht besser und nicht schlechter. Von einem zusätzlichen Smoothing habe ich nichts bemerkt.
Bis denn
Hamba
