Positionsbestimmung mit RTKLIB

[tpo]

Hallo Stefan!

Danke für dein Bemühen!

Ich hoffe ich mache nicht irgendwas falsch, bei dem sich die GPS-Profis gleich an den Kopf fassen würden...

Potentielle Probleme die mir noch einfallen, mehr oder weniger unwahrscheinlich:
-> Die freiliegenden GPS-Eval-Boards stören sich gegenseitig, oder stören den Empfang über die GPS-Antenne
-> Ripple bei Spannungsversorgung über USB ist zu hoch
-> Externe Störquelle an meinem derzt. Messpunkt (...werd mal wo anders hingehen demnächst)
-> Doch eine falsche FW in die SkyTaqs eingespielt und/oder unpassende RTKLIB-Version
-> Unpassende Groundplane
-> ???

Btw. soll die Groundplane eigentlich elektrisch mit dem Schrim der Antenne verbunden werden?

Danke,
lg,
Thomas

[Jörn Weber]

Btw. soll die Groundplane eigentlich elektrisch mit dem Schrim der Antenne verbunden werden?

Die Grundplane gehört einseitig an Masse gelege. Gegen den eigentliche Masse des Stativs im Bodens muss sie deshalb isoliert sein. Andernfalls gibt es bei feuchten Untergrund eventuell Brummschleifen...

Gruss Joern Weber

[Jörn Weber]

Hallo Thomas,

hattest du den Empfängern Zeit gelassen, die Ephemrieden einzulesen oder diese per AGPS vor geladen? Zu Beginn der Sitzung scheinen die Empfänger einen Unterschiedlichen Stand diesbezüglich zu besitzen.

Gruss Joern Weber

[ssquare_de]

Hallo Thomas,


ich habe mir gerade das gestrige RINEX-File der nahegelegenen ( ~15km) Referenzstation Linz (EUREF-Net) besorgt und damit leider auch keine grossen Verbesserungen feststellen können.
( Mit den Daten einer professionellen Referenzstation auf einer so kurzen Basislinie sollte es geradezu flutschen mit der Genauigkeit! )
Daraufhin habe ich einen Blick in die RINEX-Files der beiden SkyTraqs geworfen und festgestellt, dass die Dopplerwerte allesamt mit xxxx.000 enden!
Zm Vergleich: Mein Antaris zeigt bei den Dopplerwerten 2 Dezimalen an.

Mail an Tomoji ist gerade raus...warten wir, was der Fachmann dazu meint.

Mir fällt bislang kein offensichtlicher Fehler auf, den du bei deinen Versuchen begangen hättest.

Die Ground Plane muss nicht unbedingt geerdet sein, sie dient ja nur als Schirmung vor den flach oder gar von unten in die Antenne einstrahlenden Multipathsignalen.
Auf keinen Fall würde ich die direkt mit der Empfängermasse koppeln, da hätte ich Angst um das gute Stück.
Erdung im Boden schadet zwar nichts, muss aber zum Zwecke der Multipathschirmung nicht unbedingt sein.



Stefan

[Jörn Weber]

Hallo Thomas

festgestellt, dass die Dopplerwerte allesamt mit xxxx.000 enden!
Zm Vergleich: Mein Antaris zeigt bei den Dopplerwerten 2 Dezimalen an.

Schalte bitte probehalber mit dem GPSView Tool Skytraq zwangsweise manuell die Ausgabe der Dopplermessages im binären Protokoll ein. Eventuell hat die RTKLib da noch einen Bug.

Die Ground Plane muss nicht unbedingt geerdet sein, sie dient ja nur als Schirmung vor den flach oder gar von unten in die Antenne einstrahlenden Multipathsignalen.

Ein geerdeter Schirm wirkt besser und strahlt ggf. nicht selber. Rechne im Gebirge auch mit Mehrfachreflexen von der Seite.
btw. Ich habe gerade auch Sktraq kontaktiert um deren kommerziellen Lieferbedingungen abseits von Paypal zu ergründen. Wenn das funktioniert ordere ich dort auch ein Board. Desweiteren habe ich das dortige Marketing auf das Logging des binary streams im receiver angesprochen. Da wollen sie aber nicht ran, obwohl es technisch möglicht ist. Den kompakten PTV/ECF stream können sie ja bereits im externen Flash des Empfänger im Modul selber(!) loggen. Ein Prototype in USB Stickform dazu liegt neben mir. Hat via London 28 Euro gekostet. Mit BT wären es 40 Euro gewesen. [träum]Eine solche Kombi aus BT-Stick, Data-Logger und RAW-receiver wäre genau die richtige Mischung. [träum] Aber das überblickt selbst Skytraq wohl momentan nicht.

