1. *** New version of B4J is available ***
    B4J v7.8
    Dismiss Notice

GPSSerial library

Discussion in 'Additional Libraries' started by agraham, Nov 12, 2008.

  1. agraham

    agraham Expert Licensed User

    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.
     

    Attached Files:

    Last edited: Jan 16, 2009
  2. wolfgang

    wolfgang Member Licensed User

    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.
     

    Attached Files:

  3. agraham

    agraham Expert Licensed User

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

    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.
     
    Last edited: Nov 13, 2008
  4. agraham

    agraham Expert Licensed User

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

    wolfgang Member Licensed User

    That's it. Thank you so much.
     
  6. Erel

    Erel Administrator Staff Member Licensed User

    This file is intended for cases like that.
    However you can just add this line anywhere in your code:
    Code:
    SIP(false)
    It will have the same effect.
     
  7. agraham

    agraham Expert Licensed User

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

    agraham Expert Licensed User

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

    schimanski Well-Known Member Licensed User

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

    Sorry, perhaps I have made a mistake?

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

    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?
     
  10. agraham

    agraham Expert Licensed User

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

    schimanski Well-Known Member Licensed User

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

    agraham Expert Licensed User

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

    agraham Expert Licensed User

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

    schimanski Well-Known Member Licensed User

    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?
     
    Last edited: Jan 15, 2009
  15. agraham

    agraham Expert Licensed User

    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)

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

    agraham Expert Licensed User

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

    schimanski Well-Known Member Licensed User

    Hello agraham, thanks for your fast help.

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

    agraham Expert Licensed User

    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 :(
     
  19. agraham

    agraham Expert Licensed User

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

    schimanski Well-Known Member Licensed User

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

    much thanks...:):sign0060::)
     
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice