GPS Intermediate Driver Issues

Im having some issues with the GPS intermediate driver, I have added a virtual serial port to our Camera/GPS hardware to expose the raw NMEA data and this is now working without a problem, any application requiring raw NMEA data can connect to COM8 and receive it.

If the GPS Intermediate Driver is involved, i.e. "Setting | External GPS" has hardware port set to COM8 and program port to COM7. Then when applications request data from COM7 the data appears to be different. I only say appears as I am unable to check the physically output, see Note开发者_JS百科 A below.

The difference appears to be it is returned noticeably slower than connecting to COM8 directly, but also applications like visualGPS whilst they show locked onto 6 satellites will not show a 3D GPS fix. Only when connected to COM8 will I receive a 3D GPS fix, this to me indicates the Microsoft software is changing the data rather than simply sharing it and thus causing issues for users who want to use the driver to share data across several applications.

Anyone have any ideas on why the Microsoft intermediate driver is causing me such issues, there seems to be very little information about it.

Note A) - There seems to be no diagnostic program for WM6 professional that will read COM ports or at least redirect traffic to a COM port connected to the PC. If anyone can recommend a program for WM6 to connect and view data from COM ports, ideally with timestamps. Or a program to redirect traffic i.e. read from COM7, Open COM6 and send data over COM6. I can push data into the system, just no programs I can locate will push data out.

---

Altering the device data is what the GPS Intermediate Driver is supposed to do. It isolates your app from the implementation details of the GPS device so that your code can work with any GPS device. I can't diagnose the exact problem you are having from your question, I can only recommend the docs.

---

I have worked with the mobile device manufacturer to diagnose this. They had to use our device and a debug version of the OS to isolate it, and even then its not a line of code on either side (driver vs OS) that is the problem. Our read method does not have a timeout, being a software port it doesn't really matter but it is required.

Something like this MUST be added.

if(WaitForSingleObject(driver->GPSDataAvailableThread, driver->GPSTimeouts.ReadTotalTimeoutConstant) != WAIT_OBJECT_0)
{
   //debug message, no data to read
   return 0; //return 0 bytes read
}
//otherwise carry on a normal read operation.

Even with a timeout of 0, it allows the thread to sleep and other processes to continue. The problem was without it, applications were reading the COM port so much it was causing a overhead in the intermediate driver making calls and creating mutex locks. Applications that do many reads of 1 byte like pocketputty cause this issue, but SatNav software like copilot reading 1024 once a second have no issue.