@Stefan, du spachst von einer BT-Verlängerung für die Module? Was ist da gut und preiswert?

Gruss Joern Weber

[tpo]

Hallo!

Habe nichts mit AGPS hineingeladen, und die Empfänger nur kurz vor der Aufzeichnung aufgestellt. Sie lagen allerdings ein paar Minuten vorher hinterm Fenster der Wohnung.

Das mit der Doppler-Genauigkeit scheint eine heiße Spur zu sein. Mal abwarten was Tomoji dazu sagt.
Habe dummerweise grad einiges um die Ohren. Aber vielleicht komme ich dazu und bohre die RTKLIB ein bissal auf, so, dass die von den Empfängern gelieferten Raw-Dopplerwerte direkt ausgegeben werden. So könnt man ein Problem in der RTKLIB ausschließen.

Interessant wär, ob bei deinem Empänger Stefan, die zwei Stellen hinterm Komma auch "stimmen" bzw. ob sie einen spürbaren Einfluss auf die Navigation haben. Oder obs eh mehr oder weniger nur Rauschen ist was hinterm Komma ausgegeben wird.
Ev. könnte man mal versuchen in einem RINEX-Log aus dem UBLOX die Stellen hinterm Komma allesamt mit 000 zu überschreiben, und dann die Solution rechnen lassen. Wenns (nur) daran liegt, dass die Skytraqs nicht gescheit tun, dann müsste sich hierbei ein ähnliches Verhalten einstellen.
Dummerweise hab ich jetzt (noch) keine Ahnung wie das RINEX-Format aussieht, und ob sich das so leicht nachträglich verändern lässt.

Bei mir gehts weiter wenn ich wieder mehr Zeit habe...

lg,
Thomas

[tpo]

Hallo!

Hab mal das "Raw Channel Measurement" Telegramm selbst decodiert und ausgegeben bevor es in die RTKLIB hineingeht.

Man sieht deutlich, dass keine Nachkommastellen beim Doppler-Wert vom Skytraq Modul gesendet werden.

lg,
Thomas

** numSats: 10
1 prn snr[dBHz] ps[m] carrCyc[Cyc] doppler[Hz] [dopplerBin] chInd
1 23 51dBHz 20141991.680m 769058.881 -1728.000Hz [0xc4d80000] 0x07
1 20 47dBHz 21478395.465m 1478779.757 -3029.000Hz [0xc53d5000] 0x07
1 2 48dBHz 22961630.739m -1532899.168 2471.000Hz [0x451a7000] 0x07
1 4 36dBHz 21030006.484m -530032.332 31.000Hz [0x41f80000] 0x07
1 32 42dBHz 23801216.223m 1374268.289 -3328.000Hz [0xc5500000] 0x07
1 31 18dBHz 25272198.967m 477317.103 -3860.000Hz [0xc5714000] 0x1f **SLIP**
1 13 29dBHz 19895236.100m -349750.722 538.000Hz [0x44068000] 0x17
1 25 33dBHz 21299377.023m -882832.928 2050.000Hz [0x45002000] 0x07
1 7 28dBHz 22830649.186m -1821910.167 3109.000Hz [0x45425000] 0x17
1 16 22dBHz 24300611.685m -233088.678 1258.000Hz [0x449d4000] 0x1f **SLIP**
1
** numSats: 10
1 prn snr[dBHz] ps[m] carrCyc[Cyc] doppler[Hz] [dopplerBin] chInd
1 23 51dBHz 20142322.222m 770790.697 -1731.000Hz [0xc4d86000] 0x07
1 20 46dBHz 21478972.055m 1481813.341 -3033.000Hz [0xc53d9000] 0x07
1 2 48dBHz 22961162.183m -1535366.789 2467.000Hz [0x451a3000] 0x07
1 4 35dBHz 21029999.905m -530059.757 27.000Hz [0x41d80000] 0x07
1 32 43dBHz 23801852.554m 1377599.890 -3331.000Hz [0xc5503000] 0x07
1 31 20dBHz 25272931.309m 481182.228 -3865.000Hz [0xc5719000] 0x1f **SLIP**
1 13 28dBHz 19895126.277m -350285.449 534.000Hz [0x44058000] 0x17
1 25 32dBHz 21298987.455m -884879.175 2046.000Hz [0x44ffc000] 0x07
1 7 26dBHz 22830045.915m -1825016.093 3105.000Hz [0x45421000] 0x17
1 16 23dBHz 24300332.080m -234342.530 1253.000Hz [0x449ca000] 0x1f **SLIP**
1 pntpos : validation error (ns=7 cs=26.0)
1 rtkpos : single point positioning error (ns=0)

