GPSSerial library

[agraham]

With the shiny new GPSDriver library for WM5.0 devices, and later, with internal GPS we now have two incompatible ways of writing GPS apps. The "old" GPS library and Serial2 for serial ports, such as Bluetooth, and the new GPSDriver for GPS Intermediate Driver equipped devices.

I thought that it might be nice to be able to develop GPS apps on my laptops or desktop which use Bluetooth or USB GPS devices then port them to my Diamond which uses the Intermediate Driver. Also GPSDriver returns more information than GPS does and I wanted to be able access that on other platforms than an Intermediate Driver equipped device.

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.

This is quite a complex piece of code (have peek at the source!) and I have observed that the NMEA sentences from different devices don't all carry the same information in the same way. I have tested it on my Axim X30 (WM2003, Bluetooth) my desktop (Vista, RS232 to USB) and my EEE PC (XP, Bluetooth and RS232 to USB). However some code bugs may remain and there may be incompatibility problems with some devices. However if it will work with GPS and Serial2 it ought to work with this library.

EDIT :- Version 1.1 posted with corrected GPSSerialConverter object.

EDIT :- Version 1.2 posted. See post #16 for details.

EDIT :- Version 1.3 rapidly posted as I didn't get 1.2 quite right . See post #19 for details.

 

[wolfgang]

External compiler error

Hi agraham,
when I try to compile your code for the device the attached error is displayed (desktop works). Nothing is changed in your code. Downloaded twice, installed in a new folder but no succes. All files are avaiable in the correct folders.

 

[agraham]

I am afraid that I cannot reproduce that error. I have just downloaded the zip to make sure I have the same code as you. I have put it into an empty folder unzipped it and it optimised compiles fine for both desktop and device and also both with and without the source file in the Libraries folder

The reference to the MicrosoftCE namespace is puzzling as there is no explicit reference in the library to that (or it wouldn't work on both desktop and device). I have checked the compiler response file that Basic4ppc produces for device compilation and only the dlls that Basic4ppc refers to by default for all optimised device compilation are required. Do you get the error WITHOUT the source code in the Libraries folder and can you optimise compile other device applications?

The only thing that I can think of is that you don't have the Compact Framework SDK installed but if this is the case you couldn't have optimised compiled and I would expect a "Cannot locate .Net Compact Framework 2.0 files." error message.

 

[agraham]

I found it! You have the ImageLibExDevice.cs source file in your library. Delete it and all should be fine. ImageLibEx Device needs a reference to Microsoft.WindowsCE.Forms to optimise compile and as Basic4ppc doesn't know this by default it needs an entry in the compiler LibrariesExceptions.txt file

You could also edit your LibrariesException.txt file to overcome this problem but Erel probably doesn't everyone playing with that file. I'll check with him, in the meantime just delete the ImageLibExDevice source and use the pre-compiled library.

 

[wolfgang]

I found it! You have the ImageLibExDevice.cs source file in your library. Delete it and all should be fine. ...

That's it. Thank you so much.

 

[Erel]

You could also edit your LibrariesException.txt file to overcome this problem but Erel probably doesn't everyone playing with that file. I'll check with him, in the meantime just delete the ImageLibExDevice source and use the pre-compiled library.

This file is intended for cases like that.
However you can just add this line anywhere in your code:

SIP(false)

It will have the same effect.

 

[agraham]

However you can just add this line anywhere in your code:

SIP(false)

It will have the same effect.

:sign0161: I'd forgotten that trick - makes mental note!

 

[agraham]

Version 1.1 now posted with the corrected GPSSerialConverter. The original code was inherited (copied!) from the original GPSDriver code which turned out to be buggy and which Erel has now fixed.

 

[schimanski]

Differnt Lat/Lon in GPSDriver and GPSSerial????

Sorry, perhaps I have made a mistake?

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.

Is the format of the latitude/longitude in the GPSDriver-Lib different to the latitude/longitude of the GPSSerial-Lib?

In my large gps-application, I only have changed the object and the open-method for the desktop, but with the two different formats, it doesn't work. Did I missed something?

 

[agraham]

it doesn't work.

It should be the same. Can you give me some details of what the problem is?

 

[schimanski]

Hello agraham!

One example for the same position:

With GPS as GPSDriver-Object:

GPS.Latitude=51.029435
GPS.Longitude=5.99185

With GPS as GPSSerial-Object:

GPS.Latitude=510.173,850
GPS.Longitude=55.951,450

 

[agraham]

It looks like your readings are a factor of 10 out but I don't see that problem here. I am sure another user would have meantioned this if it were a general problem. Are you using two different GPS receivers for the GPSDriver and GPSSerial apps?

I have a test program that I wrote for GPSDriver and then, like you, transferred to GPSSerial. I've just run the two side by side.

My HTC Diamond with internal GPS receiver using GPSDriver and my Axim X30 with an external Bluetooth Fuzion GPS receiver running GPSSerial both give almost the same latitude and longitude readings.

The latitude and longitude are taken from the $GPRMC sentence. If you can look at the contents of that sentence that might give a clue as to what is happening.

 

[agraham]

With GPS as GPSSerial-Object:

GPS.Latitude=510.173,850
GPS.Longitude=55.951,450

Should those commas be there? Is this a culture thing? Are those erroneous readings actually 510173.85 and 55951.45?

 

[schimanski]

Should those commas be there? Is this a culture thing? Are those
erroneous readings actually 510173.85 and 55951.45?

I have checked it and the commas are there.

You are right, that I use two different GPS receivers. For the GPSSerial I use a DiMP3 bluetooth receiver (SirfIII) and my device has an internal SirfIII.

I have read the NMEA-sentences with your testapplication GPSSerial on the device and the desktop:

Both RMC-Sentences are the same:
GPSSerial: Latitude=5101.7372, Longitude=00559.5017
GPSDriver: Latitude=5101.7505, Longitude=00559.5182
(with the typical receiver difference)


But I have noticed, that GPSSerial shows on the device and the desktop this format:

GPS.Latitude=510.173,850
GPS.Longitude=55.951,450

But I need the following, because it is the format of the GPSDriver-Lib (displayed with the GPSDriver-testapplication):

GPS.Latitude=51.029435
GPS.Longitude=5.99185

What can I do without modifying the code for desktop and device?

 

[agraham]

What can I do without modifying the code for desktop and device?

Wait for me to post tomorrow a slightly modified GPSSerial that can cope with OS culture settings where the decimal separator is a comma. It is an oversight on my part (I think). I assume that your culture settings on your device and desktop are German and this is causing the decimal point to be ignored when converting the NMEA data as it is being interpreted as a group separator and not a decimal point - hence the value comes out about 10000 times too large. I need to override your culture settings.

I haven't had to deal with culture dependent formatting before. Can you tell me when you use Basic4ppc and enter decimal data do you have to use the decimal point and not a comma for decimal data? Also what happens with the following three lines of code

test1 = 10
test2 = test1 + 1234.567 ' UK and US number format
test3 = test1 + 1234,567 ' European number format ' does this error?
msgbox(test2 & crlf & test3)

GPS.Latitude=510.173,850

Do you know how that number is being formatted for output. Are you using Format()? I am puzzled why it comes out in European format as I thought that Basic4ppc enforced the use of US standard numeric formatting.

 

[agraham]

Version 1.2 now posted has a small modification to hopefully cope with computers whose culture settings use comma rather than full-stop as a decimal point separator.

Also added to the GPSSerial object are four new properties that return the last copy of each NMEA sentence that was parsed to provide the GPS data. These sentences are complete with checksum. It is probably easier to use these properties than parse the sentences out of the stream of data returned by the NMEAReadXXX methods.

 

[schimanski]

Hello agraham, thanks for your fast help.

test1 = 10
test2 = test1 + 1234.567 ' UK and US number format
test3 = test1 + 1234,567 ' European number format ' does this error?
msgbox(test2 & crlf & test3)

The result is test2=1244.567, for test3, I get a syntax error.

I have test also the new GPSSerial.Lib. Now I get:

GPS.Latitude=51,029435
GPS.Longitude=5,99185

The calculate of the distance etc. are wrong. I think that it is the comma. Instead of the comma there must be a point....

 

[agraham]

I think that it is the comma. Instead of the comma there must be a point....

Sorry, I overlooked a line of code that I should have fixed as well. I now realise where the formatting comes from that puzzled me earlier. I'll fix it tomorrow. It's a bit tricky to fix this stuff that doesn't occur on your own computer

 

[agraham]

Version 1.3 now posted is hopefully now immune to OS culture setting problems.

 

[schimanski]

Yes, agraham! I have tested the new lib in my application and it runs perfect!

much thanks...:sign0060: