GPS Modul für Motorsport, Entscheidungshilfe

[ssquare_de]

Hallo Peter,


sehr schön, dass du uns auf dem Laufendem halten wirst!

Bis dahin wünsch ich dir viel Erfolg und lauter gute Ideen.



Stefan

[peterguy]

Hallo zusammen,

die erste Versuchsfahrt ist geschafft.
Leider ist das Ergebnis ziemlich ernüchternd, denn die Genauigkeit des Systems lässt stark zu wünschen übrig!

Auf langen Geraden mit freier Sicht funktioniert noch alles super und auch mit der erreichten Genauigkeit kann man sehr gut leben.
Teilweise kann man sogar Spurwechsel auf der Autobahn nachvollziehen, was mich sehr positiv Überrascht hat. Auch die 10Hz Erfassungsrate sind mehr als Ausreichend.

Leider, leider lässt das Gerät einen aber in Kurven komplett im Stich Ich habe einmal den NMEA Datenstrom mit der Autobahnauffahrt hier im Dorf angehängt (Ca. Mitte im Logfile).
Da stimmt echt garnichts dran, weder Geschwindigkeit noch die gefahrene Strecke.
Im weiteren Verlauf der Aufzeichnung sieht man auch noch die Genauigkeit auf der Autobahn, die ja wie gesagt recht gut ist.

Die Kurve ist übrigens keine Ausnahme, alle schneller gefahrenen Kurven werden verzerrt. Ich habe fast den Eindruck, je schneller die Kurve durchfahren wird (Querbeschleunigung), um so ungenauer wird das Ganze.
Diese Woche werde ich einmal versuchen, Daten mit niedriger Frequenz aufzuzeichnen, z.B. 1Hz. Vielleicht wirds dann ja doch noch genauer.

Die NMEA Daten habe ich übrigens mit GPSBabel ins KML-Format übersetzt und dann in Google Earth dargestellt. Ich vermute das hat keinen Einfluß auf die Genauigkeit, oder?

Viele Grüße,
Peter

[ssquare_de]

Hallo Peter,



ich hab mir heute früh mal kurz dein NMEA-Log mit u-center angesehen.
Eines ist mir aufgefallen:
Über gut die Hälfte der Logzeitspanne verwendet dein Venus nur 6 Sats zur Positionsberchnung, 4-5 Sats werden zwar getracked, aber nicht zu Positionsberechnungen herangezogen, obwohl die nach Kurzcheck in GoogleEarth gut sichtbar sein müssten...darauf deutet auch die konstant hohe Signalstärke in u-center hin.
Vermutlich hast du dein GPS-Board eingeschaltet ( Kaltstart) und bist kurz nach erstem 3D-Fix losgefahren. Da waren aber vermutlich noch nicht alle Almanach/Ephemeriden-Daten eingelesen.
Hast du an deinem GPS-Board eine Stützbatterie angeschlossen, die die Daten nach dem Abklemmen von der Hauptspannungsversorgung puffern kann?
Wenn nicht, musst du bei jedem Einschalten des Boards den Venus bei guten Empfangsbedingungen bis zu 12-20 Min. die Daten sammeln lassen, bevor du das Loggen startest.

Wegen der geringen Empfängerdynamik in schnellen Kurven: ich habe mir mal die Venus-Protokolldoku ( Binary Command Set auf Watterotts Website) angesehen:
SKYTRAQ bietet eine Input-Message "Configuration navigation mode" an, die du auf "Pedestrian" oder "Car" setzen kannst. Damit kann , je nach Einsatzgebiet, Einfluss auf die Empfängerdynamik genommen werden.
Steht die Einstellung bei dir auf "Car"?

Frage da mal beim Hersteller nach, ob dieses PDF-File ALLE Konfigurationsmöglichkeiten benennt, und vergewissere dich, ob die neueste Firmware aufgespielt ist?
( U-Blox bietet da bei seinen Receivern anscheinend feiner abgestufte Konfigurationsmöglichkeiten bei der Wahl der geeignetsten "Dynamic-Platform". )

Also, vor den nächsten Versuchen die "Car"-Einstellung sicherstellen und den Empfänger im Vorfeld des Loggings den Almanach/die Ephemeriden komplett einlesen lassen...

Das ist das, was mir momentan dazu einfällt.




Stefan

[Jörn Weber]

Hallo Peter,

Da stimmt echt garnichts dran, weder Geschwindigkeit noch die gefahrene Strecke.

