Hi guys
I've been experimenting more as well from my end (after replacing the breadboard & cables), and I am still having the same problem. As Dave mentioned from his observations on the previous posts, the problem looks like it may not be in the wiring, but instead, on how the data is being parsed since the NMEA data shows that the data is being fed to the arduino, but the sketch/arduino cannot parse it correctly.
Even further, I've done some tests again today and I got the same "Fix: 1 quality 0" results. Below is what I got. Could this be a problem with the Adafruit GPS library? It looks like the GPS is supplying the necessary valid data to the Arduino, but the Arduino is reporting "Fix 1 quality 0" despite of the good data coming in.
Time: 19:9:24.984
Date: 31/1/2014
Fix: 1 quality: 0
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.04
Angle: 13.42
Altitude: 0.00
Satellites: 0
$PGTOP,11,3*6F
$GPGGA,190926.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,7,1.22,55.4,M,4.7,M,0000,0000*4C
$GPRMC,190926.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.07,13.42,310114,,,D*4C
$PGTOP,11,3*6F
$GPGGA,190927.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,7,1.22,55.4,M,4.7,M,0000,0000*4E
$GPRMC,190927.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.13,13.42,310114,,,D*4B
Time: 19:9:27.0
Date: 31/1/2014
Fix: 1 quality: 0
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.13
Angle: 13.42
Altitude: 0.00
Satellites: 0
$PGTOP,11,3*6F
$GPGGA,190928.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,7,1.22,55.3,M,4.7,M,0000,0000*47
$GPRMC,190928.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.16,13.42,310114,,,D*40
$PGTOP,11,3*6F
$GPGGA,190929.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,7,1.22,55.3,M,4.7,M,0000,0000*41
$GPRMC,190929.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.16,13.42,310114,,,D*46
Time: 19:9:28.984
Date: 31/1/2014
Fix: 1 quality: 0
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.16
Angle: 13.42
Altitude: 0.00
Satellites: 0
$PGTOP,11,3*6F
$GPGGA,190930.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,7,1.22,55.0,M,4.7,M,0000,0000*4A
$GPRMC,190930.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.18,13.42,310114,,,D*40
$PGTOP,11,3*6F
$GPGGA,190931.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,7,1.22,54.9,M,4.7,M,0000,0000*44
$GPRMC,190931.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.19,13.42,310114,,,D*47
$PGTOP,11,3*6F
$GPGGA,190932.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.52,54.7,M,4.7,M,0000,0000*46
$GPRMC,190932.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.19,13.42,310114,,,D*43
Time: 19:9:32.0
Date: 31/1/2014
Fix: 1 quality: 0
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.19
Angle: 13.42
Altitude: 0.00
Satellites: 0
$PGTOP,11,3*6F
$GPGGA,190933.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.52,54.6,M,4.7,M,0000,0000*47
$GPRMC,190933.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.21,13.42,310114,,,D*48
$PGTOP,11,3*6F
$GPGGA,190934.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.52,54.4,M,4.7,M,0000,0000*42
$GPRMC,190934.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.23,13.42,310114,,,D*4D
Time: 19:9:34.0
Date: 31/1/2014
Fix: 1 quality: 0
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.23
Angle: 13.42
Altitude: 0.00
Satellites: 0
$PGTOP,11,3*6F
$GPGGA,190935.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.52,54.3,M,4.7,M,0000,0000*44
$GPRMC,190935.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.24,13.42,310114,,,D*4B
$PGTOP,11,3*6F
$GPGGA,190936.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.52,54.0,M,4.7,M,0000,0000*44
$GPRMC,190936.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.27,13.42,310114,,,D*4B
$PGTOP,11,3*6F
$GPGGA,190937.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.1,M,4.7,M,0000,0000*45
$GPRMC,190937.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.27,13.42,310114,,,D*4A
Time: 19:9:36.984
Date: 31/1/2014
Fix: 1 quality: 0
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.27
Angle: 13.42
Altitude: 0.00
Satellites: 0
$PGTOP,11,3*6F
$GPGGA,190938.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.1,M,4.7,M,0000,0000*4E
$GPRMC,190938.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.24,13.42,310114,,,D*42
Time: 19:9:38.0
Date: 31/1/2014
Fix: 1 quality: 2
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.24
Angle: 13.42
Altitude: 54.10
Satellites:$PGTOP,11,3*6F
8
$GPGGA,190939.00
0,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.2,M,4.7,M,0000,0000*4B
$GPRMC,190939.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.23,13.42,310114,,,D*43
$PGTOP,11,3*6F
$GPGGA,190940.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.3,M,4.7,M,0000,0000*45
$GPRMC,190940.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.41,13.42,310114,,,D*48
$PGTOP,11,3*6F
$GPGGA,190941.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.2,M,4.7,M,0000,0000*46
$GPRMC,190941.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.39,13.42,310114,,,D*45
Time: 19:9:40.984
Date: 31/1/2014
Fix: 1 quality: 2
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.39
Angle: 13.42
Altitude: 54.20
Satellites: 8
$PGTOP,11,3*6F
$GPGGA,190942.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.2,M,4.7,M,0000,0000*46
$GPRMC,190942.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.31,13.42,310114,,,D*4D
$PGTOP,11,3*6F
$GPGGA,190943.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.5,M,4.7,M,0000,0000*41
$GPRMC,190943.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.24,13.42,310114,,,D*49
Time: 19:9:43.0
Date: 31/1/2014
Fix: 1 quality: 2
Location: XXXX.XXXXN, XXXXX.XXXXW
Speed (knots): 0.24
Angle: 13.42
Altitude: 54.50
Satellites: 8
$PGTOP,11,3*6F
$GPGGA,190944.000,XXXX.XXXX,N,XXXXX.XXXX,W,2,8,1.17,54.7,M,4.7,M,0000,0000*43
$GPRMC,190944.000,A,XXXX.XXXX,N,XXXXX.XXXX,W,0.05,13.42,310114,,,D*4A
$PGTOP,11,3*6F
$GPGGA,190945.000,XXXX.XXXX,N,15750.3810,W,2,8,1.17,54.9,M,4.7,M,0000,0000*4E
$GPRMC,190945.000,A,XXXX.XXXX,N,15750.3810,W,0.07,13.42,310114,,,D*4B
$PGTOP,11,3*6F
$GPGGA,190946.000,XXXX.XXXX,N,15750.3810,W,2,8,1.52,55.2,M,4.7,M,0000,0000*46
$GPRMC,190946.000,A,XXXX.XXXX,N,15750.3810,W,0.13,13.42,310114,,,D*4D
Fix Value with the Ultimate GPS Breakout
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- coding1227
- Posts: 32
- Joined: Tue Apr 30, 2013 5:00 pm
Re: Fix Value with the Ultimate GPS Breakout
Last edited by coding1227 on Sat Feb 01, 2014 5:52 pm, edited 1 time in total.
- adafruit_support_mike
- Posts: 67454
- Joined: Thu Feb 11, 2010 2:51 pm
Re: Fix Value with the Ultimate GPS Breakout
Are the NMEA sentences you posted everything that comes from the GPS module?
If so, it looks like the fix may be getting generated from information stored in the module, not from a connection with the satellites. You should get a $GPGSV sentence for every sattelite connection currently active.
If so, it looks like the fix may be getting generated from information stored in the module, not from a connection with the satellites. You should get a $GPGSV sentence for every sattelite connection currently active.
- coding1227
- Posts: 32
- Joined: Tue Apr 30, 2013 5:00 pm
Re: Fix Value with the Ultimate GPS Breakout
Hi Mike
yeah... what I posted is what I get from the GPS. The only thing I did was not include some earlier "paragraphs" so as not to clog up the forum. But what I posted is exactly as it comes out from the GPS.
yeah... what I posted is what I get from the GPS. The only thing I did was not include some earlier "paragraphs" so as not to clog up the forum. But what I posted is exactly as it comes out from the GPS.
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Fix Value with the Ultimate GPS Breakout
Mike - not so simple. This is one from the Twilight Zone. The GGA sentence is reporting a quality of 2 and 8 satellites, and the parser is still coming up with quality 0, satellites 0.adafruit_support_mike wrote:If so, it looks like the fix may be getting generated from information stored in the module, not from a connection with the satellites. You should get a $GPGSV sentence for every sattelite connection currently active.
Look at the parser output timestamped Time: 19:9:32.0. In the GPGGA sentence immediately above, the two fields after the 'W' are quality and # satellites. They are 2 and 8, yet the parser output is 0 and 0.
Looking at the library code, the only way for that to happen is if the parser encounters an unknown character where the 'N' or the 'W' are. It will then bail out without parsing the rest of the sentence.
1chicagodave pointed out a Twilight Zone companion feature. When parsing the latitude and longitude as FP numbers, it will sometimes give a fractional part which does not match that in the sentence. Floating-point roundoff, you say. Yes, except Dave shows an example where the fractional part is larger than the original ascii value
- adafruit_support_mike
- Posts: 67454
- Joined: Thu Feb 11, 2010 2:51 pm
Re: Fix Value with the Ultimate GPS Breakout
Ah.. I only skimmed the previous messages in the thread, so I'll leave this one to you and head back over to some of the Twilight Zone issues over in the RasPi forum.
- coding1227
- Posts: 32
- Joined: Tue Apr 30, 2013 5:00 pm
Re: Fix Value with the Ultimate GPS Breakout
Hi Rick
thanks for making time to look in such great detail at the issues I'm experiencing with Adafruit Ultimate GPS v3. I just wanted to check-in to see if you guys had found/are finding a way to correct the library's behavior?
thanks for making time to look in such great detail at the issues I'm experiencing with Adafruit Ultimate GPS v3. I just wanted to check-in to see if you guys had found/are finding a way to correct the library's behavior?
adafruit_support_rick wrote: Look at the parser output timestamped Time: 19:9:32.0. In the GPGGA sentence immediately above, the two fields after the 'W' are quality and # satellites. They are 2 and 8, yet the parser output is 0 and 0.
Looking at the library code, the only way for that to happen is if the parser encounters an unknown character where the 'N' or the 'W' are. It will then bail out without parsing the rest of the sentence.
1chicagodave pointed out a Twilight Zone companion feature. When parsing the latitude and longitude as FP numbers, it will sometimes give a fractional part which does not match that in the sentence. Floating-point roundoff, you say. Yes, except Dave shows an example where the fractional part is larger than the original ascii value
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Fix Value with the Ultimate GPS Breakout
I really don't know what's going on. All I have is a guess, which is that the GGA sentence is being over-written by the RMC sentence in the internal buffer. If you don't actually need any of the info in the GGA sentence, then you might want to turn it off. If all you care about is whether or not you have a good fix, then the RMC sentence contains that information.
Alternatively, you could try disabling the interrupt. In the setup() function, find the line that has the statement useInterrupt(true), and change the to useInterrupt(false).
That may or may not cause other problems, but I'd be interested in knowing if it gets rid of the fix-quality problem, because that would pretty much confirm my hypothesis about the buffer being overwritten.
Alternatively, you could try disabling the interrupt. In the setup() function, find the line that has the statement useInterrupt(true), and change the to useInterrupt(false).
That may or may not cause other problems, but I'd be interested in knowing if it gets rid of the fix-quality problem, because that would pretty much confirm my hypothesis about the buffer being overwritten.
-
- Posts: 564
- Joined: Wed Jun 19, 2013 3:35 am
Re: Fix Value with the Ultimate GPS Breakout
Short answer from my end...not really.
I'm currently using my GPS set up for an ongoing data-logging project involving lots of sensors and communication with a handful of Trinkets (which I'm pretty surprised even works!), so I am a bit weary to go experimenting with it right now.
I'm wondering if it might be a bizarre timing issue -
The default settings (in library, code) is 1HZ update rate (info from GPS) and print raw & parsed data every 2 seconds. Could it be that some coincidence between baud rate, buffer size, print timing, and the antenna check may be interrupting the parsing?
This theory doesn't really make a lot of sense to me...hence the descriptive, "bizarre". But, it's something....
Have you tried changing any other settings?
I'm curious what might happen if you disable the antenna update ($PGTOP...) and/or change the GPS baud rate and/or update rate?
Slightly related....? The GPS library 'saves' two consecutive series of sentences - one to print/echo, and one to parse. So, the raw NMEA sentence being printed on the screen is not the same one which is being parsed. Could it be possible that the second copy of the sentence (the one for parsing) is either the corrupted, cut-off, not a GGA sentence....other...?
**EDIT - Sorry, I didn't see Rick's response before I posted this. That makes (the most) sense. I forgot about that interrupt; I usually don't use it....to keep more control over things.
I'm currently using my GPS set up for an ongoing data-logging project involving lots of sensors and communication with a handful of Trinkets (which I'm pretty surprised even works!), so I am a bit weary to go experimenting with it right now.
I'm wondering if it might be a bizarre timing issue -
The default settings (in library, code) is 1HZ update rate (info from GPS) and print raw & parsed data every 2 seconds. Could it be that some coincidence between baud rate, buffer size, print timing, and the antenna check may be interrupting the parsing?
This theory doesn't really make a lot of sense to me...hence the descriptive, "bizarre". But, it's something....
Have you tried changing any other settings?
I'm curious what might happen if you disable the antenna update ($PGTOP...) and/or change the GPS baud rate and/or update rate?
Slightly related....? The GPS library 'saves' two consecutive series of sentences - one to print/echo, and one to parse. So, the raw NMEA sentence being printed on the screen is not the same one which is being parsed. Could it be possible that the second copy of the sentence (the one for parsing) is either the corrupted, cut-off, not a GGA sentence....other...?
**EDIT - Sorry, I didn't see Rick's response before I posted this. That makes (the most) sense. I forgot about that interrupt; I usually don't use it....to keep more control over things.
- coding1227
- Posts: 32
- Joined: Tue Apr 30, 2013 5:00 pm
Re: Fix Value with the Ultimate GPS Breakout
Sounds good. I will try this out and see how it goes... Thank you so much again for all your help!!
- coding1227
- Posts: 32
- Joined: Tue Apr 30, 2013 5:00 pm
Re: Fix Value with the Ultimate GPS Breakout
Dear Adafruit team
I'm writing again in order to follow-up on the problems mentioned previously in this thread. Since I am still working on my project that uses the Utlimate GPS, I just recently purchased a new Ultimate GPS unit since by this point I had "given up" and assumed there was something wrong with my GPS. In any case, to my surprise, upon connecting my new unit to my arduino Uno using pins 2 & 3 (exactly as shown in the tutorial, and using the original "Parsing" sketch within the Adafruit_GPS library, I am still experiencing the same problems as before!
Basically, there seems to be a few strange things happening:
1. the GPS unit (which has also a brand new external antenna connected to it) prints data that is highly unlikely to be correct (e.g.: it can sometimes print an angle of 0.00, or even a speed of 0.00).
2. another thing that I found is that the GPS seems to sometimes not "update" its data, since it can print the EXACT same parameters over and over [as seen in the example included below] (e.g.: atitude, longitude, angle, velocity) when clearly, the GPS should register some variations in these
3. also, if you look at the "Parsing" output included below, you will notice another strange issue. If you look closely at any two consecutive blocks of data, you will see that the time reported in the lower block corresponds to the $GPGGA/$GPRMC lines found in the block directly above it... BUT the lat & lon values reported in the lower block does NOT match the lat & lon values reported in the upper block
Therefore, since I would really like to be able to accurately use the GPS units that I recently bought, I was wondering if you could please help me solve the data issues I am experiencing.
Thank you so much in advance!!!
==================================================
Partial serial output:
Time: 22:31:48.984
Date: 24/3/2014
Fix: 1 quality: 1
Location: XXXX.XXXX, 15750.3769W
Speed (knots): 0.31
Angle: 0.00
Altitude: 49.00
Satellites: 5
$PGTOP,11,3*6F
$GPGGA,223150.000,XXXX.XXXX,N,XXXX.XXXX,W,1,5,1.62,49.0,M,4.7,M,,*44
$GPRMC,223150.000,A,XXXX.XXXX,N,XXXX.XXXX,W,0.30,0.00,240314,,,A*7B
$PGTOP,11,3*6F
$GPGGA,223151.000,XXXX.XXXX,N,XXXX.XXXX,W,1,5,1.62,49.0,M,4.7,M,,*46
$GPRMC,223151.000,A,XXXX.XXXX,N,XXXX.XXXX,W,0.27,0.00,240314,,,A*7F
Time: 22:31:51.0
Date: 24/3/2014
Fix: 1 quality: 1
Location: XXXX.XXXX, XXXX.XXXX
Speed (knots): 0.27
Angle: 0.00
Altitude: 49.00
Satellites: 5
$PGTOP,11,3*6F
$GPGGA,223152.000,XXXX.XXXX,N,XXXX.XXXX,W,1,5,1.62,49.0,M,4.7,M,,*4A
$GPRMC,223152.000,A,XXXX.XXXX,N,XXXX.XXXX,W,0.25,0.00,240314,,,A*71
$PGTOP,11,3*6F
$GPGGA,223153.000,2118.XXXX,N,XXXX.3771,W,1,5,1.62,49.0,M,4.7,M,,*4B
$GPRMC,223153.000,A,2118.XXXX,N,XXXX.3771,W,0.42,0.00,240314,,,A*71
I'm writing again in order to follow-up on the problems mentioned previously in this thread. Since I am still working on my project that uses the Utlimate GPS, I just recently purchased a new Ultimate GPS unit since by this point I had "given up" and assumed there was something wrong with my GPS. In any case, to my surprise, upon connecting my new unit to my arduino Uno using pins 2 & 3 (exactly as shown in the tutorial, and using the original "Parsing" sketch within the Adafruit_GPS library, I am still experiencing the same problems as before!
Basically, there seems to be a few strange things happening:
1. the GPS unit (which has also a brand new external antenna connected to it) prints data that is highly unlikely to be correct (e.g.: it can sometimes print an angle of 0.00, or even a speed of 0.00).
2. another thing that I found is that the GPS seems to sometimes not "update" its data, since it can print the EXACT same parameters over and over [as seen in the example included below] (e.g.: atitude, longitude, angle, velocity) when clearly, the GPS should register some variations in these
3. also, if you look at the "Parsing" output included below, you will notice another strange issue. If you look closely at any two consecutive blocks of data, you will see that the time reported in the lower block corresponds to the $GPGGA/$GPRMC lines found in the block directly above it... BUT the lat & lon values reported in the lower block does NOT match the lat & lon values reported in the upper block
Therefore, since I would really like to be able to accurately use the GPS units that I recently bought, I was wondering if you could please help me solve the data issues I am experiencing.
Thank you so much in advance!!!
==================================================
Partial serial output:
Time: 22:31:48.984
Date: 24/3/2014
Fix: 1 quality: 1
Location: XXXX.XXXX, 15750.3769W
Speed (knots): 0.31
Angle: 0.00
Altitude: 49.00
Satellites: 5
$PGTOP,11,3*6F
$GPGGA,223150.000,XXXX.XXXX,N,XXXX.XXXX,W,1,5,1.62,49.0,M,4.7,M,,*44
$GPRMC,223150.000,A,XXXX.XXXX,N,XXXX.XXXX,W,0.30,0.00,240314,,,A*7B
$PGTOP,11,3*6F
$GPGGA,223151.000,XXXX.XXXX,N,XXXX.XXXX,W,1,5,1.62,49.0,M,4.7,M,,*46
$GPRMC,223151.000,A,XXXX.XXXX,N,XXXX.XXXX,W,0.27,0.00,240314,,,A*7F
Time: 22:31:51.0
Date: 24/3/2014
Fix: 1 quality: 1
Location: XXXX.XXXX, XXXX.XXXX
Speed (knots): 0.27
Angle: 0.00
Altitude: 49.00
Satellites: 5
$PGTOP,11,3*6F
$GPGGA,223152.000,XXXX.XXXX,N,XXXX.XXXX,W,1,5,1.62,49.0,M,4.7,M,,*4A
$GPRMC,223152.000,A,XXXX.XXXX,N,XXXX.XXXX,W,0.25,0.00,240314,,,A*71
$PGTOP,11,3*6F
$GPGGA,223153.000,2118.XXXX,N,XXXX.3771,W,1,5,1.62,49.0,M,4.7,M,,*4B
$GPRMC,223153.000,A,2118.XXXX,N,XXXX.3771,W,0.42,0.00,240314,,,A*71
Last edited by coding1227 on Fri Mar 28, 2014 8:12 pm, edited 1 time in total.
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Fix Value with the Ultimate GPS Breakout
This problem is certainly unrelated to the GPS module itself. It's a buffering issue in the library. What is your update rate set to? Try it at 1Hz, and see if the problems go away.
- coding1227
- Posts: 32
- Joined: Tue Apr 30, 2013 5:00 pm
Re: Fix Value with the Ultimate GPS Breakout
Hi Rick
yeah... I'm not sure what's going on. The update rate has always been set to 1 Hz. I am using the original "parsing sketch" from the Adafruit_GPS library (without any modifications at all).
yeah... I'm not sure what's going on. The update rate has always been set to 1 Hz. I am using the original "parsing sketch" from the Adafruit_GPS library (without any modifications at all).
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Fix Value with the Ultimate GPS Breakout
Do you need the PGTOP and GGA sentences? If not, turn them off.
- coding1227
- Posts: 32
- Joined: Tue Apr 30, 2013 5:00 pm
Re: Fix Value with the Ultimate GPS Breakout
I do need the GGA and RMC statements, but not the PGTOP (antenna info).
I'd be glad to try to disable the PGTOP statement. Could you tell me exactly how to do this?
I'd be glad to try to disable the PGTOP statement. Could you tell me exactly how to do this?
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Fix Value with the Ultimate GPS Breakout
In the parsing sketch, comment out this line in setup()
Code: Select all
// Request updates on antenna status, comment out to keep quiet
//GPS.sendCommand(PGCMD_ANTENNA);
Please be positive and constructive with your questions and comments.