Non-GPS NMEA sentences using GPSSerial

N

navman

Member
Licensed User
Longtime User

I think we both may have made some incorrect assumptions and realise why the ,R and ,T circumstances aren't working.
I didn't take your instructions as being so literal and thought the character after the comma was being used as a search term for the remainder of the sentence. The R or T don't in fact occur immediately after the sentence identifier field.

The actual sentence structure is as follows:
$--MWV,x.x,a,y.y,b,A*hh<CR><LF>
where
x.x is a variable length numeric field for wind angle
a is a single character R or T
y.y is a variable length numeric field for wind speed
b is units K or M or N
A is status, A = valid
hh is hex checksum

Clearly, simply matching a string isn't going to work to select the specific R or T sentence.
 

agraham

Expert
Licensed User
Longtime User
I think you will just have to accept all the MWV sentences, StrSplit them into an array and do a quick check on the element at index 2 to see if you want the data or not. There is no more overhead to do that in a compiled application than there is to build it into the library.
 
N

navman

Member
Licensed User
Longtime User

I'd be happy to do as you suggest but as both sentences have the same ID (MWV) and are transmitted one after the other every second, one over-writes the other by the time the data is read with a 1 second tick interval. If the tick interval is decreased to the point where both sentences can be read independently, I'm not sure the overhead could be coped with and there is still no guarantee I'll pick up all sentences.

If I revert to the other technique of reading all the raw data I assume I'll have to effectively include the code from the library to break data into sentences etc which seems to negate the point of using the library in the first place.

I think my best alternative is to put the time into extending what you have already done with the library - or at least have a go.
 
M

mjcoon

Well-Known Member
Licensed User
navman said:
... both sentences have the same ID (MWV) and are transmitted one after the other every second, one over-writes the other by the time the data is read with a 1 second tick interval.
Click to expand...

Isn't a second long enough to do the processing so long as you grab both first and process after? (I'm being simplistic on purpose, of course! ;-)

Mike.
 
N

navman

Member
Licensed User
Longtime User
mjcoon said:
Isn't a second long enough to do the processing so long as you grab both first and process after? (I'm being simplistic on purpose, of course! ;-)

Mike.
Click to expand...

Mike,
My understanding of the GPSSerial library is that it will only return the most recently received version of a particular sentence ID. The sentence in question (MWV) is unique in that it is sent twice per second with different contents, one sentence immediately after the other (unlike other sentence IDs which are typically only once per second eg RMC, GLL). In order to catch both versions (or indeed either version) with any degree of regularity using the library method discussed earlier, I would have to read the MWV property with much higher frequency than 1 second to avoid data being overwritten before being read.

I had wanted to utilise all the serial and sentence compilation functionality of the library rather than reinvent the wheel in my code which is why I would prefer to try to extend the library functionality rather than revert to dealing with raw data.

Does this make sense or is their another method I'm missing?
 
M

mjcoon

Well-Known Member
Licensed User

I doubt you are missing anything! And I have not bothered to look up what the functionality is that you would have to replicate. If it is just calling StrSplit (as Andrew was implying) that doesn't seem too hard.

I was recollecting my early parsing of NMEA (late 1990s, probably, on a Psion series 3) when I found that the SV sentence divided up the dozen or so satellites' info into three consecutive sentences. It was essential to get all three in the same one-second burst because it would probably be inconsistent in subsequent bursts. This all required some optimisation (the details of which I do not remember!) to get it to work. I'll have the code somewhere, probably...

Mike.
 
You must log in or register to reply here.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…