Non-GPS NMEA sentences using GPSSerial

[navman]

Originally Posted by agraham
Alternatively, if you have VS2005 or later you could build an enhanced library adding the parsing for extra sentences which would be a trivial exercise. If you don't have the capability I would be happy to add any sentences you wanted.

Originally Posted by navman
I'm attempting to write some tactical yacht racing software for my use that requires NMEA input from not only a GPS but also a wind instrument.
The one stumbling block I have would seem to be the parsing of the MWV NMEA sentence. I would be most grateful if you could extend your offer above to include this sentence in the library.

Originally Posted by agraham
Try the attached. (see GPSDriverNMEA library thread) There are two new read/write properties, GETUSER1 and GETUSER2. If you write to either of them a case-sensitive prefix such as "$GPMWV" then you should be able to read from that property the last NMEA sentence received with that prefix. There is no restriction on when you can change them, they take effect any time.

Post if it works, or doesn't. There are a couple of very minor bug fixes in as well that weren't worth reposting the library for before so I'll repost it properly when it works.

I've now installed the NMEA interface into the boat and captured some data to see what else I might need to do. Turns out I really need RMC, DPT, MWV and VHW sentences with optionally GLL and HDG as well, although these 2 are really redundant.
A couple of hurdles have come to light though I'm afraid.

First: The instruments send all sentences with the prefix "II" (Integrated Instrumentation according to NMEA 0183) not "GP" so there goes the ability of GPSSerial to do RMC out of the box and clearly I'd need a couple more GETUSER properties to do all sentences.

Second: MWV can transmit wind data in two ways, relative or true, each identified by an R or T in the sentence. Unfortunately the instrument sends BOTH sentence variations, one after the other, each with the MWV sentence format. Without the ability to identify the particular sentence format characters seperately, I suspect the current parsing techniques would end up losing the first sentence as it is stated above "the last NMEA sentence received" is the one able to be read. Depending on where the timer tick lands in relation to the serial data from the instruments, one could end up losing either R or T. I really need a method to capture both reliably.

This has got me stumped. Any help gratefully received.

 

[agraham]

First: The instruments send all sentences with the prefix "II" (Integrated Instrumentation according to NMEA 0183) not "GP"

That's not a problem, The GP is not assumed by the library. Just specify "$IIMWV" as the prefix.

I'd need a couple more GETUSER properties to do all sentences.

I have changed the name from GETUSER to NMEA in the attached version and there are four of them. NMEA1 to NMEA4.

Second: MWV can transmit wind data in two ways, relative or true

Specify the prefix as "$IIMWV,R" or "$IIMWV,T". Why do you need both, isn't one sufficient? Can't you calculate the other? EDIT:- Oops, that won't work I'll think about it a bit more.

EDIT:- Attachment removed, see post #4

 

[agraham]

First: The instruments send all sentences with the prefix "II" (Integrated Instrumentation according to NMEA 0183) not "GP" so there goes the ability of GPSSerial to do RMC out of the box

I think I originally misunderstood this when I read it. Do you mean that $--GSA comes in as $IIGSA and not "GPGSA? By the way, $GPRMC is already supported.

 

[agraham]

Try this library.

The four GPxxx properties are now writable. They default to "$GPxxx" but if you write a two character sender string such as "II" they will try to match "$IIxxx" sentences.

The four NMEAx properties now match the first part of the sentence including any characters after the prefix. so writing "$IIMWV" will return both MWV sentences but "$IIMWV,R" will return only the relative sentence.

 

[navman]

I think I originally misunderstood this when I read it. Do you mean that $--GSA comes in as $IIGSA and not "GPGSA? By the way, $GPRMC is already supported.

Yes, and yes I was aware that $GPRMC was supported which is why I was disappointed the instruments changed all the prefix id's to II and I have to now deal with $IIRMC. The GPS connects to an input on the instrument system and the system changes the prefix before sending out a combination of GPS and other sentences on the output, all beginning with $IIxxx.

I have changed the name from GETUSER to NMEA in the attached version and there are four of them. NMEA1 to NMEA4.

Fantastic! That's problem number one dealt with.

Specify the prefix as "$IIMWV,R" or "$IIMWV,T". Why do you need both, isn't one sufficient? Can't you calculate the other?

Yes, and no. I guess what is most important is that I can reliably choose which one I'm getting. My interpretation of the library code is that as it stood, I could get either depending on which was received immediately before the $IIMWV call. Your new method of specifying the T or R character as well is brilliant and should overcome my impass.

In all my pre-code design work I have only required the T (True wind) version, but the instruments calculate the T from the R (apparent wind) version based on the boats motion through the water. In a situation of light wind and strong current, the T calculation could be quite imprecise so I had wanted to do a few comparisons using the R version, COG and SOG to see if there was much impact on the accuracy of true wind.

The four GPxxx properties are now writable. They default to "$GPxxx" but if you write a two character sender string such as "II" they will try to match "$IIxxx" sentences.

Great. So I can write "II" to the "$GPRMC" property and then when reading from "$GPRMC" I will actually be reading data from "$IIRMC" sentences.

The four NMEAx properties now match the first part of the sentence including any characters after the prefix. so writing "$IIMWV" will return both MWV sentences but "$IIMWV,R" will return only the relative sentence.

You are amazing, thankyou. So, if I write "$IIMWV,R" to NMEA1 and "$IIMWV,T" to NMEA2, I should be able to independently read both sentences.

Given all the reading of sentences I am doing is through the NMEA port, I won't need to use the conventional serial driver method at all. Again, not being across the techniques used in the library, I am concerned at the risk and implications of buffer overrun. If I am reading the GPRMC sentence and all NMEA sentences for which I have written parameters to on a regular basis, are there any other things I should be doing to prevent overrun?

 

[navman]

Why bother with the Sender ID?

As I was writing my last post, it occurred to me that it may be easier for "everyone" if the sender ID characters were simply ignored all together. Just so we are on the same page, its the "XX" in "$XXABC". The important part is clearly the "ABC". I'm not sure anyone would be concerned that the data was being sent by a GPS, NAV instrument or any other device. The 4 "GPxxx" properties could be replaced by just "xxx" properties and the NMEA1 - 4 properties could just use a 3 character parameter. This makes the whole NMEASerial functionality more generic and OK, I accept, if I change boats and they have a different brand of instruments, it makes my life easier too.

 

[mjcoon]

... It may be easier for "everyone" if the sender ID characters were simply ignored all together. Just so we are on the same page, its the "XX" in "$XXABC".

But can you be sure that the triplet XXX is always unique and never re-uses one of the standard triplets so that the sentence can only be distinguished by sender ID?

I had imagined that the sender ID had been invented just to ensure complete uniqueness so long as all five letters were taken into account (a sort of namespace).

Mike.

 

[agraham]

So, if I write "$IIMWV,R" to NMEA1 and "$IIMWV,T" to NMEA2, I should be able to independently read both sentences.

Yes

Given all the reading of sentences I am doing is through the NMEA port ... I am concerned at the risk and implications of buffer overrun.

You are not using the NMEA port, or shouldn't be, so there is no need to open it and it saves processing time to not open it. The NMEA port just gives you the raw data stream, via NMEAReadData or NMEAReadString, that you would need to parse into sentences yourself. Buffer overrun can occur if you don't read the raw data quickly enough but as you are not dealing with raw data this is a non-issue.

You are reading individual NMEA sentences parsed from the data stream by the GPSSerial code that are then further parsed to fill in the GPS data properties. Buffer overrun is not an issue here, the GPSSerial code keeps up with the data stream and if you don't read a sentence in time it just gets replaced by the next one.

In retrospect renaming GGETUSER to NMEA is a bit confusing as all the other methods and properties prefixed NMEA are do do with the NMEA raw data port. I think I will further rename them to something like GPXXX1 to better match the other parsed sentence properties.

it may be easier for "everyone" if the sender ID characters were simply ignored all together.

Possibly but I think I'll keep it as an exact match as then it is certain what is happening..

 

[navman]

But can you be sure that the triplet XXX is always unique and never re-uses one of the standard triplets so that the sentence can only be distinguished by sender ID?

I had imagined that the sender ID had been invented just to ensure complete uniqueness so long as all five letters were taken into account (a sort of namespace).

Mike.

The "NMEA Sentence Formatter", the 3 characters after the 2 "talker ID" characters are highly defined under the NMEA standard so any use of a certain 3 characters implies a specific sentence format no matter what the talker happens to be. In my MWV example, the talker could have been II (integrated Instrumentation) or WI (weather instrument). It really doesn't matter what sort of instrument the talker thinks they are.

There is also no identification of the particular instrument so if you had say 2 GPS units for redundancy and combined their serial data through some external device before bringing into one serial port on a PPC, there would be no way of telling which GPRMC sentence came from which instrument for instance. Even if you used 2 PPC serial ports, each sentence would appear identical in format. The talker ID is more a "type" identifier than an actual instrument ID.

However, it's not my library so I'm happy to go with the opinion of the far more experienced expert as to how they write their software.
Greg:sign0144:

 

[navman]

You are not using the NMEA port, or shouldn't be, so there is no need to open it and it saves processing time to not open it. The NMEA port just gives you the raw data stream, via NMEAReadData or NMEAReadString, that you would need to parse into sentences yourself.
You are reading individual NMEA sentences parsed from the data stream by the GPSSerial code that are then further parsed to fill in the GPS data properties.

Sorry, I assumed that because the GPxxx properties were included in amongst the NMEA port info text in the original GPSSerial help file, they required the NMEA port to be open as well.
So is it the GetGPSData method that fills the GPxxx and now also NMEA1-4 properties?

 

[agraham]

the GPxxx properties were included in amongst the NMEA port info text in the original GPSSerial help file

Actually they are in alphabetical order which is the convention for Basic4ppc help files.

they required the NMEA port to be open as well.

No.

So is it the GetGPSData method that fills the GPxxx and now also NMEA1-4 properties?

No. Open starts acquiring data and filling the GPXXX and NMEAx (soon to be renamed) sentences and parsing the individual satellite data from the sentences. In GPSDriver GetGPSData actually fetches the latest data from the GPS Intermediate Driver, which does the data extraction, and updates the various individual data properties. GetGPSData exists in GPSSerial for compatibility but after the first call to it, which sets internal stuff, it probably isn't entirely necessary to keep calling it but doing so does update the internal validity of the individual data depending upon the age that you define in the call. GetGPSData is completely separate from the ability to read the complete sentences which is not present in GPSDriver and is present in GPSSerial as a by-product of it having to parse the sentences to get the individual data points.

 

[navman]

Actually they are in alphabetical order which is the convention for Basic4ppc help files.

Thanks for pointing that out.

Since the last post I've been coding the structure at every opportunity and have just got to the interesting bit of getting the data from the GPS using the method discussed earlier. All has been going well but unfortunately it won't now compile after trying to write the prefix to GPS.GPRMC and NMEA1 etc.
error images are attached






I have added the new GPSSerial library as it is clear in the third image that the properties are shown as I/O types. Am I doing something wrong?

 

[agraham]

Those properties compile OK for me so I would need to see some actual code rather than just the error messages to see what you are doing wrong.

 

[navman]

Variable Declarations so far:
Dim Type(RMC,UTC,STS,LAT,LTH,LON,LNH,SOG,COG,DAT,MAG,MVD,CHK)RMCData
Dim Type(MWV,WAM,REF,WSP,WSU,STW,CHW)MWVData
Dim Type(VHW,HD1,HDT,HD2,HDM,LGS,LGU,SPD,SPK,CHL)VHWData
Dim Type(DPT,DEP,OFF,CHD)DPTData
Public RMCuse, MWVuse, VHWuse, DPTuse, ConfigChange As Boolean
Public RMCprefix, MWVprefix, VHWprefix, DPTprefix, GPSStatus
Public TimerLoad, UTCTicks, LocalTimeTicks, UTCOffTicks, UTCOff, StartTimeTicks, RaceTimerTicks As Number
Public GPSLat, GPSLon, SSLLat, SSLLon, PSLLat, PSLLon As Number
Public LMLat, LMLon, LMBear, LMDist, WMLat, WMLon, WMBear, WMDist As Number
Public RaceTimerRun As Boolean
Reload = cNo

The recently added code that causes error:
Sub Timer1_Tick
If GPS.Opened Then
If ConfigChange = True Then
' update config settings and reinitialise NMEA sentence data
If RMCuse Then
GPS.GPRMC = RMCprefix
End If
If MWVuse Then
GPS.NMEA1 = MWVprefix
End If
If VHWuse Then
GPS.NMEA2 = VHWprefix
End If
If DPTuse Then
GPS.NMEA3 = DPTprefix
End If
ConfigChange = False
End If

XXXprefix is a two character string eg GP or II
I should add it runs OK on the desktop - just won't compile for the device

 

[agraham]

I can't see a problem, expecially as it runs on the desktop. Does it compile for the desktop OK. Have you added GSPSerial.dll as a device component?

 

[navman]

I can't see a problem, expecially as it runs on the desktop. Does it compile for the desktop OK. Have you added GSPSerial.dll as a device component?

It doesn't compile for either desktop or device. The errors are the same.
I have removed and added the dll component a few times to make absolutely sure I'm using the right one.

 

[agraham]

Have you got a GPSSerial.cs in your libraries folder? If so then delete it as the source code in that does not match the modified library. For good measure delete GPSSerial.dll if that is there as well. You can reinstate them, and so merge the source in the exe, once I have posted the next "official" version with source code that includes these changes.

 

[navman]

Have you got a GPSSerial.cs in your libraries folder?

Good call!
Not having read up on the fine print of libraries and compilation I was less knowledgable yesterday than I am now on how libraries get merged at compilation time.
I deleted the .CS file and all is well again thanks.

 

[navman]

Back again

Try this library.

The four GPxxx properties are now writable. They default to "$GPxxx" but if you write a two character sender string such as "II" they will try to match "$IIxxx" sentences.

The four NMEAx properties now match the first part of the sentence including any characters after the prefix. so writing "$IIMWV" will return both MWV sentences but "$IIMWV,R" will return only the relative sentence.

Hi, Happy New Year for tomorrow!

After a wife and family imposed period of inactivity (longer than anticipated), I'm finally back on to the project. I expect you are very busy with the new b4android tasks but would appreciate another look at this at some stage please.

When I was last working with data from the boat, the "$IIMWV" style of getting data was working and returning both the R and T type sentences as they happened to be received, but when I wrote the "$IIMWV,R" style of code, no data of the "MWV" type was returned correctly at all and I believe the program crashed after a little while.

If you aren't able to help with this any further, could you please post the most recent source code for the library as I have a programmer friend who works with visual studio who may have a look for me.

 

[agraham]

As I wrote before

The four NMEAx properties now match the first part of the sentence including any characters after the prefix. so writing "$IIMWV" will return both MWV sentences but "$IIMWV,R" will return only the relative sentence.

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 can see no reason why the library should crash when it is not matching any sentences, it will just ignore them.