GPSSerial library

R

reny1978to

Member
Licensed User
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

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

reny1978to

Member
Licensed User
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

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

nl1007

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

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

Expert
Licensed User
Longtime User
nl1007 said:
NMEA was in some way seperate to the GPS Serial COM port
Click to expand...
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!
 
M

mjcoon

Well-Known Member
Licensed User
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.
 

Attachments

  • GPSSerial-runtime.JPG
    17.4 KB · Views: 13

agraham

Expert
Licensed User
Longtime User
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.
 
Last edited:
M

mjcoon

Well-Known Member
Licensed User

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.
 

Attachments

  • compile-error (name-space).JPG
    16.7 KB · Views: 6
M

mjcoon

Well-Known Member
Licensed User
mjcoon said:
... I'm happy to post the code if needed.
Click to expand...

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

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

mjcoon

Well-Known Member
Licensed User

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

Expert
Licensed User
Longtime User
mjcoon said:
Am I right in thinking that it is not possible to have a "project" separate from the main *.sbp module?
Click to expand...
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.
 
M

mjcoon

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

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.
 

Attachments

  • GPS4PPCx2-V2.zip
    12.4 KB · Views: 18
M

mjcoon

Well-Known Member
Licensed User

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:
B4X: 
<-$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

Expert
Licensed User
Longtime User
mjcoon said:
Although you say, Andrew, that "(Easterly var. subtracts from true course)"
Click to expand...
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.
 
Last edited:
M

mjcoon

Well-Known Member
Licensed User

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

mjcoon

Well-Known Member
Licensed User

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