Go Down

Topic: Big positioning error using U-BLOX NEO-6M GPS module with TinyGPS (Read 6916 times) previous topic - next topic

achenal

Jun 13, 2012, 10:51 am Last Edit: Jun 13, 2012, 10:54 am by achenal Reason: 1
Yesterday I have tested U-BLOX NEO-6M GPS module with TinyGPS lastest library v12.

The following is my codes copy from Arduino Cookbook.

Code: [Select]

#include "TinyGPS.h"
#include "SoftwareSerial.h"

#define HEMISPHERE_PIN 13
#define GPS_RX_PIN 2
#define GPS_TX_PIN 3

TinyGPS gps; // create a TinyGPS object
SoftwareSerial ss(GPS_RX_PIN, GPS_TX_PIN); // create soft serial object

void setup()
{
Serial.begin(9600); // for debugging
ss.begin(9600); // Use Soft Serial object to talk to GPS
pinMode(HEMISPHERE_PIN, OUTPUT);
digitalWrite(HEMISPHERE_PIN, LOW); // turn off LED to start
}

void loop()
{
while (ss.available())
{
int c = ss.read();
Serial.write(c); // display NMEA data for debug
// Send each byte to encode()
// Check for new position if encode() returns "True"
if (gps.encode(c))
{
long lat, lon;
unsigned long fix_age;
gps.get_position(&lat, &lon, &fix_age);
if (fix_age == TinyGPS::GPS_INVALID_AGE)
Serial.println("No fix ever detected!");
else if (fix_age > 2000)
Serial.println("Data is getting STALE!");
else
Serial.println("Latitude and longitude valid!");
Serial.print("Lat: ");
Serial.print(lat);
Serial.print(" Lon: ");
Serial.println(lon);
if (lat < 0) // Southern Hemisphere?
digitalWrite(HEMISPHERE_PIN, HIGH);
else
digitalWrite(HEMISPHERE_PIN, LOW);
}
}
}


UNO can read NMEA formatted codes successfully. Here is part of printing in Serial monitoring window.

$GPVTG,,T,,M,0.005,N,0.010,K,A*27
$GPG.0306129,189762,,809,6.,.80
$GGV311,23627330,238490,528271,922,87
GGV,,,01,2,1,2135,0,1,6,0,201,4,7*B
GPS,,,1,32,013,8,0192*7
$PL,20.62,,189762E,5670,AA6
$GPRMC,153658.00,A,3206.16229,N,11849.75641,E,0.016,,120612,,,A*70
Latitude and longitude valid!
Lat: 3210270 Lon: 11882927

After input the position into GOOGLE Map in my iPhone, I found the error was so big, i.e. up to 200m, while the supplier says the error should be within 2m.
Can anyone tell me what is the reason? Thank you.

MarkT

The lat/long values you are printing out are in units of 1/100000 of a degree, note.

It might be that Google maps is way out, it might be you have a poor fix.  Take a fix outside away from buildings.  Also if its the first time the GPS module has been used you need to run it for several minutes continuously to update the almanac.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

achenal

#2
Jun 13, 2012, 04:44 pm Last Edit: Jun 13, 2012, 06:26 pm by achenal Reason: 1
Thank you MarkT.
I input 32.10270N,118.82927E position and find that the error is within 200m.
Yes I test the NEO-6M GPS module near the window for the first time.
BTW, I found the GPS coordinates of NEO-6M can be verified by another handed GPS device. Why?

achenal

It seems that the NMEA messages are not correct. Maybe 9600 baut rate is too high for Arduino?

Quote

$GPVTG,,T,,M,0.005,N,0.010,K,A*27
$GPG.0306129,189762,,809,6.,.80
$GGV311,23627330,238490,528271,922,87
GGV,,,01,2,1,2135,0,1,6,0,201,4,7*B
GPS,,,1,32,013,8,0192*7
$PL,20.62,,189762E,5670,AA6
$GPRMC,153658.00,A,3206.16229,N,11849.75641,E,0.016,,120612,,,A*70

extrablind

Hello,

Exactly same problem here, must wait 1 hour to have a poor fix. I have date and time from time to time.
GPS seems to drop bits…

Could someone help to understand this issue ?

Bye


gpaulucci

You have to set the Dilution of Precision (DOP) through UBX-CFG-NAV message. By default it is set 25.0. A DOP > 20 is considered a poor precision level. At this level, measurements are inaccurate by as much as 300 meters. You need to catch satellites as much separated as possible to get a good geometry to fit into the DOP you set. Between buildings or mountains you only catch satellites that are near one from the others not getting a valid position.
UBLOX6 protocol document says:
Important: To qualify a position as valid the gpsFixOK flag in the UBX-NAV-STATUS message must be checked. gpsFix=3D/3D in the UBX-NAV-STATUS message does not qualify a fix as valid and within the limits. To qualify a position as valid and within the pDop and pAcc limits set in the UBX-CFG-NAV5 message the gpsFixOK flag in the UBX-NAV-STATUS message has to be checked. [/i]

-dev

???  When you were posting, did you see the warning about how old this thread is?

Although the "poor fix" mentioned in the last post may be due to a bad DOP, the sample output from the OP and everyone else shows they are dropping characters, probably because they are not reading frequently enough.  This is a very common problem with the TinyGPS example programs.

Cheers,
/dev

jeff-jordan

Even so that the thread is very old, I do have to make a comment about this !

There seem to be modules with ublox chips in cirulation, that show a severe error in providing positioning data.
I've got a dashcam with an external GPS module, fitted with such a chip, and the error may go up to several kilometers.
I'ts quite curious, when your tracked route suddenly "jumps" a few kilometers beside the motorway :-P... (no, it's not a signal reflection problem, or a problem with unprecise route data, the error is too big for such effects).

The amount of the error depends on your location. There are wide areas, where you get (moderately) precise NMEA data, and suddenly, at a specific location, you seem to be beamed away a mile.

When connected to the arduino, you can see the wrong NMEA data arriving with 9600 baud while data from another module (other brand, maybe other chip) delivers correct positioning data.

greetz
Jeff

-dev

Quote
When connected to the arduino, you can see the wrong NMEA data arriving with 9600 baud while data from another module (other brand, maybe other chip) delivers correct positioning data.
I'm afraid your claim is a little vague.

I have seen this behavior in several other circumstances, and it was not due to the GPS module.  It is usually caused by electrical noise, poor reception, poor connections, poor serial software, poor GPS software or even poor loop structure.  In this thread, the OP problem was printing too much and using the super-inefficient SoftwareSerial.

Not that a defective or counterfeit ublox module is impossible, but there are so many other common causes that I would have to see your setup and your software before accepting your first post.  :)

BTW, it is rarely worth adding anecdotal evidence to an old thread.  Please consider starting a new thread with your specific symptoms.  The odds are good that your problems would be solved by using a better software serial library (AltSoftSerial or NeoSWSerial), a better GPS library (mine) and a better loop structure.  Maybe not, but I really can't see what you have tried so far.

Cheers,
/dev

jeff-jordan

Hi /dev,

Quote
BTW, it is rarely worth adding anecdotal evidence to an old thread
I think it's worth it, because we all use old threads as a knowledge base; and because I've no actual problem with it (just want to provide some additional information), there's no need to set up a new thread.
Or do you always want a new thread for problems already posted ? Haven't you ever proposed to newbies the use of the search button ?

Quote
It is usually caused by electrical noise, poor reception, poor connections, poor serial software, poor GPS software or even poor loop structure.
I believe you, that' you've noticed a similar behaviour due to all these circumstances.

But: everything already checked !

1st: In case of inacurate positioning data: these* modules with the problematic ublox chip provide, at a given unlucky location, a steady constand false value. Over hour's the same (wrong) NMEA data.
2nd: this does not change, even when I connect the devices directly thru a ftdi RS232 or ch340g  to the computer.
3rd: at the same location, other modules (like this) provide correct data.

*) both, the above already mentioned one from the cheap dashcam and the NEO-6M GPS.
Cheers,
Jeff

btw. I'm an electrical engineer for over 25 years now (finished uni in 1990) and only a newbie here at this forum not in electronics at all.

-dev

Quote
I think it's worth it, because we all use old threads as a knowledge base;
Yes, this is a great knowledge base.

My objection is that you did not recognize that the OP's problem as different from yours:  You provided an anecdote for different symptoms (and a different problem, IMO).  This made me question your conclusions.

The symptoms are interesting, though, and really merit a new post.  Here ya' go.

Cheers,
/dev

Go Up