Nachlaufen der GPS-Position wg. zu langsamer Übertragungsgeschwindigkeit

Hallo zusammen,

ich hatte mit meiner SysOnChip GPS CF Plus Model mit z.Zt. neuester Firmware (also SW Version 2.4.12.09-XJCOMC4PROD2.0) ein Problem mit dem Nachlaufen der GPS-Position, der GPS-Geschwindigkeit etc. Da ich glaube, dass andere ebenfalls mal in dieses Problem rein laufen, poste ich es mal hier gemeinsam mit der Lösung.

Das Problem trat bei mir immer auf, wenn mehr als 8 Satelliten in View waren. Die GPS-Ausgabe (Position, Speed, etc.) lief dann auf einmal ca. 10 Sekunden der tatsächlichen Position hinterher. Wohlgemerkt Voraussetzung war, dass mehr als 8 Satelliten "in View" aber nicht zwingend "in Use" sind. Das Problem trat also bei mir auch auf, wenn ich "nur" 6 Satelliten in use aber eben 9 oder 10 in view hatte.

Wenn alle GPS-Unterprotokolle (GGA, GLL, GSA, GSV, RMC und VTG) eingeschaltet sind und dann auch noch auf 1 Sekunde Intervall stehen, fallen innerhalb einer Sekunde bei mehr als 8 Satelliten in View so viele Daten zur Übertragung an, dass die Geschwindigkeit von 4.800 kb/s (Default-Übertragungsgeschwindigkeit) nicht mehr zur Übertragung der GPS-Daten zwischen der GPS-Maus und dem PDA ausreicht.

Im Gegensatz zu dem bereits in dem Thread (hier) beschriebenen Nachlaufproblem, tritt dieses Nachlaufproblem aber halt nur zeitweise - eben während mehr als 8 Satelliten in View sind - auf und das Nachlaufen ist linear. Also nicht von der Geschwindigkeit oder der Richtungsänderung abhängig, wie durch den XT-Algorithmus verursacht. Das Nachlaufproblem konnte ich bei meiner SysOnChip GPS CF Plus einfach durch Erhöhung der Übertragungsgeschwindigkeit auf 38.400kb/s beheben. Eine andere Variante ist natürlich, die Anzahl der GPS-Unterprotokolle zu reduzieren oder einen Teil der Protokolle auf ein höheres Intervall (z.B. GSV auf 5 oder 10 Sekunden) einzustellen. Da ich aber eher zur Kategorie der Sammler gehöre und daher lieber mehr Daten geliefert haben möchte als zuwenig, habe ich das Problem eben durch erhöhen der Übertragungsgeschwindigkeit gelöst. Mein PDA macht dies auch klaglos mit. Allerdings verwende ich auch keine echte Navigationssoftware die ggf. mehr PDA-Performance benötigt sondern nur die MovinMap-SW OziExplorerCE.

Nachfolgend habe ich auch noch ein Diagramm eingefügt, dass die Situation belegt. Zwar kann man hier aufgrund eines fehlenden Referenzwertes das Nachlaufen selbst nicht sehen, dafür sieht man aber die fehlenden VTG-Sequenzen (Magentafarben), wenn mehr als 8 Satelliten in View sind (gelbe Linie).

Bis denn
Hamba

Hallo Spezies,

für Euch : das Problem tritt deshalb erst bei mehr als 8 Satelliten in View auf, weil dann 2 GSV Sequenzen nicht mehr ausreichen, um die Daten aller Satelliten in View zu übermitteln. Da pro GSV Sequenz maximal die Daten von 4 Satelliten übertragen werden können, sind bei mehr als 8 Satelliten 3 GSV Sequenzen erforderlich. Das führt dann entsprechend zu einem höheren zu übertragenden Datenvolumen zwischen GPS-Maus und PDA, welches eben mit 4.800b/s in der gegebenen Zeit nicht vollständig übertragen werden kann. Bei meinen Tests war die VTG Sequenz bei mehr als 8 Satelliten in View nur noch vereinzelt in den Intervallen (bei mir 1 Sekunde) vorhanden. Meistens fehlte die komplette VTG Sequenz.

O.k. diejenigen, die sich das Diagramm genau ansehen, werden feststellen, dass meine Erklärung etwas zu oberflächlich ist. Immerhin dauert es in diesem Fall über 3,5 Minuten, bis die VTG-Sequenzen nach dem 9. Satellit in View ausbleiben. Es scheint also ev. auch die Anzahl Satelliten in Use eine gewisse Rolle zu spielen. Es ist aber auf jeden Fall so, dass es bei nur 8 Satelliten in View keine Rolle spielt, wie viele Sats in Use sind. Selbst, wenn alle 8 in Use sind tritt das Probleme nicht auf.

