Dropped USB Input Reports

[grober]

Jan,

Your book, USB Complete, has been incredibly useful.  Thank-you.

I have noticed the following anomaly.  Perhaps you have some suggestion.  I am using HID, sending from 18F4550 to PC, 8 byte interrupt input reports every 2.5 ms.  Works pretty well.  The windows OS gets around to servicing the buffer with typically 5-10 reports in the buffer, which is fine. 

Each report contains a byte which is an ID number, so i can make sure all reports have arrived.  Every now and again reports get dropped.  Typically 1-3 consecutive reports.  So, as an example of the problem, say the buffer has accumulated 9 reports, perhaps the first three would be fine, then there will be a couple of missing reports, and then the next 6 are fine.  So, it behaves as if the PC USB receiver stops paying attention for short periods of time.

Now for the strange thing, I can make the problem worse/better, by turing the wireless network card on and off (this is actually how i first noticed the problem).  With the wireless adaptor on, the dropped reports come in bursts which are spaced by 10-12 seconds and last for of order 1 second.   

Clearly, the wireless network card is not related to the USB, but perhaps there is some sort of interrupt structure for which the wireless has priority over the USB hardware?  Is that possible?  Any thoughts?

p.s.  I noticed a small logic error in IsWindows98Gold(), located in hid.cs

the code :                    if (MyEnvironment.Version >= Version98SE)

should be:                    if (MyEnvironment.Version <= Version98SE)
   

[Jan Axelson]

Thanks for posting to the forum.

If the dropped reports are between ReadFile calls (for example, one call returns reports #1-5 and the next call returns reports 9-14), HidD_SetNumInputBuffers can increase the buffer size and might help.

If the dropped reports are within a call to ReadFile, for example a single call returns reports #1, 2, 6, 7, 8, it sounds like a Windows driver/priority problem.

If you absolutely have to have every report, control transfers are an option.

Thanks for the error report.

Jan

[etasigm]

I was just wondering if this worked for you grober, or whether you had to do something else.  I am having the same issue as you are/were.  I am using Jan's vb.net version of the code.

[Guido Koerber]

One possible reason is that you might have a race condition in your USB code that mixes up the toggle bit for the reports. If a report with an out of sequence toggle bit arrives many operating systems just drop it.

We had this kind of error with Cypress M8 chips and it was just a matter of sorting out which interrupt can happen at which time and to make certain operations atomic.