NMEA GPS messages

[aldina]

Hello,

I'm using a GPS module (Quectel L86) to read information from NMEA messages ($GPVTG....)

My Code:

[Ttelmah]

First thing, the UART on this chip is a PPS peripheral. You _must_ use
pin select to set it up. Currently you are using a software UART.
Look at the sticky at the top of the forum for how to use pin select.

Second thing, with this done, the code you post would hang the UART.
The reason is that you sit for 100mSec lumps not reading the UART. If
a UART receives a couple of characters and they are not read, it switches
into an 'overrun error', and stops working.
Two solutions exist for this:
1) Use an interrupt driven RS232 RX. This then receives the characters
when they arrive. Long term the right solution, but for now not needed.
However the second fix is...
2) Use 'ERRORS' in your #use RS232 statement. On a hardware UART,
this should _always_ be used, unless you are adding your own error
handling. This adds code to the RS232 handling routine, to automatically
clear the overrun error if it occurs. So, get in the habit, of always using this.

As a comment then you drive C4 low. The idle for a TTL serial line is high.
Don't drive this pin (the UART will do it).

[aldina]

Hi Ttelmah,

Thank you very much for your answer and help.

First thing is done and works. Second thing, I'm choose using ERRORS in #USE RS232 statement. This is my new code:

[Ttelmah]

The problem you now have is the difference between text, and numbers.
The text character '1' has a numeric value of 49. '0' a numeric value of
48. So you are not getting the value you expect. Look at the atol function.
Add a terminating NULL to the array holding the input characters, and this
can then convert the text into a numeric result.

[bkamen]

As Ttelmah has said - and having written enough NMEA parsing systems, I can't also stress enough:

Really consider writing your GPS Serial receiver as an ISR.

Do it on a simple project like this so you have the hang of it for more complex programs where it will matter.

I did a fun secondary display for a Garmin GPS's VHF-Out mode and there's a lot of data and it actually comes out of the GPS at 9600bps... and every cycle matters.

The RS232 RX had to be an ISR with good buffering.

So -- do it now for the practice if you plan on doing more of this down the road.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[temtronic]

As others have said, you really need to get GPS data inside an ISR. Actually you should use an ISR for all 'serial data' if the PIC has a Hardware UART.
Also, you should run the PIC at the highest clock speed that it can. The faster it runs, the more it can do for you. I downloaded the datasheet and that PIC can run at 32MHz. That is 32x FASTER than you have it going ! This will allow the PIC to do a LOT more, faster which is especially important for 'parsing' routines, floating point math, etc.

Jay

[aldina]

Hello everybody,


I continue trying to discover the solution to my problem.
This is my recent code:

[temtronic]

Get RID of the 'restart_WDT' AND disable the WDT ( fuse = NOWDT )
there is no need for you enable the WDT until your code is 100% reliable and 'ready for market'. Then and only then, enable the WDT and test your code under all conditions for at least a week of 24/7 testing.

While WDT may not be the actual problem regarding C3, it can be resetting the PIC and causing additional headaches.
At the very least by disabling it, you'll eliminate a possible source of problem.

also

If possible, use a faster clock rate. 1MHz may not be fast enough, especially to receive and parse the GPS serial data. Typically @4MHz, it take 1us per line of machine code..... faster is generally always better.

and
press the 'code' button before posting your program. That way it'll 'magically' turn green and line up better ! Easier for eyes to see what may be wrong....

[PrinceNai]

Hi,

My approach is different. All the parsing of UART characters received is done inside the RDA ISR using a switch statement. When $ is received, raise a flag to inform main to turn on one LED. When $GPVTG is received, record next characters into a buffer and raise a flag inside ISR to inform main to do something with the data. If you try to decode many different messages this switch statement gets quite big, but it is relatively easy to follow. In your case with just one message it is very easy.

[PrinceNai]

Please excuse indents and comment placements, I did it in Notepad++ and it differs a bit from CCS editor regarding tabs.

[PrinceNai]

The code was copied from an existing project and rewritten for this specific case. There were some mistakes in it regarding braces in if statements and no error checking. Please see the edited version. Still no guarantee that it is 100% clean of mistakes, but the previous version 100% wouldn't work.

Regards

[aldina]

Hi PrinceNai,

Thank you so much for your reply and help.
I'm trying to implement your RDA_ISR() code. I understand the essence of your proposed code but I want to ask you the following:

I'm receiving NMEA data like:

[PrinceNai]

Yes, I do. So, your start character is 'N', which is already in the code. This is when you start recording characters in the buffer, after 'N' is received. Your end character is 'K', or ',' , so replace 'X' in state 16 with 'K' or with ','. That way you will start filling the buffer after 'N' is received and stop when you get 'K' or ','. Then you only have to extract characters from buffer (you should have something like ",15.8," in your buffer and send those characters from correct location in the buffer to LCD or wherever you want.

Do you have a debugger? If yes, just add delay_cycles(1) into every state and have a breakpoint there. That way you'll see how you progress through state machine and check if there is a state the program doesn't reach. I can't test it, but I assure you that this approach works. I'm using it to get the messages from a GSM module (800 lines of code) and this part of the code never failed. As soon as I got all my braces right :-). Don't forget to initialize all the variables to 0 when you declare them, otherwise you'll have a problem.

Regards,
Samo

[bkamen]

[bkamen]

I wrote something similar to PrinceNai...

I was only interested in a single string -- so I could strip off stuff when I wanted.

I also used ring buffer of arrays (rather than a single dimension. Uses more RAM... but I had it so I wrote it that way)

The main routine just monitors the buffer index to see if there's new strings to process and if so, it processes them and then sets another index so the ISR doesn't overrun.

If the main loop can't keep up, the ISR throws strings away.

With this PIC running at 40MHz, I've never had that problem. :D