I'm developing a Java application using xbee-api. I've implemented com.rapplogic.xbee.api.PacketListener to receive all responses and process them asynchronously. There is however a problem with packet type 0x95. The response received is of type ErrorResponse, and the exception incapsulated in it is:
com.rapplogic.xbee.api.XBeeParseException: There are remaining bytes according to stated packet length but we have read all the bytes we thought were required for this packet (if that makes sense) at com.rapplogic.xbee.api.PacketParser.parsePacket(PacketParser.java:178) at com.rapplogic.xbee.api.InputStreamThread.run(InputStreamThread.java:151) at java.lang.Thread.run(Thread.java:680)). The response I receive is of type ErrorResponse, and when I print the stack trace from getException(), I see the following:
This seems to happen when a new node joins the PAN (is switch on for example) and is causing a head ache since I was hoping to use ZNetNodeIdentificationResponse to detect new nodes and gather information about them.
Some more information: - I'm using xbee-api 0.9 compiled from svn. - I'm using S2 XBee modules
> I'm developing a Java application using xbee-api. I've implemented > com.rapplogic.xbee.api.PacketListener to receive all responses and process > them asynchronously. There is however a problem with packet type 0x95. The > response received is of type ErrorResponse, and the exception incapsulated > in it is:
> com.rapplogic.xbee.api.XBeeParseException: There are remaining bytes > according to stated packet length but we have read all the bytes we thought > were required for this packet (if that makes sense) > at > com.rapplogic.xbee.api.PacketParser.parsePacket(PacketParser.java:178) > at > com.rapplogic.xbee.api.InputStreamThread.run(InputStreamThread.java:151) > at java.lang.Thread.run(Thread.java:680)). The response I receive > is of type ErrorResponse, and when I print the stack trace from > getException(), I see the following:
> This seems to happen when a new node joins the PAN (is switch on for > example) and is causing a head ache since I was hoping to use > ZNetNodeIdentificationResponse to detect new nodes and gather information > about them.
> Some more information: > - I'm using xbee-api 0.9 compiled from svn. > - I'm using S2 XBee modules
> Many thanks for your assistance.
> Gideon
> -- > You received this message because you are subscribed to the Google Groups > "xbee-api" group. > To post to this group, send email to xbee-api@googlegroups.com. > To unsubscribe from this group, send email to > xbee-api+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/xbee-api?hl=en.
The log up to is 2011-11-28 17:42:39,776 is generated by starting my application (which does some things including a ND). The log from 2011-11-28 17:43:10,923 is generated when I power up another node, which causes the problem.
> Can you set the log level to debug, repeat the error and post the log file? Thanks
> On Sun, Nov 27, 2011 at 11:43 AM, Gideon le Grange <donkam...@gmail.com> wrote: > Hi
> I'm developing a Java application using xbee-api. I've implemented com.rapplogic.xbee.api.PacketListener to receive all responses and process them asynchronously. There is however a problem with packet type 0x95. The response received is of type ErrorResponse, and the exception incapsulated in it is:
> com.rapplogic.xbee.api.XBeeParseException: There are remaining bytes according to stated packet length but we have read all the bytes we thought were required for this packet (if that makes sense) > at com.rapplogic.xbee.api.PacketParser.parsePacket(PacketParser.java:178) > at com.rapplogic.xbee.api.InputStreamThread.run(InputStreamThread.java:151) > at java.lang.Thread.run(Thread.java:680)). The response I receive is of type ErrorResponse, and when I print the stack trace from getException(), I see the following:
> This seems to happen when a new node joins the PAN (is switch on for example) and is causing a head ache since I was hoping to use ZNetNodeIdentificationResponse to detect new nodes and gather information about them.
> Some more information: > - I'm using xbee-api 0.9 compiled from svn. > - I'm using S2 XBee modules
> Many thanks for your assistance.
> Gideon
> -- > You received this message because you are subscribed to the Google Groups "xbee-api" group. > To post to this group, send email to xbee-api@googlegroups.com. > To unsubscribe from this group, send email to xbee-api+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/xbee-api?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "xbee-api" group. > To post to this group, send email to xbee-api@googlegroups.com. > To unsubscribe from this group, send email to xbee-api+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/xbee-api?hl=en.
It looks to me like the packet is being parsed correctly. I looked at the digi doc and I seem to be parsing everything in the packet. I had the second 16 bit and 64 bit addresses swapped but that would not have caused this problem. The last bytes (mfg id) read are correct: 0x10 0x1e. Based on the length in the packet, it's saying there are 4 more bytes left, but I can't make sense of them since they are not documented. You can see that there are indeed 4 more bytes, as they are consumed and ignored.
[2011-11-28 17:43:10,987] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] Read base10=3,base16=0x03,base2=00000011 from input stream [2011-11-28 17:43:10,988] [InputStreamThread] [WARN] [com.rapplogic.xbee.api.InputStreamThread] expected start byte but got this 0x03, discarding [2011-11-28 17:43:10,988] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] About to read from input stream [2011-11-28 17:43:10,988] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] Read base10=0,base16=0x00,base2=00000000 from input stream [2011-11-28 17:43:10,988] [InputStreamThread] [WARN] [com.rapplogic.xbee.api.InputStreamThread] expected start byte but got this 0x00, discarding [2011-11-28 17:43:10,988] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] About to read from input stream [2011-11-28 17:43:10,988] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] Read base10=0,base16=0x00,base2=00000000 from input stream [2011-11-28 17:43:10,988] [InputStreamThread] [WARN] [com.rapplogic.xbee.api.InputStreamThread] expected start byte but got this 0x00, discarding [2011-11-28 17:43:10,988] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] About to read from input stream [2011-11-28 17:43:10,988] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] Read base10=65,base16=0x41,base2=01000001 from input stream [2011-11-28 17:43:10,988] [InputStreamThread] [WARN] [com.rapplogic.xbee.api.InputStreamThread] expected start byte but got this 0x41, discarding [2011-11-28 17:43:10,988] [InputStreamThread] [DEBUG] [com.rapplogic.xbee.api.InputStreamThread] No data available.. waiting for new data event
On Mon, Nov 28, 2011 at 8:46 AM, Gideon le Grange <donkam...@gmail.com>wrote:
> The log up to is 2011-11-28 17:42:39,776 is generated by starting my > application (which does some things including a ND). The log > from 2011-11-28 17:43:10,923 is generated when I power up another node, > which causes the problem.
> Gideon
> -- > You received this message because you are subscribed to the Google Groups > "xbee-api" group. > To post to this group, send email to xbee-api@googlegroups.com. > To unsubscribe from this group, send email to > xbee-api+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/xbee-api?hl=en.
> On 28 Nov 2011, at 5:03 PM, Andrew Rapp wrote:
> Hi,
> Can you set the log level to debug, repeat the error and post the log > file? Thanks
> On Sun, Nov 27, 2011 at 11:43 AM, Gideon le Grange <donkam...@gmail.com>wrote:
>> Hi
>> I'm developing a Java application using xbee-api. I've implemented >> com.rapplogic.xbee.api.PacketListener to receive all responses and process >> them asynchronously. There is however a problem with packet type 0x95. The >> response received is of type ErrorResponse, and the exception incapsulated >> in it is:
>> com.rapplogic.xbee.api.XBeeParseException: There are remaining bytes >> according to stated packet length but we have read all the bytes we thought >> were required for this packet (if that makes sense) >> at >> com.rapplogic.xbee.api.PacketParser.parsePacket(PacketParser.java:178) >> at >> com.rapplogic.xbee.api.InputStreamThread.run(InputStreamThread.java:151) >> at java.lang.Thread.run(Thread.java:680)). The response I receive >> is of type ErrorResponse, and when I print the stack trace from >> getException(), I see the following:
>> This seems to happen when a new node joins the PAN (is switch on for >> example) and is causing a head ache since I was hoping to use >> ZNetNodeIdentificationResponse to detect new nodes and gather information >> about them.
>> Some more information: >> - I'm using xbee-api 0.9 compiled from svn. >> - I'm using S2 XBee modules
>> Many thanks for your assistance.
>> Gideon
>> -- >> You received this message because you are subscribed to the Google Groups >> "xbee-api" group. >> To post to this group, send email to xbee-api@googlegroups.com. >> To unsubscribe from this group, send email to >> xbee-api+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/xbee-api?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "xbee-api" group. > To post to this group, send email to xbee-api@googlegroups.com. > To unsubscribe from this group, send email to > xbee-api+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/xbee-api?hl=en.
> It looks to me like the packet is being parsed correctly. I looked at the digi doc and I seem to be parsing everything in the packet. I had the second 16 bit and 64 bit addresses swapped but that would not have caused this problem. The last bytes (mfg id) read are correct: 0x10 0x1e. Based on the length in the packet, it's saying there are 4 more bytes left, but I can't make sense of them since they are not documented. You can see that there are indeed 4 more bytes, as they are consumed and ignored.
Thank you for your help.
I'll check the firmware version on that module tonight and maybe see if the behaviour goes away on a different version (in which case I'll ask Digi).
>> It looks to me like the packet is being parsed correctly. I looked at the digi doc and I seem to be parsing everything in the packet. I had the second 16 bit and 64 bit addresses swapped but that would not have caused this problem. The last bytes (mfg id) read are correct: 0x10 0x1e. Based on the length in the packet, it's saying there are 4 more bytes left, but I can't make sense of them since they are not documented. You can see that there are indeed 4 more bytes, as they are consumed and ignored.
> Thank you for your help.
> I'll check the firmware version on that module tonight and maybe see if the behaviour goes away on a different version (in which case I'll ask Digi).
I was running firmware 2170 on the Coordinator and 2270 on the remote node. I upgraded to 21A0 and 22A0, and the same problem occurs. Downgraded to 2164 and 2264, same problem.
I checked your code against the latest version of the documentation (H) and what they specify is what you implemented. I will contact Digi and ask them to clarify.
I recommend a short term solution of not throwing the exception since it appears to be parsing the packet correctly -- just ignore the extra 4 bytes. I can help with this if you're not sure how to do this. As I mentioned I had the 16 and 64 bit addresses swapped so will fix that as well.
On Tue, Nov 29, 2011 at 12:27 PM, Gideon le Grange <donkam...@gmail.com>wrote:
> > On 29 Nov 2011, at 7:53 AM, Andrew Rapp wrote:
> >> It looks to me like the packet is being parsed correctly. I looked at > the digi doc and I seem to be parsing everything in the packet. I had the > second 16 bit and 64 bit addresses swapped but that would not have caused > this problem. The last bytes (mfg id) read are correct: 0x10 0x1e. Based > on the length in the packet, it's saying there are 4 more bytes left, but I > can't make sense of them since they are not documented. You can see that > there are indeed 4 more bytes, as they are consumed and ignored.
> > Thank you for your help.
> > I'll check the firmware version on that module tonight and maybe see if > the behaviour goes away on a different version (in which case I'll ask > Digi).
> I was running firmware 2170 on the Coordinator and 2270 on the remote > node. I upgraded to 21A0 and 22A0, and the same problem occurs. Downgraded > to 2164 and 2264, same problem.
> I checked your code against the latest version of the documentation (H) > and what they specify is what you implemented. I will contact Digi and ask > them to clarify.
> Gideon
> -- > You received this message because you are subscribed to the Google Groups > "xbee-api" group. > To post to this group, send email to xbee-api@googlegroups.com. > To unsubscribe from this group, send email to > xbee-api+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/xbee-api?hl=en.
> I recommend a short term solution of not throwing the exception since it appears to be parsing the packet correctly -- just ignore the extra 4 bytes. I can help with this if you're not sure how to do this. As I mentioned I had the 16 and 64 bit addresses swapped so will fix that as well.
Thank you. I've implemented a workaround in my application that will do for now. I've logged the issue with Digi and sent them additional information they requested. I'll post their response or solution.
I've received a response from Digi: -- Dear Gideon,
You have enabled API=2, means API Operation with escaped characters and it works likes this, When sending or receiving a UART data frame, specific data values must be escaped (flagged) so they do not interfere with the data frame sequencing. To escape an interfering data byte, insert 0x7D and follow it with the byte to be escaped XOR'd with 0x20.
Data bytes that need to be escaped: 0x7E - Frame Delimiter 0x7D - Escape 0x11 - XON 0x13 - XOFF For more information regarding this, please refer the page number 99 of the product manual at the link, http://ftp1.digi.com/support/documentation/90000976_H.pdf .
According to this page http://code.google.com/p/xbee-api/wiki/XBeeConfiguration I need to have escaping on though, and I assume xbee-api is handling the escaping from me. When I look at the sample packets I received (which I sent Digi as well), there are indeed escaped bytes in the ZNetNodeIdentificationResponse frames. Here is where it gets interesting:
The first escaped byte is the 2nd byte of the 64-bit source address. Since Digi radios are all use 0013A200 for the MSB 32 bits of their address, escaping 0x13 should be very common. The next escaping happens on the 2nd byte of the 64-bit network address.
Gideon
On Nov 30, 9:09 pm, Gideon le Grange <donkam...@gmail.com> wrote:
> > I recommend a short term solution of not throwing the exception since it appears to be parsing the packet correctly -- just ignore the extra 4 bytes. I can help with this if you're not sure how to do this. As I mentioned I had the 16 and 64 bit addresses swapped so will fix that as well.
> Thank you. I've implemented a workaround in my application that will do for now. I've logged the issue with Digi and sent them additional information they requested. I'll post their response or solution.
On Dec 2, 3:13 pm, Gideon le Grange <donkam...@gmail.com> wrote:
> Disregard what I just sent. I'm looking at the packet output and I'm > pretty sure Digi are wrong.
Digi have come back to me and said:
>The extra bytes I.E.., 00 03 00 00 which you are getting specifies DD parameter of the module. You can refer the product manual for the description of the DD parameter.
>The checksum in the frame(output) that you have sent(attachment) is showing wrong, calculate the checksum manually and send the frame again and let us know the results. >I'll raise a failure against the document, in the next version those bytes will be documented.
So, it's undocumented. The manual says: "DD Device Type Identifier. Stores a device type value. This value can be used to differentiate different XBee-based devices. Digi reserves the range 0 - 0xFFFFFF."
