Forum: Projekte & Code GPS-Parser für XMEGA


von Marc S. (euro)


Angehängte Dateien:

Lesenswert?

Hallo,

im Anhang mal ein GPS-Parser, geschrieben in C, optimiert für XMEGA-µCs.

Der Code ist so geschrieben dass es vergleichsweise einfach ist auch 
mehrere Empfänger gleichzeitig auszulesen. Im Codebeispiel habe ich 2 
Empfänger implementiert.

Der Parser ist gleichzeitig auch die Einleseroutine für die Seriellen 
Daten, dies geschießt über eine (oder mehrere) ISR, welche dank Nutzung 
von DMA auch sehr schlank (schnell) gehalten ist.

Für die Nutzung von nicht X-Mega Bausteinen muss  DMA entfernt werden 
(und ein Schleifen-array-copy implementiert werden ), sowie die ISR 
Umbenannt und die initialisierung geändert werden !

Da ich hier im Board nur ASM-Parser gefunden habe dachte ich jemand 
könnte dieses Teil sicherlich gebrauchen ;)

Der Quelltext ist Teilkommentiert, in der .h Datei finden sich 
Informationen zur Benutzung.

Fehlermeldungen, Fragen oder Anregungen sehe ich gerne!

Viele Grüße,

Marc

: Verschoben durch User
von GG (Gast)


Lesenswert?

Hallo,

das sieht schon recht ordentlich aus. DMA ist prima, wollte das schon 
öfters testen.

Leider fehlen einige Kommentare wie z.B. USART-Geschwindigkeit.
Um deine Funktionen zu testen wäre eine lauffähige Test-Routine nicht 
schlecht gewesen.



Gruß GG

von Marc S. (euro)


Lesenswert?

Hallo GG,

Ja, den DMA hab ich hier auch das erste mal getestet. Ist dank der 
Atmel-Bibliothek ne schön einfache sache und hat auch auf Anhieb 
geklappt. Sicher könnte man das aber noch verschönern ^^

Ich denke das die Einstellung der usart-geschwindigkeit von jedem selber 
vorgenommen werden kann. Die GPS-Chips habe heutzutage verschiedene 
Geschwindigkeiten (4800, 9600, 38400 Baud sind üblich), und nicht jeder 
taktet den xmega mit 32 Mhz so wie ich in dem Beispiel. Mal davon ab 
gibts von Atmel ein schönes excel-sheet zum berechnen der werte, zu 
finden in der Datei zur application note wie man den USART der xmegas 
nutzt.

Eine Test-Routine ist nicht wirklich nötig. Einfach Serinit() aufrufen 
und die ankommenden Daten werden im Rohformat in die Arrays abgelegt. 
Will man die Werte im Klartext haben einfach 
GPS_Einlesen(Empfängernummer) aufrufen und schon sind die Werte in den 
betreffenden Variablen.

Die Testroutine ist also:

Serinit();
while(1)
{
GPS_Einlesen(1);
// Hier Displayausgabe für Empfänger 1 machen !
}

;)

Netten Gruß,

Marc

von GG (Gast)


Lesenswert?

Hallo und Danke,

werde mich die nächsten Tage damit beschäftigen.



Gruß GG

von Egon 64 (Gast)


Lesenswert?

@Marc

muß das Array zweidimensional sein?

uint8_t GPGSV0[3][70];

Gruß Egon

von XMEGA (Gast)


Lesenswert?

Hallo Marc Seiffert,

Egon 64 schrieb:
> muss das Array zweidimensional sein?


sollte so sein, vermutlich für 4 Satelliten.

Aber.. der Aufruf GPGSV_Einlesen(GPGSV0, &GPS_Daten0) führt im 
AVR-Studio4 zu folgenden Fehler, da die Variable ein mehrdimensionales 
Array ist.

warning: passing argument 1 of 'GPGSV_Einlesen' from incompatible 
pointer type

void GPS_Einlesen(uint8_t Empfaenger){
if(Empfaenger == 0)
{
GPRMC_Einlesen(GPRMC0, &GPS_Daten0);  // ok
GPGGA_Einlesen(GPGGA0, &GPS_Daten0);  // ok
GPGSA_Einlesen(GPGSA0, &GPS_Daten0);  // ok
GPGSV_Einlesen(GPGSV0, &GPS_Daten0);  // ** führt zu Fehler**
}

die dazugehörigen Variablen

uint8_t GPRMC0[70];  // ok
uint8_t GPGGA0[70];  // ok
uint8_t GPGSA0[70];  // ok
uint8_t GPGSV0[3][70];  // ** führt zu Fehler **

Den Fehler kann ich zwar im Aufruf beseitigen
GPGSV_Einlesen(GPGSV0[0], &GPS_Daten0);

aber dann stimmt sicher der Code nicht mehr.

Marc Seiffert bitte um Infos!



Gruß XMEGA

von Marc S. (Gast)


Lesenswert?

@ XMEGA

nein, der Code müsste der selbe sein

und das array ist 2-Dimensional weil es 3 Nachrichten mit 
sateliteninformationen gibt je 4 Sateliten

ausserdem ist das kein Fehler sondern eine Warnung also nur halb so 
schlimm ;)

Ich hätte auch 3 Einzelne Arrays erstellen können mit entsprechender 
abfrage aber ich fand das so eleganter ;)

Sollte er wirklich etwas falsch einlesen sag aber bitte nochmal bescheid 
!

Viele Grüße,

Marc

von XMEGA (Gast)


Lesenswert?

@Marc S.

schrieb im Beitrag #2021518:
> Sollte er wirklich etwas falsch einlesen sag aber bitte nochmal bescheid

Danke, es funktioniert astrein!


Gruß XMEGA

von Michael K. (mmike)


Lesenswert?

Hey Marc,

vielen Dank für den Code und fürs "sharing".
Aber warum nicht gleich UBX?? Sollten die Empfänger doch heute auch 
schon "sprechen" oder??

Und schon ein Paar Buchstaben mehr ;-) ??

Grüße,

Mike (UniBW)

von Marc S. (Gast)


Lesenswert?

Hallo Mike,

ich muss ehrlich sagen das mir UBX nix sagt.

Und ich es auch noch nie bei einem empfänger gesehen habe ?

Grüße,

Marc (TU DO)

von Michael K. (mmike)


Angehängte Dateien:

Lesenswert?

Hey Marc,

ich hab nen Navilock GPS Empfänger, der eben dieses UBX (siehe Anhang) 
Protokoll spricht. Ist binär und wirklich super umfangreich und damit 
spart man sich die ganze NMEA Parserei ...

Das Protokoll scheint zwar von µBlox zu sein, aber mein Empfänger 
(http://www.navilock.de/produkte/gruppen/13/Boards_und_Module/60413_NL-504ETTL_MTK_TTL_Modul.html) 
spricht das auch!

Grüße,
Mike

von Bernd (Gast)


Lesenswert?

Hallo Marc,
sehr interesant dein Code für XMeGA.
Ich brauche nur die Uhrzeit aus dem RMC String für einen Datenlogger.
So wie ich DMA verstehem arbeitet das doch unanhängig vom eigentlichen 
Programm, ich kann mich also auf meine Messroutinen konzentrieren mit 
meinem XMEGA, die Daten speichern auf SD Card und wenn ich die Uhrezeit 
brauche, hole ich die aus dem DMA Speicher ?
Kann man auch noch einen DMA-Routine fürs speichern
über SPI Port schreiben? Wäre toll, wenn Du mir dabei helfen könntest.

Gruss Bernd

von Marc S. (Gast)


Lesenswert?

Hallo Bernd,

das komplette speichern der NMEA-Strings inclusive des DMAs wird übern 
interrupt gesteuert, daher ist das schon richtig das du da nix mehr 
weiter tun musst ausser den Interrupt zu aktivieren.

Du holst die Uhrzeit-Routinen aber nicht aus dem "DMA-Speicher" sondern 
aus dem dafür vorgesehenen String in das er per DMA gespeichert wurde ;)

Was ich mich aber gerade Frage ist warum die DMA haben willst um auf die 
SD-Karte zu schreiben ? Wenns ein Datenlogger ist (und kein Oszi o.ä.) 
ist die Datenmenge i.a. so gering das da kein DMA nötig ist. Ich würde 
einfach einen Timer anwerfen mit der Samplerate die gewünscht ist und in 
der routine die Daten auf die Karte schreiben.

Was auch noch wichtig ist: DMA geht NICHT mit der klassischen SPI 
Hardware (nicht als Master) dafür muss man den USART nehmen. Warum auch 
immer Atmel das so gemacht hat ich finde es extremst bescheuert.

Ansonnsten muss ich dich leider enttäuschen ich habe selber ein Projekt 
das mit "sehr großen" Datenmengen hantiert. Leider habe ich DMA nie 
wirklich für die SD-Karte implementiert. Es war in meinem Fall 
vorteilhafter die daten von der SD-Karte zuerst auf einen At45DB161 zu 
speichern (und dabei zu konvertieren) um sie anschließend per DMA aufs 
Display zu streamen (dabei wurden Datenraten nahe 2 MB/s erreicht). Ich 
glaube etwa 12fps konnte ich aus dem Display herauskitzeln ;)Ziel des 
Projektes war das Anzeigen von 320x240x16 Bitmaps auf einem ebensogroßen 
Bildschirm, und das so schnell das man eine vernünftige Menüführung 
damit aufbauen kann.

Viele Grüße,

Marc

von Marc S. (Gast)


Lesenswert?

Hey Mike,

UBX scheint tatsächlich Ublox spezifisch zu sein. Ich weis über die 
Vorteile binärer Protokolle und war auch schon am überlegen SIRF binary 
zu implementieren. Was mich aber davon abhält:

NMEA versteht JEDER reciever !

Und wirklich Rechenleistung nimmt das ganze nicht ein auf nem XMEGA. das 
macht der im Hintergrund nebenbei ;)

Daher (und weil ich zeitlich eh schon eng eingespannt bin) begnüge ich 
mich mit dem klassischen NMEA Protokoll.

Wenn du natürlich Routinen für UBS oder weis Gott was schreibst füge ich 
sie gerne in die lib mit ein. Kannst natürlich auch Teile der LIB für 
deine eigene nutzen und dann UBX machen.

Viele Grüße,

Marc

von Michael K. (mmike)


Lesenswert?

Hi Marc,

Du hast schon Recht ... NMEA spricht wirklich jeder Empfänger. Ich war 
damals, als ich das UBX ausprobiert habe einfach so happy mit den vielen 
Messages, die das Ding anbietet! Neben der "Standard" Position in LLH, 
gibts viele Werte auch in ECEF, Geschwindigkeiten sogar in NED ....

hier ein Auszug aus dem Protokoll für NAV-VELNED

0  - iTOW ms GPS Millisecond Time of Week
4  - velN cm/s NED north velocity
8  - velE cm/s NED east velocity
12 - velD cm/s NED down velocity
16 - speed cm/s Speed (3-D)
20 - gSpeed cm/s Ground Speed (2-D)
24 - heading deg Heading 2-D
28 - sAcc cm/s Speed Accuracy Estimate
32 - cAcc deg Course / Heading Accuracy Estimate

Ich bezweifle dass NMEA, das auch bringen kann ... man beachte die 
Einheiten z.B. für die Geschwindigkeiten [cm/s]. Ich finds klasse ...

Viele Grüße,
Mike

von Marc S. (Gast)


Lesenswert?

Hallo Mike,

wenn ich mir die Einheiten so ansehe muss ich ehrlich sagen das ich 
bezweifel das GPS das auch nur ansatzweise kann. Die Ungenauigkeit 
zwischen 2 Fixes kann ja schon ein paar Meter betragen.

Vermutlich kann man die Hohe Auflösung nur nutzen wenn man mit DGPS 
arbeitet um die Positionsgenauigkeit stark zu erhöhen. Dann haben sie 
defintiv ihren Sinn.

Viele Grüße,

Marc

von Michael K. (mmike)


Lesenswert?

Hallo Marc,

teils gebe ich Dir recht, aber die Geschwindikkeitsmessung erfolgt bei 
so gut wie allen Empfänger nicht über eine Positionsdifferenzierung, 
sondern über die Phasenverschiebung (Dopplerverschiebung) der 
Trägerfrequenz (ugs. das GPS-Lock). Ich hab mal nen paar Tests im Garten 
gemacht und bin ein wenig rumgelaufen ... Klar ist Rauschen drauf, aber 
die Werte sahen wirklich nicht schlecht aus! Muss mal schauen, evtl. 
finde ich die Plots noch ...

Mit DPGS wärs dann natürlich am Besten ...

Viele Grüße,
Mike

von Marc S. (Gast)


Lesenswert?

Hallo Mike,

Interessant auf die idee das die Dinger das per Dopplereffekt machen bin 
ich noch nie gekommen :)

Die Plots klingen interessant zeig mal ruhig her !


Ja nur ist DGPS leider nicht so ganz ohne Aufwand ^^

Viele Grüße,
Marc

von Michael K. (mmike)


Lesenswert?

Hi Marc,

hätte mich auch gewundert, wenn Dir das entgangen wäre ;-) Die Plots 
sind leider unauffindbar, aber ich code grad an meinem Tricopter - 
Regler und da werden hoffentlich bald auch mal ein paar Flugversuche im 
Garten gestartet und demnach neue Plots entstehen, die ich dann 
nachreiche ...

Viele Grüße,
Mike

von Marc S. (euro)


Lesenswert?

Hi Mike,

schöne Sache das,

ich arbeite zur Zeit mit zwei Kollegen an nem recht großen Quadro...weg 
von "klein und niedlich" hin zu groß und "böse", maximal 12kg Auftrieb 
wird er haben bei nem Eigengewicht von etwa 3kg, Spannweite fast 1m.

Ist ala AEV konzipiert und dementsprechent mit leistungsstarken Antennen 
(50km) sowie langer Flugzeit(ca 40-60 Minuten) ausgestattet. Wollten 
ursprünglich einen Oktocopter bauen wegen der Redundanz haben das aber 
aus Kosten- und Aufwandsgründen gelassen.

Viele Grüße,

Marc

von Michael K. (mmike)


Lesenswert?

Hi Marc,

klingt spannend!! Wofür steht den AEV? Kenne nur AUV ;-)

Kennst das schon:
http://www.youtube.com/watch?v=kh_eZE3OQlQ
http://defense-update.com/wp/20101004_panther_uav.html

Geiles Projekt!

Grüße,
Mike

von Marc S. (euro)


Lesenswert?

Morgen Mike,

AEV steht für Autonomous Aerial Vehicle.

Im Endeffekt brauch ner nutzer nacher nix weiter eingeben ausser einer 
GPS-Koordinate und das Gerät fliegt diese automatisch an und kehrt 
wieder zurück. Natürlich ist dieser Modus nur neben dem vollhändischen 
flug implementiert.

Das Israelische Projekt schaut nicht schlecht aus. Aber so extrem geil 
finde ich es nicht, ich wagesogar zu bahaupten das es auf der welt noch 
andere private modellbauer gibt die auch soetwas haben ;) Scheint auch 
ausschließlich als überwachungsdrohne konzipiert zu sein. Wobei ich den 
israelis da noch ein paar Tricks zutraue ^^

Grüße,
Marc

von Michael K. (mmike)


Lesenswert?

Hey Marc,

klingt schick! Habt ihr dann dann auch einen "intelligenten" Agenten an 
Bord, der Entscheidungen trifft (bzgl. dem autonomous), plant und eine 
Mission bekommt?? Oder doch eher "automatic" ??

Das Israeli - Projekt finde ich dahingehend cool, da das Ding 65kg wiegt 
und 6 Stunden in der Luft bleiben kann ... ich bezweifel, dass das ein 
"normaler" Modellbauer auch hat ... aber das Konzept hab ich auch schon 
ein einem "Zagi" gesehen, von daher gebe ich Dir Recht!

Grüße,
Mike

von Marc S. (euro)


Lesenswert?

Hey Mike,

der Copter wird autonom auf einige Probleme reagieren können, zum 
Beispiel wenn der Akku zu leer wird kehrt er automatisch zur Basis 
(Startpunkt / Vorgegebene Position) zurück. Bei verlust des Empfanges 
wird zuerst versucht in eine günstige Positon zu geraten ( höher ) und 
anschließene ebenfalls der Rückweg angetreten falls das nix bringt. 
Weitere Autonomität machtkeinen Sinn das Ding soll im Endeffekt ja nur 
das tun was ich will ;)

hmm...65kg sind definitiv ne Hausnummer. Aber groß bedeutet nicht 
unbedingt schwer zu realisieren oder teuer ! Teilweise im Gegenteil. 
Mein Copter hat sogar ein recht großes Grafikdisplay drauf und nen 
Empfängerakku zusätzlich, weils das Gewicht einfach erlaubt. Und ich 
habe zwar stark aufs gewicht geachtet (sogar dünnes Epoxi ist in 
Verwendung) trotzdem ist es nicht so kritisch.

Die lange Flugzeit wird wohl auch nur im Horizontalflug, nicht beim 
schweben zu realisieren sein ( es sei denn die Israelis haben Akkus von 
denen ich nix weis ;))

Grüße,

Marc

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.