ZNetNodeIdentificationResponse failure
Gideon le Grange
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
Andrew Rapp
Can you set the log level to debug, repeat the error and post the log file? Thanks
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...@googlegroups.com.
To unsubscribe from this group, send email to xbee-api+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xbee-api?hl=en.
Gideon le Grange
Andrew Rapp
Gideon le Grange
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).
Gideon
Gideon le Grange
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
Andrew Rapp
Gideon
Gideon le Grange
On 30 Nov 2011, at 5:23 PM, Andrew Rapp 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.
Gideon
Gideon le Grange
--
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
.
Can you please check try with the API=1 and use API frame builder
(http://ftp1.digi.com/support/utilities/digi_apiframes.htm ) to build
the packet and make sure the frame is correct.
Hope this helps. Let us know the results.
--
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
Gideon le Grange
pretty sure Digi are wrong.
Gideon le Grange
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."
Gideon