data in buffer object from usb device being truncated

[kglueck]

I ran into an issue when I was taking a look at the project. Got it compiled and running, my RMS300A detected just fine, talking to couchdb on another machine just fine. Problem is that I was only getting a reading every once in a while...the rest of the time I was getting a ton of debug error messages saying that it was "Discarding reading with wrong length or wrong checksum". The data included after the error message looked like a fragmented data stream to me. So, looking into it, I determined that I was getting situations where I had the 0xFF 0xFF marker in the middle of the buffer, but what was left when it passed off to the postReadingAndPrepareForNew in src/WMR100NDeviceController.m was the beginning of a new packet of data. This was getting dropped so the next time I came to process it, it was missing the beginning of data.

For example, here are some of the "data" included after the error message. You'll note a distict pattern:
<42301c01 35003000 305401>
<301c0135 00300030 5401>
<1c013500 30003054 01>

What appeared to be happening was the beginning of the packet was being chopped off. So I stepped through the code in WMR100NDeviceController. Inside the inputReport method, I found the culprit. What was happening was this:

• find the 0xFF 0xFF marker in buffer
• make a copy of the data up to that marker in the 'new' object
• pass that object off to be processed
  (here's the key)
• clear contents of buffer by setting the size 0...even if data existed after the 0xFF 0xFF marker

Ideally it would have been nice if the NSMutableObject class gave us a way to drop data off the front and shift it, but alas it does not...we're just allowed to truncate it. My fix went like this:

• find the 0xFF 0xFF marker in buffer
• make a copy of the data up to that marker in the 'new' object
• pass that off to be processed
  (up to this point we're the same, changes happen beginning next)
• if there is data after the 2nd 0xFF, get a pointer to the buffer's data and use memmove to copy starting at the first bit of data after the 2nd 0xFF marker to the beginning (memmove uses a non-destructive copy method).
• truncate the buffer to the length that's left (the buffer can end with 0xFF 0xFF).

Here's my hacked solution (grr the webform mangled my patch data...no way to attach a file apparently...):

change the line in inputReport method inside WMR100NDeviceController.m (line 150 in the 2009-12-05 version):
[buffer setLength:0];
to:
if ((i + 2) < len) { // if data exists after the 0xFF 0xFF marker
char *bufferData=[buffer mutableBytes];
memmove(bufferData,(bufferData + i + 2),(len - i - 2));
}
[buffer setLength:(len - i - 2)];

This seems to have fixed my issue. Comments?

[ejeklint]

Thanks for the patch! I have never seen this myself but it might well be that RMS300A sends data packed a bit differently. I will roll this in when I'm finished with another big project: changing windows on my summer house. :-)