Discussion in 'Questions (Windows Mobile)' started by Chester Wilson, Dec 17, 2008.

  1. Chester Wilson

    Chester Wilson Member Licensed User

    I'm trying the new GPS library, at Erel's kind suggestion.
    However, it tells me it cannot load GPSapi.dll,
    and I can't find GPSapi.dll anywhere.
    (Using W CE 6 on HP iPaq 212)
    Where does it live please?
    Chester ("Erik") Wilson.
  2. agraham

    agraham Expert Licensed User

  3. Chester Wilson

    Chester Wilson Member Licensed User

    More on GPS / Serial 2 problem

    Thanks, Andrew. There are a couple of problems. One I'll put in a second post.
    (1) the .dll required seems to exist on the PDA, but not on the PC, which adds to the interest of debugging!

    (2) I am using serial2, having not known about your serialEx. There were no troubles under 6.3 of basic4ppc, but thr programme crashes under 6.5. I have added debugging bits to the code, and it appears that something is getting written over that shouldn't. Going back to 6.3 lets it work ok. As always, it could always be something in my programme writing where it shouldn't, but here is the code including the debugging bits in case you have any ideas:

    (It appears that something to do with the pointer for the array GPS has gone awry . . .)

    Sub GPSGetChar
    'Returns the next character from the GPS, or chr(0) if none available


    ok = False
    Do While ok = False

    If GPSBufferPointer >= GPSBufferLength Then
    i = GPSGetBuffer
    If i <= 0 Then Return Chr(0)
    End If

    If GPSBufferLength > 0 Then
    j = ArrayLen(GPS()) & " " & GPSBufferPointer
    If GPSBufferPointer = 0 Then
    j = j & "*" 'DEBUG Gets to here
    i = GPS(0)
    j = j & "^" 'DEBUG not to here
    i = gps(gpsbufferpointer)
    End If
    j = j & "!" 'DEBUG nor to here.
    i = Chr(i)
    j = j & "!"
    i = Chr(GPS(GPSBufferPointer)) '(original line)
    GPSBufferPointer = GPSBufferPointer + 1
    i = Chr(0)
    End If

    If i <> Chr(0) Then ok = True ' Ignore nulls


    Return i

    Msgbox("Error in GPSGetChar (" & j & ")")

    Serial2.PortOpen = False
    End Sub

    Sub GPSGetBuffer
    'Gets a new bufferful from the GPS
    ' Returns the character count in the buffer (0 if none available)
    GPSBufferPointer = 0
    GPSBufferLength = 0


    i = Serial2.InBufferCount
    If i > 0 Then
    GPS() = Serial2.InputArray
    i = gps(0) 'DEBUG This does not cause a crash.
    GPSBufferLength = ArrayLen(GPS()) 'Not always the same as i !
    GPSBufferLength = 0
    End If

    Return GPSBufferLength

    If Charting = False Then
    Msgbox("You have become disconnected from the GPS")
    Serial2.PortOpen = False
    End If

    Return 0
    End Sub
  4. Chester Wilson

    Chester Wilson Member Licensed User

    New GPSDriver problem

    I am trying the new GPSDriver, at Erel's kind suggestion.
    Using the demo programme provided with it, it says it can connect to the GPS (which works fine with OziExplorer) but provides no data at all past the first 4 lines. The COM5 port which it specifies is correct for the GPS. Everything past there returns invalid data.

    Any ideas please?

    Chester ("Erik") Wilson.
  5. agraham

    agraham Expert Licensed User

    That's odd, I thought I posted a lot longer reply than that but only the first paragraph seems to have got through :confused:

    That's interesting to know. My assumption was that GPSapi.dll only shipped with devices that had internal GPS, but then I've only seen WM6.0 devices that do have GPS. It looks like the Intermediate Driver may ship with all WM5.0 and later devices. Have you got a configuration program for it? It is a device only dll, there is no desktop equivalent.

    Your description is a bit short of exact details. Does this happen on the device for both the optimised compiled app and when run under the IDE? What error message is shown if you remove the ErrorLabel statement?
  6. Chester Wilson

    Chester Wilson Member Licensed User

    (1) The Serial2 programme works fine under the IDE on the PC.
    (2) Compiling with the non-optimised compiler produces a version which works, with 2 caveats: (a) as slow as a 1-legged dog, and (b) the size of the screen is doubled so only 1/4 of each form fits on the screen!
    (3) The error message without the ErrorLabel is "Invalid Cast Exception"

    Interesting, eh?
    Chester ("Erik") Wilson.
  7. agraham

    agraham Expert Licensed User

    I actually meant the device IDE!

    That's OK. It means it probably will work OK in the device IDE

    You must have defined the GPS array in Globals, did you do so as a byte array? "Dim GPS(0) As Byte?". If not try that as a next step.
  8. Chester Wilson

    Chester Wilson Member Licensed User

    Re (2) - yes, it works in the device IDE, on which it is very slow (about 1 gps line every few seconds!)
    GPS is defined GPS() as char. Any difference between that and byte?
  9. agraham

    agraham Expert Licensed User

    Yes, a .NET Char is a 16bit Unicode character, a Byte is an 8bit value. GPS() should be defined as a Byte array because that is what Serial2.InputArray returns.

    Look at post #2 here I suspect this is your problem with the optimising compiler. The IDE and legacy compilers, being interpreted, can cope with arrays changing type at runtime, the optimising compiler can't, it tries but often fails causing strange problems like this - if indeed that is what the problem is. In Sub GPSGetBuffer you can access GPS(0) as the compiler knows that it is now a byte array because the assignment is in that Sub. However the GPS(0) access in Sub GPSGetChar fails because when it compiled it the compiler thought it was a Char array, however at runtime it is actually a Byte array.

    Incidentally this is a very slow way of processing the GPS input, do you need to process each character individually? GPSDriver or GPSSerial will give you ready parsed access to almost all the GPS data in the NMEA sentences.
  10. Chester Wilson

    Chester Wilson Member Licensed User

    Thanks, Andrew: changed "char" to "byte" and everything now works, and at full speed too. From a debugging point of view I am happy to keep reading the serial line as chunks of characters (I suspect the internal GPS stuff has to do this anyway before handing it over to GPS libraries), as things function without change on the desktop too. It means that I can cope with knowing when there is a break in traffic (such as walking out of the BlueTooth range), and I can use the same code with other BlueTooth devices. The only thing that would be handy would be a Serial2.GetLines(Lines()) with dim Lines() as string, to save breaking up large chunks of characters.

    What are the .dlls written in? I am a Delphi programmer these days, but they had a blue with MS and don't seem to have sorted out their programming for PDAs unfortunately.

    Many thanks again: I had forgotten the Unicode quirk of .NET. (I would MUCH sooner find a bug in my programme than in the compiler!!!!!!)

  11. agraham

    agraham Expert Licensed User

    Yes but many times faster and so more efficient as it is closer to native code than Basic4ppc.

    GPSSerial works on both desktop and device but probably not through a virtual COM port provided by the Windows GPS Intermediate Driver due to an incompatibility between that and the .NET SerialPort class (this was why GPSDriver was developed). The reason for writing GPSSerial was to be able to take an app from my device using GPSDriver and run it on my desktop (actually my EEE PC for portability) virtually unchanged.

    GPSSerial has a DataAge property that tells you the age of the parsed data and also an age parameter to GPSSerial.GetGpsData that will not return any valid data older than age.

    Hmmm!. I originally put raw NMEA data access into GPSSerial for debugging purposes and for the same reason implemented my GPSDriverNMEA library when I was degugging the original code that became the official GPSDriver library. Looking again now I realise I may have missed an opportunity to provide a "middle ground" option between totally raw data and completely parsed data that returned complete NMEA sentences. I might take another look at that.

    I use C# and Visual Studio 2005. You can also use VB.NET and SharpDevelop is a free .NET development environment that some here use - but I never have. If you wanted to play I would try C# and SharpDevelop. As all the .NET languages run on the same framework the learning curve is that of the facilities offered by the framework (effectively the runtime libraries) rather than that of the syntax of tany of the languages. To me C# is better than VB as it is more elegant and less verbose.
  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