Range Error #12
Comments
|
Looks like it might be a bug. To be sure: Are you sending/receiving "a lot" of messages? Are you properly using the api_mode setting to match your XBee? Could you share a minimal version of your program that reproduces the error? Or preferrably a dump of the incomming data that produce the error? |
|
I had the same issue but it was resolved by making sure that the baud rate on the xbee and the initialization for the serial library matched (9600 in my case). |
|
Hi, Sorry for long time. Here is the code I use in my raspberry pi. var xbee_api = require('xbee-api'); xbeeAPI = new xbee_api.XBeeAPI({ serialPortBee = new SerialPort("/dev/ttyAMA0", { serialPortBee.on("open", function () { xbeeAPI.on("frame_object", function(frame) I'm printing on line 123 of file xbee_api.js ... } The log file (forever) is at http://pastebin.com/wCrnJ0Wr |
|
Hi @jankolkmeier , I have the similar problem as the below: the condition to reproduce this problem is my code: var util = require('util')
var SerialPort = require("serialport").SerialPort
var xbee_api = require('xbee-api');
var C = xbee_api.constants;
var xbeeAPI = new xbee_api.XBeeAPI({
api_mode: 1
});
var serialPort = new SerialPort("/dev/ttyUSB0", {
baudrate: 57600,
parser: xbeeAPI.rawParser()
});
// All frames parsed by the XBee will be emitted here
xbeeAPI.on("frame_object", function(frame) {
console.log(">>", util.inspect(frame));
});XBee Sending Setting -- This is the remote Xbee sending ADC sample IO data via 16bit address XBee Receiving Setting -- This is the XBee talking to the xbee-api Application. above setup tested under X-CTU and the XBee can receive packets successfully from the remote XBee with IO sample data. When I run the node-serialport test program to see the buffer: var com = require("serialport");
var serialPort = new com.SerialPort("/dev/ttyUSB0", {
baudrate: 57600,
parser: com.parsers.raw
});
serialPort.on('open',function() {
console.log('Port open');
});
serialPort.on('data', function(data) {
console.log(data);
});I got the below output which shows a lot of zeroes ahead of the useful buffer data. Now I assume those leading zeros causes buffer length range errors and I don't know why so many leading zeros generated. Another strange thing is that if I enable "Encryption" on both XBee and set a 32-bit Hex String as the key and run the same app, it shows new errors: The serial port test program shows output: The difference is that this time the leading zeros will not go away and they occur every time when you run the app or the test program. Anyone tried it with Encryption on with XBee Series 1 and get successful data output? |
|
I never used encryption, so I cannot report on that, but in principle, it shouldn't matter. It might be that the issue is related to a bug/curiosity in serialport. I do not think that writing any zero bytes just like that is part of the xbee specs. Far fetched, but maybe it is an issue with the serial 2 usb converter you are using? Are you using an official shield with FTDI? Maybe a third party shield? @duffmeister @infomk did you happen to use something unusual? Regardless, a fix would be something inside the parseRaw function that prevents writing to the working buffer unless we are inside a package, after we received a start byte. Could you check out if 889e588 |
|
@jankolkmeier , Thank you and the Range error goes away by using the above fix I have put the function MAKE_NEXT_READER(valueName, size) {
valueName = cap(valueName);
BufferReader.prototype['next' + valueName] = function() {
// added debug code
console.log(this.buf);
console.log("Offset: " + this.offset + " Size: " + size + " Buf Length: " + this.buf.length);
console.log("");
assert(this.offset + size <= this.buf.length, "Out of Original Buffer's Boundary");
var val = this.buf['read' + valueName](this.offset);
this.offset += size;
return val;
};
}Here are the outputs: Clearly when My Then I disabled the Encryption and here are the results: The last row is I hope this can help further debug the problem cause I have no clue why the code cannot parse this 18 byte buffer |
|
I briefly read into encryption. I am a bit confused. The xbee specs say that a frame send with encryption would carry a 0x20 byte in the transmit options, however none of the buffers you reported contain a 0x20 byte. You are using series 1, right? Could you send me the complete frame that causes the issue, from start delimiter (0x7e) to checksum? And maybe a complete frame that does work? |
|
@jankolkmeier , here are my complete frame that causes the issue: If I run my customized parser code I will get Assertion error: The parser code is simply as: var util = require('util')
var SerialPort = require("serialport").SerialPort
var xbee_api = require('xbee-api');
var C = xbee_api.constants;
var xbeeAPI = new xbee_api.XBeeAPI({
api_mode: 1
});
var serialPort = new SerialPort("/dev/ttyUSB1", {
baudrate: 57600,
parser: xbeeAPI.rawParser()
});
// All frames parsed by the XBee will be emitted here
xbeeAPI.on("frame_object", function(frame) {
console.log(">>", util.inspect(frame));
});When I disabled the Encryption (EE=0), here are the complete frame that does the work. I am using Series 1, AP mode = 2 (escaping enabled). The serial port read code is as the below (Am I getting the full frame by using the below code?): var SerialPort = require("serialport").SerialPort;
var serialport = new SerialPort("/dev/ttyUSB1", {
baudrate: 57600
});
serialport.on('open', function(){
console.log('Serial Port Opend');
serialport.on('data', function(data){
console.log(data);
});
}); |
|
My mistake, the 0x20 is only in the series 2 transmit status fields! |
|
The error is caused because the frames with encryption have a value of 0xff in the 9th byte. This indicates that there are 255 samples (instead of 0x01=one as in the frames without encryption). The spec does mention that encrypted packets always use their 64 address as the src address for RF packets - but trying that gives an even less meaningful interpretation of the packet... At this point, I'm clueless, sorry :( |
|
So the problem is that the RF Data part I got under Encryption mode is different from the Non-Encryption mode. It has 4 more bytes. By right, the RF data content should remain the same content with OR without encryption. But the below results said NO and it puzzled us. Well, I will ask this on Digi forum and hopefully someone will answer it. Thanks. @jankolkmeier . |
|
Keep me posted! :) |
|
This may help in the interim: Line 146: |
|
did you ever figure this out, @xianlin ? |
|
@jankolkmeier, this may be related and I know the cause of the problem. I have XBee3 running 802.15.4 firmware. API mode 1 and no encryption. If I configure 2 digital inputs with a mask and 1 analogue channel with a sample rate of 10 sec, I get two different frame lengths (12 and 10) depending on whether the analog sample is present or not (last 2 bytes), However the channel masks are the same regardless, so the frame parser tries to read the last two bytes (the ADC channel) but this is past the buffer length: 7E 00 0C 83 AF 2E 4A 00 01 08 03 00 03 00 00 46 Hope this helps someone. The fix should be easy but I am not sure how to apply it |
|
Hi @Dowster64 , thanks for chiming in here, and especially for providing sample packages. I've taken a look, and checked back in the documentation. See pages 113 & 114 here. The 9th byte (offset=8) indicates Given that information from channel mask & number of samples sets byte, the parser must expect to get both the 16 bit digital samples (bytes 12 & 13) and one 16 bit analog sample (bytes 14 & 15). So there is no way of knowing for the shorter packages whether byte 14 is part of the expected analog sample or an early checksum. Unfortunately, the best I can make of this is that your device is not behaving according to specification. What's more, the documentation says that these packages (0x83 16-bit Address IO Samples) are legacy, and instead 0x92 should be used. Perhaps that's a solution? |
|
Hi @jankolkmeier, thanks for the reply. I've made a change to frame-parser.js at the the end of this comment that makes the code work. Regarding whether it should or shouldn't be a valid frame might be moot, because these are the frames that an Xbee makes. These are TH XBee3 with 802.15.4 200D firmware. The frames above were copied from XCTU as they came in. The Legacy setting in the firmware (AO) is the defualt for 802.15.4 and it seemed to be for 0x80/0x81. Although I can check the other frame type but it does look like I would need to use the full 64bit addresses. I find the MY address very useful. BTW the checksum and the first 3 bytes are removed by the software prior to the parser and the length of the whole frame is known from the 2nd two bytes? Thanks for yoiur very quick reply :-) for( var si=0; si < data.sampleQuantity; si++ ){ |
|
@jankolkmeier . Using the 0x92 frame (by changing the AO setting to 0 - API Rx Indicator only necessary on the transmitter) and leaving 16 bit addressing as is, packets are generated like this. Here we see that the analog sample mask is correctly set: If 16 bit addressing is used and AO is set to 0, then 0x92 frames are generated which set the Analog channel mask consistent with the sample data. Thanks for your help. |
|
I see your point about "it happens on my real hardware so it should be fixed". But in general, it seems best to implement stuff according to the datasheet rather than according to undocumented behavior... And everything seems to point to that "legacy behavior" being undocumented... Your suggested workaround (i.e. using the package size/checking if there is more data) is fine, but in a way just passes the same issue (inconsistency between channel mask & actual included samples) down to the user (depending in their implementation, now they have to add another check for whether an expected entry in the samples is actually there or not). A proper "fix" or workaround would be to also correct the channel mask & other properties derived from it, which also feels weird. So I'm hesitant to just include that as a half-fix. Anyway, glad you got it working now and thanks for sharing the details. This might help others down the line. |
|
Hi @jankolkmeier . Some very revealing information! (well at least I'm happy and as you say I hope this helps others that find this). I do have a one TH S1 XBee running XBEE 802.15.4 function set version 10ef. With the same configuration as before, I would be confident in saying that this firmware behaves as documented, and that the the behaviour of the XBee3 with 802.15.4 is not as documented (exepected). |
Hi,
I'm using xbee-api on my project, but I have a problem when the nodes (I'm using xbee-api for Arduino) send a information to controller (using node js). Sometimes (after a long time) I have a error:
Caught exception: RangeError: Trying to write outside buffer length - Line: undefined
RangeError: Trying to write outside buffer length
at RangeError ()
at checkInt (buffer.js:788:11)
at Buffer.writeUInt8 (buffer.js:794:5)
at XBeeAPI.parseRaw (/user/node_modules/xbee-api/lib/xbee-api.js:148:14)
at Object.parser (/user/node_modules/xbee-api/lib/xbee-api.js:119:10)
at Object.SerialPort.options.dataCallback (/user/node_modules/serialport/serialport.js:143:15)
at SerialPortFactory.SerialPort._emitData (/user/node_modules/serialport/serialport.js:312:20)
at afterRead (/user/node_modules/serialport/serialport.js:290:18)
at /user/node_modules/serialport/serialport.js:304:9
at Object.wrapper as oncomplete
I'm printing: console.log(S.b); console.log(S.offset); on file xbee-api.js, line 147, and after a long time values > 255 are received (495, 498, 499, 502, 495, 505, ...). Then I need to restart the application.
Thank's
The text was updated successfully, but these errors were encountered: