problem with ublox gps

[Ttelmah]

Probably my typing. I run in a virtual PC, and it has a nasty habit of sometimes changing what keys return what character. I'd have expected an error message when he tried to compile though.

Best Wishes

[andys]

[Ttelmah]

You need to look at what the parser is doing.

It looks for particular commas, and then parses out the parts of the string after these. Take your string, print it out, and then run through the parser 'on paper', and see what it'll do. This is what any of the programmers here would do, whether starting with their own code, or a parser from someone else.

It's probably something minor like a difference in your string that is making the parser not pull the parts it should. Maybe it assumes that there is always a character between commas, or something similar.

[ezflyr]

Hi andys,

To answer your specific question, yes, it does appear that you are receiving data correctly from the GPS module! The problem, it appears is in the parser.

As Ttelmah suggests, there is nothing 'magic' about that code. It simply processes the GPRMC sentence looking for comma positions and extracting characters. Try to play a bit and see if you can figure out what is going on.

I don't use that code myself, but would not mind having a look. At this point I can't do that for a couple of days, so try it yourself first, but if you get stuck I'll see if I can get it to work!

John

[andys]

There are 2 questions according the results which i received from the gps.
the first is:
according the http://www.gpsinformation.org/dale/nmea.htm

[ezflyr]

Hi andys,

I did a bit of looking at the Ublox Neo 6 documentation, and it says that if these fields contain no data then it means "Magnetic variation value, not being output by receiver", and "Magnetic variation E/W value, not being output by receiver". The documentation also states "By default the receiver will not output invalid data. In such cases, it will output empty fields". The documentations does not seem to address why the data may be invalid, but it could be that some data on the module is outdated.

Here is the document, page #63.

http://www.u-blox.com/images/downloads/Product_Docs/u-blox6_ReceiverDescriptionProtocolSpec_%28GPS.G6-SW-10018%29.pdf

Magnetic variation (the difference between magnetic North and true North) is something that the GPS "looks up" in a database, or "calculates" based a model (such as the World Magnetic Model) using current position as a reference. Not sure how your does it, and not sure why your GPS is not doing is properly, although I did see several references on-line to Ublox receivers not getting this right in some circumstances. The models typically used are updated periodically because variation is not constant. The most common model is updated every 5 years. Maybe old model data causes your issue?

A couple of key points. Have you checked the checksum in a received GPRMC sentence? Either write some code to do it, or copy/paste the data to an online NMEA checksum tool to see if the data you received is correct. Also, are you seeing an 'A' in the 'Valid' field? In other words, is everything else being sent by the GPS receiver OK??

John

[Ttelmah]

Whether it is needed/wanted, depends on what you actually want to do?.
Many mapping applications and operations now work purely with 'true north'. Where you need it is on things like maritime applications where bearings are given as 'compass', and much data recorded on charts also uses this.

If you are working over a reasonably sized area, it is not hard to just code your own lookup for this.

If you read the data output specifications for this receiver, for the RMC sentence, it says:

"Magnetic variation value, not being output by
receiver"

On systems using this GPS, it is common to have a separate compass, and store a local value for variation, input by the user, or calculated from the difference between GPS track, and compass bearing.

[andys]

I would like to ask if there is any way for the following c functions to work:
sscanf,strtok,strcmp,

I tried to use them but i get error for these functions.

[ezflyr]

Hi,

There is no native sscanf provided in CCS C. Here is a link to a sscanf function written some time ago by a forum user, Mark:

http://www.ccsinfo.com/forum/viewtopic.php?t=20225

Strcmp and Strtok are native string functions, and are available for use if you include String.h.

John

[andys]

At the code below:

[PCM programmer]

Use the forum's search page:
http://www.ccsinfo.com/forum/search.php
Search for this:

[andys]

I fixed the error with the strcmp but i still have problem with strtok and sscanf.

how to fix these??

[ezflyr]

Hi andys,

Imagine if you went to your local auto mechanic and said "I'm having a problem with my car, how to fix it?" What kind of a look do you think you would receive? Well, that is exactly what you have presented to us! How is it possible for us to help solve the problem, when we have no idea what the problem actually is?? Without seeing your code, without the compiler error messages (if any), and without some description of the actual problem, then you are quite literally asking us to read your mind!

John

[Ttelmah]

You have already been given a link to a sscanf.

The same comment applies to all string operations. PASS_STRINGS=IN_RAM should fix the pointer to constant problem across the board.

Have you looked at the manual entry for strtok?.

You need to be very careful with strtok, to trap the 0 return when the token is not in the target string.

[andys]

For the sscanf
i have already add the

#device PASS_STRINGS=IN_RAM

also i tried other thinks to fix the problem (from the link) without success.

I used V4.140 version.


for the strtok i didn't find anything from the manual