SparkFun Forums

[lyttlec]

I have a network setup where I need to do queried sampling.
I send 0x7E..... 0xFF 0xFE 0x00 0x49 0x53 <checksum>
I get back ....0x00 0x00 0x49 0x53 0x01 <checksum>

I have some DIO configured as input, some as output, no analog.
The only information I can find indicates that 0x01 is an error, but i cannot find information as to what consititutes an error.

I have already tried all combinations of Remote command options and all 16-bit addresses. The result is always the same.
I have also tried searching the DIGI documentation.

Does anyone have any suggestions as to how to troubleshoot the error?

Thanks

[Valen]

Your sent and received API packets are incomplete. It makes no sense the way they are displayed in your post. Show the entire string of byte values so we can analyse them.

Note that there is a newer version of XCTU that has an API interpreter function built in. So you do not have to analyse them manually:

Digi's "Next Gen XCTU":
http://www.digi.com/support/productdetail?pid=3352

[lyttlec]

Your sent and received API packets are incomplete. It makes no sense the way they are displayed in your post. Show the entire string of byte values so we can analyse them.

Note that there is a newer version of XCTU that has an API interpreter function built in. So you do not have to analyse them manually:

Digi's "Next Gen XCTU":
http://www.digi.com/support/productdetail?pid=3352

I didn't quote the entire packet, just the start and end with unique data.
The API Console in the "Next Gen XCTU" doesn't display the received frame. It always shows it as receiving 7E000408d92556A3 and as sending 7E000788D9255600080612.
If I repeat using the old xctu on the sending end. It indicates
SENT
7E 000F 17 04 0013A2004040B09EFD FFFE 02 4953 09
| | | |- Packet ID | | | | |-Check sum varies with device serial number
| | | | | | |- "IS"
| | | | | |- Apply Changes. Should this be 00?
| | | | |-Document recommends leaving this FFFE instead of inserting device address
| | | |-Serial Number. Depends on the device connected
| | |-Remote AT
| |-Data Length (always 000F)
|-Start Delimiter

Response received is always
7E 0007 88 04 00 00 49 53 01 D6

Next Gen XCTU API Frame Generator does not have the 00 00 bytes between the Packet ID and the "IS". Otherwise the documentation indicates this is a response to a remote AT IS command and the 01 indicates an error.

[Valen]

...
I didn't quote the entire packet, just the start and end with unique data.
...

Please don't. The devil is in the details. As just a single bit in the packet can cause the checksum to fail to match, and be ignored by the Xbees.

The API Console in the "Next Gen XCTU" doesn't display the received frame. It always shows it as receiving 7E000408d92556A3 and as sending 7E000788D9255600080612.

The API packet interpreter says:

7E000408d92556A3 means:

Code: Select all

AT Command

7E 00 04 08 D9 25 56 A3

    - Start delimiter: 7E
    - Length: 00 04 (4)
    - Frame type: 08 (AT Command)
    - Frame ID: D9 (217)
    - AT Command: 25 56 (%V)
    - Checksum: A3

This AT command does not make sense. What did you intend to do here?

7E000788D9255600080612 means: "Invalid checksum" Are you sure you transcribed/copied it correctly?

If I repeat using the old xctu on the sending end. It indicates
SENT
7E 000F 17 04 0013A2004040B09EFD FFFE 02 4953 09
| | | |- Packet ID | | | | |-Check sum varies with device serial number
| | | | | | |- "IS"
| | | | | |- Apply Changes. Should this be 00?
| | | | |-Document recommends leaving this FFFE instead of inserting device address
| | | |-Serial Number. Depends on the device connected
| | |-Remote AT
| |-Data Length (always 000F)
|-Start Delimiter

7E 000F 17 04 0013A2004040B09EFD FFFE 02 4953 09

API interpreter reports invalid packet length. You have 1 byte too many in there. Also, there is a 0x13 in there. That could be required to be escaped depending on your AP register settings (if AP=2). Check this. I'm not sure if the XCTU nextgen is smart enough work around this. (there is no option to make it aware of this.) If you did, then it wasn't correctly done.

Response received is always
7E 0007 88 04 00 00 49 53 01 D6

That means:

Code: Select all

AT Command Response

7E 00 07 88 04 00 00 40 53 01 DF

    - Start delimiter: 7E
    - Length: 00 07 (7)
    - Frame type: 88 (AT Command Response)
    - Frame ID: 04 (4)
    - AT Command: 00 00 ()
    - Status: 40 (Unknown status)
    - Response: 53 01
    - Checksum: DF

The other Xbee hasn't responded. Makes sense if the address in the previous sent command is not correct.

Double check your XBee SH and SL registers. There is also a sticker on the back with them. Check the correct adresses and please show them here also. It helps identifying what parts are the adresses in the packet. Otherwise this keeps being a guessing game.

[lyttlec]

...
I didn't quote the entire packet, just the start and end with unique data.
...

Please don't. The devil is in the details. As just a single bit in the packet can cause the checksum to fail to match, and be ignored by the Xbees.

The API Console in the "Next Gen XCTU" doesn't display the received frame. It always shows it as receiving 7E000408d92556A3 and as sending 7E000788D9255600080612.

The API packet interpreter says:

7E000408d92556A3 means:

Code: Select all

AT Command

7E 00 04 08 D9 25 56 A3

    - Start delimiter: 7E
    - Length: 00 04 (4)
    - Frame type: 08 (AT Command)
    - Frame ID: D9 (217)
    - AT Command: 25 56 (%V)
    - Checksum: A3

This AT command does not make sense. What did you intend to do here?

7E000788D9255600080612 means: "Invalid checksum" Are you sure you transcribed/copied it correctly?

If I repeat using the old xctu on the sending end. It indicates
SENT
7E 000F 17 04 0013A2004040B09EFD FFFE 02 4953 09
| | | |- Packet ID | | | | |-Check sum varies with device serial number
| | | | | | |- "IS"
| | | | | |- Apply Changes. Should this be 00?
| | | | |-Document recommends leaving this FFFE instead of inserting device address
| | | |-Serial Number. Depends on the device connected
| | |-Remote AT
| |-Data Length (always 000F)
|-Start Delimiter

7E 000F 17 04 0013A2004040B09EFD FFFE 02 4953 09

API interpreter reports invalid packet length. You have 1 byte too many in there. Also, there is a 0x13 in there. That could be required to be escaped depending on your AP register settings (if AP=2). Check this. I'm not sure if the XCTU nextgen is smart enough work around this. (there is no option to make it aware of this.) If you did, then it wasn't correctly done.

Response received is always
7E 0007 88 04 00 00 49 53 01 D6

That means:

Code: Select all

AT Command Response

7E 00 07 88 04 00 00 40 53 01 DF

    - Start delimiter: 7E
    - Length: 00 07 (7)
    - Frame type: 88 (AT Command Response)
    - Frame ID: 04 (4)
    - AT Command: 00 00 ()
    - Status: 40 (Unknown status)
    - Response: 53 01
    - Checksum: DF

The other Xbee hasn't responded. Makes sense if the address in the previous sent command is not correct.

Double check your XBee SH and SL registers. There is also a sticker on the back with them. Check the correct adresses and please show them here also. It helps identifying what parts are the adresses in the packet. Otherwise this keeps being a guessing game.

Thanks for replying. There is an extra "40" typo in the sent address in the post. It isn't in the sent message on the live system. My fat fingers.
The reply received is 7E 0007 88 04 00 00 49 53 01 D6. When I enter the message in the NextGen frame interperter, it insists on changing the 49 to 40. I just double checked and it does that both under XP and Linux.
Traditional XCTU terminal correctly indicates the sent and received messages.
NextGen XCTU always indicates the %V messages.
The xbees are mounted on sparkfun xbee usb explorer modules. NextGen XCTU seems to have problems reading/writing usb serial. I've never been able to write changes using NextGen XCTU. Traditional XCTU has alway had some difficulty, but not like NextGen.

[Valen]

Ok, I didn't notice that 49 changed to 40 in the interpretation of the response packet. That is odd indeed. The XCTU Next Gen could still have bugs in it, as it is fairly new. I had version 6.1.0. Just made it check for updates, and there is now version 6.1.1. However, not from the download page that I earlier provided. That is still 6.1.0. I managed to make it update itself (some how) internally to 6.1.1.

Hmm, 6.1.1 doesn't seem to solve the 49/40 Statusbyte replacement.

Still, two nil bytes ( 00 00) as AT command, and the value 49 (or 40) as Status byte (totally undocumented values) in the response packet from the Xbee is suspect in and of itself. Are you sure the firmware in your Xbees is updated to the latest?

If the above is not sufficient to solve the strange API packets on your side then I suggest you report this by emailing Digi's Techsupport. Or start a topic on their forums. I suggest you eliminate all unnecessary elements from your network to replicate this issue. (less complexity and confusion) Your current arrangement of your 'network' is still rather vague. No mention of which kind of modules, topology and which firmware they have. I only see different 64-bit hardware adresses in the packets. And please give them full disclosure on the settings inside each XBee module.

[waltr]

What Baud rate are you using? XBee's are know to have issues with very high Bauds.

[lyttlec]

Ok, I didn't notice that 49 changed to 40 in the interpretation of the response packet. That is odd indeed. The XCTU Next Gen could still have bugs in it, as it is fairly new. I had version 6.1.0. Just made it check for updates, and there is now version 6.1.1. However, not from the download page that I earlier provided. That is still 6.1.0. I managed to make it update itself (some how) internally to 6.1.1.

Hmm, 6.1.1 doesn't seem to solve the 49/40 Statusbyte replacement.

Still, two nil bytes ( 00 00) as AT command, and the value 49 (or 40) as Status byte (totally undocumented values) in the response packet from the Xbee is suspect in and of itself. Are you sure the firmware in your Xbees is updated to the latest?

If the above is not sufficient to solve the strange API packets on your side then I suggest you report this by emailing Digi's Techsupport. Or start a topic on their forums. I suggest you eliminate all unnecessary elements from your network to replicate this issue. (less complexity and confusion) Your current arrangement of your 'network' is still rather vague. No mention of which kind of modules, topology and which firmware they have. I only see different 64-bit hardware adresses in the packets. And please give them full disclosure on the settings inside each XBee module.

I finally got things working. The bad news for me is I don't know why they started working.
I broke out a second (older) computer and downloaded NextGen onto it. I got version 6.1.1. It seems work better. It can at least read/write to devices on the usb serial port (shown as com8). I'm not sure which version was on the other computer.

The API console only logs exchanges initiated by XCTU, which isn't much help. The constant repition of the %V messages appears to have been a result of the problems between XCTU and the USB serial interface. All the radios definately send the two nil bytes in the response. The easiest way to duplicate the problem is to send a remote AT request with an invalid command.

My routers all have version 2364, end devices have 29A7, and the coordinator has 218C. It will be a pain to update and verify all 100+ devices, especially if that doesn't solve the problem without creating new ones. If the firmware gets updated, the entire V&V process has to be repeated.

All are set for 19200 8-N-1. On the previous system baud rates higher than that were totally unusable.


[rant]
Time was I would submit bug reports. But software vendors seem to have quit testing. They want users to spot the bugs for them and I now spend more time debugging other peoples software than my own. If DIGI wants me to test their software, I charge $100/hr.
[/rant]

[waltr]

All are set for 19200 8-N-1. On the previous system baud rates higher than that were totally unusable.

This would indicate that the clock for the Baud rate generator on the PC you were using is not accurate. I have used XBees to 57kBaud.
You might get the Baud 'tuned' by using non-standard Baud rates and tweaking until it works. Or better measure the Buad rate from the PC with an O'scope by continuously sending 0x55 ('U' character).

[lyttlec]

All are set for 19200 8-N-1. On the previous system baud rates higher than that were totally unusable.

This would indicate that the clock for the Baud rate generator on the PC you were using is not accurate. I have used XBees to 57kBaud.
You might get the Baud 'tuned' by using non-standard Baud rates and tweaking until it works. Or better measure the Buad rate from the PC with an O'scope by continuously sending 0x55 ('U' character).

Thanks,

That was my first suspect, The test is if other applications function at higher baud rates on com8. I use a pattern of 0x55 'U' and 0x66 'f'. One pc fails all test above 9600, the others pass up to 115k.
Right now one pc (the oldest xp) passes with xctu, all others behave erratically at or above 9600. I don't care if the problem belongs to DIGI, MS, or HP. I'm going to build an rs232 interface for the xbees and see if they will work that way. Still, that doesn't explain all the extra bytes in messages and the changing of values( consistant change 0x49 to 0x40 for example).

BTW, traditional xctu works with WINE under Linux, NextGen XCTU does not. Thus we have to develop a lot of applications ourselves to perform the functions XCTU should provide.. Once we've done that there is no reason to buy DIGI. There are other vendors.