Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uncaught exception when frame size becomes slightly bigger #26

Closed
Dowster64 opened this issue Jun 11, 2022 · 2 comments
Closed

uncaught exception when frame size becomes slightly bigger #26

Dowster64 opened this issue Jun 11, 2022 · 2 comments

Comments

@Dowster64
Copy link

Dowster64 commented Jun 11, 2022

Hi, running your examples/simple-monitor.js with the changes below works fine for a frame with 2 digital outputs. However when 1 analog output is added (making the frame slightly bigger (by 16 bits? ) I get the uncaught exception as shown.

This occurs because mixed frames (digital and analog) when digital samples are event driven and analog are periodical contains the same channel mask (digital and analog) but there is sometimes no analog data. Each analog reading is 2 bytes and when they aren't there the frame parser still tries to read them - causing the uncought exception.*****************

It shows one frame translated but fails on the next. This error affects the node-red-contrib-xbee module and it potentially originates with xbee-api module. It might be that the frame parser buffer sizes is too small but the error isn't handled.
Thanks for your support.

var xbee = xbeeRx({
serialport: "/dev/ttyUSB0",
serialportOptions: {
baudRate: 115200
},
module: "802.15.4",
// turn on debugging to see what the library is doing
debug: true
});

and commenting out this line (couldn't run otherwise but no console output unless debug is on):
//stdin.setRawMode(true);

Connecting to serialport /dev/ttyUSB0
Monitoring incoming packets (press CTRL-C to stop)
Debug frame (in):
{
type: 131,
remote16: 'af2e',
rssi: 83,
receiveOptions: 0,
data: {
sampleQuantity: 1,
channelMask: 2051,
channels: { ADC2: 1, DIO0: 1, DIO1: 1 },
analogSamples: [ [Object] ],
digitalSamples: [ '11' ]
}
}
node:internal/process/promises:288
triggerUncaughtException(err, true /* fromPromise */);
^

AssertionError [ERR_ASSERTION]: Out of Original Buffer's Boundary
at MAKE_NEXT_READER.BufferReader. [as nextUInt16BE] (/home/dowster64/projects/node-test/node_modules/buffer-reader/index.js:77:9)
at frame_parser.Recieved16BitPacketIO (/home/dowster64/projects/node-test/node_modules/xbee-api/lib/frame-parser.js:281:34)
at frame_parser. (/home/dowster64/projects/node-test/node_modules/xbee-api/lib/frame-parser.js:322:16)
at XBeeAPI.parseFrame (/home/dowster64/projects/node-test/node_modules/xbee-api/lib/xbee-api.js:134:27)
at XBeeAPI.parseRaw (/home/dowster64/projects/node-test/node_modules/xbee-api/lib/xbee-api.js:229:26)
at XBeeAPI.parser._transform (/home/dowster64/projects/node-test/node_modules/xbee-api/lib/xbee-api.js:48:19)
at Transform._write (node:internal/streams/transform:154:8)
at writeOrBuffer (node:internal/streams/writable:390:12)
at _write (node:internal/streams/writable:331:10)
at Writable.write (node:internal/streams/writable:335:10) {
generatedMessage: false,
code: 'ERR_ASSERTION',
actual: false,
expected: true,
operator: '=='
}

Node.js v18.3.0

@101100
Copy link
Owner

101100 commented Jun 13, 2022

@Dowster64 As you have found, this is an issue with xbee-api. As I don't have experience in that area, I don't really want to directly handle packets in this library. If I can modify this library in some way to help you out, please let me know.

@Dowster64
Copy link
Author

@101100 Thanks for the reply to my comment. I've (had to) learn a lot more about debugging with VSCode than I expected over the last few days! I have been communicating with @jankolkmeier and learning at the same time about the way the code functions. There is an open issue on xpee-api here that highlighted a similar issue, so I replied there, only editing my comment above to identify the problem.
Essentially, when creating 0x83 frames where analog inputs are read with a fixed period and digital inputs read on change, the earlier S1 firmware correctly sets the analog channel mask when analog data is present or not. With XBee3 (S3) and 802.15.4 firmware the 0x83 frame the analog channel mask is constant, so it stays the same regardless of whether analog data is present. This causes the frame-parser code to try to read past the end of the reader buffer.
The legacy frame type (0x83) is the default behaviour of the XBee3 802.15.4 firmware (AO=2). Changing AO to 0 produces 0x92 frames with XBee3 firmware and this correctly sets the analog channel mask to reflect the actual contents of the frame and not the configuration of the XBee3.
XCTU 'handles' the XBee3 'bug'. frame-parser.js can be edited to fix the XBee3 behaviour but as @jankolkmeier writes, this is an undocumented behaviour. I'll try and highlight this to Digi international for a firmware fix.
Thansk again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants