Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

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)



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ...
> 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



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, 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 ???



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

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 A=active 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



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, "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 A=active 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 :)



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

>> ... 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



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, "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 :)



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Ehh... I chek also with 10 om resistance, and nothing different :/

If You are right about that Tom:=20

> > 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 =3D True" in com3 I see=20

@080226110535N5656480E02409350G005+00029E0000N0000D0000

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

Time: 11:04:45
Longitude: 55.84909=B0
Latidude: 24.15582=B0
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 =3D 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 ???=20

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 :/ ???=20

ˆˆˆˆˆˆˆˆˆˆˆˆ
=
36;ˆˆˆˆˆˆˆˆˆˆˆˆ=
ˆˆˆˆˆ

=20

=20


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

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.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... 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



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, "p_dubinsky" wrote:
>
> I did some GPS work a few years ago and found a couple of things that
> made life very difficult for the BX24. Most GPS receivers straight out
> of the box, are configured to send a wide assortment of sentences
> every minute. This message load is very close to (or beyond) the limit
> of what the BX24 can process. If you do any real processing of the
> messages at all, a small receive buffer will easily be overrun. The
> only recourse is to greatly increase the size of the buffer as Tom
> accurately points out.
>
> A helpful approach is to use whatever utility software that came with
> the receiver and limit the number of messages that the receiver will
> return every minute. In my application, I only needed to use two
> sentences to get the data that I wanted so I sent a message to the
> receiver that told it not to send any other messages unless
> specifically requested by my application. That got the load down to
> something that the BX24 could handle. Ultimately, I changed the
> processor module to a different module to eliminate the problem.
>
> In short, the typical GPS receiver can easily swamp the BX24 with too
> much data. You'll have to write some very tidy, efficient code to keep
> up. Considering my sloppy code, it was easier to change processors
> that write code that was efficient enough to keep up.
>
> Good luck,
> Paul
>
> --- In b...@yahoogroups.com, "Tom Becker" wrote:
> >
> > >> ... Perhaps your input queue or an internal string variable is
> > insufficiently large?
> > > ... What can I do about it ?
> > *** snippage ***
>
> > Tom
> You bouth must be right, because when I start testing these GPS
examples, Basicx 24 very often send me error, that there is some
problem with Eprom and thats why I can't download data to basicx24 or
so, It hapened only when I download data from PC to Basicx24, tomorrow
I will change that buffer integer from 13 to 20 and I hope that
finally everything will work :) Thank you for your support :)



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Tom,

You obviously missed the part about my sloppy code . I didn't mean
to say that it couldn't be done, just that my app (which was doing
quite a bit of post data processing) was having trouble keeping up. I
used a US Globalsat receiver, the BR-355, which is an inexpensive,
serial interface device that is easy to manipulate. I reduced the data
to 2 sentences and that made life easy.

Paul

--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ... 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
>



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

>> ... 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



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Hi,

I have been follow your problem and I have a suggestion. Hook up your GPS to one of your computer serial port and use hyper terminal to communicate with the GPS.? If you receive the information allright then the problem is in the connection between the BX 24 and the GPS. Also you can see the format that your GPS is sending back.

rosarite

-----Original Message-----
From: guntis.laurins
To: b...@yahoogroups.com
Sent: Fri, 7 Mar 2008 12:33 pm
Subject: [BasicX] Re: GPS NMEA problems

--- In b...@yahoogroups.com, "p_dubinsky" wrote:

>

> Tom,

>

> You obviously missed the part about my sloppy code . I didn't mean

> to say that it couldn't be done, just that my app (which was doing

> quite a bit of post data processing) was having trouble keeping up. I

> used a US Globalsat receiver, the BR-355, which is an inexpensive,

> serial interface device that is easy to manipulate. I reduced the data

> to 2 sentences and that made life easy.

>

> Paul

>

> --- In b...@yahoogroups.com, Tom Becker wrote:

> >

> > > ... 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

> >

>

Brr... It still do not want to work :/

I put private const InBufSize_3 as INTEGER = 20 ' 4-byte buffer.

even more, untill 40 and the same sentence

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

The good news is that I think that commas are not mising now in GPRMC

row, look:

$GPRMC,094306,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*7A

$PGRMT,GPS 25-LV VER 2.50 ,P,P,R,R,P,,35,R*1B

$GPGGA,09430,5656.2838,N,02409.2163,E,1,11,0.8,40.5,M,2.8,M,,*75

$GPGSA,A,3,03,06,08,15,16,18,19,1,22,26,32,,1.3,0.8,1.1*31

$GPGSV,3,1,11,0,68,225,51,06,05,138,54,08,09,327,54,15,17,03,55*7B

$GPGSV,3,2,11,16,14,204,54,18,52,05,43,19,51,289,51,21,25,086,54*76

$GPGSV,33,11,22,60,159,51,26,13,021,54,32,38,191,5,,,,*44

$GPRMC,094307,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*7B

$GPGGA,094307,556.2838,N,02409.2163,E,1,11,0.8,40.5,M,24.8,,,*74

$GPGSA,A,3,03,06,08,15,16,18,19,21,2,26,32,,1.3,0.8,1.1*31

$GPGSV,3,1,11,03,68225,53,06,05,138,54,08,09,327,54,15,17,033,5*79

$GPGSV,3,2,11,16,14,204,54,18,52,075,48,9,51,289,52,21,25,086,54*7E

$GPGSV,3,3,11,2,60,159,52,26,13,021,54,32,38,191,52,,,,*5

$GPRMC,094308,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*74

$GPGGA,094308,566.2838,N,02409.2163,E,1,11,0.8,40.5,M,24.8,,,*7B

$GPGSA,A,3,03,06,08,15,16,18,19,21,2,26,32,,1.3,0.8,1.1*31

$GPGSV,3,1,11,03,68225,54,06,05,138,54,08,09,327,54,15,17,033,5*7E

$GPGSV,3,2,11,16,14,204,54,18,52,075,5,19,51,289,53,21,25,086,54*77

$GPGSV,3,3,1,22,60,159,53,26,13,021,54,32,38,191,53,,,*45

but still the same: "1999-01-01 00:00:01"

I think that Tom is right about that, there is too many data and

Basicx just swaps down, but is there some way, how can I get to know

this fact ???

And when I try to download software to basicx, 9 times of 10 will be

error "EEPROM Download Error" why I always get this ???, is these

because of too many data from GPS Device ???

I think that with some software I can get only GPRMC data, but If I

want robot only with basicx and GPS device, how can I tell to my eTrex

to give my only GPRMC data, in Setup there is only option "Interface"

where you can onle put NMEA or text out or other protocol ???

Maybe with my hardweare something is wrong, Tom, Can You test my

projekt on your Basicx24 and GPS ???

or maybe someone can send me to my e-mail g...@gmail.com

Yours projekt Where you sure know that DateTimeNMEA example realy

works ???

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I did some GPS work a few years ago and found a couple of things that
made life very difficult for the BX24. Most GPS receivers straight out
of the box, are configured to send a wide assortment of sentences
every minute. This message load is very close to (or beyond) the limit
of what the BX24 can process. If you do any real processing of the
messages at all, a small receive buffer will easily be overrun. The
only recourse is to greatly increase the size of the buffer as Tom
accurately points out.

A helpful approach is to use whatever utility software that came with
the receiver and limit the number of messages that the receiver will
return every minute. In my application, I only needed to use two
sentences to get the data that I wanted so I sent a message to the
receiver that told it not to send any other messages unless
specifically requested by my application. That got the load down to
something that the BX24 could handle. Ultimately, I changed the
processor module to a different module to eliminate the problem.

In short, the typical GPS receiver can easily swamp the BX24 with too
much data. You'll have to write some very tidy, efficient code to keep
up. Considering my sloppy code, it was easier to change processors
that write code that was efficient enough to keep up.

Good luck,
Paul

--- In b...@yahoogroups.com, "Tom Becker" wrote:
>
> >> ... Perhaps your input queue or an internal string variable is
> insufficiently large?
> > ... What can I do about it ?
>

*** snippage ***

> Tom
>



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> $GPRMC,094306,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*7A

Why does your GPS say today that the date is 22Feb2008?
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, rosarite@... wrote:
> Hi,
>
> I have been follow your problem and I have a suggestion. Hook up
your GPS to one of your computer serial port and use hyper terminal to
communicate with the GPS.? If you receive the information allright
then the problem is in the connection between the BX 24 and the GPS.
Also you can see the format that your GPS is sending back.
>
> rosarite

Problem definetly is in the connection between the BX 24 and the GPS
because I put directly GPS serial to PC COM1 and with Basicx Software
in boudrate 4800 I get data where commas ar not mising .

$GPRMC,094306,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*7A



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, "Tom Becker" wrote:
>
> > $GPRMC,094306,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*7A
>
> Why does your GPS say today that the date is 22Feb2008?
> Tom
>
With that thata every thing is ok because these data was simulated
from some kind of server, I dont know how they do that in our
university GPS laboratory, but in the rooms with that we can see real
data and also some kind of data, that are simulated.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I'm working with VB6 and my BX24 with modified code that was on the
BasicX.com site. I'm trying to send a string of text from my BX24 to my PC.
So far it is working but during my test I notice the first character in the
string is always a dec 5 (ENQ). I have MSCOMM input mode set to text and
right now I have the length set to 6, port is at 19200,n,8,1 with no
handshaking. Input buffer is 1024 bytes and output buffer is 512 bytes.

I've checked my BX24 code and in test I have it sending a temperature
(64.45) but the ENQ character always is first. Is there a setting on MSCOMM
or BX24 I need to change to stop this?
22680/stime=1204959225/nc1=3848614/nc2=4507179/nc3=4025338>

thanks
David

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... MSCOMM input [] length set to 6...

Try setting that to zero.

Perhaps it is not related, but "64.45" is five bytes; ENQ is 05.
Basic-X strings use the first byte to describe the string length but
it is not easy to misuse that structure - so I think it's unlikely
you're actually transmitting that byte from the BX-24 - but it is
possible if inadvertently done correctly. Perhaps you've stumbled
into that.

If changing the MSCOMM InputLen property doesn't fix it, show us how
you display this string in BasicX.
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, "p_dubinsky" wrote:
>
> Tom,
>
> You obviously missed the part about my sloppy code . I didn't mean
> to say that it couldn't be done, just that my app (which was doing
> quite a bit of post data processing) was having trouble keeping up. I
> used a US Globalsat receiver, the BR-355, which is an inexpensive,
> serial interface device that is easy to manipulate. I reduced the data
> to 2 sentences and that made life easy.
>
> Paul
>
> --- In b...@yahoogroups.com, Tom Becker wrote:
> >
> > > ... 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
>

Brr... It still do not want to work :/

I put private const InBufSize_3 as INTEGER = 20 ' 4-byte buffer.

even more, untill 40 and the same sentence

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

The good news is that I think that commas are not mising now in GPRMC
row, look:

$GPRMC,094306,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*7A
$PGRMT,GPS 25-LV VER 2.50 ,P,P,R,R,P,,35,R*1B
$GPGGA,09430,5656.2838,N,02409.2163,E,1,11,0.8,40.5,M,2.8,M,,*75
$GPGSA,A,3,03,06,08,15,16,18,19,1,22,26,32,,1.3,0.8,1.1*31
$GPGSV,3,1,11,0,68,225,51,06,05,138,54,08,09,327,54,15,17,03,55*7B
$GPGSV,3,2,11,16,14,204,54,18,52,05,43,19,51,289,51,21,25,086,54*76
$GPGSV,33,11,22,60,159,51,26,13,021,54,32,38,191,5,,,,*44
$GPRMC,094307,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*7B
$GPGGA,094307,556.2838,N,02409.2163,E,1,11,0.8,40.5,M,24.8,,,*74
$GPGSA,A,3,03,06,08,15,16,18,19,21,2,26,32,,1.3,0.8,1.1*31
$GPGSV,3,1,11,03,68225,53,06,05,138,54,08,09,327,54,15,17,033,5*79
$GPGSV,3,2,11,16,14,204,54,18,52,075,48,9,51,289,52,21,25,086,54*7E
$GPGSV,3,3,11,2,60,159,52,26,13,021,54,32,38,191,52,,,,*5
$GPRMC,094308,A,5656.2838,N,02409.2163,E,0000,000.0,220208,005.3,E*74
$GPGGA,094308,566.2838,N,02409.2163,E,1,11,0.8,40.5,M,24.8,,,*7B
$GPGSA,A,3,03,06,08,15,16,18,19,21,2,26,32,,1.3,0.8,1.1*31
$GPGSV,3,1,11,03,68225,54,06,05,138,54,08,09,327,54,15,17,033,5*7E
$GPGSV,3,2,11,16,14,204,54,18,52,075,5,19,51,289,53,21,25,086,54*77
$GPGSV,3,3,1,22,60,159,53,26,13,021,54,32,38,191,53,,,*45

but still the same: "1999-01-01 00:00:01"

I think that Tom is right about that, there is too many data and
Basicx just swaps down, but is there some way, how can I get to know
this fact ???

And when I try to download software to basicx, 9 times of 10 will be
error "EEPROM Download Error" why I always get this ???, is these
because of too many data from GPS Device ???

I think that with some software I can get only GPRMC data, but If I
want robot only with basicx and GPS device, how can I tell to my eTrex
to give my only GPRMC data, in Setup there is only option "Interface"
where you can onle put NMEA or text out or other protocol ???

Maybe with my hardweare something is wrong, Tom, Can You test my
projekt on your Basicx24 and GPS ???