Meine Faustformel lautet also : wenn alle GPS-Sequenzen (Unterprotokolle) eingeschaltet sind und auf 1 Sekunde Intervall stehen, sollte die Übertragungsgeschwindigkeit auf 38.400kb/s eingestellt sein.

Bis denn
Hamba

Hallo,

es wurde hier vor langer Zeit schon mal gepostet, dass GSV auf 5 sek einzustellen sei, eben wegen solcher Verzögerungen. Das ist ja auch default-Wert einiger Tools, wie z.B. CruxView.

Hallo Charly,

tjo, vor langer Zeit ist ja ganz toll. Nur wenn ich sehe, welche Themen hier in dem Forum mit wöchentlicher oder sogar fast täglicher Regelmäßigkeit diskutiert werden, sollte ein weiteres Posting zu diesem Thema ja wohl nicht weiter schlimm sein. Oder ???

Darüber hinaus ist der Ansatz GSV auf 5 Sekunden zu stellen bei entsprechender PDA-Performance für mich nur der nachrangige Lösungsansatz. Die Übertragungsgeschwindigkeit zu erhöhen ist mir da lieber. Ob die Default-Werte von CruxView eine Aussagekraft bzgl. Optimal eingestellten GPS-Empfängern ist natürlich Ansichtssache - haben, kann und will ich nicht beurteilen.

Aber wenn es allgemeine Meinung ist, dass dieser Thread unnütz ist, könnt Ihr ihn ja rauswerfen.

Bis denn
Hamba

He he Hamba,

wer wird denn gleich so empfindlich sein...

Nein, war nur so ne Feststellung, Meinung. Keine Negativ-Kritik.

Interessiert mich, könntest Du mal 2 logs posten, eines mit der kleinen Baudrate, mit den "Fehlern" und eines mit 38400? Würde mir gerne mal die Unterschiede ansehen.

Ich habe mir noch nicht die Mühe gemacht nachzurechnen, aber es wurde auch schon gepostet, dass in 4800 alle Daten ganz locker passen würden. Muss ich also doch auch mal anfangen zu rechnen.

Hallo Hamba,
deine Beobachtung kann ich zumindest teiweise bestätigen. Als ich noch mit meinen Mäusen rumexperimentiert habe ( ), hatte ich bei GSV = 1 ziemliches Hinterherhinken der Position bei TomTom. Durch GSV=5 war das Problem sofort wieder behoben. Dies trat übrigens bei einem normalen Chipsatz auf, also nicht x-Track.
Ich halte allerdings die Empfehlung, GSV auf 5-Sekundentakt zu setzen, für besser als die Geschwindigkeit hochzusetzen.
Warum? Der Nutzen einer sekündlichen GSV-Übertragung scheint mir gering. Die Anzahl der Sats in View ändert sich doch nicht sekündlich, da reichen 5 Sekunden. In jedem Fall reduziert die Absenkung dieses Protokolls die erforderliche Performance, nicht nur vom PPC, auch von der Maus. Ob das in der Praxis relevant ist, weiss ich allerdings nicht. (Übrigens empfiehlt nicht nur CruxView den 5-Sek-Takt für GSV, aus dem Stand fallen mir da noch GPSMaus und BlueGPS ein).

Ob eine Erhöhung der Übertragungsgeschwindigkeit nicht auch nachteilige Auswirkungen hat, weiss ich auch nicht - würde es aber mal nicht ausschliessen. Immerhin müssen doch wesentlich mehr Daten durchgesetzt werden, und das für eine Information, die für Navigation zumindest für mein Verständnis nicht die wichtigste ist.

Hier für alle, die das Thema auch interessiert, nochmal die Definition des GSV-Satzes (aus kowoma) :

Zitat

Der GPGSV-Datensatz (SV=satellites in view, sichtbare Satelliten) enthält Informationen über Satelliten, die zur Zeit möglicherweise empfangen werden können und Informationen zu deren Position, Signalstärke usw. Da pro Satz nur die Informationen von vier Satelliten übertragen werden können (Beschränkung auf 82 Zeichen), kann es bis zu drei solche Datensätze geben.

Hallo Peter, Charly und alle die es lesen,

ich bestehe ja nicht darauf, die Geschwindigkeit hoch zusetzen. Schließlich hatte ich in meinem ersten Posting ja auch schon erwähnt, dass auch GSV auf 5 Sekunden oder höher hochgesetzt werden kann. Wenn allerdings jemand eine Navi- oder sonstige GPS-Software einsetzt, die diese Informationen entweder gar nicht verarbeitet oder diese für den User uninteressant sind, dann würde ich GSV lieber komplett abschalten also auf 0 Sekunden Intervall. Ist also Geschmacksache und soll jeder machen, wie er will. Wenn derjenige aber gelegentlich die GPS-Daten auch mitloggt um diese später auszuwerten, dann machen sich in der Log genaue Informationen über den jeweiligen Status der Satelliten ausgesprochen gut. Und wer denkt dann schon daran, wenn er die Log mitlaufen lassen will, vorher mal eben GSV auf 1 Sekunde zu stellen. Und wenn er das tatsächlich tut, dann muss er auch die Speed hochdrehen oder er darf nur loggen, wenn nicht mehr als 8 Satelliten am Himmel zu sehen sind.

Darüber hinaus gibt es für mich folgende Gründe, doch lieber die Geschwindigkeit anzupassen, wenn alle GPS-Daten ausgegeben werden soll :

1.) sollte jeder einigermaßen aktuelle PDA auch mit einer Übertragungsgeschwindigkeit von 38.400kb/s Performancemäßig zurecht kommen. Schließlich gibt es ja auch User, die mit Ihrem PDA über eine serielle Verbindung zum Handy auch mal im Internet surfen. Nutzt man dafür die Möglichkeiten von GSM-Netze der 2,5. Generation also HSCSD oder GPRS dann kommt man durchaus auf ähnliche Übertragungsgeschwindigkeiten. Von WLAN das ja sogar in div. PDAs bereits eingebaut ist will ich gar nicht erst reden (Speed 10Mb/s).

2.) wenn es mit 4.800b/s im Sekundenintervall zu eng wird, dann wird es doch auch bei GSV auf 5 Sekunden alle 5 Sekunden zu eng. Oder ?? Schließlich fallen dann ja alle 5 Sekunden ebenso große Datenmengen an, die wohl nicht wirklich bis zum nächsten Sekundenintervall abgearbeitet werden können. Das wirkt sich dann halt nur nicht sichtbar bzw. spürbar ?? aus. Oder vielleicht doch ??

3.) ich habe hier schon Postings gelesen in denen steht, dass es GPS-Mäuse gibt, die werksseitig 38.400kb/s als Default eingestellt haben !!!!

4.) mit welcher Speed laufen eigentlich die Bluetooth Mäuschen ??

Also mir fallen absolut keine nachteiligen Auswirkungen einer höheren Speed ein. Einen einigermaßen aktuellen PDA und eine nicht zu träge GPS-Maus vorausgesetzt. Andere als SiRF Star II Chipssätze (wie Everymore u.a.) kann ich allerdings absolut nicht beurteilen.

Ich habe meine SysOnChip jetzt seit Anfang April mit der Geschwindigkeitseinstellung 38.000kb/s am laufen. Tw. nutze ich parallel zum GPS auch RunningVoice auf dem PDA. Dabei steht RunningVoice dann permanent über Bluetooth mit dem Handy in Kontakt. Auch in dieser Situation habe ich keinerlei Probleme ausmachen können. Wobei mein iPAQ 3970 auch nicht mehr der jüngste ist und immer noch unter PocketPC 2002 läuft.

Das Problem kann ich sowohl bei meiner SysOnChip GPS CF Plus also High Sensitive (von mir aus auch X-Track) als auch bei meiner normalen SysOnChip CF Plus nachstellen.

@Charly
Wenn Du nachrechnest, wirst Du feststellen, dass es rechnerisch eigentlich kein Problem geben dürfte. Es fallen ca. 480 Byte pro Sekunde an. Das entspricht einer erforderlichen Übertragungsbandbreite von ca. 3.840b/s. Vom Übertragungsvolumen her passt das also.
Offensichtlich spielt also der Prozessor der Maus oder vielleicht auch die Firmware noch eine entsprechende Rolle. Es scheint so, also wäre der Prozessor während der Übertragung der GPS-Daten nicht in der Lage andere Aufgaben zu erledigen. Aber das kann nur ein wirklicher Mäuslebauer solche sollen sich ja hier im Forum ebenfalls tummeln beurteilen.

Wie auch immer : ich habe die Speed hochgedreht und damit das Problem abgehackt. Da ich zur Gattung der Sammler und nicht der Jäger gehöre, freue ich mich jetzt über die vielen Daten in meinen Logs. Die sehe ich mir in der Masse zwar nie wieder an, aber was solls ;-).

Bis denn
Hamba

Hallo Charly,

anbei ein ZIP-File mit zwei NMEA-Loggings. Die Log vom 26.3.2004 wurde mit 4.800b/s aufgenommen und weist das Problem auf. Die Log vom 2.4.2004 wurde mit 38.400b/s aufgezeichnet und hat das Problem nicht.

Bis denn
Hamba

Hallo Charly,

hast Du Dir eigentlich inzwischen die Unterschiede der beiden Logs ansehen können ? Mich würde Dein Statement interessieren.

Bis denn
Hamba

Hallo Hamba,
Charly ist im Urlaub, bitte warte noch etwas.
Er kann das einfach am besten.