Problem reading RS232

[Kristofer]

Hi!

I have got a problem to read a string over the RS232 connection.
There is a GPS receiver connected which sends a string looking like this:

$GPGGA,125803.60,5224.43451,N,00130.09173,W,1,05,1.5,84.5,M,48.7,M,,*4E<CR><LF>

When I send the same message from a PC without the carriage return and line feed in the end, it works fine. The PIC18F452 reads it and returns the latitude and longitude via printf.
When the GPS is connected (so there is a CR and LF), it works only one time. There is no way to read another string but resetting the PIC.

Any idea?

Sourcecode:

[angel]

I think it would be better to use kbhit and gets :
if(kbhit){
gets(message)
}
and message could be a global char message[71] variable

[Donlaser]

In the read function you need to wait for $ symbol, or better $GPGGA, then read the rest of the line.

Search the forum for NMEA parsing.

I do someting like that, and then do the parsing of the string received, in my case i use the sentence $GPRMC,...

[Eliberg]

I don't know if this is the error, but in your string
$GPGGA,125803.60,5224.43451,N,00130.09173,W,1,05,1.5,84.5,M,48.7,M,,*4E<CR><LF> you have 73 chars, if you consider <CR><LF>, and you read only 71 chars, with your void read_RS232 function.

Bye
eli

[darkswarm]

Hi,

i'm having almost the same problem as Kristofer. I'm using 16F876 to extract the latitude and longitude from my GPS receiver to be shown on Hyperterminal.

Eliberg, I use a function similar to void read_RS232, and my program also works only once before i have to reset everything. If it really is a problem, how do i solve it?

I'm not familiar with NMEA parse, so i try not to use it for now as i'm afraid it might mess up my program even further.

Really appreciate the help. Thanks in advance.

[sjbaxter]

Guys, the easiest way of parsing NMEA is using a state machine. Handle each byte as it comes in and change the state of the machine (a simple switch statement with cases for handling '$' '*' ',' '<CR>' '<LF>' and the default case hanlding the data in between based on the current machine state.

If the wrong thing arrives when you aren't expecting it, throw the sentence away and reset the state machine. If you get a $ at any point and your state machine is waiting for something else, throw the sentence away as you have missed the end marker * so set the state machine accordingly. If the checksum doesn't match your calculated checksum, throw the sentence away and reset the state machine. Don't assume all fields to be populated with data so dont parse on byte position of the fields, use the comma delimiters, count them in the state machine.

You could try and use the UART interrupt handler for capturing each character so you don't miss any.

you can eliminate the for loops this way as you already have the data, so why go though it again, the more processing you do after the event, the more likly you are of missing new data comming in and at 1 second intervals (NMEA0183), the data doesn't come around too often !

Using a state machine, you only need buffers big enough to build up the LAT/LONG info from the bytes coming in as you aren't interested in storing the whole sentence. i.e.

char latitude[13];
char longitude[14];

hope this gives you a few ideas and a different view on how to solve this one.
_________________
Regards,
Simon.

[darkswarm]

Hi,

Below is a code that I modified from another CCS forum author, Kimi. It works for me but i'm hoping to improve on it.

[Douglas Kennedy]

It might be possible to get this to work reliably without an RDA interrupt routine filling a circular buffer but I wouldn't bet on it.
Advice:
Keep the RDA as short as humanly possible.
Get the received character if it is the $ then set a global flag in the RDA to indicate on the next interrupt to begin stuffing chars into the buffer until you see the end of a sentence. Then set a global flag that a sentence is in the buffer and parse the sentence in your main routine.
Any attempt to do extensive parsing in the interrupt will mess up the timing.
Remember at no time whatsoever is the GPS ever synchronized to your PIC code. Whatever the PIC is doing it must be prepared to capture an inbound character at anytime ..that's where the RDA interrupt comes in and the severe lack of extensive code in the interrupt makes sure that the interrupt work is done before the next char would cause the next interrupt.
Have fun you'll learn alot.
PS some GPS modules can be polled but most just start talking so you can't synchronize them to your code.

[Douglas Kennedy]

I believe you would learn more by doing this yourself but reluctantly here is some code I wrote a few years ago
It takes an rs232 talking GPS and sets it up as a slave in an I2C bus
you won't need the I2C stuff but the GPS parsing might help
Disclaimer :
the code below is not for commercial use and there is no assertion that it is save for any risky purpose like navigation. Any user of this code assumes all risks.

[Guest]

Thanks for all the help. I've been trying out new codes before logging on and the results look quite promising. I'll probably just stick to those and try to improve on them step by step. Anyway, thanks again.

[darkswarm]

Thanks for all the help. I've been trying out new codes before logging into the forum and the results look quite promising. I'll probably just stick to those and try to improve on them step by step. Anyway, thanks again.

[darkswarm]

Hi,

I've added a few lines of codes to the program i posted last time n results have been encouraging. This is what i get to see on Hyperterminal.

[Douglas Kennedy]

Your code synchronises to the receipt of sentences by capturing one into your buffer and then processing it . Your code contains very time intensive printf statements and there is no absolute guarantee that they will finish before the receipt of the next sentence. Your code so far is having good luck in partially working but any addition code especially printf type statements will eventually doom it.
RS232 is asynchronous and the luck you are having so far with your code is due to the GPS taking sufficient specific pause between any two sentences you are interested in. Printf statements even in an interrupt fed circular buffer will eventually doom things but only if on average they exceed the availbable time between sentences.
As to the first sentence being messed up it may be due to the fact that your code requires synchronization with an essentially asynchronous start up. Alternatively a GPS on start up ( and other times) can speak a sentence with 0 position info info since it has placed a don't use code in its status byte (" loss of signal")
Advice:
up the baud rate on th PIC to PC side to reduce the time the printf takes
Check the sentence status byte for "A" ok
look at an interrupt fed circular buffer.

[darkswarm]

Thanks for your suggestion. I'll certainly try it when i have the time. But now, my supervisor wants me to add a new feature in the program, which is to display the location in addition to the latitude and longitude. For example,

Latitude:0257.8069,N
Longitude:10143.5982,E
Location:College of Engineering

He doesn't really require a very accurate location, just an approximation so that he'll know which place the latitude and longitude refer to.

I tried adding a few lines of codes to the previous program, but it did not work. i guess i was naive enough to think a few lines of codes like this would work.

[Douglas Kennedy]

I thought this was someone trying to work with a GPS as a hobby.
Sadly this looks like another homework assignment and I bought into it by suppyling sample code..I'll have to try harder to spot this going forward.

Advice
Never expect to be spoonfed
A smart person learns from his/her own errors
A wise person learns from others.
Be honest with your supervisor tell him or her you don't fully understand and are asking this board to do some of the heavy lifting for you that way it is you and not this board that gets graded.

PS.
I will always be grateful to PCMprogrammer Mark and others. A search of this board will answer 90% of questions and 100% of common pitfalls.