GPS-Modul mit Raspberry Pi ansteuern

Bastel B. OP #3763170
Lesenswert?
• ▲
▼ 
Hallo,
ich versuch schon eine ganze Weile das 
GPS-Bee-Modul(http://www.seeedstudio.com/wiki/GPS_Bee_kit) von 
Seeedstudio mit dem Raspberry Pi B v2 
(http://elinux.org/RPi_Low-level_peripherals) unter Zuhilfenahme von 
wiringPi(http://wiringpi.com/reference/serial-library/) anzusprechen, es 
gelingt mir allerdings nicht :/.

Eine Skizze der Schaltung befindet sich im Anhang, der verwendete Code 
steht unten. Der Gleiche Aufbau mit einem Arduino-Mega 2560, dessen 
Serieller Schnittstelle und einem entsprechenden Programm funktionierten 
einwandfrei.

Update!
Es funktioniert! Leider nur ab und an, ich erhalte dann nur Fragmente 
der Daten, die ich haben möchte (Bsp. unten).

>>$GPGGA,181506.000,5101.0737,N,00853.1000,E,1,9,0.93,436.0,M,47.8,M,,*5 7
$GPGSA,A,3,22,11,14,19,27,28,32,01,20,,,,1.25,0.93,0.83*05
$GPGSV,3,1,12,11,74,275,28,32,59,211,25,01,52,286,25,19,50,166,21*7B
$GPGSV,3,2,12,14,39,080,19,22,28,060,20,28,26,299,38,27,20,157,14*7C
$GPGSV,3,3,12,<<

Zu Grunde liegen folgende Beispiele:
http://iamzxlee.wordpress.com/2013/09/08/gps-bee-kit-part-2-2/
http://nicohood.wordpress.com/2014/04/18/arduino-raspberry-pi-serial-communication-protocol-via-usb-and-cc/

1
#include<iostream>

2
using namespace std;

3


4
#include <wiringPi.h>

5
#include <wiringSerial.h>

6


7
#define DELAY 5

8
#define TIMEOUT 3000

9


10
int main()

11
{

12
  int fd = 0;

13
  bool state = false;

14
  char device[] = "/dev/ttyAMA0";

15
  unsigned long time;

16


17
  if((fd = serialOpen(device, 9600)) < 0) {

18
    cout << "unable to open serial device" << endl;

19
    return 0;

20
  }

21


22
  if(wiringPiSetup () == -1) {

23
    cout << "unable to start wiringPi" << endl;

24
    return 0;

25
  }

26


27
  cout << "search for signal [fd = " << fd << "]\n" << endl;

28


29
  time = millis();

30
  cout << ">>";

31


32
  while(true) {

33
    while(serialDataAvail(fd) > 0) {

34
      if(!state) {

35
        state = true;

36
        delay(1000);

37
      } 

38
      cout << char(serialGetchar(fd));

39
      delay(DELAY);

40
    }

41


42
    if(state) {

43
      cout << "<<" << endl;

44
      break;

45
    }

46


47
    if(millis() - time >= TIMEOUT) {

48
      cout << "<<\n\t...timeout (" << TIMEOUT / 1000.0 << "s)" << endl;

49
      return 0;

50
    }

51
  }

52


53
  serialClose(fd);

54


55
  cout << "\n\n\t...done" << endl;

56
  return 0;

57
}
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Mike A. Gast #3763313
Lesenswert?
• ▲
▼ 
l. o. schrieb:
> Zu schlechter GPS-Empfang?

Wenn du im nördlichen Teil von Oberholzhausen wohnst, ist die Position 
doch gar nicht so verkehrt.

Allerdings sind die Signale nach den ausgegebenen Daten etwas schwach, 
auch wenn der Empfänger aus den empfangenen 9 Satellite die Position gut 
bestimmen kann. Das kann aber an der Kalibierung des Empfängertyps 
liegen und muss nichts (schlechtes) heißen. Die drei flach stehenden 
Satelliten hat er nicht mehr zu fassen gekriegt, was entweder durch 
Abschattung oder eine nicht optimale Antenne verursacht werden kann. 
Warst du bei den Empfangversuchen im Freien?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Mike A. Gast #3767793
Lesenswert?
• ▲
▼ 
l. o. schrieb:
> Davon ab bekomme ich nur sehr unregelmäßig Datensätze rein, die dann
> an einer willkürlichen Stelle abbrechen...

Wenn der GPS-Empfänger Probleme mit dem Empfang hat, sollte er trotzdem 
ununterbrochen NMEA Datensätze ausspucken. Da fehlt dann ggf. im GPGGA 
die Position. Im GPGSA stünde bei Empfangsproblemen Mode als 1 (=Fix not 
available) und die Liste der empfangenen Satelliten wäre kürzer. Dein 
Datenmitschnitt weiter oben sieht aber ganz vernünftig aus.

Um die Fehlerquellen einzugrenzen, prüfe erstmal mit einem 
Terminalprogramm, dass auf dem PC läuft, ob die Daten vom GPS regelmäßig 
kommen. Wenn du die NMEA-Daten nicht direkt verstehst, kannst du sie 
auch mit einem Tools wie GPSView dekodieren und visualisieren.
Umgekehrt kannst du als zweiten Schritt auch deinem Raspberry Pi vom PC 
aus gültige NMEA Daten schicken (z.B. mit HTerm) und damit prüfen, ob es 
an deiner Empfangsroutine auf dem µC liegt.

Wenn beides läuft, hängst du den GPS-Empfänger wieder direkt an den RP.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bastel B. OP #3767840
Lesenswert?
• ▲
▼ 
Der GPS-Empfänger sendet regelmäßig (schätze mal 1Hz), das habe ich 
gerade mit einem anderen µC getestet. Das Problem liegt meines Erachtens 
im Raspberry Pi.

Mike A. schrieb:
> Umgekehrt kannst du als zweiten Schritt auch deinem Raspberry Pi vom PC
> aus gültige NMEA Daten schicken (z.B. mit HTerm) und damit prüfen, ob es
> an deiner Empfangsroutine auf dem µC liegt.

Wie stelle ich das an? Also wie verbinde ich die Geräte in diesem Fall, 
Softwareseitig sollte ich das hinkriegen...

PS: HTerm nützt mir wenig, bin auch auf dem Desktop unter Linux (Ubuntu 
14.04 LTS) unterwegs, das soll aber kein Hindernis sein :P
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Mike A. Gast #3767925
Lesenswert?
• ▲
▼ 
l. o. schrieb:
> Wie stelle ich das an? Also wie verbinde ich die Geräte in diesem Fall ...

Falls du am PC eine serielle Schnittstelle hast, kannst du mit der 
TX-Leitung (Pin 3 beim D-Sub9) über einen invertierenden Pegelwandler an 
Stelle des GPS-Moduls auf den RX-Pin vom RP gehen. Masse (Pin5) nicht 
vergessen.
Falls du keine RS-232 Schnittstelle am PC hast, kommt noch ein USB-RS232 
oder ein USB-TTL Wandler dazu. Mit einem "TTL-Wandler" mit 3.3V Pegeln 
kannst du direkt auf den RP gehen, d.h. Inverter/Pegelwandler sind dann 
nicht nötig.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren