query on c

Rather than look for the character look for the ASCII code. Carriage return (enter) is 13dec or Dhex so look for that. Be sure that your input buffer is long enough to handle the '\0' string terminator at the end.

You may well want to have a timeout method to avoid getting stuck in the loop. What if the GPS has a comms hiccup and the carriage return is lost? You'll sit for ever waiting for it to come.

This should probably be in a different group but, if you would post your code I will take a look at it. Parsing a nmea sentence it pretty basic in my opinion, you don't even need the \n or \r because you can sync on $ and * chars.

good luck Edwin

Aha, that's the culprit. Your terminal probably program only sends the CR (0x0D). You might be able to set it to output CR and LF when the enter key is pressed.

Meindert

A proper NMEA device does not output a \0 after an NMEA string.

Correct. you should use a time-out of second. NMEA specifies that the sentence should be transmitted within 1 second.

Rule is: check for a $ or ! for the start of the sentence, and for a CR/LF pair at the end. *Every* NMEA device should follow this format.

Meindert

sindhu escribió:

Hi, Googleing I found this:

but my GPS don't send a CR + LF only send a CR (0x10). You could plug your GPS in the serial port and take a look with the Hyperterminal at the string, and make a decision.

... snip ...

You don't need any of that for a positive action, if you can drive an input state machine from an interrupt. The ISR should look roughly like:

/* totally untested */ void process(void) {

int ch; static enum state {startup, newch, awaitlf}; static char buf[MAXMSG]; static int ix; static time_t t, now; /* assumed in millisecs */

ch = getc(inputdevice); if ('$' == ch) state = startup; switch (state) { case startup: ix = 0; t = systemtime; if ('$' == ch) state = newch; break; case newch: if ('\n' == ch) state = awaitlf; else if (ix < MAXMSG-1) buf[ix++] = ch; else state = startup; /* overlong input, discard */ break; case awaitlf: if ('\r' == ch) { now = systemtime; if ((now - t) < TIMEOUT) { /* not too long */ buf[ix] = '\0'; /* terminate string */ ship(buf); /* to processing code, make copy */ } state = startup; break; default: state = startup; break; } /* switch */ return; /* from interrupt */ } /* process, untested */

Watch out for timer wrap-around.

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

Which GPS is that?

Meindert

And how did you check this? With hyperterminal? Then please re-check with a real terminal program. Hyperterminal always translates to a single when capturing to file.

For test I just captured a bit of data from my GPS with hyperterminal and loaded the file in hexedit: 0A only

Then I started Docklight and this showed 0D/0A.

Btw. CR = dec 13 is hex 0x0D and LF = dec 10 = hex 0x0A

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

There is some information here:

and here: that should be of help to you.

Right, my GPS sends a , but I finish the routine when I recive a CR.

Hi all, Thank you for all who has replied . As i told ,iam working on GPS. iam using Turbo c compiler. i have given the NMEA sentence GPRMC.as soon as i press enter key it has to output the string which i have placed in char array of size 100. I have checked for CR and LF(ie either CR or LF) .still not getting the output. after compilation,it goes to output screen,i have given GPRMC sentence and pressed enter key.the cursor blinks in the next line .it got stuck. it didnt return to edit screen.

can u point out the mistake.

bye.

Hi all, Thank you for all who has replied . As i told ,iam working on GPS. iam using Turbo c compiler. i have given the NMEA sentence GPRMC.as soon as i press enter key it has to output the string which i have placed in char array of size 100. I have checked for CR and LF(ie either CR or LF) .still not getting the output. after compilation,it goes to output screen,i have given GPRMC sentence and pressed enter key.the cursor blinks in the next line .it got stuck. it didnt return to edit screen.

can u point out the mistake.

bye.

It would greatly help if we could take a peek at that code, instead of gazing at our crystal ball and trying to figure out "who you given the RMC sentence" and all....

Meindert

Perhaps you might want to check what you are typing - grammatical accuracy doesn't seem to be high on your priority list - however, Mr Falconer has covered that.

I would look very closely at the char array and whether you are overflowing it. This is something I do by accident sometimes and it always results in some very strange behaviour. If your debugger supports it then set a breakpoint to capture writes on the 101st element and see what happens.

Have a look at nmealogr.zip at

- it is a simple NMEA-0183 logging and display program written in Turbo C.

--
Peter Bennett, VE7CEI  Vancouver BC, Canada
peterbb4 (at) interchange.ubc.ca  
new newsgroup users info : http://vancouver-webpages.com/nnq
GPS and NMEA info: http://vancouver-webpages.com/peter
Vancouver Power Squadron: http://vancouver.powersquadron.ca

Where exactly is the NMEA Sentence coming from? (keyboard/serial port...) How often is it coming? What significance is 'enter' key as we do not know what you are using for

Platform (host) Operating System (if any) Type of serial port Type of serial port driver/buffering How your application is or is not handling the serial stream.

More likely the programme uses calls like fetches of strings from stdin, whereby the CR/LF/ENTER is NOT passed or passed correctly to the array in the first place. More than likely the string has '\0' terminator (if enought room in array) and has one of the following scenario due to not understanding the use of system I/O calls

1/ NO CR or LF 2/ LF (\n) only as CR or CRLF translated to LF 3/ CR (\r) only as CR or CRLF translated to CR

However the issue of array size is also possible problem, especially if this is a PC with serial port connected to a GPS device. The buffer may have overflowed many times and not been synchronised at the programme start as the device may have transmitted many sentences.

We know nothing of how the data is being captured, what error recovery, buffer handling, serial port handling, let alone items too numerous to mention as every attempt to get answers such as "Let's see the code" fall on deaf ears.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

Hi, I need to write a c code for calculating the distance detween two points on earth using GPS data. NMEA sentence from GPS receiver is GPRMC . The sentence is $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A It is given thro keyboard.code checks for $ and then put the characters in an array of size 100. After the last character,'\0'is assigned to terminate the character array. How to identify the end of sentence?(i/p comes from keyboard. scanf is used in code) could u pls advice me what to do?

thank you,

sindhu

Why is the NMEA sentence coming from a keyboard?

Why are you using scanf?

If you must use scanf, it is safer to use fgets/sscanf, to handle errors.

Your problems are about how the C library functions work on your compiler and how it handles the 'enter' key, on stdin.

Which will be completely different to how it would work for a real GPS receiver usually via a serial port, unless you structure your code properly.

This is not an embedded issue, but a C programming issue, and your understanding of the system i/o and string processing functions.

Read up on scanf and your library functions.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate