jankolkmeier / xbee-api

Node.js and Chrome communicate with XBee/ZigBee devices in API mode
MIT License
105 stars 51 forks source link

Error: Checksum Mismatch #55

Closed cent89 closed 7 years ago

cent89 commented 7 years ago

Hi, I have 3 XBee series 2 in mesh configuration, AP=1 (A attached to raspberry pi 2B at /dev/ttyAMA0, B and C send data only to A). When I type: sudo node xbmq.js it returns for every frame: error: Error: **Checksum Mismatch** {"buffer":{"type":"Buffer","data":[126,0,20,146,0,19,162,0,64,246,53,248,255,254,193,1,0,12,2,0,8,2,9,117,51,44,52,56,44,52,52,44,53,50,44,53,50,44,52,52,44,53,51,44,53,49,44,52,52,44,53,51,44,52,56,44,52,52,44,53,50,44,53,50,44,52,52,44,53,51,44,53,48,44,52,52,44,53,51,44,53,48,44,52,52,44,53,50,44,53,50,44,52,52,44,53,51,44,53,49,44,52,52,44,53,51,44,52,57,44,52,52,44,53,50,44,53,50,44,52,52,44,53,51,44,53,49,44]},"offset":24,"length":20,"total":1674,"checksum":30,"b":30,"escape_next":false,"waiting":true} at XBeeAPI.parseRaw (/home/pi/node_modules/xbmq/node_modules/**xbee-api/lib/xbee-api.js**:195:19) at XBeeAPI.<anonymous> (/home/pi/node_modules/xbmq/node_modules/xbee-api/lib/xbee-api.js:133:10) at SerialPort._emitData (/home/pi/node_modules/serialport/lib/serialport.js:313:18) at SerialPort.<anonymous> (/home/pi/node_modules/serialport/lib/serialport.js:293:14) at SerialPort.<anonymous> (/home/pi/node_modules/serialport/lib/serialport.js:306:7) at FSReqWrap.wrapper [as oncomplete] (fs.js:603:17)

Why? Can you help me? Thanks, Roberto

jankolkmeier commented 7 years ago

The frame logged that was causing the error seems to be a ZigBee IO Data Sample Rx Indicator (0x92=146). The second and third byte tell us the amount of data before the checksum. This appears to be 20 bytes. However, the actual package has more than 100 bytes before the checksum if you count them. When the parser comes to position 20 (offset 24 from beginning of entire package), it expects to read the checksum. Since it is not really the end of the package, the checksum doesn't check out and the error is produced.

So that is why the error is produced. The real question is where this misformed package is coming from. These packages come straight from the serialport, so one might think it is a misbehaving device(?).

You can try parsing the rest of the package by hand to figure out what is going wrong/other than expected. Use this document, p. 115: http://rabbit-note.com/wp-content/uploads/2014/09/XBee_90000976_S.pdf

I would also recommend cross posting this issue to the xbmq module github. While I'm not sure whether the error lies with them or with xbee-api, I am unfamiliar with how they employ xbee-api, so they might understand better what is going on.

jankolkmeier commented 7 years ago

On an additional note, I find the package suspicious looking for an ZigBee IO Data Sample Rx Indicator, with those wierd almost-permutations all over the end of the package. Also, what a coincidence that the package is exactly 128 byte long in total... starting perfectly fine but clearly not having a decend ending (it looks more like it would run longer if it could).

Does the logged faulty frame look like this exactly every time you run it?

cent89 commented 7 years ago

Hi, No, the frame is not the same every time. For example, if I try now, the data frame is: 126,0,26,145,0,19,162,0,64,246,53,208,255,254,232,232,0,146,193,5,193,1,0,12,2,0,12,1,124,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

In my Xbee device, I have tried to set the API Options to "Explicit RX indicator [1]", but nothing change. However, my device is not ZigBee, but Xbee with Digimesh firmware.

jankolkmeier commented 7 years ago

Hmm, maybe the extra bytes beyond the (in the last example) 29th byte shouldn't matter anyway. It seems that is just the space of memory that got allocated for parsing (see here https://github.com/jankolkmeier/xbee-api/blob/master/lib/xbee-api.js#L145). It is interesting that it sometimes contains something else than just zeros as in your last example (alloc should be save and not reveal previous memory).

Still, can you verify what version of xbee-api is exactly installed, and what version of node you are using? We made some regarding this exact piece of code recently.

Did you give hand parsing these packages a shot? Let me know if you found anything, otherwise, I might have some time later today to give it a shot.

jankolkmeier commented 7 years ago

Okay, there is nothing odd with these packages. The test program below parses them just fine. Once I add an extra byte at the end of either frames, it does properly emit the frame when it parses the first checksum, but then tries to check the checksum again for the next byte coming in (unless it is a start byte). So if the extra byte does not happen to be equal to the checksum (or a start byte, as is the case when two "no-extras" packages are being consumed), we get the error.

var xbee_api = require('xbee-api');
var C = xbee_api.constants;
var xbeeAPI = new xbee_api.XBeeAPI();

var done = 0;

xbeeAPI.on("frame_object", function(frame) {
    console.log(frame);
    done++;
});

var raw_frame_1 = new Buffer([
    126, 0, 20, // "Header"
    146, 0, 19, 162, 0, 64,
    246, 53, 248, 255, 254, 193,
    1, 0, 12, 2, 0, 8,
    2, 9, // 20 bytes
    117 // Checksum
]);

var raw_frame_2 = new Buffer([
    0x7e, 0x00, 0x1a, // "Header"
    0x91, 0x00, 0x13, 0xa2, 0x00, 0x40,
    0xf6, 0x35, 0xD0, 0xff, 0xfe, 0xe8,
    0xe8, 0x00, 0x92, 0xc1, 0x05, 0xc1,
    0x01, 0x00, 0x0c, 0x02, 0x00, 0x0c,
    0x01, 0x7c, // 26 Bytes
    0x00 // Checksum
]);

xbeeAPI.parseRaw(raw_frame_1);
xbeeAPI.parseRaw(raw_frame_2);

(function wait () {
  if (done < 2) setTimeout(wait, 1000);
})();

Output:

{ type: 146,
  remote64: '0013a20040f635f8',
  remote16: 'fffe',
  receiveOptions: 193,
  digitalSamples: { DIO2: 0, DIO3: 1 },
  analogSamples: { AD1: 611 },
  numSamples: 1 }
{ type: 145,
  remote64: '0013a20040f635d0',
  remote16: 'fffe',
  sourceEndpoint: 'e8',
  destinationEndpoint: 'e8',
  clusterId: '0092',
  profileId: 'c105',
  receiveOptions: 193,
  data: <Buffer 01 00 0c 02 00 0c 01 7c> }
jankolkmeier commented 7 years ago

Could you see if this fix helps in your setup?: https://github.com/jankolkmeier/xbee-api/commit/d97945d01dbb04f14f5438c4116343129ada6fdc

cent89 commented 7 years ago

Ok, perfect! I have updated xbee-api to the latest version and added the lines. Now works even xbmq. Thanks a lot!