Aus welchem NMEA-Datensatz nimmst Du die Geschwindigkeitsdaten? Ich würde die aus dem $GPVTG-Datensatz verwenden wollen und daraus die Strech anhand der zeit zwischen zwei Trackpunkten zurückrechnen wollen. Warum? Der $GPVTG liefert bei den meisten Chipsätzen die per Dopplerefekt gemessene Geschwindigkeit. Auch die Uhr des Empfängers ist hinreichend genau.
Die anderen Datensätze liefern oft, die aus der Entfernung zwischen zwei Punkten und der Zeit errechnete Geschwindigkeit. Das heißt in Kurven erhältst du die über eine Sehne der Kurve berechnete Geschwindigkeit und nicht die anhand der tatsächlich zurückgelegte Strecke berechnete Geschwindigkeit. Ein Restfehler bleibt dann immer noch, das du auf dieser Weise nur die horizontale Geschwindigkeit erhältst und nicht die Geschwindigkeit bezogen auf den tatsächlichen dreidimensionalen Streckenverlauf.

Gruss Joern Weber

[peterguy]

Hallo zusammen,

also ersteinmal vielen Dank für die ausführlichen und sehr hilfreichen Erklärungen.
Stefan hat natürlich recht mit seinem Verdacht, daß ich kurz nach dem 3D-Fix losgefahren bin.

Also habe ich gestern die selbe Route nochmal unter die Räder genommen, aber diesesmal das GPS-Modul eine halbe Stunde vorheizen lassen.
Da ich leider keine Stützbatterie vorgesehen hatte (wird noch geändert!!), scheint das im Moment leider noch notwendig zu sein.

Im Anhang wieder ist ein Auschnitt der Tour, diesmal ist sehr schön zu erkennen daß auch Kurven genau aufgezeichnet werden. Mit der jetzt erreichten Genauigkeit kann man ganz gut leben glaub ich.
Probleme gibt es nur an schattigen Plätzen und in Häuserschluchten, was natürlich zu erwarten war.
Ob das Modul im Pedestrian oder Car modus ist habe ich noch nichtabgefragt, es sieht allerdings so aus als wäre der Car Modus die Standardeinstellung.

Ich habe trotz der guten Ergebnisse mit Skytraq Kontakt aufgenommen und nach "nichtdokumentierten Features" gefragt.
Es kam sehr zügig eine Antwort, in der von einem Firmwareupdate die Rede war. Mit diesem kann eine Rohdatenerfassung von 1Hz errreicht werden.
Ausserdem war von einem Modul S1315F die Rede, daß bis zu 20Hz Roh-Datenausgabe unterstüzt.

Leider habe ich über das S1315F keinerlei Informationen finden können und meine Frage nach Verfügbarkeit ist bisher noch unbeantwortet.
Ist euch dieses Modul schon mal untergekommen?

Die laut Datenblatt ausgegebenen Rohdaten beinhalten u.a. folgende Werte:
- Channel pseudo-range
- Accumulated carrier
cycles during
measurement period
- Doppler frequency

Müsste für DGPS ausreichen, oder?

Viele Grüße,
Peter

[Roland]

Na,

googeln
kann ich grad noch.

Roland

[XPosition]

Versuchte mich jetzt auch mal über das Modul schlau zu machen.
Ist aber etwas verwirrend.

Meine Vermutung:
Die interne Bezeichnung für das Basis-Modul nennt sich
S1315F - flash firmware
S1315R - rom firmware
Damit gehen sie zu OEM's und ändern je nach Kundenwunsch diese Basis ab.

Dann veräußern sie das Modul aber auch am öffentlichen Markt und da nennt sich das Modul
Venus 634FLPx - flash firmware
Venus 634LPx - rom firmware

Was verkauft eigentlich Sparkfun ? Flash oder Rom ?
Auf ihrer Seite ist die Doku vom Flash und die Bezeichnung vom Rom Modul.

Dann haben sie auch noch ein neues Modul Venus634LPx-T angekündigt. http://www.skytraq.com.tw/news20090701.htm
Das wird wohl das 20Hz Gerät sein.

Wo gibt es übrigens diese Rohdaten-Firmware ?

[ssquare_de]

Hallo Peter,


schön, dass sich bei deinen Versuchen Verbesserungen einstellten.

Die sparsame Dokumentation der Asiaten machts für uns schon sehr mühsam.
Auch deswegen habe ich empfohlen, sich schon vorab an den Hersteller zu wenden.

Anhaltspunkte, ob der Empfänger Flash- oder ROM-basierend ist, kann man von dem "F"(lash) oder "R"(om) in der Typenbezeichnung ableiten, wie schon XPosition bemerkt hat.
Zudem besitzen die Flash-Modelle häufig geringere Updateraten.
Im Falle des Venus ist auch die Tracking-Empfindlichkeit um 1dBm geringer, also -160dBm beim Flashmodell, im Gegensatz zu den -161dBm der ROM-Ausführung.

Das sind alles aber nur Anhaltspunkte, begründet zwar, aber leider eben nicht verbindlich.

Die Firmwareversion, die die Rohdatenausgabe ermöglicht, wäre natürlich höchst interessant.
Dazu bräuchte man mehr Details.
Der von Peter beschriebene Umfang der Rohdaten lässt vermuten, dass sowohl Postprozessing, als auch RTK ermöglicht würden.
Aber eben nur mit 1 Hz Updaterate - wenn ich das richtig verstanden habe.

Trotzdem, Peter, her mit allen verfügbaren Infos!
Ich bin mir fast sicher, dass Tomoji TAKASU, wenn es irgendwie machbar ist, sein RTKLIB http://gpspp.sakura.ne.jp/rtklib/rtklib.htm VENUS-tauglich machen würde.





Stefan

P.S. nette Visualisierungssoftware für GoogleEarth http://www.wugsi.com/Tools/GPS2KML/GPS2KML.php

[peterguy]

Also wirklich viel schlauer geworden bin ich jetzt immer noch nicht, trotz mehrerer Mails
Hier mal die Antworten von skytraq..

Mail1:

Hi Peter,
>
> Default firmware of Venus634FLPx doesn't support raw measurement
> output. Special firmware version does allow the module to support raw
> measurement output; Venus634FLPx could support 1Hz raw measurement output,
> S1315F could supports 1 / 2 / 4 / 5 / 10 / 20 Hz raw measurement output.
>
> The raw measurement output format is attached for your reference.
> Thank you.
>

Aufgrund der Mail bin ich davon ausgegangen, daß S1315F ein GPS Modul ist und habe folgende geantwortet:

Hi Oliver,

thanks for your fast reply.
I think the S1315F is exactly that what I'm looking for.
Unfortunately I could not find any information about availability in the
web. Can you provide me some information about where and when I can buy
the device?

Will there be some evaluation board available?

Heute kam dann die Rückantwort von Skytraq:

The unit price of S1315F (raw measurement output) is $25 for sample,
and $12.5 @ 250pcs.

We offer S1315F raw measurement output evaluation kit (comprising
active antenna + evaluation board + USB cable + evaluation software on
CDROM) for $99. FedEx shipping to Germany is $25.

You can order the above items directly from us. Thank you.

Könnt Ihr mit den Antworten etwas anfangen?
Aus dem Post von XPosition und den in letzter Mail genannten Preisen würde ich jetzt schließen, daß S1315F wohl eher eine Firmware ist.
Aber wie schon gesagt, so ganz sicher bin ich mir da noch nicht Undurchsichtige Geschichte...

Wenigstens eine Frage kann ich aber schon beantworten:
Das Modul auf meinem Schreibtisch ist von Sparkfun und der Chip trägt die Bezeichnung 634FLPx, ist also die Flashversion.

Viele Grüße,
Peter

[ssquare_de]

Hallo Peter,



_______________________________________________________________
....."The unit price of S1315F (raw measurement output) is $25 for sample,
and $12.5 @ 250pcs.

We offer S1315F raw measurement output evaluation kit (comprising
active antenna + evaluation board + USB cable + evaluation software on
CDROM) for $99. FedEx shipping to Germany is $25.

You can order the above items directly from us. Thank you.".....
________________________________________________________________



Wahnsinn!!!
Skytraq bietet also offensichtlich für < 125$ ein Empfängerboard samt Antenne und Zubehör und Rohdatenausgabe von 1-20 Hz an .
Und inklusive Versand!
Unglaublich!


Fast zu schön, um wahr zu sein.
Wenn die Rohdaten eine für eine Verwendung in RTKLIB ausreichende Qualität aufweisen würden, das wäre der absolute Kracher!

Können die dir vielleicht wenigstens einen Vorabinfoflyer zukommen lassen, der die wichtigsten Facts (Grösse, Stromversorgung, Antennenstecker, Empfängerdaten ( Kanäle, Empfindlichkeit, SBAS, Schnittstellen...) und Protokollinfo zu den ausgegebenen Rohdaten...) beinhaltet?
Das wäre riesig, dann könnten wir vielleicht schon eine grobe Vorabschätzung treffen...



Stefan

P.S. ..."The raw measurement output format is attached for your reference."...
Hast du da schon Infos bekommen?
Wenn ja, kannst du die mir/uns mal offenlegen?

[peterguy]

P.S. ..."The raw measurement output format is attached for your reference."...
Hast du da schon Infos bekommen?
Wenn ja, kannst du die mir/uns mal offenlegen?

Oh, das hötte ich fast vergessen
Hast recht, habe schon infos bekommen, einmal das Datenblatt zum S1315F (ist das jetzt eigentlich ein Modul oder eine Firmware?),
und einmal die erweiterte Binary Doku...
Siehe Anhang.

Viele Grüße,
Peter

[ssquare_de]

Hallo Peter,


danke für die nachgeschobenen Infos!
Nun ist alles soweit klaro!

Der S1315F ist ein potentes GPS-Empfängermodul, das mit der neuesten Firmware vom 08.April 2009 von 10 Hz auf 20 Hz Rohdatenausgabe aufgebohrt wurde.
Die Ausgabe der "fertig berechneten" Positionslösungen ist auf 10 Hz beschränkt.
Laut Datenblättern ist der S1315F in der Lage, alles notwendige für die Erzeugung eines vollständigen RINEX-Datensatzes, also NAV-Datei und komplette OBS-Datei ( Pseudorange, Doppler, Carrierphase, Signalstärke...) bereitzustellen.

Soweit nach einer ersten Sichtung im Querleseverfahren.
Da hast du ja einen dicken Fisch an Land gezogen.... Gratuliere!!!

Das Modul ( zum eigenhändigen Platinenbestücken ) kostet 25 $.

Den fertig aufgebaute Empfänger ( nur Antenne anstecken, Spannung anlegen, USB-Anschluss ist offensichtlich auch schon mit an Bord...), also mindestens so einfach in Betriebzu nehmen, wie dein aktuelles Sparkfun-Board,
gibts tutto kompletto und frei Haus für schlappe 87 Euronen!!!

Das schaut bislang richtig gut aus.



Stefan

[peterguy]

Dicken Fisch an Land gezogen
Der ist wohl eher von alleine an Land gesprungen, bzw. mit eurer Hilfe...

Werde am WE mal drei S1315F sowie eines der Eval boards bei Skytraq bestellen.
Bin mal gespannt wie das mit dem Zoll etc. ausschaut, ist meine erste Fern-Ost Bestellung auf eigene Faust

Wie sieht das eigentlich aus mit der Berechnung der DGPS Daten? Für meine Zwecke reicht wahrscheinlich ein Post-Processing der Daten erstmal aus. Also würde ich das Folgende Plannen:
Im Rover werden die Daten geloggt (welches Format?).
Die Basisstation muss an einer exakten Position (wie bestimmt man diese?) montiert werden und loggt ebenfalls die Daten mit.

Bei der späteren Auswertung werden die Daten mit der RTKLIB in hochgenaue NMEA Daten umgerechnet und visualisiert in Google Earth bzw mit Hilfe von Open Street Maps.

Könnte das so funktionieren?

Viele Grüße,
Peter

[ssquare_de]

Hallo Peter,



ich glaube, jetzt muss ich mal ein bischen als Spassbremse auftreten...auch wenns mir schwerfällt...

Vielleicht solltest du erstmal nur das Evaluationsboard ordern, um damit erste Versuche anzustellen.
Wenn die in Punkto RTKLIB/Postprocessing positiv ausfallen, kann man ja immer noch nachbestellen.
Ich könnte mir auch vorstellen, dass bei (d)einem Nachschlag eine kleine Sammelbestellung die Versandkosten minimiert.

Habe gestern die Datenblätter an Tomoji TAKASU, einen der Hauptverantwortlichen für RTKLIB, weitergeleitet.
Der bedankt sich für die Infos und antwortet mir eben, dass die Implementierung des SkyTraq-Binärformates in RTKLIB wahrscheinlich keine grosse Sache sei und er die Aufgabe in Angriff nehmen wird.

Die Papierform des S1315F stimmt auf jeden Fall, nur ob die Qualität der Phasenmesswerte in der Realität ein Ambiguity Fixing zulassen, kann jetzt noch nicht abgesehen werden.
Die LowCost-Empfänger plagen sich oft mit höherem Rauschen, zahlreichen Cycle Slips und Half Cycle Shifts ab.
Da müssen wir leider erst erste Versuche abwarten.

Was mir bislang nach einem gründlicherem Lesen der PDFs eher negativ aufgefallen ist:

- für die Timing-Genauigkeit werden eher magere 300ns angegeben

- wird auf das Binärformat umgeschaltet, gibt der Empfänger Position und Geschwindigkeit nur noch im ECEF-Format aus, also keine Grad/Minuten/Sekunden-position und auch keinen Geschwindigkeitsvektor in m/s, sondern nur Komponenten in den 3 Achsen XYZ. Anscheinend wird da der gesamte Navigationsrechner abgeschaltet, der sonst für die Ausgabe des NMEA-Parts zuständig ist. Das erklärt auch die hohen möglichen Update-Raten von 20 Hz.
Das Rechenwerk ist limitiert, was bei der geringen Stromaufnahme des S1315F ja keine wirkliche Überraschung ist.

(Wenn ich das an dieser Stelle anmerken darf: der LEA-4T / LEA-5T von ublox erlauben eine kombinierte Ausgabe Binär/ASCII zeitgleich über eine UART-Schnittstelle. So kann man über einen nachgeschalteten Portsplitter gleichzeitig in einer Software die Binärformate, in einer anderen Software die NMEA-Messages auswerten. Loggen des kombinierten Binär/ASCII-Datenstroms und eine nachträgliche Auswertung funktioniert natürlich auch .
Diese Möglichkeit ist nicht zu verachten.)

- wie schaut es mit den SBAS-Fähigkeiten des S1315F aus?
Wurden anscheinend nicht impementiert ?!? ( limitiertes Rechenwerk?!? )



Du könntest noch vorab bei SkyTraq nachfragen, für was man die Software auf CD-Rom einsetzen kann:
Konfiguration des Empfängers?
Datenlogging auf PC/PDA?
Konvertierung der Rohdaten ins verbreitete RINEX-Format?
...

Versteh mich bitte nicht falsch, Peter.
Ich möchte nur vermeiden, dass du/wir nach Geld/Zeiteinsatz mit enttäuschten Gesichtern dasitzen.
Deswegen bitte keine unüberlegten Schnellschüsse und vorab eben "nur" das Evo-board ordern.
Ist natürlich nur meine Meinung und ein Rat an dich.

Bis der SkyTraq in RTKLIB eingepflegt ist, gibts für uns ja noch genug Arbeit.


Wie willst du nach dem GPS-Empfänger weiter mit den Daten verfahren?
Loggen, ja, aber worauf?

Meinst du, der kompakte STM32 PRIMER 2 http://www.sander-electronic.de/es0030.html oder http://www.watterott.com/STM32-Primer2 wäre brauchbar für dich?
Der Primer müsste doch mit eingeschobener SD-Card einen Klasse Logger abgeben?
Leider sind Programmierung und Microcontroller nicht mein Ding.

Für das Geld kommt man im Selbstbau nicht sehr weit.
Der Primer müsste doch universell und flexibel einsetzbar sein, egal was uns zu deinem Projekt noch alles einfällt...

Muss für den Moment leider Schluss machen.





Stefan

[XPosition]

Die Papierform des S1315F stimmt auf jeden Fall, nur ob die Qualität der Phasenmesswerte in der Realität ein Ambiguity Fixing zulassen, kann jetzt noch nicht abgesehen werden.
Die LowCost-Empfänger plagen sich oft mit höherem Rauschen, zahlreichen Cycle Slips und Half Cycle Shifts ab.
Da müssen wir leider erst erste Versuche abwarten.

Naja, wie genau will es Peter denn haben ?
Auf 1 Meter genau via Postprocessing könnte es ja gehen/ausreichen.

-
Was mir bislang nach einem gründlicherem Lesen der PDFs eher negativ aufgefallen ist:
- für die Timing-Genauigkeit werden eher magere 300ns angegeben

Das ist das externe PPS Signal. Kann man als Zeitgeber benutzen.
Das ist unwichtig für unseren Fall.

Aber ansonsten hast du natürlich recht. Lieber erst mal vorsichtig testen.