GPSSerial library

[reny1978to]

Hi Agraham, I've an HTP Pharos and I'm using GPSDriver and GPSSerial.

With GRPSerial (v. 1.3), even if I don't move my GPS releave that my speed is not 0 while with GPSDriver and my internal GPS my speed is 0.

What's the reason? It'a a problem of my External GPS?

Best regards,

Renato.

 

[agraham]

I assume that you are using GPSSerial with an external GPS. The speed is provided by the GPS not by the library. You can see what the GPS thinks the speed is by looking at GPSSerial.GPRMC, speed is item 7.

$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh
1 = UTC of position fix
2 = Data status (V= fix inValid, A = fix Active)
3 = Latitude - ddmm.mm
4 = N or S
5 = Longitude - ddmm.mm
6 = E or W
7 = Speed over ground in knots
8 = Track made good in degrees True
9 = UT date
10 = Magnetic variation degrees (Easterly var. subtracts from true course)
11 = E or W
12 = Checksum

 

[reny1978to]

Thanks a lot.

Just a doubt: if I take a look at the NMEA sentence with serial2.dll, Time is a string while with your function it returns me a Double.

I've already tried to manage that value with Date.FromOADate function but I didn't manage to obtain good result.

Can you tell me how you manage time value obtained by NMEA Sentence?

Thanks,

Renato.

 

[agraham]

I'm afraid that I don't understand the problem! Date.FromOADate looks like a C# or VB.NET statement. What are you trying to do? Why are you using Serial2? If you need NMEA data surely it is easier to use the ready parsed NMEA sentences available from GPSSerial.

 

[reny1978to]

U're right, I've been not precise.
Thanks, I'll try with parsed NMEA Sentence as you told.

 

[nl1007]

I've been looking at the help, demo and source for this and would like to make this comment:

Help:

"NMEAOpen: Opens the NMEA data port. The GPSSerial port does not have to be open to use this port."

This suggested to me that the NMEA was in some way seperate to the GPS Serial COM port, but then I couldn't see where the NMEA data would come from; I looked at the source, and the GPS 'Open' doesn't open the serial port if 'nmeaopen' is True, and the nmeabuffer is only filled from the serial port during 'datareceived' event. This suggests that the GPS Serial port should be opened first, then the NMEA 'port' opened - and the NMEA 'port' has to be closed before using the Close method (or else it doesn't close the serial port)..

 

[agraham]

NMEA was in some way seperate to the GPS Serial COM port

Your analysis is correct. In the early pre-release versions, if I remember correctly, they were logically separate. I think I did a simplification of the physical Serial Port handling at some time so only GSPSerial touched it and didn't get it quite right If there is ever a reason for new release I'll fix the code, and the Help!

 

[mjcoon]

I've just downloaded this library and demo and tried the latter.

Got attached error message (running under desktop IDE). What means?

The display shows data from my external GPS via COM1.

Mike.

 

[agraham]

It looks like your GPS is sending the time or date in an unexpected format.

Use the NMEA option to look at the GPRMC sentence

$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh
............^ time ^......................................^date^.............

GPSSerial expects the time and date in the above format. If it isn't that would account for the error. Note the spaces after "dd" and in the dots is a forum artifact and are not really present.

 

[mjcoon]

So here is a compatible solution, the GPSSerial library. It looks like GPSDriver to the code but hiding underneath is a SerialPort like in the Serial2 library. Porting code between the two should be a matter of changing your objects to use the correct library and altering the Open method which is the only one that differs between the two libraries.

I have been happily testing my version of GPS4PPC under the desktop IDE using GPSSerial and an external GPS.

I have also changed the Gpsdriver object to derive from Gpsdriver.dll, and removed the Open parameters, as per Help, and it runs compiled for my device with built-in GPS.

But if I go back to the desktop IDE (still running under the IDE OK) and try to compile for desktop, I get the attached compile error. The referenced line number and content seems entirely irrelevant. If I remove the module that is referred to, the same error shows up against an equally irrelevant line in a different module.

What does it mean? I'm happy to post the code if needed.

Mike.

 

[mjcoon]

... I'm happy to post the code if needed.

... but that should not be necessary since I have discovered that small changes to the published GPS4PPC will show the problem.

First, to compile under 6.90 it is necessary to add "As Double" to the two declarations of the UTM() array.

Then make the change that I believe is needed to compile for desktop, viz remove object GPSDriver (from GPSDriver.dll) and replace it with GPSDriver from the newly added GPSSerial.dll. Then compile (without bothering to make the change to the GPSDriver.Open syntax that would be needed to run the code; that change makes no difference) and get the compile error.

Mike.

 

[agraham]

My guess is that you have got both GPSDriver and GPSSerial added as components on the desktop side? If so then I am afraid that it won't work because GPSSerial, intentionally, looks like GPSDriver and you will get a namespace clash.

You will need two projects, one for the device with GPSDriver added as a component to both desktop and device, without GPSSerial, and one for the desktop with GPSSerial as a desktop component.

 

[mjcoon]

My guess is that you have got both GPSDriver and GPSSerial added as components on the desktop side? If so then I am afraid that it won't work because GPSSerial, intentionally, looks like GPSDriver and you will get a namespace clash.

You will need two projects, one for the device with GPSDriver added as a component to both desktop and device, without GPSSerial, and one for the desktop with GPSSerial as a desktop component.

Thanks Andrew, that cured the problem (though I also had to switch the GPSConverter object, in a separate module, between the two DLLs).

Am I right in thinking that it is not possible to have a "project" separate from the main *.sbp module? In any case the imported objects are spread around the modules in this application, so this would not help with "single source" for desktop and device.

I suppose if starting from scratch it would be possible to have an "import" module which differed between desktop and device versions and all the other modules be shared by both versions.

Mike.

 

[agraham]

Am I right in thinking that it is not possible to have a "project" separate from the main *.sbp module?

Not that I can think of. Objects belong to the module they are defined in but the libraries are global and are referenced by the contents of the main sbp file so I can see no way of using "similar but different" libraries in one project.

 

[mjcoon]

Objects belong to the module they are defined in but the libraries are global and are referenced by the contents of the main sbp file so I can see no way of using "similar but different" libraries in one project.

I've got as close as I think is possible!

Since the "Main" module is always called that it can have two file names (for desktop and device). This contains the minimal code so that synchronised updates are not called for; in this case just the GPSDriver.Open.

In the version of GPS4PPC-V2 that I have attached the rest of the content of the old Main module has been moved to a new GPS4PPC.bas module.

The two new Main modules are then given the correct objects from either GPSSerial or GPSDriver and these objects are actually used in other modules with the "Main." prefix.

Of course I have had to make minor changes to allow desktop use which was precluded in the original.

And the attachment only contains the altered files, not the images and data file.

Mike.

 

[mjcoon]

I assume that you are using GPSSerial with an external GPS. The speed is provided by the GPS not by the library. You can see what the GPS thinks the speed is by looking at GPSSerial.GPRMC, speed is item 7.

$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh
1 = UTC of position fix
2 = Data status (V= fix inValid, A = fix Active)
3 = Latitude - ddmm.mm
4 = N or S
5 = Longitude - ddmm.mm
6 = E or W
7 = Speed over ground in knots
8 = Track made good in degrees True
9 = UT date
10 = Magnetic variation degrees (Easterly var. subtracts from true course)
11 = E or W
12 = Checksum

Although you say, Andrew, that "(Easterly var. subtracts from true course)", it should still be delivered by the interface according to the convention that a W variation is negative. It is then up to the user how to use it.

Whereas my ancient GPS delivers:

<-$GPRMC,085451,A,5131.055,N,00044.574,W,000.0,259.0,290810,004.2,W*71

so I should be getting -4.2 from the MagneticVariation method but I get +4.2. See http://www.b4x.com/forum/official-updates/3268-new-gpsdriver-library-11.html#post36787. But maybe this is Microsoft's fault.

Similarly with the supplied heading. It should be delivered as a True value (since it does not claim to be magnetic) but what I see is that when I change my GPS to show magnetic heading the NMEA-derived heading changes too.

Mike.

 

[agraham]

Although you say, Andrew, that "(Easterly var. subtracts from true course)"

It's not me saying it. It an extract from some documentation that I found on the Web. Looking at some other documentation I don't think that the magnetic variation value in the RMC sentence is ever signed. The example of your "old GPS" doesn't give a sign. I think the sign needs to be inferred from the E or W value at position 11 in the sentence.

EDIT: If you saw the original version of this ignore it as I was stupidly relying on memory and not looking at the code. GPSDriver, just passes on the value of magnetic variation it receives but the sign should be being adjusted by the Windows Intermediate Driver as it does not pass on the E/W value and is documented by Microsoft as "Magnetic variation, which is the difference between the bearing to true north and the bearing shown on a magnetic compass. Positive numbers indicate east.". If GPSDriver is not returning a negative value it looks like a WIA bug. Maybe they've got it the wrong way round.

GPSSerial does check the E/W value and returns a negative variation value if the position 11 contains "E" so it looks like either I made a mistake and got it the wrong way round or I did it deliberately to match GPSDriver. I'm afraid that I can't remember!

GPSSerial does nothing to the heading value and just passes it on as extracted from the RMC sentence. Presumably changing your GPS to magnetic changes the value being inserted in the RMC sentence.

 

[mjcoon]

It's not me saying it. It an extract from some documentation that I found on the Web. Looking at some other documentation I don't think that the magnetic variation value in the RMC sentence is ever signed. The example of your "old GPS" doesn't give a sign. I think the sign needs to be inferred from the E or W value at position 11 in the sentence.

GPSSerial, and GPSDriver, just pass on the values they receive but in the case of GPSDriver perhaps the sign is being adjusted by the Windows Intermediate Driver as it does not seem to pass on the E/W value. GPSSerial does nothing to it because I just mirror what GPSDriver does and pass the received value on unchanged.

Thanks Andrew. Since I posted I found that I can set my GPS to "User variation" and thus to an "E" value instead of "W". And confirm that the NMEA sentence changes accordingly. And GPSDriver delivers a negative value.

So all I have to do is negate the value delivered, to set it to the convention used by the rest of the non-Microsoft world! (E.g. http://www.ngdc.noaa.gov/geomag/WMM/soft.shtml.)

Mike.

 

[agraham]

Please reread post #37. I got it wrong originally and have corrected it.

 

[mjcoon]

I think the sign needs to be inferred from the E or W value at position 11 in the sentence.

... and is documented by Microsoft as "Magnetic variation, which is the difference between the bearing to true north and the bearing shown on a magnetic compass. Positive numbers indicate east.". If GPSDriver is not returning a negative value it looks like a WIA bug. Maybe they've got it the wrong way round.

GPSSerial does check the E/W value and returns a negative variation value if the position 11 contains "E" so it looks like either I made a mistake and got it the wrong way round or I did it deliberately to match GPSDriver. I'm afraid that I can't remember!

GPSSerial does nothing to the heading value and just passes it on as extracted from the RMC sentence. Presumably changing your GPS to magnetic changes the value being inserted in the RMC sentence.

Thanks for looking at all that again. I think that you are right about the sign of the variation: it would be extra confusing to have a sign and an E/W letter! But it also seems very sloppy on Microsoft's part, even if it had been a beta version of s/w, to get a sign wrong vis-a-vis a convention actually stated in s/w specification. However I think that does, as you imply, constrain you to replicate Micrsoft's mistake to make the GPS interfaces in Basic4PPC self-consistent.

You are right about my GPS emitting true bearings. Since I am "simulating" travel I have to remember that I am setting a magnetic value if I have the correction switched on!

There's another anomaly I've discovered in the NMEA which may be recognised somewhere in their documentation. If my true heading is zero degrees, the NMEA, and hence GPS interfaces in Basic4PPC, show 360. This is not a valid heading value, and my GPS prevents me from actually simulating it. So that is another correction that needs to be applied before display to the discerning user!

Mike.