Non-GPS NMEA sentences using GPSSerial

[navman]

As I wrote before
There is no different code in the two circumstances. All the code does is match whatever it is given to the start of the incoming sentences so if "$IIMWV" matches but "$IIMWV,R" doesnt there are sentences arriving prefixed with $IIMWV" but no sentences arriving prefixed "$IIMWV,R". Note that the comparison is case sensitive.

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]

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.

 

[navman]

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.

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.

 

[mjcoon]

... 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.

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.

 

[navman]

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.

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?

 

[mjcoon]

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?

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.