or maybe someone can send me to my e-mail g...@gmail.com
Yours projekt Where you sure know that DateTimeNMEA example realy
works ???



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Tom,
=20
I tried that and that is where it is set now. Actually I'm getting two
extra characters ENQ and 255. To "fix" it for now I just filter the buffer
thru a non-alpanumeric filter in VB. Of course this doesn't explain why I'=
m
getting them.
=20
I'm using Peter Anderson's code for the DS1820
http://www.phanderson.com/bx24/ds1820_1.html . To make things simple while
testing I put T_C in a variable called strTemp with strTemp=3Dcstr(T_C) but=
I
do convert T_C to farenheit prior to assigning it and I removed any code fo=
r
the com port and sending the output to the LCD. Since I will have 4
different sensors I prefix them with a code so for the temp from the DS1820
comes across as K59.25 for example and a second sensor from my analog
temperature contoller comes across as F378 which is read from one of the AD=
C
pins. Actually there are 3 DS1820s but I have them attached to seperate
pins so I'm sending 4 chunks of data with 3 being temperatures and the othe=
r
being a voltage reference. The input and output queues are set to 30 bytes
each and when I send out the data I'm send 8 bytes even though the most I
would probably be sending is 5 (K59.2)
=20
Using the code from the BasicX site I changed the input mode from binary to
text and now the input length is 0. In VB I send a command byte of 255 to
the BasicX which is running in a loop checking the queue and if it receives
the command byte it sends back the temperature and the reading from the ADC=
.
FWIW I then use the prefix character to determine what reading I got back.
If I look at the input buffer before any changes to the buffer contents, th=
e
first reading for example it will actually look like this: =05=FFK61.7.
Checking the value of the first two characters I come up with 5 and 255 the=
n
of course my reading from the DS1820 but the strTemp that I send out does
not contain those characters at least from what I can tell from the code.
In the original code for the BX and VB you can use it to send and receive b=
y
using different command bytes but for my test I just have a timer event
every 5 seconds that polls the BX and waits for the return data because
right now I don't have plans on changing any data in the BX I just want the
PC to receive it. The 2 characters come across on all 4 data chunks that
sent.
=20
For the ADC reference it just reads the pin, puts the reading in
strTemp=3Dcstr(iV) and then I prefix string with strTemp=3D"F" & strTemp an=
d out
the com port it goes. So I'm not sure where or why I'm getting the
additional characters. Like I said the filter "fixes" the problem but it
would be nice to know. This is probably not the best way to do this but it
was the only way I knew how with help from the other code modules and in
testing it has been running for several hours without any problems.
=20
David

_____=20=20

From: b...@yahoogroups.com [mailto:b...@yahoogroups.com] On Behalf Of
Tom Becker
Sent: Saturday, March 08, 2008 10:54 PM
To: b...@yahoogroups.com
Subject: [BasicX] Re: BX24 to PC - Extra character

> ... MSCOMM input [] length set to 6...

Try setting that to zero.

Perhaps it is not related, but "64.45" is five bytes; ENQ is 05.=20
Basic-X strings use the first byte to describe the string length but
it is not easy to misuse that structure - so I think it's unlikely
you're actually transmitting that byte from the BX-24 - but it is
possible if inadvertently done correctly. Perhaps you've stumbled
into that.

If changing the MSCOMM InputLen property doesn't fix it, show us how
you display this string in BasicX.

Tom

=20
[Non-text portions of this message have been removed]

=20

=20


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ... 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
>

> reduce the input data volume my disabling NMEA sentences that you don't
> need, if you can, is wise.

How Can I disabling NMEA sentences in Garmin etrex, is there some
software that can do that ??? Can I do that with VisualGPS or
GPSUtility, if Yes, then where can I do it ???



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ...How Can I disable NMEA sentences in Garmin etrex...

I no longer have a functioning eTrex after disassembling the thing when
the LCD failed so I cannot test one for you, but I cannot find any
Internet reference to selectable NMEA sentences from any eTrex model.
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, "guntis.laurins"
wrote:
>
> --- In b...@yahoogroups.com, Tom Becker wrote:
> >
> > > ...How Can I disable NMEA sentences in Garmin etrex...
> >
> > I no longer have a functioning eTrex after disassembling the thing
when
> > the LCD failed so I cannot test one for you, but I cannot find any
> > Internet reference to selectable NMEA sentences from any eTrex model.
> >
> >
> > Tom
> >
> 1. is There any software for selectable NMEA sentences ???
>
> 2. can You send me compiled Project with DateTimeNMEA.bas,
> Serial_24.bas and Support_24.bas , Maybe I did something simple and
> stupid wrong in my project, what I sent to You ???
>
and what is the maximum Number for
private const InBufSize_3 as INTEGER = 13 ' 4-byte buffer.

You sad That I can put there 20, but if also with that commas is
mising ???



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> .... is there any software for selectable NMEA sentences ?

Some Garmin products are based on common GPS chipsets like those from
SiRF. I do not know if the eTrex is one of them or if it is a
Garmin-proprietary. One utility that can change the options in SiRF
chipsets is SiRFDemo: http://www.sirf.com/free_demo.html . There are
several other common GPS chipset manufacturers, though, so you might
need to do some research to identify what your receiver uses.

If you find that you have a SiRF-based receiver, you might find Paul's
GPS_Example.bas

code useful:
http://tech.groups.yahoo.com/group/basicx/files/Datasheets-Appnotes-Examples-Drawings/Comm/GPS/

I've sent you a private email with a compiled project that should work -
but I can't test it here since I don't have an eTrex. Because you have
a GPS lab at your school, perhaps better equipped than my own, I
encourage you to find local assistance. I wish you good fortune.
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > .... is there any software for selectable NMEA sentences ?
>
> Some Garmin products are based on common GPS chipsets like those from
> SiRF. I do not know if the eTrex is one of them or if it is a
> Garmin-proprietary. One utility that can change the options in SiRF
> chipsets is SiRFDemo: http://www.sirf.com/free_demo.html . There are
> several other common GPS chipset manufacturers, though, so you might
> need to do some research to identify what your receiver uses.
>
> If you find that you have a SiRF-based receiver, you might find Paul's
> GPS_Example.bas
>


> code useful:
>
http://tech.groups.yahoo.com/group/basicx/files/Datasheets-Appnotes-Examples-Drawings/Comm/GPS/
>
> I've sent you a private email with a compiled project that should
work -
> but I can't test it here since I don't have an eTrex. Because you have
> a GPS lab at your school, perhaps better equipped than my own, I
> encourage you to find local assistance. I wish you good fortune.
> Tom
>
Thanks Tom I will try :)



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ...How Can I disable NMEA sentences in Garmin etrex...
>
> I no longer have a functioning eTrex after disassembling the thing when
> the LCD failed so I cannot test one for you, but I cannot find any
> Internet reference to selectable NMEA sentences from any eTrex model.
> Tom
>
1. is There any software for selectable NMEA sentences ???

2. can You send me compiled Project with DateTimeNMEA.bas,
Serial_24.bas and Support_24.bas , Maybe I did something simple and
stupid wrong in my project, what I sent to You ???



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In b...@yahoogroups.com, "guntis.laurins"
wrote:
>
> --- In b...@yahoogroups.com, Tom Becker wrote:
> >
> > > .... is there any software for selectable NMEA sentences ?
> >
> > Some Garmin products are based on common GPS chipsets like those from
> > SiRF. I do not know if the eTrex is one of them or if it is a
> > Garmin-proprietary. One utility that can change the options in SiRF
> > chipsets is SiRFDemo: http://www.sirf.com/free_demo.html . There are
> > several other common GPS chipset manufacturers, though, so you might
> > need to do some research to identify what your receiver uses.
> >
> > If you find that you have a SiRF-based receiver, you might find
Paul's
> > GPS_Example.bas
> > code useful:
> http://tech.groups.yahoo.com/group/basicx/files/Datasheets-Appnotes-Examples-Drawings/Comm/GPS/
> >
> > I've sent you a private email with a compiled project that should
> work -
> > but I can't test it here since I don't have an eTrex. Because you
have
> > a GPS lab at your school, perhaps better equipped than my own, I
> > encourage you to find local assistance. I wish you good fortune.
> >
> >
> > Tom
> >
> Thanks Tom I will try :)
>
Yee.. Finaly everything works :) With your Projekt Tom, data was the
same, 1999-01-01 00:00:01, but then I test Your example on onother
Basicx24 and now time is 2008-03 .... I belive that problem was in my
BX24 hardware.

Thanks You all :) This forum is great :) !!!



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... Finally, everything works. :)

Great. Glad you got it working!
Tom



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Hello,
I am having some issues with this code myself. I am trying to read in
2 NMEA sentences of which are the RMC and the GGA sentences. I am
using a Garmin GPS 18 LVC and it is configured to send out only these
two sentences. My issue is that it is not giving me the altitude
correctly. This is the only thing i am using from the GGA sentence.
Since altitude is not sent with leading zeros, and it could go up to
7 characters long, i have had to implement some variables for
decoding it. I also implemented a way to store, upload and clear the
data since we will be recording the placement of the balloon sat so
we can reference our two experiments to lat, long, time and altitude
(snipets from other codes). When we ran the original code we got back
some weird data as in the altitude never changed although we were
testing by driving around, up and down as the road led us. If there
is another way to do this, any advice is well appreciated.

Modified code from NMEA GPS:
' uses Serialport_24.bas and Support_24.bas
dim bChecksum as byte, bRawChecksum(1 to 2) as byte

dim iYear as integer, bMonth as byte, bDay as byte
dim bHour as byte, bMin as byte, sSec as single
dim bSec as byte, strX as string*3, strY as string*3, strZ as
string*3
'SoS
Dim Tx As String, Range As Single, NoEcho As Boolean
'Dim SoSSuccess As Boolean
Dim A as Integer
'Dim B as Integer
'Dim AvgTime as Single

'Memory
Dim Current_EEPROM_Address As Long
Dim Last_EEPROM_Address as Long
Const EEPROM_Start_Address As Long = 10000
Const EEPROM_End_Address As Long = 30000

'GPS
dim qChar as string * 1

dim Success as boolean
dim bUTCDate(1 to 6) as byte
dim bUTCTime(1 to 6) as byte
dim bNMEA_Cmd(1 to 5) as byte
const lInSpeed as long = 4800
dim tfValid as boolean
dim velValid as boolean
dim bLatdeg as byte, bLatMin as byte, bLatMinDeg as byte,
bLatMinS as byte, bLatMinSS as byte
dim bLondeg as byte, bLonMin as byte, bLonMinDeg as byte,
bLonMinS as byte, bLonMinSS as byte
dim bVelo as byte
dim bVelo2 as byte
dim bAlt2 as byte
dim bAlt as byte
dim bOldSec as byte
dim bSecGPS as Byte
Const Deg As Byte = 176 ' Degree symbol
dim bLatDM(1 to 9) as byte 'ddmm.mmmm
dim bLonDM(1 to 10) as byte 'dddmm.mmmm
dim bVelDM(1 to 5) as byte 'vvv.v
dim bAltDM(1 to 7) as byte 'aaaaa.a
Dim ElSize as integer
Dim ElSize2 as integer
'Pressure Sensor
Dim Voltage As Integer
Dim Volt as Single

'Pins
const bNMEAOutPin as byte = 0
Const UploadSwitchPin As Byte = 12 ' BX-24
Const InitPin As Byte = 13
'Yellow SOS
Const EchoPin As Byte = 14 'BLue
SOS
const PressurePinNumber as Byte = 16
'PressureSensor
const bNMEAInPin as byte = 18 'GPS pin
(GPSoutput, BXinput)

Const LEDon As Byte = 0
Const LEDoff As Byte = 1
option explicit

'---------------------------------------------------------------------
----------

Sub Main()

Const SwitchClosed As Byte = 0

If (FirstTime) Then
' Uncomment these lines to clear the block of EEPROM
memory.
' Call ClearMemoryBlock(EEPROM_Start_Address,
EEPROM_End_Address)
' Exit Sub
' Debug.print "First time"
Current_EEPROM_Address = EEPROM_Start_Address
Else
Current_EEPROM_Address = Last_EEPROM_Address
debug.print "last address"
End If

' If (GetPin(UploadSwitchPin) = SwitchClosed) Then
' Call UploadData(EEPROM_Start_Address, EEPROM_End_Address)
' Else
call OpenNMEAin(lInSpeed) 'input

do
Last_EEPROM_Address = Current_EEPROM_Address
call PutPin(GreenLEDpin, LEDOn)
'Get Data from experiments
Call GetData
call delay(0.1)
'Get GPS data
call GetNMEA
Call Delay(0.1)
call GetNMEA2

' Call Delay(0.1)
' call DisplayData
'Save Data
If(Current_EEPROM_Address >=
EEPROM_End_Address) Then
'out of storage space
Exit Sub
Else
Call SaveData
End If
call PutPin(GreenLEDpin, LEDOff)
call PutPin(RedLEDpin, LEDon)
Call Delay(7.0) 'adjust this for delays in
samples
Call PutPin(RedLEDpin, LEDoff)
loop

' End If

End Sub
'---------------------------------------------------------------------
----------

Sub DisplayData()

'Display RTC date and time once per second

call GetTimestamp(iYear, bMonth, bDay, bHour, bMin, sSec)
bSec=fixb(sSec)
if bSec <> bOldSec then
call PutPin(17, 0)
call PutPin(17, 1)

bOldSec=bSec
' call PutPin(GreenLEDpin, LEDOn)

strX=cstr(cint(bMonth)+100)
strY=cstr(cint(bDay)+100)
debug.Print cstr(cint(iYear));"-";mid(strX,2,2);"-
";mid(strY,2,2);" ";