[ssquare_de]

Hallo Thomas,


Tomoji hat mir gerade geschrieben, dass RTKLIB die Dopplerwerte nicht auswertet.
Somit falscher Verdacht von mir!
Mit dem RINEX-Converter RTKCONV.exe werden aber alle binären Informationen, die die verschiedenen Empfängertypen ausgeben, zu möglichst vollständigen RINEX-Files umgesetzt, die dann auch in anderen Softwareanwendungen optimal weiterverarbeitet werden können.

Er wird sich deine Logs genauer ansehen, sagte mir aber schon vorab, dass ihm die Qualität der Trägerphasen nicht soo gut gefällt.
Auch das Coderauschen des SkyTraq s sei gegenüber den ublox-Empfängern leicht erhöht.
Ich meine: Beim Coderauschen spielen aber auch die Antenne und die Ground Plane stark mit herein.Schauen wir mal, was mit dem 7x7cm²Blech geht!

Er gab mir aber den entscheidenden Tip, wegen der genannten Empfängereigenschaften unter "Options"---> "Statistics" das "Code/Carrier-Phase Error Ratio" von voreingestellten 100.0 auf 300.0 zu erhöhen.
Damit sieht das dann gleich viel besser aus!

Genauere Datenanalyse wird er noch vornehmen.




Stefan

[Jörn Weber]

Hallo Stefan,

Damit sieht das dann gleich viel besser aus!

Damit steht dann ja wohl das Skelet das wir ankleiden können. Danke! kannst du uns nochmal die Folgen des Fehlers inklusive Dopplershiftausgabe darstellen. Die Dopplershifts sind doch erst im Subzentimeterbereich von Bedeutung? Oder werden sie schon im Dezimeterbereich benötigt?

Gruss Joern Weber

[tpo]

Hallo!

Hatte vorhin kurz Zeit, und hab zwei 70x70mm Groundplanes ausgeschnitten und die Patch-Antennen darauf montiert.
Morgen folgt dann die nächste Messung.

lg,
Thomas

[ssquare_de]

Hallo,


ich möchte hier eine erste Hilfestellung für das Postprozessing von GNSS-Daten unter Verwendung des Softwarepakets RTKLIB geben, die den Einstieg erleichtern soll.

Das Postprozessing in der Programmsammlung RTKLIB geschieht mit den Programmen RTKPOST.exe oder auch RTKPOST_mkl.exe
( dieses Programm muss vom Betriebsystem unterstützt werden, führt aber zu den gleichen Ergebnissen wie RTKPOST.exe )

Diese beiden Programme erwarten im Eingang die Beobachtungsdaten von Basis und Rover im sogenannten RINEX-Format.
Das ist ein herstellerunabhängiges, genormtes ASCII-Datenformat, welches im GNSS-Bereich etabliert wurde, um Hardware- und Softwareunabhängigkeit zu schaffen und so unkomplizierte Datenaustauschbarkeit sicherzustellen.
Ein RINEX-Datensatz besteht aus mindestens 2 Dateien, dem sogenannten Observationsfile und dem Navigationsfile.

Ein vollwertiges Observationsfile enthält die sogenannten Rohdaten des Empfängers, also mindestens
-Pseudorange,
-CarrierPhase,
-Doppler,
-Signalstärke
jedes einzelnen empfangenen Sat s, und zusätzlich eventuell weitere Informationen.

Im Navigationsfile werden die Ephemeriden der Sats übertragen, Uhrenkorrekturen und Angaben für das Ionospährenmodell.

Näheres zum RINEX-Format unter:
http://de.wikipedia.org/wiki/Receiver_I ... nge_Format
http://www.geodetic.gov.hk/smo/gsi/Data ... INEX21.ppt


Die Informationen zur Generierung beider RINEX-Files sind in der binären Logdatei des Empfängers enthalten, müssen aber erst mit dem Datenkonverter RTKCONV.exe aufbereitet werden.
Im gestartetem RTKCONV.exe wird zunächst der Empfänger ausgewählt, mit dem das Log erstellt wurde und dann das ins RINEX-Format zu konvertierende
Log.
Unter OPTIONs kann man noch Infos für den RINEX-Header eingeben oder auch einen festen Höhen/Lageoffset der Antenne....
Mit "Convert" werden die beiden RINEX-Files und eventuell ein File mit SBAS-Aufzeichnungen erstellt, sofern diese im Empfängerlog vorhanden sind.

Wird auch die Basisstation eigenbetrieben, ist bei der Aufbereitung dieser RINEX-Daten analog zu verfahren.
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________

Es gibt auch die Möglichkeit, bei der Basisstation auf RINEX-Daten festinstallierter Referenzstationen zurückzugreifen.
Siehe dazu: http://igs.bkg.bund.de/

Dort sucht man sich zunächst die dem Rover-Einsatzort nächstliegende Basisstation:
"Station Information" --> " maps " --> Project"--> "EUREF oder auch IGS" und nimmt dann unten die Landesauswahl vor.
Klicken auf die nächstgelegene in der Map eingetragen Station zeigt das Stationskürzel, ein Klick auf "Info" macht die genauen Stationskoordinaten sichtbar.
Nun links unter "File Status" "by station" klicken und im erscheinenden Fenster oben das 4-stellige Kürzel der ausgewählten Station eintragen.
Bitte warten, kann einige Zeit dauern.
Mit dem Cursor über die blauen "Jahrestage" fahren, das Datum der Roverdatenaufzeichnung auswählen und per Klick ins grüne Feld unter "RINEX D" das "D"aily RINEX-Ganztageslog ( .OBS Observation-File) auswählen.
___________________________________________________
( Das entsprechende RINEX N(av) braucht man nicht unbedingt, man kann ja auch das schon vorhandene .NAV-File der Roverstation nutzen!)
Das letze "daily"-File ist normalerweise das des zurückliegenden Tages.
Dieses wird ungefähr ab 2.00Uhr Früh des nachfolgenden Tages online gestellt.
Was bedeutet, dass das Postprozessing per "daily"-File erst immer am nächsten Tag erfolgen kann!
Es werden die RINEX-Daten auch stundenweise online gestellt (hourly). Diese Files decken jeweils ganze, volle Stunden ab und sind normalerweise rund 2 Stunden später online.
Wenn also Daten von 15.10-15.54 Uhr mit dem Rover aufgezeichnet wurden, sollte man ab spätestens ca. 18.00Uhr an die Daten der Referenzstation drankommen.
___________________________________________________

Auf der nächsten Seite "File Name" kopieren, links unter "Data Archive" "Search File" klicken, File Name eintragen-->"Find" und dann Häkchen vors File und downloaden.
Das Zip entpacken, und im neuen Archiv das nächste enthaltene Zip ( wie bei russischen Puppen ) entpacken.
Nun sollte eine Datei mit der Endung .09d vorhanden sein. 09steht für das Jahr (2009), d für daily.
( Der Datenname setzt sich aus Stationskürzel und dem Tag im Jahr (also eine Datumsform) zusammen.)
Dieses .09d-File ist nun unser RINEX-File, leider aber noch in einer speziellen komprimierten Form.
Um das für RTKPOST lesbar zu machen, benötigt man das Windows-Programm "Hatanaka", das unter Vista als Systemadministrator ausgeführt werden muss.
Damit die .09d-Datei entpacken und endlich hat man das RINEX.OBS Format.

Hatanaka für Windows kann hier heruntergeladen werden:
http://www.lverma.nrw.de/produkte/downl ... wnload.htm
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________

In RTKPOST.exe wird dann unter

"Observation Data" die RINEX .OBS Datei des Rovers,
"Navigation Messages" die RINEX .NAV Datei der Basis ( oder auch des Rovers, egal...)
"Base Station Observation Data" die RINEX .OBS Datei der Basisstation eingetragen.

Dann werden unter "Options" alle gewünschten Vorgaben und Einstellungen gemacht.
Erwähnenswert ist hier folgendes:
Basisstationsdateien können natürlich nur angewählt werden, wenn in Options--> Settings1---> Positioning Mode NICHT Single ausgewählt ist!
Wichtig auch:
Unter Options--> Positions die korrekte Position der Basisstation einzutragen!
Dazu kann aus verschiedenen Möglichkeiten gewählt werden.
In den "daily" RINEX-Files ist im Header die Position der Referenzstation vermerkt.
RTKPOST kann die direkt auslesen u. nutzen--> manuelle Eingabe kann somit entfallen.






Stefan


P.S. Sorry, dabei wollte ich es ganz kurz und übersichtlich halten...und hätte noch sooo viel zu schreiben...
Wenn was unklar blieb, bitte nachfragen.

[tpo]

Danke Stefan für die ausführliche Anleitung!

Die http://igs.bkg.bund.de/ ist ja gar nicht so einfach zu bedienen... Und wenn man noch dazu nicht recht weiß wie das mit den einzelnen Files und Datenformaten zusammenspielt...

Habe vorhin gesehen, dass auch bei der RTKLIB ein crx2rnx.exe dabei ist. Mit dem kann man offenbar auch dekomprimieren.

Postman wäre heute auch da gewesen um die Bluetooth-Module zu bringen. Allerdings war keiner daheim, und so hat ers wieder mitgenommen

Die nächste Messung werde ich wohl erst morgen machen. Hab mir frei genommen.

lg,
Thomas

[ssquare_de]

Hallo Joern,



zu deiner Frage:
..." kannst du uns nochmal die Folgen des Fehlers inklusive Dopplershiftausgabe darstellen. Die Dopplershifts sind doch erst im Subzentimeterbereich von Bedeutung? Oder werden sie schon im Dezimeterbereich benötigt?"


Um die maximal möglichen Genauigkeiten bei der Trägerphasenauswertung voll auszuschöpfen, ist es zunächst nicht zwingend notwendig, die Dopplerwerte mit auszuwerten.
Nützlich kann die Auswertung der Dopplerwerte bei kinematischen Messungen werden, da sie helfen können, sogenannte Phasensprünge schnell aufzuspüren, die die optimale Phasenträgerauswertung sehr erschweren.
Allerdings scheint in Zukunft der Weg zur robusteren Nutzung der Trägerphasenmesswerte über die Koppelung mit IMUs(Trägheitsnavigation) per erweitertem KALMAN-Filter zu laufen.
Diese Koppelung verspricht, temporäre, abschattungsbedingte Signalausfälle besser überbrücken zu helfen und so den potentiellen Möglichkeiten der Trägerphasenauswertung bessere Alltagstauglichkeit zu verleihen.
Die Einarbeitung der Trägheitsnavigation soll ja in einem der nächsten RTKLIB-Releases geschehen.
Freuen wir uns darauf!

Siehe dazu auch:
http://gpspp.sakura.ne.jp/paper2005/ion2008.pdf



Hallo Thomas,

ja, das ist wohl die DOS-Version des Hatanaka-Programms.Hatte ich schon bemerkt, da aber die Windows-Version schon seit Ewigkeiten auf der Festplatte meines Rechners herumliegt...
Das Schönste wäre es ja, wenn der Aufruf des Progrämmchens beim Import der komprimierten RINEX-Dateien ins RTKPOST.exe selbstständig tätig werden würde...vielleicht klappts ja irgendwie und nur ich habs noch nicht kapiert...

Stefan

[Jörn Weber]

Hallo Stefan,.

zu deiner Frage:
..." kannst du uns nochmal die Folgen des Fehlers inklusive Dopplershiftausgabe darstellen. Die Dopplershifts sind doch erst im Subzentimeterbereich von Bedeutung? Oder werden sie schon im Dezimeterbereich benötigt?"

Danke für die Antwort. MIr war bisher nich klar, das die Japaner den Dopplershift zur Erkennung der Mehrdeutigkeiten heranziehen könnten. Damit hätte man ja theoretisch auch die Chance gewisse Atmosphärische sTörungen zu erkennen


btw.

Ich bin inzwischen die Beschaffung eines Bords in Taiwan direkt angegangen. Man kann die geodätischen Evaluation-Boards direkt bei Skytraq beim sales department kaufen. Sie wollen 99 US$ pro STück plus 25US$ für den Versand mit dem Courierdienst FeedEX. Bezahlt wird entweder mit Pypal oder Vorkasse. Die Überweisung per Vorkasse verursacht nochmals Bankspesen. Um den Überweisungsbeleg für die Vorkasse korrekt ausfüllen zu können lässt man sich am besten von Skytraq eine pro-forma Rechnung (proforma invoice) per Mail schicken. Die Postbank hat mir gerade dafür 9 Euro inklusive Devisenumtauschkosten für die Vorkasseüberweisung in Rechnung gestellt. Meine Gesamtbeschaffungs kosten belaufen sich also pro Board auf ca. 100 Euro. Das ist immer noch nur ein Drittel vom Preis eines u-blox LEA 5t Kit (395 Euro) Zum Skytrq Kit gehören ein Board, auf dem sich das GPS-Modul S1315F befindet und die Antenne. Das geheimisumwitterte "S1315F" des DR. T. Takasu ist also ein GPS Komplettmodul und kein GPS-Chip. Der GPS-Chip Venus 634FLPx selber befindet sich im Modul. Ein Mailwechsel mit Skytraq Ingenieuren ergab, das sie zwei Arten von Modulen herstellen, solche die im Modul zusätzlich, aber außerhalb des CPS-Chip einen SPI-Flash enthalten. Außerdem gibt es Module ohne SPI-Flasch. Der SPI-Flash speichert ggf. auch die AGPS-Daten. Dieser ist in der Lage einen Track zu speichern. Die Wegpunkte können dabei direkt vom ARM-Prozessor des GPS-Chips in den Flash geschrieben werden. Leider werden nur die ECF-Koordinaten in den Flash geschrieben nicht aber die Rohdaten.

So nun muss ich warten ob die Zahlung in Taiwan ankommt.

Gruss Joern Weber

Gruss Joern Weber

[Jörn Weber]

Hallo Stefan,.

zu deiner Frage:
..." kannst du uns nochmal die Folgen des Fehlers inklusive Dopplershiftausgabe darstellen. Die Dopplershifts sind doch erst im Subzentimeterbereich von Bedeutung? Oder werden sie schon im Dezimeterbereich benötigt?"

Danke für die Antwort. MIr war bisher nich klar, das die Japaner den Dopplershift zur Erkennung der Mehrdeutigkeiten heranziehen. Damit hätte man ja theoretisch auch die Chance gewisse Atmosphärische Störungen zu erkennen


btw.

Ich bin inzwischen die Beschaffung eines Bords in Taiwan direkt angegangen. Man kann die geodätischen Evaluation-Boards direkt bei Skytraq beim sales department kaufen. Sie wollen 99 US$ pro STück plus 25US$ für den Versand mit dem Courierdienst FeedEX. Bezahlt wird entweder mit Pypal oder Vorkasse. Die Überweisung per Vorkasse verursacht nochmals Bankspesen. Um den Überweisungsbeleg für die Vorkasse korrekt ausfüllen zu können lässt man sich am besten von Skytraq eine pro-forma Rechnung (proforma invoice) per Mail schicken. Die Postbank hat mir gerade dafür 9 Euro inklusive Devisenumtauschkosten für die Vorkasseüberweisung in Rechnung gestellt. Meine Gesamtbeschaffungs kosten belaufen sich also pro Board auf ca. 100 Euro. Das ist immer noch nur ein Drittel vom Preis eines u-blox LEA 5t Kit (395 Euro) Zum Skytrq Kit gehören ein Board, auf dem sich das GPS-Modul S1315F befindet und die Antenne. Das geheimisumwitterte "S1315F" des DR. T. Takasu ist also ein GPS Komplettmodul und kein GPS-Chip. Der GPS-Chip Venus 634FLPx selber befindet sich im Modul. Ein Mailwechsel mit Skytraq Ingenieuren ergab, das sie zwei Arten von Modulen herstellen, solche die im Modul zusätzlich, aber außerhalb des CPS-Chip einen SPI-Flash enthalten. Außerdem gibt es Module ohne SPI-Flasch. Der SPI-Flash speichert ggf. auch die AGPS-Daten. Dieser ist in der Lage einen Track zu speichern. Die Wegpunkte können dabei direkt vom ARM-Prozessor des GPS-Chips in den Flash geschrieben werden. Leider werden nur die ECF-Koordinaten in den Flash geschrieben nicht aber die Rohdaten.

So nun muss ich warten ob die Zahlung in Taiwan ankommt.

Gruss Joern Weber

Gruss Joern Weber