Lost data using interrupt transfers

[this_guy]

I found similar threads, but they did not totally answer my question, so I hope I'm not re-hashing.

Thanks for the Generic HID software, it has been alot of help.

I'm sending event driven reports from the device at a variable rate, from 1Hz to about 167Hz (6msecs) max. The reports are 64 data bytes plus the report ID. In the data bytes, I have a msg counter. On the host side, I get about 95% of the reports, but drop a few here and there. Plus the GUI 'freezes' for short periods of time (I display some 'real time' data on the GUI that is contained in the report). I'm guessing that Windows is tending to someone elses needs and so a few of the reports get missed.  So here are my questions, when using the interrupt transfers, does the InputReportBufferSize come into play? I have it at the default of '32'. Can I increase that to increase the number of reports buffered?

When calling:

fileStreamDeviceData.BeginRead(inputReportBuffer, 0, inputReportBuffer.Length, new AsyncCallback(GetInputReportData), inputReportBuffer);
                     
Should I increase the size of the  number of bytes ( inputReportBuffer.Length)? That does not seem correct, but I dont know. I'm not the C# host side guy, I'm the embedded side guy.

Thanks for any help you can provide.

[Jan Axelson]

Yes, you can increase InputReportBufferSize to hold more reports.

If the issue is getting the reports out of the buffer fast enough, you can read multiple reports at once. I know it works with ReadFile, and it likely does with Filestreams. Increase inputReportBuffer.Length and if multiple reports are available and fit in the buffer, Read will return multiple reports.

[this_guy]

Thanks for the reply.

Does it pack in as much data as will fit, or does it only add a report to that buffer if there is room? If I double the inputReportBuffer do I get two reports per interrupt call back? If I make inputReportBuffer 2.5 times larger do I still just get 2 reports, or does it give me 2.5 reports and I re-assembly the partioned chunks myself? I'm not wanting to do that, just trying to get an idea of this 'interrupt' setup on the host side works. Is there anyway to figure out who is at fault, the InputReportBufferSize being to small and older packets getting dumped, or not being able to read them off the buffer fast enough? I assume its a combination of the two, but I dont see how to check when my InputReportBuffer is full of input reports.

[Jan Axelson]

The call will return as many complete reports as are available and will fit in the buffer. If the buffer can hold 2 reports and only one is available, the call will return 1 report.

The two buffers are related. No way to check in advance how many reports are available. Try increasing InputReportBufferSize. If that doesn't work, try increasing the Read buffer.

As I said, I haven't tried the larger Read buffer with filestreams so you'll need to experiment.

Jan

[this_guy]

Thanks for the replies.

I tried simply increasing the number of reports that get buffered (InputReportBufferSize), but that alone did not resolve the problem. Just took a little longer for the problem to start. I'll play around with increasing the read buffer on the filestreams. It'll take some reading and testing. I need to learn more about the "interrupts" on the host side and how they work.

I also have to figure out what to do on the embedded side. I do not have space to buffer very many reports if I am waiting on the host. My current depth is 2 reports on the device side.

Thanks again.

[Jan Axelson]

Another option is to increase the report size and send fewer, longer reports.