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
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
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.
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
I've been looking at the help, demo and source for this and would like to make this comment:
Help:
Quote:
"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)..
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!
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
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,dd mmyy,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.
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
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.