So i'm using a modified Hello World GPS program, i'm outputting to my LCD other then to my PC. I'm using the EM-406A GPS module, it gets a location fix within a minute but i'm still reading 0.000000 for my lat and long.

#include "mbed.h"
#include "TextLCD.h"
#include "GPS.h"

TextLCD lcd(p14, p12, p15, p16, p29, p30, TextLCD::LCD20x4); 
GPS gps(p9, p10);

int main() {

while(1) {
	led2 = 1;
	lcd.locate(0,0);
	lcd.printf("LOOKING FOR GPS");
	lcd.locate(0,2);
	lcd.printf("I'm at %f, %f\n", gps.longitude, gps.latitude);
}

Any ideas as to why i'm not getting my location information, even when i have a valid location lock?

Thanks much,

-Jorge

Hi Jorge,

According to the library you have to call gps.sample() before being able to read the long/lat info, which returns 1 on success and 0 on failure.

Donatien

Thanks for the quick response Donatien,

So, it's always pretty embarrassing to spend hours trying to troubleshoot a problem just to realize that it was a wiring mistake. In my zeal of hooking it up last night i had put a jumper wire in an empty row in my breadboard.

Thanks for your help though =)

-Jorge

Hmm..

I thought it would be a pretty cool idea to see how many satellites the module was currently tracking so i looked up the datasheet.

GGA-Global Positioning System Fixed Data

Table B-2 contains the values for the following example:

$GPGGA,161229.487,3723.2475,N,12158.3416,W,1,07,1.0,9.0,M,,,,0000*18

The 07 is the "Satellites Used" return with a max of 12 satellites. It's been two years since my last C/C++ course and i rarely program so i added the next bit of code hoping for the best.

From the gps.cpp i added "&tracking" and correspondingly linked it to %d

        // Check if it is a GPGGA msg (matches both locked and non-locked msg)
        if(sscanf(msg, "GPGGA,%f,%f,%c,%f,%c,%d,%d", &time, &latitude, &ns, &longitude, &ew, &lock, &tracking) >= 1) {

In the GPS.h i added

    // Returns the number of satellites currently tracking, 12 max
    int tracking;

Any ideas here? Am i overlooking something?

Thanks for everyones help and time,

-Jorge

some comments on the EM-406A. I hope this is useful to somebody, this episode took more time than it should have.

The LED on a locked EM-406A blinks. My unit refused to lock to the satellites at first, and the LED remained lit. The reason is that it needs to download the almanac once, and this takes maybe 30 minutes for a new device. I had to take it out to the garden to improve reception.

Now that it's got its almanac, clock drift etc initialized, it also works off my window sill. If so, point it slightly away from the wall. The "eye" of the antenna should "see" as much blue sky as possible.

- changing the baud rate is permanent, at least until the backup capacitor runs out (1 month?). Setting it back is difficult if one doesn't know the current baud rate, it may take some trial-and-error

- changing to binary mode is also permanent. Reportedly, the LED works differently in binary mode.

Hi, I am also trying to read GPS data on my LCD of lpc expresso baseboard. can you pls send me the code that you have used for testing?

Hello,

I hope this is from the correct file..

Serial gps(p9, p10); gps.baud(4800); gps.printf("$PSRF105,1*3E\013\010"); ... char c = gps.getc();

Hello Everyone, how strange this is. For the past week I've been using my EM-406 to log around the street where I live to get a position fix for the contours of the road (for my Rover project). During the week I checked the data from the EM-406 displayed on my lcd screen against the data displayed on my cars GPS system (Nissan). I found that on a days/nights when the cloud density was high I got no lock, but on clear skies or skies with a less cloud density I got lock and data within say 30secs and also have a lock within my kitchen, we have clear weather at the moment and it's flashing in the kitchen right now. I fully understand electromagnetic theory et al and that cloud or water vapour should not interfere at these signal frequencies, I am just declaring my own observations from this week. Nissan Data 53.31.17N 2.30.25W

EM-406 Data 53.52.1427 latitude -3.84.0512 longitude

I can see in Simon's cpp code and his previous explanations why the longitude has a -ve sign. But my question would be is it possible to 'calibrate' the EM-406 or are these values expected between different GPS devices?

Hi Derek, you should not need to calibrate a gps. Once it has good reception, acquired a lock and downloaded the almanac it should give you good data. There will always be small differences between two devices due to rounding errors, time drift etc, but an error of more than 1 degree is huge. There must be something wrong in the decoding or print routines. Find a good map and check what the coordinates should be. Also check which geodetic system is used by the 2 gps systems. It is probably set to WGS84. They should be the same to avoid differences.

Edit: make sure you have good satellite reception. The antenna should have clear view of the sky. It should best be placed on a groundplane (like a carbody..). Be aware of rf interference from sources like the high clockrates found on mbed. Better use shielding and some distance. Decouple powersupply.

but of course they do. The increase the permittivity of space, slowing the waves down. That said, there may be a more down-to-earth explanation than electromagnetic voodoo.

As always Wim thanks for the help, I'll investigate the geodetic system settings and see if they compare, I was concerned by the 1 degree difference as you rightly point out it's huge? Post back when I find out more.

This link I found is a great help for newbies in getting to grips with GPS :-

http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/guidecontents/index.html

Which provides a pdf version for download.

GPS horizontal accuracy (not elevation) is limited in the main by 3 or so error sources...

http://en.wikipedia.org/wiki/Dilution_of_precision_%28GPS%29

GDOP: Geometry dilution of precision: This error increases when the GPS receiver cannot "see" the entire sky - due to being inside a car, on the dashboard rather than rooftop, or by buildings, trees, and by mountains that block large parts of the sky. Example: Your receiver can see only 1/3 of the sky. That means that the satellites in view are "clustered" and not evenly distributed from horizon to horizon N,S,E,W. This poor geometry greatly increases the math errors in the position estimate.

GPS receiver needs propagation delay correction data. A key error is the variable delays through the ionosphere. On many continents there are grids of "reference GPS receivers" that allow corrections for this error to be determined every few minutes. These corrections need to get to the GPS receiver. There are several ways: some receivers have a serial port input for correction data (older or high precision GPS as in agriculture and survey work); today, correction data is sent by a non-GPS satellite in geosynchronous orbit (22K miles out, unlike GPS which are much closer to earth). Most new GPS receivers can decode that correction data received with the same hardware. However, your receive needs to support this "WAAS" capability, AND your receiver needs sky view of the geosync satellite belt at your latitude, e.g.., 34 degrees up from the horizon in the southern US. If buildings or mountains obscure for long durations, the errors build due to a lack of correction data. This gets more complicated with "assisted GPS" where the location is computed by a distant computer using raw data sent from your GPS receiver; cell phone 911 does this.

The NMEA standard formats for GPS includes "number of satellites used in solution" and their IDs. If you care, you can check the GDOP on any single solution. Or better, just get WAAS data reliably and do lots of averaging to reduce the error stats.

This just touches the surface of GPS error sources. And of course, all GPS location data needs to be averaged/integrated for some time so the statistics can benefit you.