jankolkmeier
commented
8 years ago Sorry Mickey, I don't get what your question is.
You don't even describe what the code is inside your 'test.js'. I can only assume that you are logging the response buffer object. It just happens that the way a buffer object is logged by nodejs is that it will just show the first 100 bytes of the object and not the rest. Imagine a image or movie being inside that buffer, it would log millions of lines if it would show the full buffer.
The way this works has nothing to do with xbee-api. If you are looking to inspect the whole buffer, consider writing a function that logs the hex value of each byte in a for loop.
When I attempt to create a frame object and console log the result, the result will add a ... if I include more then 34 bytes of data and a 64bit mac address. I can use XCTU and produce much larger frames.
This frame works. Notice that the "<buffer" result does not have "...>" at the end? This frame matches what XCTU shows when I build the same frame.
node test.js test111111111111111111111111111111 0013A20040EF5A70 { type: 0, destination64: '0013A20040EF5A70', data: 'test111111111111111111111111111111' } <Buffer 7e 00 2d 00 01 00 7d 33 a2 00 40 ef 5a 70 00 74 65 73 74 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 d2>
If I add just one more "1" making it 35 bytes the "<buffer" result now has "...>" at the end and it is missing the checksum and I am sure it will continue to drop anything else. If you remove the <, buffer, > and the spaces the remaining hex is 100 characters long. It never outputs more than 100 hex characters.
node test.js test1111111111111111111111111111111 0013A20040EF5A70 { type: 0, destination64: '0013A20040EF5A70', data: 'test1111111111111111111111111111111' } <Buffer 7e 00 2e 00 01 00 7d 33 a2 00 40 ef 5a 70 00 74 65 73 74 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 ... >