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?