GPS Serial-capturing experts.. need your help for my project!

l337hxr

Okay, I have a Garmin eTrex outputing NMEA data to the microcontroller basic stamp II oem.

I'm capturing just the heading,bearing, and waypoint.

Here's the problem, as I debug the captured heading/waypoint to the debug terminal, i see that the numbers are tootally off!· Sometimes, it is right....... this has been screwing up my robot's navigation.....

Here is my SERIN capturing code:

SERIN 15, 16572, [noparse][[/noparse]WAIT("RMC,"),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),
WAIT(","),DEC heading,WAIT("RMB,"),WAIT(","),WAIT(","),WAIT(","),WAIT(","),DEC waypointID,
WAIT("RMB,"),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),DEC bearing]



So once in a while, when the robot is moving erratically going off course, I find out it's because either the heading or bearing number is totally wrong...such as a huge number like 17349...than what is displayed on the garmin eTrex.

Tonight, i went home and hooked up the eTrex to my computer and debugged it to HyperTerminal......

I FOUND the problem..... it seems like half-way thru outputting the NMEA "RMC" and "RMB" sentences, it cuts off..then continues to re-output data...... however, the PBASIC code ignores the 2nd "RMC" or "RMB" code and just counts the commas then captures the WRONG data..... in this case... it captures the longitude/latitude coordinates (huge number)..........


#1 question : why does this happen?· is this supposed to happen

#2 question: how do I compensate or fix this in my PBASIC code?


As you can see below..the eTrex spits out the RMC...... i want the 9th value of that sentence assuming all of it is spitted out correctly..but in this case..it repeated!...so therefore it captures the wrong data..... BLUE.........· what i want is the GREEN data..... same thing for the RMB..... because the first RMB sentence got cut off..... it ignored the 2nd GPRMB data and went ahead and kept counting the comma..... it stored the WRONG value (blue data) ....instead i want the GREEN value.......


$GPRMC,094328,A,3352.
$GPRMC,094434,A,3352.0613,N,11804.8444,W,0.0,0.0,110507,13.4,E,A*30··································· ·········
$GPRMB,A,9.99,R,003,0
$GPRMB,A,9.99,R,003,002,3403.4956,N,11749.3998,W,17.201,48.2,,V,A*71·············································


Post Edited By Moderator (Chris Savage (Parallax)) : 5/11/2007 1:51:29 PM GMT

stamptrol

You'll have much better luck using the WAIT modifier in conjunction with SKIP.

SERIN 15, 16572, [noparse][[/noparse]WAIT("RMC,"),SKIP 21,DEC heading] 'you may have to play with the SKIP numbers to get the digits you want.

SERIN 15, 16572, [noparse][[/noparse]WAIT("RMB,"),SKIP 10,DEC waypointID] 'you may have to play with the SKIP numbers to get the digits you want.

SERIN 15, 16572, [noparse][[/noparse]WAIT("RMB,"),SKIP 18,DEC bearing] 'you may have to play with the SKIP numbers to get the digits you want.

Also, the Stamp will be grabbing integer values, not numbers to 4 decimal places, so make sure your variables are the right type.
By grabbing STR instead of DEC you can get the whole number into the Stamp and process it to get both parts of the number.

What's likely happening is the Stamp is getting bogged down with a complicated SERIN command
and the gps has time to send out a second or third sentence while the Stamp is processing.

Using multiple SERIN's, always WAITing for the start of transmission, and SKIPping as required to get to the right place
in the string have worked well for me.

Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Chris Savage

Our GPS Module takes the load off a microcontroller such as the BS2 which doesn’t have the resources to easily handle long GPS strings and provides only the information requested. For using the RAW mode such as provided by your GPS a BS2p would help since it has Scratch Pad RAM which can buffer the entire string and then you can move the relevant values into variables, disregarding the rest. It is also faster. Take care.

http://www.parallax.com/detail.asp?product_id=28146

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Phil Pilgrim (PhiPi)

On the eTrex, when you've selected NMEA output, the baudrate is fixed at 4800, the NMEA standard. This may be too fast for the BS2 to keep up with. The eTrex also has a "text" output mode, which operates down to 1200 baud. In another thread, Jon Williams posted a BS2 program, Easy_GPS.bs2, which can capture this data. (It doesn't give you a waypoint, though. 'Not sure if you really need that...)

-Phil

l337hxr

I am using VAR BYTE for all values.. for example:

heading VAR Word
bearing VAR Word
waypointID VAR Word
reference VAR Word
difference VAR Word
left_delay VAR Word
right_delay VAR Word



thanks everyone... I will try to debug the problem today and fixed what needs to be done. I thought 4800 was an okay speeds since GPS has been done before succesfully using a Garmin eTrex / BS2 ????

l337hxr

stamptrol

correct me if i'm wrong but if i use the skip command..that shoud reduce the load on the BS2 right?

however..in doing so..wouldn't this still pose a problem because the garmin unit is still cutting off half of the sentences some times.. and when it does so...it will throw off all the capturing of the data....?

stamptrol

· Yes, I believe the Skip function is a more efficient way of setting up the SERIN.

· I'd be a bit surprized if the e-trex was really chopping·off the string without a good reason. I'd

check it again on Hyperterminal, or more preferably, Procomm to see that its outputting the two sentences

you need.

· By always using the Wait function, you ensure that the stamp is starting at the same point in the

string each time. Even if the string were interupted while waiting for a DEC number, the first non-numeric

character or the CRLF at the end of any string would reset SERIN and it would pick up the next occurance

of the string·you're WAITing for.

· And, as another poster has pointed out, a speed less than 4800 baud would be preferrable. I do all

mine at 2400 baud or move up to a BS2sx. Not all gps units give the choice, however.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Chris Savage

l337hxr said...(trimmed)
I am using VAR BYTE for all values.. for example:
heading VAR Word
bearing VAR Word
waypointID VAR Word
reference VAR Word
difference VAR Word
left_delay VAR Word
right_delay VAR Word

BYTE or WORD variables...You said BYTE but typed WORD.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

l337hxr

err... correction.. i am using VAR Word. not Byte. sorry =]

l337hxr

I have used hyperterminal to verify the outputs of the NMEA serial of the Garmin eTrex legend.... i set to 4800 baud rate.. no parity 1 bit stop.

here are what the hyperterminal shows.. as you can see its MANY sentences getting cut off...... then the garmin seems to repeat some...........
can someone clarify why this happpens:


PLEASE SEE ATTACHMENT FOR MY HYPER TERMINAL OUTPUT .. ITS A DOC FILE.

Chris Savage

Hello,

This is the string you want to deal with. It will have almost all of the information you could want from the GPS Module.

[color=#000000]$GPRMC,094354,A,3352.0601,N,11804.8452,W,0.0,0.0,110507,13.4,E,A*35[/color]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

l337hxr

I just got off the phone with Garmin Tech Support.

Apparently, they are aware of this happening on the Garmin eTrex... it's just the way it works.

The NMEA sentences get cut off and it repeats......· he didn't tell me exactly why it does this but it just does what it does.

So I guess the only way for me to process the NMEA data is to capture the whole line of the GPRMC... compare it and make sure these numbers
are valid...then "hope" that the value I am going to use is valid as well......

what i do notice is that.....if the sentence is cut off, its cut off and repeats.· So it's not like the sentence is good in the beginning, garbage in the middle, then good in the end....

if its garbage, its garbage to the end and goes to the next line.

*sigh* this sux.
·

l337hxr

Okay, I got it guys......

the GPRMC and GPRMB sentence is what I need.... but notice that the asterisk at the end is always there.. i can USE this as a checksum..to see if the sentence is valid.... if it exists..then we're good!


$GPRMC,094354,A,3352.0601,N,11804.8452,W,0.0,0.0,110507,13.4,E,A*35

so now..... how do i STORE this asterisk ?

DEC asterisk?
BIN asterisk?


because I will write a statement to do:

If (asterisk = "*")THEN
GOTO Begin_Calculate
ELSE
GOTO Get_NMEA_DATA_AGAIN
END




or it seems like i need to do:

Asterisk VAR BYTE
serin 9, 16572 [noparse][[/noparse]skip, skip, Asterisk ] etc.etc.

If(Asterisk = * )
then GOTO Calculate
else GOTO GetDataAgain


Post Edited (l337hxr) : 5/11/2007 8:56:04 PM GMT

stamptrol

To detect the "*", use the STR descriptor. In fact you can capture the whole sentence as a STR, (within constraints of memory, I grab it 15 chars at a time
and re-use variable space) then slice and dice as required to get the information, including the asterisk.

Cheers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Tr0N

I need some advice from members familiar with GPS or other NMEA 0183 string catching.

Is the BS2 worth using for NMEA strings or should I just move on to an SX or propeller?

Chris Savage

Hello,

The BS2p is quite capable for handling the strings by buffering them into the SPRAM which doesn’t take up any variable space and there are examples of reading this data into examples at the following links. Take care.

http://www.parallax.com/dl/docs/cols/nv/vol4/col/nv103.pdf

also

http://www.parallax.com/dl/docs/cols/nv/vol3/col/nv83.pdf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support