Verzögerte Positionsbestimmung bei Lassen iQ

>Ich war ja bisher wirklich ein Fan von Trimble (hier nachzulesen!),
aber das ist ja wohl die Höhe!

Wenn das Ding in nächster Zeit ausläuft (und durch etwas
anderes/besseres ersetzt wird), kann ich deren Haltung verstehen.

Dann muß man sich halt etwas langsamer bewegen...

Hi,
woher weisst Du denn eigentlich, dass die Position verzögert rauskommt?
Hast Du eine Referenzposition oder sowas?
Sorry für die blöde Frage :-))

Gruß
AxelR.

@Rahul: Das iQ ist ja selbst noch recht jung. Was ich verdächtig finde:
es sollte ja eigentlich das SQ ersetzen, aber nun haben sie vom SQ wohl
noch einmal eine RoHS-Version gemacht. Seltsam.

@AxelR: Es fiel mir erstmals beim Navigieren auf: wenn ich mir die
Entfernung vom nächsten Kreuzungspunkt anzeigen lasse, war die immer zu
hoch, egal aus welcher Richtung ich kam. An den GIS-Daten lag es also
nicht. Dann habe ich mal eine Vollbremsung gemacht und siehe: nachdem
ich längst stand, ging die Entfernung noch eine ganze Weile runter, bis
sie eine realistische Größe erreichte. Beim Anfahren umgekehrt.
Blöd ist die Frage übrigens nicht: es ist sehr lange gar nicht
aufgefallen. Solange man vor allem Strecken aufzeichnet, merkt man das
praktisch nicht.

Könnte vlt. sein, dass nicht der GPS Empfänger Schultz hat, sondern die
Auswertesoftware einfach nicht hinterher kommt, weil die
NMEA-Inetrvalle a) zu schnell kommen oder b) sämtliche - auch nicht
benutzte NMEA Sätze - ausgegeben werden, die dein "Navi" garnicht
braucht?
Wenn es vorhier schin mal ging - nun?
Lass Dir die Daten von beiden Empfängern aufm Terminal ausgeben. Auf
den Empfänger schieben kann mans immernoch. Allerdings sagtest Du oben,
das das Prob bei trimble bekannt sei, was deine Behauptung nur
bekräftigen würde.
Dann brauchst Du natürlich nichts nachweisen.
Die Idee kanm mir nur, weil ich ebenfalls mit ähnlchen Problemen zu
kämpfen hatte. Bei mir war es die Latenzzeit in der Datenaufbereitung.
Ich hatte eine neue NMEA Routine probiert, die wesentlich
Codeeffizienter war (deutlich kleiner), aber dafür schnarchlahm.
Nun denn...

Viele Grüße

AxelR.

(Huch -- gar nicht bemerkt, daß da noch eine Antwort kam!)
Mit dem NMEA-Parsen bin ich auf der sicheren Seite: ich verarbeite
sekündlich die beiden Datensätze, die ich auch wirklich brauche und der
Controller (ich sollte hinzufügen, daß ich hier nicht auf einem 4-Bitter
hantiere, sondern 100 MHz 32-Bit-Leistung draufwerfen kann) braucht
einen verschwindenden Bruchteil für das bißchen Fixkommaarithmetik.
Aber ich habe schon sicherheitshalber mitprotokolliert, ob nicht andere
Programmbestandteile die Echtzeitverarbeitung gefährden: nein, das ist
es leider nicht.

Zumal noch ein zweiter Effekt auftritt, den ich noch gar nicht erwähnt
habe: meine Bremsmanöver haben die Filter des Moduls total verwirrt,
daß mir das Auto (zum Glück nur in der Aufzeichnung) seitlich ein
großes Stück (bis um die 80 Meter!) von der Straße springen lassen --
ohne erkennbaren Grund. Als ich diese Aufzeichnungen Trimble geschickt
habe, haben sie gar nichts mehr beschönigt ...

Dann wird wohl bald ein FW Update fällig, schön ist das nicht!