Static Navigation & GPSDriver.dll

[numerus]

Hi,

Two years ago, I have developed GPS application. It is intended for pedestrian use, so it is very important to turn off so-called Static Navigation in the GPS chipset configuration. As you know the Static Nawigation is often included by the manufacturer (especially for the SiRF) and freezes the coordinates at low speed traffic. For pedestrians use in my application I need to turn it off.
My app uses the library Serial2.dll, to turn off Static Navigation is necessary to send to the GPS chipset same configuration data - I use for this Serial.Output2 (Array) .
My app works correctly on the part of the equipment, but some of my potential customers received information that my app does not see any GPS data on their device (ex. Samsung Omnia, Mio Explora K70). Settings for COM port are exactly the same as for VisualGPS or BeeLineGPS that work properly with the GPS.

So I'm going to modify and improve my applications using GPSDriver.dll, which can found automatically communication between device and its internal GPS, I hope. But I see a serious problem - GPSDriver.dll has very useful functions to read GPS data, but I do not see any function to send data to the GPS chipsets - something like Serial.Output2.

My question is - how to send data to the GPS chipset using GPSDriver.dll, or what else could I use to have two-way communication with the chipset and not have problems with certain types of devices, which not accept Serial2.dll?

Best regards

 

[agraham]

I am afraid that there is nothing you can do with an internal GPS which can't be used with Serial2. GPSDriver uses the Windows Intermediate Driver which provides an interface to the GPS data that can be used by more than one program at once. There is no provision in this driver to talk back to the GPS hardware (actually there is at low level using native code but the Microsoft documentation strongly recommends against using it and the facility is not guaranteed to be present on all devices). The reason is stated to be to avoid an application putting the GPS in a non-standard state that other GPS programs using the port at the same time would not understand.

 

[numerus]

Thanks Agraham for reply,

I am not saying that it must be the library GPSDriver.dll, it could be anything else. I'm looking for something other than Serial2.dll, because some devices do not accept this one. As I wrote before, there are more and more devices on which, for example BeeLineGPS works correctly, and my application based on Serial2.dll not see the GPS.

I suppose that BeeLineGPS also uses Windows Inetrmediate Driver and is doing it well. I will describe a sample situation:
In the system settings "Exteral GPS" the Hardware port and the Programs port is set. For BeeLineGPS the same COM (as Programs port) is used. After this BeeLineGPS works properly with the GPS. In particular, any time we can do GPS chipset setup (Tools> GPS> Manufacture Specific> SiRF Setup Parameter) - after the warning message you can set the status of the Static Navigation and other parameters for the GPS chipset. At the same device my application based on Serial2.dll sees no GPS (using hardware port either the programs port). To be precise, it only happens for some devices, for other devices my app is working properly also.

BeeLineGPS to make such a setup has to send to the GPS harwaere some simple configuration data in binary SIRF mode. And I would like to have the same opportunity as the developer of BeeLineGPS. I thought that Basic4ppc allow me to do this. It is a stressful situation for me to tell my client that for the old equipment something was possible and now for the new device it is not possible, if he sees that another application works well in both cases.

Kind regards

 

[agraham]

To be precise, it only happens for some devices

We know! Some devices internal GPS (mainly those made by HTC) do not like the .NET SerialPort class that Serial2 uses. Other .NET applications also suffer from this problem on the device, not just Basic4ppc. That is why the GPSDriver was written (by me on Erels request) that uses the parsed data access of the WIM.

BeelineGPS does not seem to be using that main WIM functionality but is using raw data access to the GPS data - I know this because you do not need a COM port specified for parsed data access to the WIM. As BeelineGPS is not a .NET application it will be using native code access to the raw data port and will not suffer whatever problem afflicts the .NET SerialPort. It may or may not be using this port to access the chipset or may be going in at a lower level - there is no way of telling.

My http://www.b4x.com/forum/additional-libraries/3319-gpsdrivernmea-library.html provides read-only access to the raw data port. The library attached has a single new function.

WriteData(buffer As Byte(), bytestowrite As Int32) returns the number of bytes written.

This is the function Microsoft advices against using. I have not tried this and it may not work. If it does not work then there is nothing further I can suggest.

 

[numerus]

My http://www.b4x.com/forum/additional-libraries/3319-gpsdrivernmea-library.html provides read-only access to the raw data port. The library attached has a single new function.

WriteData(buffer As Byte(), bytestowrite As Int32) returns the number of bytes written.

This is the function Microsoft advices against using. I have not tried this and it may not work. If it does not work then there is nothing further I can suggest.

It could to be a very good solution for me.
But I do not see this new property WriteData in .chm file and the contents of the attached zip file are the same as the old GPSDriverNMEA. Is this property hidden and not mentioned in the .chm file?
I would like to test this property, although it will be a little problem because I do not have such a problematic device, which does not like serial2.dll. I will try to ask one of my client to test.

regards

 

[agraham]

Sorry, a slip of the mouse uploaded the old not the modified library. I've now uploaded the correct one. Note that you should be able to use this library at the same time as GPSDriver so you could try using the new function to alter the parameters (if it works) and still access the data from GPSDriver.

 

[numerus]

Hi,

Thank you for adding new property.
I thought about this matter again, and I will be able to test it in the future if I have my own device of this type. If you are not sure whether it works properly, I am afraid that I can disorganize something in the clients device.

Modification of the GPS chipset parameters generally consists of three steps:
1. send the NMEA command to set the SiRF binary protocol for the GPS chipset ($PSRF100 command),
2. send some configuration data,
3. send a command that set back the NMEA protocol for the GPS chipset.

The risk is after step 1 is done - if something does not work the chipset keeps the binary protocol and will not send NMEA sentences at all. It remembers its new configuration, so would be a problem because chipset sends binary raw data only. It is true that this can be remedied, but it is better to test it on my own device.

Reagards

 

[numerus]

Sorry, a slip of the mouse uploaded the old not the modified library. I've now uploaded the correct one.

Mr Agraham

But now in the revised file GPSDriverNMEA1.01.zip attached to post #4 we have GPSDriver.dll, not modified GPSDriverNMEA.dll. In post #4 you wrote that the new property WriteData was added to GPSDriverNMEA.dll. Now I'm a little confused. Could you check again please, because maybe there had been a mistake.

Thank you

 

[agraham]

:sign0013: again:sign0161: yet another slip of the mouse :sign0137: GPSDriver and GPSDriverNMEA are both in the same Visual Studio project and output to the same folder after compilation. I guess I was in a hurry and just clicked on the wrong dll to archive.:sign0161: The correct library is now posted