GPS NMEA problems

Started by "guntis.laurins" March 4, 2008
Hello

I woudl like to use DateTimeNMEA.zip example !!! With my GPS device
GPS_Text_Decoder.zip works great, but DateTimeNMEA.bas with
serial_24.bas and also Support_24.bas do not work :/ Where must be
time there is only text that counts all the time:

1999-01-01 00:00:01
1999-01-01 00:00:02
1999-01-01 00:00:03
1999-01-01 00:00:04
1999-01-01 00:00:05
1999-01-01 00:00:06
1999-01-01 00:00:07

Why is that, and what I havn't done jet ???
Ou by the way, in the begining DateTimeNMEA example don't like this
text row so I change it to coment, I hope that it is ok ???

'call PutPin(GreenLED, LED)

strX=cstr(cint(bMonth)+100)
strY=cstr(cint(bDay)+100)
> ...
> 1999-01-01 00:00:01
> 1999-01-01 00:00:02
> 1999-01-01 00:00:03
>

DateTimeNMEA.bas sets the BX-24 RTC to a decoded and checksummed $GPRMC
NMEA sentence. If the GPS receiver hasn't yet established its position,
it might not be issuing a valid sentence. In that case, the BX-24 RTC
will start at its zero, which is 1999-01-01 00:00:00, as you've found.

Until it receives valid RMC data, it will show the time you see. If you
are sure that a valid RMC is being issued, perhaps the serial speed is
incorrect; the normal is 4800 baud.

If you still can't get it to display the correct current time, capture a
few lines of data and post it here, please.
Tom
--- In b..., Tom Becker wrote:
>
> > ...
> > 1999-01-01 00:00:01
> > 1999-01-01 00:00:02
> > 1999-01-01 00:00:03
> >
>
> DateTimeNMEA.bas sets the BX-24 RTC to a decoded and checksummed $GPRMC
> NMEA sentence. If the GPS receiver hasn't yet established its
position,
> it might not be issuing a valid sentence. In that case, the BX-24 RTC
> will start at its zero, which is 1999-01-01 00:00:00, as you've found.
>
> Until it receives valid RMC data, it will show the time you see. If
you
> are sure that a valid RMC is being issued, perhaps the serial speed is
> incorrect; the normal is 4800 baud.
>
> If you still can't get it to display the correct current time,
capture a
> few lines of data and post it here, please.
> Tom
>

Thanks Tom for so quick respond :)

GPS Device give me this code in NMEA 4800

$GPRMC,122950,A,5656.4802,N,02409.3489,E,0.0,324.0,1902085.8,E,A*1B
$GPRMB,A,0.00,L,,SIGULD,5708.61,N,02450.922,E,25.760,61.5,,V,A*74
$GPGGA122950,5656.4802,N,02409.3489,E,1,09,0.9,2.9,M,24.8,M,,*7A
$GPGSA,A,3,01,03,09,11,1417,19,20,,28,,,1.6,0.9,1.3*36
$GPGSV,3,1,1,01,51,138,52,03,07,178,47,09,12,021,45,11,3,280,51*7B
$GPGSV,3,2,10,14,53,086,43,17,0,327,50,19,34,192,52,20,17,246,51*7D
$GPGS,3,3,10,22,29,071,51,28,16,300,50*7A
$GPGL,5656.4802,N,02409.3489,E,122950,A,A*4D
$GPOD,61.5,T,55.7,M,SIGULD,*42
$PGRME,5.0,M,79,M,9.4,M*28
$PGRMZ,91,f,3*23
$GPRTE,1,1,,*37
$GPRMC,122952,A,5656.4802,N,02409.3489,E,0.0,324.0,1902085.8,E,A*19
$GPRMB,A,0.00,L,,SIGULD,5708.61,N,02450.922,E,25.760,61.5,,V,A*74
$GPGGA,22952,5656.4802,N,02409.3489,E,1,09,0.9,27.,M,24.8,M,,*79
$GPGSA,A,3,01,03,09,11,14,1,19,20,,28,,,1.6,0.9,1.3*36
$GPGSV,3,1,1001,51,138,53,03,07,178,47,09,12,021,45,11,5,280,51*7A
$GPGSV,3,2,10,14,53,086,43,17,0,327,50,19,34,192,52,20,17,246,51*7D
$GPGS,3,3,10,22,29,071,52,28,16,300,50*79
$GPGL,5656.4802,N,02409.3489,E,122952,A,A*4F
$GPOD,61.5,T,55.7,M,SIGULD,*42
$PGRME,5.0,M,.9,M,9.4,M*28
$PGRMZ,91,f,3*23
$GPRTE,1,1c,*37

>From that data I suppose, that every thing is established or maybe I'm
wrong ???
NMEA2.3 from eTrex:
$GPRMC,235048,A,2633.3315,N,08201.5261,W,0.0,124.5,230201,4.5,W,A*19
NMEA from your device:
$GPRMC,122950,A,5656.4802,N,02409.3489,E,0.0,324.0,1902085.8,E,A*1B

There appears to be a missing comma after the date; I suspect that
there should be a comma that separates the date from the magnetic
variation, so I think your RMC sentence should look like:
$GPRMC,122950,A,5656.4802,N,02409.3489,E,0.0,324.0,190208,5.8,E,A*1B ,
indicating a date of 190208 (19 Feb 2008) and a magnetic variation of
5.8 degrees east. Somehow, that comma is dropped, which will cause a
checksum error and, therefore, a lack of validation. There is also a
missing comma in the first of your GGA sentences - and there are
probably other missing bytes on close examination.

Perhaps your input queue or an internal string variable is
insufficiently large?

According to http://www.gpsinformation.org/dale/nmea.htm#RMC , the RMC
(NMEA2.3) sentence structure is:
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
Where:
RMC Recommended Minimum sentence C
123519 Fix taken at 12:35:19 UTC
A Status Ative or V=Void.
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
022.4 Speed over the ground in knots
084.4 Track angle in degrees True
230394 Date - 23rd of March 1994
003.1,W Magnetic Variation
*6A The checksum data always begins with *
Tom
--- In b..., "Tom Becker" wrote:
>
> NMEA2.3 from eTrex:
> $GPRMC,235048,A,2633.3315,N,08201.5261,W,0.0,124.5,230201,4.5,W,A*19
> NMEA from your device:
> $GPRMC,122950,A,5656.4802,N,02409.3489,E,0.0,324.0,1902085.8,E,A*1B
>
> There appears to be a missing comma after the date; I suspect that
> there should be a comma that separates the date from the magnetic
> variation, so I think your RMC sentence should look like:
> $GPRMC,122950,A,5656.4802,N,02409.3489,E,0.0,324.0,190208,5.8,E,A*1B ,
> indicating a date of 190208 (19 Feb 2008) and a magnetic variation of
> 5.8 degrees east. Somehow, that comma is dropped, which will cause a
> checksum error and, therefore, a lack of validation. There is also a
> missing comma in the first of your GGA sentences - and there are
> probably other missing bytes on close examination.
>
> Perhaps your input queue or an internal string variable is
> insufficiently large?
>
> According to http://www.gpsinformation.org/dale/nmea.htm#RMC , the RMC
> (NMEA2.3) sentence structure is:
> $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
> Where:
> RMC Recommended Minimum sentence C
> 123519 Fix taken at 12:35:19 UTC
> A Status Ative or V=Void.
> 4807.038,N Latitude 48 deg 07.038' N
> 01131.000,E Longitude 11 deg 31.000' E
> 022.4 Speed over the ground in knots
> 084.4 Track angle in degrees True
> 230394 Date - 23rd of March 1994
> 003.1,W Magnetic Variation
> *6A The checksum data always begins with *
> Tom
>
Hmm... You are right :/ Maby it is because of 10 om resistance, I did
not use it, because with out it on GPS_Text_Decoder example
everything was workind fine , but now I think that why comas is
mising, Tommorow I will chek it :))
Really Thanks Tom :)
>> ... Perhaps your input queue or an internal string variable is
insufficiently large?
> ... What can I do about it ?

In SerialPort_24.bas, find this line:
private const InBufSize_3 as INTEGER = 13 ' 4-byte buffer.

Change the 13 to something larger. Nine bytes of queue overhead are
required, so a 10-byte queue length can hold one byte of buffered
data. Try changing 13 to 20, which will give you 11 bytes of buffering.
Tom
--- In b..., "Tom Becker" wrote:
>
> >> ... Perhaps your input queue or an internal string variable is
> insufficiently large?
> > ... What can I do about it ?
>
> In SerialPort_24.bas, find this line:
> private const InBufSize_3 as INTEGER = 13 ' 4-byte buffer.
>
> Change the 13 to something larger. Nine bytes of queue overhead are
> required, so a 10-byte queue length can hold one byte of buffered
> data. Try changing 13 to 20, which will give you 11 bytes of buffering.
> Tom
>
Ok I will try :) Thanks again :)
Ehh... I chek also with 10 om resistance, and nothing different :/

If You are right about that Tom:

> > Perhaps your input queue or an internal string variable is
> > insufficiently large?

What can I do about it ???

To help you understand the problem I get some other data from GPS
device look:

1. I Chek NMEA data direktly from GPS Device to my PC, and with that
data commas are not mising !!!

2. I notice that also in GPSTextDecoder example my data is different
because when "Const RawText As Boolean = True" in com3 I see

@080226110535N5656480E02409350G005+00029E0000N0000D0000

Bet when "Const RawText As Boolean = False" in debug.print I see

Time: 11:04:45
Longitude: 55.84909
Latidude: 24.15582
Hight: 30 m
Velocity: 0 m/s
Velocity: 0 m/s
Velocity: 0 m/s

How do you think, why latitude and longitude is diffirent value if
compear to debug.print and what I can see in com3 ???

3. About NMEA if I do not do the Validity and simply ask some other
data, they are like those:

1999-01-01 cbyte(bLonDM(1)) 104 cbyte(bLonDM(4))30.252 00:00:20
1999-01-01 cbyte(bLonDM(1)) 104 cbyte(bLonDM(4))30.252 00:00:21
1999-01-01 cbyte(bLonDM(1)) 104 cbyte(bLonDM(4))30.252 00:00:22
1999-01-01 cbyte(bLonDM(2)) 36 cbyte(bLonDM(3))172.12 00:00:03
1999-01-01 cbyte(bLonDM(2)) 36 cbyte(bLonDM(3))172.12 00:00:04
1999-01-01 cbyte(bLonDM(2)) 36 cbyte(bLonDM(3))172.12 00:00:05
and the bad news is that nothing change when I disconect GPS receiver
rx pin from Basicx24 pin 20, all the time there is only those rows

4. And one mor thing about pin 20 :

if in GPSTextDecoder example I put "Const RawText As Boolean = True"
and rx pin I define not pin 16 as in example, but pin 20, I can see
only full rows with small quadrangls, but when I put back
SerialInputPin from 20 to 16 , I get the same data with text out
protokol why my pin 20 is different ???

I will try to uploade my projekt in our yahoo grope File folder, and I
realy hope that this info help you to understand what I have done
wrong :/ ???





Just from working with this code this semester, this is some of the
thoughts i have about the subject:

Using this program with the RMC sentence, it checks for the "A"
or "V" for a valid sentence. If you are not getting a valid sentence
("A" from a live GPS signal), it will not set the time or date and
will continually count until it gets a sentence that is valid. You
can comment these check validity statements out if you are working
inside and you are not getting a GPS signal. To test, and if you
aren't getting a signal, the gps continues from the last time it had
signal and continues it's timer/lat/lon from there. Without the valid
checks, it should set the time and date.

To touch on the GPS sentences, I'm not sure about the eTrex but on
the GPS 18 you can configure it to send out only the sentences you
need.
> ... the typical GPS receiver can easily swamp the BX24 with too much
data...

That has not been my experience, Paul. I've done a number of BX-24 GPS
apps since I wrote DateTimeNMEA.bas six or so years ago. My experience
is that - as long as the input queue length is sufficient and the code
discards bytes between an uninteresting sentence type (in this case,
anything other than GPRMC) and the following "$" - the processor can
keep up fine. The data rate is only 480 Bytes/second at 4800 baud,
worst case; the queue can handle that speed without code involvement
quite easily, if it is large enough. Nevertheless, the suggestion to
reduce the input data volume my disabling NMEA sentences that you don't
need, if you can, is wise.

GPS_Text_Decoder, BTW, provides only one byte of input buffering. It is consequently very easy to overrun that code.
Tom