GPS-Modul mit Raspberry Pi ansteuern

[Bastel B. (luoc)]

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/

#include<iostream>
using namespace std;

#include <wiringPi.h>
#include <wiringSerial.h>

#define DELAY 5
#define TIMEOUT 3000

int main()
{
  int fd = 0;
  bool state = false;
  char device[] = "/dev/ttyAMA0";
  unsigned long time;

  if((fd = serialOpen(device, 9600)) < 0) {
    cout << "unable to open serial device" << endl;
    return 0;
  }

  if(wiringPiSetup () == -1) {
    cout << "unable to start wiringPi" << endl;
    return 0;
  }

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

  time = millis();
  cout << ">>";

  while(true) {
    while(serialDataAvail(fd) > 0) {
      if(!state) {
        state = true;
        delay(1000);
      } 
      cout << char(serialGetchar(fd));
      delay(DELAY);
    }

    if(state) {
      cout << "<<" << endl;
      break;
    }

    if(millis() - time >= TIMEOUT) {
      cout << "<<\n\t...timeout (" << TIMEOUT / 1000.0 << "s)" << endl;
      return 0;
    }
  }

  serialClose(fd);

  cout << "\n\n\t...done" << endl;
  return 0;
}

[Bastel B. (luoc)]

Woran könnte dieses unzuverlässige Verhalten liegen?
Fehler in der Schaltung? Störsignale usw.?
Fehler im Code?
Zu schlechter GPS-Empfang?

[Mike A. (Gast)]

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?

[Bastel B. (luoc)]

Mike A. schrieb:
> Warst du bei den Empfangversuchen im Freien?

Der Empfänger liegt auf der Fensterbank :P. Davon ab bekomme ich nur 
sehr unregelmäßig Datensätze rein, die dann an einer willkürlichen 
Stelle abbrechen...

[Mike A. (Gast)]

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.

[Bastel B. (luoc)]

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

[Bastel B. (luoc)]

Es gibt doch sicherlich auch die Möglichkeit die verschiedenen 
Schnittstellen (/dev/ttyAMA0) auch direkt über das Terminal zu erreichen 
bzw. sich die ankommenden Daten ausgeben zu lassen. Damit wäre mir aufs 
erste auch schonmal geholfen.

[Mike A. (Gast)]

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.