GPSapi.dll

[Chester Wilson]

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.

 

[agraham]

As the iPAQ 212 does not have a built-in GPS then GPSapi.dll, which implements the Windows GPS Intermediate Driver is not present on your device so you cannot use GPSDriver.dll. I don't know how your GPS is interfaced to your iPAQ but you probably want to use my http://www.b4x.com/forum/additional-libraries/3327-gpsserial-library.html#post18685 instead.

 

[Chester Wilson]

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

ErrorLabel(ErrorGetChar)

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)
Else
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
Else
i = Chr(0)
End If

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

Loop

Return i

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

Serial2.PortOpen = False
AppClose
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

ErrorLabel(GetBufErr)

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 !
Else
GPSBufferLength = 0
End If

Return GPSBufferLength


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

Return 0
End Sub

 

[Chester Wilson]

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.

 

[agraham]

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

(1) the .dll required seems to exist on the PDA, but not on the PC, which adds to the interest of debugging!

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?

 

[Chester Wilson]

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

 

[agraham]

(1) The Serial2 programme works fine under the IDE on the PC.

I actually meant the device IDE!

(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!

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

(3) The error message without the ErrorLabel is "Invalid Cast Exception"

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.

 

[Chester Wilson]

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?

 

[agraham]

GPS is defined GPS() as char. Any difference between that and byte?

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 http://www.b4x.com/forum/questions-help-needed/3439-gps-converter.html#post19534 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.

 

[Chester Wilson]

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!!!!!!)

Erik.

 

[agraham]

(I suspect the internal GPS stuff has to do this anyway before handing it over to GPS libraries)

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

as things function without change on the desktop too

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.

It means that I can cope with knowing when there is a break in traffic

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.

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.

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.

What are the .dlls written in?

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.