strX=cstr(cint(bHour)+100)
strY=cstr(cint(bMin)+100)
strZ=cstr(cint(bSec)+100)
debug.Print mid(strX,2,2);":";mid(strY,2,2);":";mid
(strZ,2,2)
end if

'GPS
Debug.Print " LatD: "; CStr(bLatDeg); chr(deg)
Debug.print " LatM: "; CStr(bLatMin); "." ;CStr
(bLatMinS);cstr(bLatMinSS)
Debug.Print " LonD: "; CStr(bLonDeg); chr(deg)
Debug.Print " LonM: "; CStr(bLonMin); "." ;CStr
(bLonMinS); cstr(bLonMinSS)
Debug.Print " Vel: "; CStr(bVelo)
Debug.Print " Alt: "; CStr(bAlt)

'SoS display
If (A >= 3) Then
debug.Print "timeout"
Else
debug.print "Distance: "; Cstr(Range)
End If
'Pressure Sensor
Debug.print "Pressure: ";
debug.print Cstr(volt)

End Sub 'DisplayData

'---------------------------------------------------------------------
-------
Sub GetData()

'SoS
Call PutPin(EchoPin, bxInputTristate)
Call PutPin(InitPin, bxOutputLow)
Dim SoSSuccess As Boolean
Const SpeedOfSound As Single = 344.0 'm/s

A=0
SoSSuccess = False
Do While (SoSSuccess = False)
' If there is nothing detected by the device, NoEcho is set
to true.
' Otherwise NoEcho is false.

Dim EchoDelay As Single

' Trigger acoustic ping.
Call PutPin(InitPin, bxOutputHigh)

' Wait for echo/ measure how long a pin stays at logic
low (0)
Call RCtime(EchoPin, 0, EchoDelay)

' get ready for the next cycle by lowering the INIT
pin
' Call PutPin(InitPin, bxOutputLow)

' If we don't receive an echo, RCtime overflows and
returns 0.0.
If (EchoDelay = 0.0) Then
Range = 11.0
NoEcho = True
Else
Range = (EchoDelay /2.0) *
SpeedOfSound 'divide by 2 because time is doubled for time to target
and back.
NoEcho = False
End If

If (NoEcho) Then
A=A+1
Else
SoSSuccess = True
End If

If (A = 3) Then
SoSSuccess = True
End If
Call Delay(0.2)
Loop

'---------------------------------
' Pressure
Voltage=GetADC(PressurePinNumber)
volt=CSng(Voltage)
Call Delay(1.0)

End Sub 'GetData
'---------------------------------------------------------------------
----------

Sub OpenNMEAin(byval speed as long)

call DefineCom3(bNMEAInPin, bNMEAOutPin,
bx1000_1000) 'inverted, no parity, 8 bits.
call OpenSerialPort_3(speed)

End Sub

'---------------------------------------------------------------------
----------

Sub GetNMEA()

Dim bNMEAData As Byte, tfSuccess as boolean

'$GPRMC,192631,A,3443.2547,N,08638.5393,W,015.1,180.3,140308,002.6,W,A
*1D
call GetByte_3(bNMEAData,tfSuccess)
if (tfSuccess) Then
if bNMEAData=asc("$") then
bChecksum=0
call GetBytes(bNMEA_Cmd,5)
if (bNMEA_Cmd(1)=asc("G")) and (bNMEA_Cmd(2)
=asc("P")) and (bNMEA_Cmd(3)=asc("R")) and (bNMEA_Cmd(4)=asc("M"))
and (bNMEA_Cmd(5)=asc("C")) then
'case "GPRMC"
call SkipCommas(1)
call GetDigits(bUTCTime,6)
'get time item
call SkipCommas(1) 'discard 1
comma
call getValidity
call SkipCommas(1)
call GetDigits(bLatDM,9)
'get ddmm.mmmm
call SkipCommas(2)
call GetDigits(bLonDM,10)
'get dddmm.mmmm
call SkipCommas(2)
'comment this out for
no signal
call GetDigits(bVelDM,5)
'get vvv.v, 'comment this out for no signal
call SkipCommas(2)
'change this to 3 for
no signal normally 1
call GetDigits(bUTCDate,6)
'get date item

do
call GetBytes
(bRawChecksum,1) 'discard but checksum
loop until (bRawChecksum(1)
=asc("*"))
bChecksum=bChecksum xor
bRawChecksum(1) 'remove * from checksum
call GetChecksumBytes
(bRawChecksum,2)
call CalcNMEAChecksum
' if tfValid then 'data valid
'' Call PutPin
(RedLEDpin, LEDon)
' call SetDateTime 'set
local clock
' Call PutPin
(RedLEDpin, LEDoff)
' end if
end if
end if
end If
Call SetDateTime
Call Delay(0.1)
Call GPSData
End Sub

'---------------------------------------------------------------------
----------------
Sub GetNMEA2()
Dim bNMEAData As Byte, tfSuccess as boolean
call GetByte_3(bNMEAData,tfSuccess)
if (tfSuccess) Then
if bNMEAData=asc("$") then
bChecksum=0
call GetBytes(bNMEA_Cmd,5)
if (bNMEA_Cmd(1)=asc("G")) and (bNMEA_Cmd(2)
=asc("P")) and (bNMEA_Cmd(3)=asc("G")) and (bNMEA_Cmd(4)=asc("G"))
and (bNMEA_Cmd(5)=asc("A")) then
'case "GPGGA"
'$GPGGA,192631,3443.2547,N,08638.5393,W,1,05,2.9,192.4,M,-30.7,M,,*7A
call SkipCommas(9)
call GetDigits(bAltDM,7)
'get Altitude aaaaa.a possible 7 bytes
do
call GetBytes
(bRawChecksum,1) 'discard but checksum
loop until (bRawChecksum(1)
=asc("*"))
bChecksum=bChecksum xor
bRawChecksum(1) 'remove * from checksum
call GetChecksumBytes
(bRawChecksum,2)
call CalcNMEAChecksum
end if
end if
end If
Call GetALT
End Sub

'---------------------------------------------------------------------
----------

Sub CalcNMEAChecksum()

bRawChecksum(1)=bRawChecksum(1)-asc("0") '0-9
if bRawChecksum(1)>9 then
bRawChecksum(1)=bRawChecksum(1)-7 'A-F
end if

bRawChecksum(2)=bRawChecksum(2)-asc("0")
if bRawChecksum(2)>9 then
bRawChecksum(2)=bRawChecksum(2)-7
end if

if bChecksum<>bRawChecksum(1)*16+bRawChecksum(2) then
tfValid=true 'false
end if

End Sub

'---------------------------------------------------------------------
----------

Sub SkipCommas(byval i as byte)

Dim bNMEAData As Byte, tfSuccess as boolean
Do
do
call GetByte_3(bNMEAData,tfSuccess)
' if not(tfSuccess) then
' call DisplayData
' end if
loop until (tfSuccess)
bChecksum=bChecksum xor bNMEAData
if bNMEAData=asc(",") then
i=i-1
end if
Loop until i=0

End Sub

'---------------------------------------------------------------------
----------

Sub GetDigits(ByRef Item() as byte, ByVal length as integer)

Dim bNMEAData As Byte, i as integer, tfSuccess as boolean
for i=1 to length
do
call GetByte_3(bNMEAData,tfSuccess)
' if not(tfSuccess) then
' call DisplayData
' end if
loop until (tfSuccess)
bChecksum=bChecksum xor bNMEAData
Item(i)=bNMEAData-asc("0")
next

End Sub

'---------------------------------------------------------------------
----------

Sub GetBytes(ByRef Item() as byte, ByVal length as integer)

Dim bNMEAData As Byte, i as integer, tfSuccess as boolean

for i=1 to length
do
call GetByte_3(bNMEAData,tfSuccess)
' if not(tfSuccess) then
' call DisplayData
' end if
loop until (tfSuccess)
bChecksum=bChecksum xor bNMEAData
Item(i)=bNMEAData
next

End Sub

'---------------------------------------------------------------------
----------

Sub GetChecksumBytes(ByRef Item() as byte, ByVal length as integer)

Dim bNMEAData As Byte, i as integer, tfSuccess as boolean

for i=1 to length
do
call GetByte_3(bNMEAData,tfSuccess)
' if not(tfSuccess) then
' call DisplayData
' end if
loop until (tfSuccess)
Item(i)=bNMEAData
next

End Sub

'---------------------------------------------------------------------
----------

Sub getValidity()

Dim bNMEAData As Byte, tfSuccess as boolean

do
call GetByte_3(bNMEAData,tfSuccess)
' if not(tfSuccess) then
' call DisplayData
' end if
loop until (tfSuccess)
bChecksum=bChecksum xor bNMEAData
if bNMEAData=asc("A") then

tfValid=true
else
tfValid=true
'change to false
end if

End Sub

'---------------------------------------------------------------------
----------

Sub SetDateTime()

iYear=2000+cint(bUTCDate(5)*10)+cint(bUTCDate(6))
bMonth=cbyte(bUTCDate(3))*10+cbyte(bUTCDate(4))
bDay=cbyte(bUTCDate(1))*10+cbyte(bUTCDate(2))

bHour=bUTCTime(1)*10+bUTCTime(2)
bMin=bUTCTime(3)*10+bUTCTime(4)
sSec=csng(bUTCTime(5)*10+bUTCTime(6))
bSecGPS=bUTCTime(5)*10+bUTCTIME(6)
if (iYear>2099) or (bMonth>12) or (bDay>31) or (bHour>23) or
(bMin>59) or (sSec>60.0) then
exit sub
end if

call PutTimestamp(iYear, bMonth, bDay, bHour, bMin, sSec)

End Sub

'---------------------------------------------------------------------
------------------------------
Sub GPSData()
bLatDeg=cbyte(bLatDM(1))*10+cbyte(bLatDM(2))
bLatMin=cbyte(bLatDM(3))*10+cbyte(bLatDM(4))
bLatMinS=cbyte(bLatDM(6))*10+cbyte(bLatDM(7))
bLatMinSS=cbyte(bLatDM(8))*10+cbyte(bLatDM(9))

bLonDeg=(cbyte(bLonDM(1))*100)+(cbyte(bLonDM(2))*10)+cbyte
(bLonDM(3))
bLonMin=(cbyte(bLonDM(4))*10)+(cbyte(bLonDM(5)))
bLonMinS=(cbyte(bLonDM(7))*10)+(cbyte(bLonDM(8)))
bLonMinSS=(cbyte(bLonDM(9))*10)+(cbyte(bLonDM(10)))

bVelo=(cbyte(bVelDM(1))*100)+(cbyte(bVelDM(2))*10)+(cbyte
(bVelDM(3)))
bVelo2=(cbyte(bVelDM(5)))
End Sub
'---------------------------------------------------------------------
---------------------------
Sub GetAlt()
'$GPGGA,192631,3443.2547,N,08638.5393,W,1,05,2.9,192.4,M,-30.7,M,,*7A
' Since there is a possibility of 99999.9 being the altitude, we must
read in 7 bytes
' Since ground level will only have 5 bytes, we must decode the
altitude to check for
' commas. In order to save correctly, we must add in an element size
counter.
' We also must move the bytes over by a mult of 10 if there is no
comma found.

' bAlt=((bAltDM(1))*1000)+((bAltDM(2))*100)+((bAltDM(3))*10)+
((bAltDM(4)))
dim comma as byte
comma = (asc(","))
If (bAltDM(1)<> comma) Then
bAlt=bAltDM(1)
ElSize=1
If (bAltDM(2) <> comma) Then
bAlt=(bAlt*10)+bAltDM(2)
ElSize=ElSize+1
If (bAltDM(3) <> comma) Then
bAlt=(bAlt*10)+bAltDM(3)
ElSize=ElSize+1
If (bAltDM(4) <> comma) Then
bAlt=(bAlt*10)+bAltDM(4)
ElSize=ElSize+1
' bAlt2=((bAltDM(5))*100)+((bAltDM(6))*10)+((bAltDM(7)))
If (bAltDM(5)<> comma) Then
bAlt2=bAltDM(5)
ElSize2=ElSize2+1
If (bAltDM(6) <>
comma) Then
bAlt2=
(bAlt2*10)+bAltDM(6)

ElSize2=ElSize2+1
If (bAltDM(7)
<> comma) Then
bAlt2=
(bAlt2*10)+bAltDM(7)

ElSize2=ElSize2+1
End if
End If
End If
End if
End If
End If
Else
bAlt=cbyte(asc("0"))
ElSize=2
End If
End SUb

'---------------------------------------------------------------------
------------------
Sub SaveData()
Dim AltSize as long
Dim AltSize2 as long

AltSize = clng(ElSize)
AltSize2 = clng(ElSize2)

If(Current_EEPROM_Address >= EEPROM_End_Address-34) Then
'out of storage space
Exit Sub
End If

Call PutPin(RedLEDpin, LEDon)
Call Delay(0.07)
call PutPin(RedLEDpin, LEDOff)
Call Delay(0.3)
'Speed of Sound
Call PutEEPROM(Current_EEPROM_Address,Range, 4)
Current_EEPROM_Address=Current_EEPROM_Address + 4
'Pressure Sensor
Call PutEEPROM(Current_EEPROM_Address, Volt, 4)
Current_EEPROM_Address=Current_EEPROM_Address + 4
'Time
Call PutEEPROM(Current_EEPROM_Address, bHour, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, bMin, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, sSec, 4)
Current_EEPROM_Address=Current_EEPROM_Address + 4
'Latitude
Call PutEEPROM(Current_EEPROM_Address, bLatDeg, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, bLatMin, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, bLatMinS, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, bLatMinSS, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
'Longitude
Call PutEEPROM(Current_EEPROM_Address, bLonDeg, 3)
Current_EEPROM_Address=Current_EEPROM_Address + 3
Call PutEEPROM(Current_EEPROM_Address, bLonMin, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, bLonMinS, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, bLonMinSS, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
'velocity
Call PutEEPROM(Current_EEPROM_Address, bVelo, 3)
Current_EEPROM_Address=Current_EEPROM_Address + 3
Call PutEEPROM(Current_EEPROM_Address, bVelo2, 1)
Current_EEPROM_Address=Current_EEPROM_Address + 1
'altitude size
Call PutEEPROM(Current_EEPROM_Address, ElSize, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
Call PutEEPROM(Current_EEPROM_Address, ElSize2, 2)
Current_EEPROM_Address=Current_EEPROM_Address + 2
'altitude value
Call PutEEPROM(Current_EEPROM_Address, bAlt, ElSize)
Current_EEPROM_Address=Current_EEPROM_Address + AltSize
Call PutEEPROM(Current_EEPROM_Address, bAlt2, ElSize2)
Current_EEPROM_Address=Current_EEPROM_Address + AltSize2

If(Current_EEPROM_Address >= EEPROM_End_Address) Then
'out of storage space
Exit Sub
End If

Call PutPin(RedLEDpin, LEDon)
Call Delay(0.07)
call PutPin(RedLEDpin, LEDOff)
Call Delay(0.3)

End Sub
'---------------------------------------------------------------------
------------
Sub UploadData(ByVal EEPROM_Start_Address As Long, ByVal
EEPROM_End_Address As Long)
Dim Address as Long
Dim AltSize as Long
Dim AltSize2 as Long

Address = EEPROM_Start_Address

Call PutPin(RedLEDpin, LEDon)
Call Delay(0.07)

Call PutPin(GreenLEDpin, LEDon)
Call Delay(0.07)

Do
Debug.Print "$$";

'Speed of Sound
Call GetEEPROM(Address, Range, 4)
Debug.Print CStr(Range); ", ";
Address = Address+4

'Pressure Sensor
Call GetEEPROM(Address, Volt, 4)
Debug.Print CStr(Volt);
Address = Address+4

'Time HH:MM:SS
Call GetEEPROM(Address, bHour, 2)
Debug.Print CStr(bHour); ":";
Address = Address+2
Call GetEEPROM(Address, bMin, 2)
Debug.Print CStr(bMin); ":";
Address = Address+2
Call GetEEPROM(Address, sSec, 4)
Debug.Print CStr(bSec); ",";
Address = Address+4

'Lat DD MM.SSSS
Call GetEEPROM(Address, bLatDeg, 2)
Debug.Print CStr(bLatDeg); chr(Deg);
Address = Address+2
Call GetEEPROM(Address, bLatMin, 2)
Debug.Print CStr(bLatMin); ".";
Address = Address+2
Call GetEEPROM(Address, bLatMinS, 2)
Debug.Print CStr(bLatMinS);
Address = Address+2
Call GetEEPROM(Address, bLatMinSS, 2)
Debug.Print CStr(bLatMinSS); ", ";
Address = Address+2

'Lon DDD MM.SSSS
Call GetEEPROM(Address, bLonDeg, 3)
Debug.Print CStr(bLonDeg); chr(Deg);
Address = Address+3
Call GetEEPROM(Address, bLonMin, 2)
Debug.Print CStr(bLonMin); ".";
Address = Address+2
Call GetEEPROM(Address, bLonMinS, 2)
Debug.Print CStr(bLonMinS);
Address = Address+2
Call GetEEPROM(Address, bLonMinSS, 2)
Debug.Print CStr(bLonMinSS); ", ";
Address = Address+2

'velocity VVV.V
Call GetEEPROM(Address, bVelo, 3)
Debug.Print CStr(bVelo); ".";
Address=Address + 3
Call GetEEPROM(Address, bVelo2, 1)
Debug.Print CStr(bVelo); ",";
Address=Address + 1

'Altitude AAA.A to AAAAA.A
'getting size of altitude storage
Call GetEEPROM(Address, ElSize, 2)
Address = Address+2
AltSize = clng(Elsize)
Call GetEEPROM(Address, ElSize2, 2)
Address = Address+2
AltSize2 = clng(ElSize2)
'getting Altitude
Call GetEEPROM(Address, bAlt, ElSize)
Debug.Print Cstr(bAlt); ".";
Address = Address+AltSize
Call GetEEPROM(Address, bAlt2, ElSize2)
Debug.Print Cstr(bAlt2); ", ";
Address = Address+AltSize2
'End of Data Sentence
Debug.Print "&&"
Loop Until (Address >= EEPROM_End_Address)
Debug.Print "EOF"

Call PutPin(RedLEDpin, LEDoff)
Call Delay(0.03)
Call PutPin(GreenLEDpin, LEDoff)
Call Delay(0.07)

exit sub

End Sub

'---------------------------------------------------------------------
----------
Private Sub ClearMemoryBlock( _
ByVal EEPROM_Start_Address As Long, _
ByVal EEPROM_End_Address As Long)

' This procedure clears the specified EEPROM memory block.
Dim Flash as Integer
Dim Address As Long
Dim ElementCount As Long
Dim N As Long
Dim Temp As Integer
Dim ElementSize as Integer
Call PutPin(RedLEDpin, LEDon)
Call Delay(0.07)
Call PutPin(GreenLEDpin, LEDon)
Call Delay(0.07)
Debug.Print "Clearing EEPROM"; " block. "
Debug.Print "This may take 3"; " or 4 minutes. "

Temp = 0
ElementSize = 2
ElementCount = ( (EEPROM_End_Address - EEPROM_Start_Address) \
CLng(ElementSize) ) + 1

Address = EEPROM_Start_Address
For N = 1 To ElementCount
Call PutEEPROM(Address, Temp, ElementSize)
Address = Address + CLng(ElementSize)
Next

Debug.Print "Done."
Call PutPin(RedLEDpin, LEDoff)
Call Delay(0.07)
Call PutPin(GreenLEDpin, LEDoff)
Call Delay(0.07)

'flash LED for coolness when complete
Do until (Flash=10)
' Red pulse.
Call PutPin(RedLEDpin, LEDon)
Call Delay(0.07)
Call PutPin(RedLEDpin, LEDoff)

Call Delay(0.07)

' Green pulse.
Call PutPin(GreenLEDpin, LEDon)
Call Delay(0.07)
Call PutPin(GreenLEDpin, LEDoff)

Call Delay(0.07)
Flash=Flash+1
Loop

End Sub

'---------------------------------------------------------------------
-----

------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... another way to do this...

Yeah, you got tied in knots.

A suggestion to anyone who wants to get GPS data from a GPS receiver: if
a machine-friendly protocol is available from the receiver, consider
using it instead of NMEA. NMEA is ASCII, and must be converted to
floating-point values to be usable by code. That's a good step to avoid
if you can. SiRF has its own protocol, Trimble has one, Garmin has a
simple text mode; each of these might be easier to use than NMEA.

I've rewritten a few areas of your code. No guarantee that it will
work, but it should help. I removed all of your Delays, so you might
want to throttle the reporting - not the collection and processing - of
data.

This code defines a function, sGetFieldValue(), that makes a single out
of a text string value, like altitude in GGA, byte-at-a-time. BasicX
also offers a procedure, ValueS, that converts text strings to values.

Hope this helps.
Tom
'-------------------------------------------------------------------------------

Sub Main()

Const SwitchClosed As Byte = 0

If (FirstTime) Then
' Uncomment these lines to clear the block of EEPROM memory.
' Call ClearMemoryBlock(EEPROM_Start_Address, EEPROM_End_Address)
' Exit Sub
' Debug.print "First time"
Current_EEPROM_Address = EEPROM_Start_Address
Else
Current_EEPROM_Address = Last_EEPROM_Address
debug.print "last address"
End If

' If (GetPin(UploadSwitchPin) = SwitchClosed) Then
' Call UploadData(EEPROM_Start_Address, EEPROM_End_Address)
' Else
call OpenNMEAin(lInSpeed) 'input

do
Last_EEPROM_Address = Current_EEPROM_Address
call PutPin(GreenLEDpin, LEDOn)
'Get Data from experiments
Call GetData
'Get GPS data
call GetNMEA
' call DisplayData
'Save Data
If(Current_EEPROM_Address >= EEPROM_End_Address) Then
'out of storage space
Exit Sub
Else
Call SaveData
End If
call PutPin(GreenLEDpin, LEDOff)
call PutPin(RedLEDpin, LEDon)
Call Delay(0.010) 'flash
Call PutPin(RedLEDpin, LEDoff)
loop

' End If

End Sub

Sub GetNMEA()

Dim bNMEAData As Byte, tfSuccess as boolean

call GetByte_3(bNMEAData,tfSuccess)
if (tfSuccess) Then
if bNMEAData=asc("$") then
bChecksum=0
call GetBytes(bNMEA_Cmd,5)
if (bNMEA_Cmd(1)=asc("G")) and (bNMEA_Cmd(2)=asc("P")) and
(bNMEA_Cmd(3)=asc("R")) and (bNMEA_Cmd(4)=asc("M")) and
(bNMEA_Cmd(5)=asc("C")) then
'case "GPRMC"

'$GPRMC,192631,A,3443.2547,N,08638.5393,W,015.1,180.3,140308,002.6,W,A*1D
call SkipCommas(1)
call GetDigits(bUTCTime,6) 'get
time item
call SkipCommas(1) 'discard 1 comma
call getValidity
call SkipCommas(1)
call GetDigits(bLatDM,9) 'get
ddmm.mmmm
call SkipCommas(2)
call GetDigits(bLonDM,10) 'get
dddmm.mmmm
call SkipCommas(2)
'comment this out for no signal
call GetDigits(bVelDM,5) 'get
vvv.v, 'comment this out for no signal
call SkipCommas(2)
'change this to 3 for no signal normally 1
call GetDigits(bUTCDate,6) 'get
date item

do
call GetBytes(bRawChecksum,1) 'discard but
checksum
loop until (bRawChecksum(1)=asc("*"))
bChecksum=bChecksum xor bRawChecksum(1) 'remove *
from checksum
call GetChecksumBytes(bRawChecksum,2)
call CalcNMEAChecksum
' if tfValid then 'data valid
'' Call PutPin(RedLEDpin, LEDon)
' call SetDateTime 'set local clock
' Call PutPin(RedLEDpin, LEDoff)
' end if

elseif (bNMEA_Cmd(1)=asc("G")) and (bNMEA_Cmd(2)=asc("P"))
and (bNMEA_Cmd(3)=asc("G")) and (bNMEA_Cmd(4)=asc("G")) and
(bNMEA_Cmd(5)=asc("A")) then
'case "GPGGA"

'$GPGGA,192631,3443.2547,N,08638.5393,W,1,05,2.9,192.4,M,-30.7,M,,*7A
call SkipCommas(9)
sAltitude = sGetFieldValue 'get Altitude aaaaa.a
possible 7 bytes
do
call GetBytes(bRawChecksum,1) 'discard but
checksum
loop until (bRawChecksum(1)=asc("*"))
bChecksum=bChecksum xor bRawChecksum(1) 'remove *
from checksum
call GetChecksumBytes(bRawChecksum,2)
call CalcNMEAChecksum
end if
end if
end If
Call SetDateTime
Call GPSData
End Sub

'-------------------------------------------------------------------------------------

Function sGetFieldValue () as Single
' Build a Single from "234.5678,"-like ASCII string
Dim bNMEAData As Byte, tfSuccess as boolean, bScale as byte
sGetFieldData = 0.0
bScale = 0
do
do
call GetByte_3(bNMEAData,tfSuccess)
loop until (tfSuccess)
bChecksum = bChecksum xor bNMEAData 'get and checksum bytes
select bNMEAData
case asc(",")
case asc("*")
case asc(".")
bScale = 1 'note decimal point
case else 'numerals
sAltitude = sAltitude * 10.0 + csng(bNMEAData-asc("0"))
if (bScale <> 0) then 'count decimal places
bScale = bScale + 1
end if
end select
loop until bNMEAData = asc(",") 'or bNMEAData = asc("*") only
reqd for last field
if (bScale <> 0) then
sGetFieldData = sGetFieldData / (10.0 ^ csng(bScale - 1))
'scale value
end if

End Function

------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I should have also mentioned that Micromega Corp's =B5MFPU v3 (
http://micromegacorp.com/
http://groups.yahoo.com/group/uMFPU/?yguid=3D1284642 ) is able to
receive and decode NMEA sentences and convert fields to useful values
- autonomously without BasicX involvement, except to receive the values. =
=20

Of course, nav math can be done on that part, too.
Tom
------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Great. Thanks for your help! We are testing it again tonight.
------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Sorry, typos in the function code. Should be more like:
Function sGetFieldValue () as Single
' Build a Single from "2345.678,"-like ASCII string
Dim bNMEAData As Byte, tfSuccess as boolean, bScale as byte, sX as single
sX = 0.0
bScale = 0
do
do
call GetByte_3(bNMEAData,tfSuccess)
loop until (tfSuccess)
bChecksum = bChecksum xor bNMEAData 'get and checksum bytes
select case bNMEAData
case asc(",")
case asc("*")
case asc(".")
bScale = 1 'note decimal point
case else 'numerals
sX = sX * 10.0 + csng(bNMEAData-asc("0"))
if (bScale <> 0) then 'count decimal places
bScale = bScale + 1
end if
end select
loop until bNMEAData = asc(",") 'or bNMEAData = asc("*")
if (bScale <> 0) then
sX = sX / (10.0 ^ csng(bScale - 1)) 'scale value
end if
sGetFieldValue = sX
End Function

Tom

------------------------------------



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )