Hi,
I am using FX2LP in Bulk mode auto in with asynchronous transfer (16 or xfers rolling queue).
My transfer rate is 4MB/s and the C routine basically just waits for xfers, fetches the buffers, restarts the completed xfers and writes the buffers to a file stream.
The data source doesn't care about any buffers being full or any handshake signals because the data stream just cannot be stopped.
Every once in a while (sometimes after 100 seconds, sometimes only after 20 minutes) there is a data loss, which means that some bytes are just not received.
There is some kind of pattern in the data (00 xx xx xx 01 xx xx xx 02 xx xx xx 03 xx xx xx 00 xx xx xx ....), which allows for me to recognize that bytes must have been lost (the 00 01 02 03 repeating pattern goes out of sync), but I can not determine how many bytes. Of course, there might be more incidents than I recognize because there is a probability of 6.25% that the number of lost bytes is an integer multiple of 16 and therefore the 00 01 02 03 repeating pattern does nit go out of sync, but I think that's not relevant now.
I assume that somehow the transfer between the FX2LP and the driver or the transfer between the driver and the C routine gets stalled and the FIFO buffers in the FX2LP run full. All data arriving at the FX2LP will just get lost until one of the buffers is emptied and the FX2LP can go on receiving data into its buffers.
Setting the priority for the C routine to high in the task manager seems to reduce the rate of incidents a bit but they still occur.
I think that Windows, from time to time, assumes that its own jobs are more important than either my C routine or the USB driver and takes too long for that job so that either the driver completely fills all 16 queued xfers before Windows allows processor time to the C routine or the FX2LP fills all 4 FIFOs before Windows allows processor time to the USB driver.
Is anyone familliar with such issues and could provide some tipps?
Many thanks,
Frank
