GPS Intermediate Driver Slowing down the data from a virtual serial port driver

Question

Follow on from - GPS Intermediate Driver Issues

The above was not successfully answered and feel I have new information over the issue to go for a new question.

The issue I am facing is the speed of which data is being delivered by the GPS Intermediate Driver.

I have successfully used Pocket Putty to read the serial ports and see the exact information been exposed.

COM 1 - GPS Intermediate Driver

COM 6 - Serial port to PC (Input data manually)

COM 8 - Virtual serial port for GPS hardware.

When reading COM 8, I can see about 18 NMEA strings appear every ~3 seconds, this is as fast as we can push it over the limited USB connection. And it appears quickly on the display. When reading COM 6 (send data from PC manually), it is displayed equally as quick. So there is no problem with the data been available.

Enter in the GPS Intermediate Driver. When The GPS Intermediate Driver is set to COM1 (Software) and COM6 (Hardware). The data entered on COM6 is displayed on COM1 just as quickly as it was without the GPS Intermediate Driver. The data is unaltered, so if I send "JON" on COM6, it will appear on COM1, even though its not valid NMEA data, which is fine.

The problem is with COM8. When the GPS Intermediate Driver is set to COM1 (Software) and COM8 (Hardware). The data showing in PocketPutty on COM1 is really slow. The output on the screen is about 5 characters per second, the data is valid but it just been delivered very slowly. This to me points out an issue in the implementation of the virtual serial port, as if the GPS Intermediate Driver is not reading all the data just one character at a time, given I have isolated the issue to my virtual serial port.

Can anyone provide a clear example of a virtual serial port implementation, as im not sure what I could change to improve this, given COM8 directly works with GPS software and the PocketPutty application, which indicates the data is available, being read, and is correct.

Answer 1

After getting support from the device manufacturer running a debug build, the cause of the problem was client applications were making to many read calls. The serial port could handle them on its own, but via the GPS Intermediate driver the number of calls were too high and the overhead was crippling the communication, this was down to Mutex locks and general threading issues.

Client applications need to read 960 bytes of data per read to the GPS Intermediate driver for them to work ok. This is not an ideal solution so another fix was found.

The resolution was to add in a WaitForSingleObject(IsThereEnoughGPSDATAEvent, COMTotalTimeout) in the read method, so that all reads would only get data if there was a sufficient amount of data available. Originally I requested 960 to be available in the buffer but i've set it down to just 10 bytes and it still works.

Sample Code

DWORD COM_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count )
{
    if(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE] != NULL)
    {
        if(WaitForSingleObject(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE], GPSTimeouts.ReadTotalTimeoutConstant) != WAIT_OBJECT_0)
        {
            return 0;
        }
    }

    //read code goes in here

    return dataOut;
}