Non-GPS NMEA sentences using GPSSerial

N

navman

Member
Licensed User
Longtime User

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

Expert
Licensed User
Longtime User
navman said:
First: The instruments send all sentences with the prefix "II" (Integrated Instrumentation according to NMEA 0183) not "GP"
Click to expand...
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.
Click to expand...
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
Click to expand...
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
 
Last edited:

agraham

Expert
Licensed User
Longtime User
navman said:
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
Click to expand...
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.
 
Last edited:

agraham

Expert
Licensed User
Longtime User
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.
 

Attachments

  • GPSSerial1.33.zip
    9.7 KB · Views: 279
Last edited:
N

navman

Member
Licensed User
Longtime User
agraham said:
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.
Click to expand...

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.

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

Fantastic! That's problem number one dealt with.

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

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.

agraham said:
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.
Click to expand...

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.

agraham said:
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.
Click to expand...

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?
 
N

navman

Member
Licensed User
Longtime User
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.
 
M

mjcoon

Well-Known Member
Licensed User
navman said:
... 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".
Click to expand...

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

Expert
Licensed User
Longtime User
navman said:
So, if I write "$IIMWV,R" to NMEA1 and "$IIMWV,T" to NMEA2, I should be able to independently read both sentences.
Click to expand...
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.
Click to expand...
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.
Click to expand...
Possibly but I think I'll keep it as an exact match as then it is certain what is happening..
 
N

navman

Member
Licensed User
Longtime User

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:
 
N

navman

Member
Licensed User
Longtime User

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

Expert
Licensed User
Longtime User
navman said:
the GPxxx properties were included in amongst the NMEA port info text in the original GPSSerial help file
Click to expand...
Actually they are in alphabetical order which is the convention for Basic4ppc help files.

they required the NMEA port to be open as well.
Click to expand...
No.

So is it the GetGPSData method that fills the GPxxx and now also NMEA1-4 properties?
Click to expand...
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.
 
N

navman

Member
Licensed User
Longtime User
agraham said:
Actually they are in alphabetical order which is the convention for Basic4ppc help files.
Click to expand...

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?
 
N

navman

Member
Licensed User
Longtime User
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
 
Last edited:
N

navman

Member
Licensed User
Longtime User
agraham said:
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?
Click to expand...

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

Expert
Licensed User
Longtime User
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.
 
N

navman

Member
Licensed User
Longtime User
agraham said:
Have you got a GPSSerial.cs in your libraries folder?
Click to expand...

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

navman

Member
Licensed User
Longtime User
Back again


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

Expert
Licensed User
Longtime User
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.
Click to expand...
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.
 
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…