"Refreshrate"?

Sorry sollte das schon irgendwo beantwortet sein. Habe die Suche bemüht aber nicht wirklich etwas gefunden.

Zur Frage: Ist die 1 Sekunden-Refreshrate bei GPS eigentlich das (durch die Sateliten) bedingte Minimum oder könnte es theoretisch schneller gehen.
Sprich, wäre es an Hand der von den SATs gesendeten Daten möglich eine höhere Refreshrate zu erhalten?

Die Frage ist wohl hypothetisch, Ich kenne kein Prog-Tool, das eine Einstellung unter 1 sec erlaubt.

Vorstellen könnte ich es mir aber schon. Nur wissen wir nicht genau, was die Maus alles rechnen muss. Das muss sie ja alles in der einen sec machen.

Ja, das ist mir schon klar das es (zumindest für den PPC) kein Tool gibt welches eine höhere Rate erlaubt.
Ebenso das die Frage mehr theoretischer Natur ist.
Es interessiert mich halt ob dieses Limit durch die Satelliten bestimmt ist, durch die Maus, durch die Programmier-Tools, ...

Die Überlegung sind mehrere Punkte:
- 1 Sekunde bedeutet eine nicht zu vernachlässigende Wegstrecke.
- "verpaßt" das Navi einen Datensatz um nur eine Millisekunde vergehen zur letzte Aktualisierung auf dem Display schon min. 2 Sekunden.

Aber wie gesagt, dazu müßte vorerst geklärt werden wo die 1 Sekunde herkommen...

Ich würde mal so sagen: gäbe es kleinere Werte als 1 sec (Verarbeitung durch/in die/der Maus) wäre in einem der Programmiertools sicher dieser kleinere Wert zu finden.

Sinn könnte es machen bei größerer Geschwindigkeit. Obwohl dort wieder "enge" Kurven nicht gefahren werden können, es also auch nicht so viel bringt.

Durch die Sat bestimmt, sicher nicht. Die Posbestimmung ist reine Rechenleistung. Mit entspr. schnellen Rechnern sollten sich Raten unter 1 sec ab er locker erreichen lassen.

Aber man müsste nochmal genauer bei kowoma z.B. nachlesen, ob die Datenübertragung dier Widerholrate einschränken kann.

Zitat

Original von HSVMichi
Ich erinnere noch einmal an das Tool FollowMe!, das meine Geschwindigkeit definitiv öfters als einmal pro Sekunde refreshed hat..

Michi,
wird dabei vermutlich die (letzten2..3?) Sekundenwerte interpolieren. Sonst nichts.
Wolf
...
m.E kommen die Sekundentakte von der Definition des NMEA-Protos.
*edit* nicht zu vergessen:
Das Proto haben _Mariner_ definiert.

Zitat

Original von HSVMichi

Aha. Wenn sowas geht, warum macht MN|4 sowas nicht?

Michi,
vielleicht wird dann der MapCatcher noch komplizierter und langsamer.
(Zur Integration/Interpolation von Orten kommt noch die Dimension Geschwindigkeit hinzu.)
Wolf
...
das sowas geht, sehen wird bei anderen Progs im Tunnel nach Abbruch des GPS-Signals.

Das NMEA Protokoll läßt für z.B. GGA auch Sekundenbruchteile zu.

Siehe hier

Rein theoretisch sollte das Refresh also auch schneller als 1 Hz gehen.

Zitat

Original von DeJe
Das NMEA Protokoll läßt für z.B. GGA auch Sekundenbruchteile zu.

Siehe hier

Rein theoretisch sollte das Refresh also auch schneller als 1 Hz gehen.

Hilf ´mal auf Die Schnelle: (bei dem Wust von Infos)
Wo steht das?
Wolf

$--GGA,hhmmss.ss,llll.ll,a,yyyyy...
"hhmmss.ss" gibt UTC an, hier mit Sekundenbruchteilen.

Aber wie gesagt, ich bin kein Profi in dieser Beziehung und könnte da etwas falsch interpretieren.

Zitat

Original von DeJe
$--GGA,hhmmss.ss,llll.ll,a,yyyyy...

"hhmmss.ss" gibt UTC an, hier mit Sekundenbruchteilen.

DeJe,
ja, aber das sagt m.E. NULL über Refresh/Update-Rate aus.
Es gibt lediglich die genaue Zeit dieser Pos-Berechnng an.
Im Proto gibt´s Infos bis runter in den Mikrosekunden-Bereich; aber refresh????
Wolf
...
ich kann mir Profi-Mäuse vorstellen, die eine deutlich höhere Refreshrate haben, allerdings mit anderen Protokollen. (SIRF??)
NB:
bin auch nur interessierter Amateur.

Aus dem entsprechenden Text-Teil von kowoma:

Modulation der Trägersignale
C/A und P-Code

Die Trägerphasen werden durch drei unterschiedliche Binärcodes moduliert, zum einen dem C/A code (coarse aquisition, grobe Bestimmung). Dieser Code ist ein 1023 "chip" langer Code, der mit einer Frequenz von 1,023 Mhz übertragen wird. Ein "chip" ist im Prinzip das gleiche wie "bit", also eine Eins oder eine Null, der Begriff "chip" wird jedoch hier deshalb verwendet, da das Signal keine Information trägt. Durch diesen Code wird das Trägersignal moduliert und dadurch auf eine Bandbreite der Hauptkeule (also des stärksten Signals) von 2 MHz (P-Code auf L2: 20 MHz) ausgebreitet (Spread spectrum), was die Störungsanfälligkeit verringert. Der C/A Code ist ein pseudozufälliger Code (PRN - pseudo random code), der wie zufällig aussieht, jedoch für jeden der Satelliten eindeutig festgelegt ist. Er wiederholt sich nach jeweils 1023 bit oder einer Millisekunde. Pro Sekunde werden damit also 1 023 000 chips generiert, wodurch sich mit Hilfe der Lichtgeschwindigkeit die "Länge" eines "chips" auf 300 m berechnet.

Auf eine Interpretation möcht ich doch verzichten, da müsste man länger darüber nachdenken und wäre doch nicht sicher, ob man richtig liegt.

Vielleicht gibt es ja auch noch andere Textteile in kowoma, habe jetzt erstmal nicht weitergesucht.

Aber das mit der Millisek. klingt ja nicht so schlecht. Nun ist aber ja nichtr nur 1 Sat berteiligt, sondern immer mehrere, deren Signale ja nun gegeneinander "verglichen" werden müssen...

Etwas Generelles zum Thema Refresh-Rate:
"Wem/Wofür nützt ggfs eine höhere Rate?"
- Schiff: schlecht vorzustellen.
- Auto: dito, (Es gibt ja Progs die sauber navigieren können)
- Flugzeug: zum (kritischen) Landen werden (noch) andere Verfahren eingesetzt.
- Raketen: sollen sich die Militärs d´rum kümmern.
Wolf
...
ich kann mit 1 Sekunde leben, und wenn ich mal einen intelligenten MapCatcher habe,
der das Beschleunigungs- und Brems-Kennfeld meines Fahrzeuges berücksichtigt,
bin ich mit der Positions-Vohersage vermutlich zufrieden.