Can't set NW

,

Whenever I send either an AT query api packet, or AT command api packet for NW with 0x0001, I always get back 0x00CF. WTF? How is that parameter getting ‘locked’? I can set the PAN ID appropriately, so it’s not like I’m not getting api AT command packets across the wire sucessfully…

Which module and firmware version are you working with? What is the CE and SM commands set to on this module?

XBeeCallbacks: Firmware version: 0x23A7
XBeeCallbacks: Hardware Version: 0x1E46
XBeeCallbacks: CE: 0xEC00
XBeeCallbacks: Sleep Mode: 0x00D6

(I’m just assuming CE and SM are 2 bytes, they are probably 1 byte, the manual is ambiguous unless you look at the defaults & range on a lot of these)

XBeeCallbacks: Firmware version: 0x23A7
XBeeCallbacks: Hardware Version: 0x1E46
XBeeCallbacks: CE: 0xEC00
XBeeCallbacks: Sleep Mode: 0x00D6

(I’m just assuming CE and SM are 2 bytes, they are probably 1 byte, the manual is ambiguous unless you look at the defaults & range on a lot of these)

This is Router API code so there is No CE command. Now it does have an SM command but D6 is not valid. The supported range of the SM command is 0 - 5.

What is the API frame you are sending and getting back?

I guess that’s why I couldn’t find any docs for CE.

If the SM command is 1 byte then it ~is~ zero since its bigendian. The second byte after that is the D6.

What do you mean by API frame? I’m sending an AT query with VR then HV then CE then SM.

To set NW I send an AT command with either 1 byte of 0x01 or two bytes of 0x0001, which both return 0x00CF…It’s broken.

The code you are working with is API code and not an AT version. So I know that you are not just issuing AT commands. You have to issue API frames.

With that said, if I issue 7E 00 05 08 01 4E 57 04 4D to a module with the same firmware version as you, I get the following response back “7E 00 05 08 01 4E 57 04 4D”. If I then issue a read of that NW with 7E 00 04 08 01 4E 57 51 I then get the following back :7E 00 04 08 01 4E 57 51

So as you can see, it is NOT a bug in the firmware but in your Code.

XBee::SendPacket(struct) : { 0x7E, (‘~’), 0x00, (‘\0x00’), 0x05, (‘\0x05’), 0x08, (‘\0x08’), 0x01, (‘\0x01’), 0x4E, (‘N’), 0x57, (‘W’), 0x01, (‘\0x01’), 0x50, (‘P’), }

XBee: Found likely packet start, STX at Pos: 0, Len: 5
&7E(~)n&00(\0x00)i&05(\0x05)t&88(\0x88)o&01(\0x01)r&4E(N)z&57(W)i&00(\0x00)g&D1(\0xd1)

Uhhh…

Now is a good time to use XCTU 6x and its API frames Interpreter…

00 (Status OK)

Well then, looks like it’s really getting set to 1, if I query again after that. I’m not exactly sure how you can set it with one byte in the command when the range is shown as 0-64FF…

However, it still doesn’t fix the 0x21 I get on TX perpetually when I unplug the coordinator then plug it back in. The router never heals itself even with NW=1 until I reboot the router pcb…

(I thought it was x22 errors, but those are right after booting the R. Rebooting the C results in x21 errors on all R’s, forever)…

XBeeCallbacks: Error sending packet: delivery status: 0x22 (0x22 = no network available, 0x24 = bad destination addr [set with ZigDestAddr cmd]), retries: 0, discovery status: 0x22
XBeeApi::ApiTxStatus: FrameType (0x8B): 0x8B; FrameID (215): 0xD7; Addr16: 0x0000; RetryCount: 0; DeliveryStatus (0=sucess): 0x22; DiscoveryStatus: 0x00 .
XBeeCallbacks: Error sending packet: delivery status: 0x22 (0x22 = no network available, 0x24 = bad destination addr [set with ZigDestAddr cmd]), retries: 0, discovery status: 0x22
XBeeApi::ApiTxStatus: FrameType (0x8B): 0x8B; FrameID (216): 0xD8; Addr16: 0x0000; RetryCount: 0; DeliveryStatus (0=sucess): 0x22; DiscoveryStatus: 0x00 .

XBeeCallbacks: Now in network! Will start sending beacons…
XBeeCallbacks: Error sending packet: delivery status: 0x21 (0x22 = no network available, 0x24 = bad destination addr [set with ZigDestAddr cmd]), retries: 0, discovery status: 0x21
XBeeApi::ApiTxStatus: FrameType (0x8B): 0x8B; FrameID (217): 0xD9; Addr16: 0x0000; RetryCount: 0; DeliveryStatus (0=sucess): 0x21; DiscoveryStatus: 0x02 .
XBeeCallbacks: Error sending packet: delivery status: 0x21 (0x22 = no network available, 0x24 = bad destination addr [set with ZigDestAddr cmd]), retries: 0, discovery status: 0x21
XBeeApi::ApiTxStatus: FrameType (0x8B): 0x8B; FrameID (218): 0xDA; Addr16: 0x0000; RetryCount: 0; DeliveryStatus (0=sucess): 0x21; DiscoveryStatus: 0x00 .
XBeeCallbacks: Error sending packet: delivery status: 0x21 (0x22 = no network available, 0x24 = bad destination addr [set with ZigDestAddr cmd]), retries: 0, discovery status: 0x21
XBeeApi::ApiTxStatus: FrameType (0x8B): 0x8B; FrameID (219): 0xDB; Addr16: 0x0000; RetryCount: 0; DeliveryStatus (0=sucess): 0x21; DiscoveryStatus: 0x02 .

Are you using Source Routing? That is, are you issuing the AR command at all?

Our coordinator has AR set to 6.

XBeeApi::ApiTxStatus: FrameType (0x8B): 0x8B; FrameID (61): 0x3D; Addr16: 0xFFFD; RetryCount: 0; DeliveryStatus (0=sucess): 0x24; DiscoveryStatus: 0x01 .

It’s stuck in address discovery forever, I get screens full of these messages, even after a successful JV / AI message.

Not sure what you mean. The API Status frame indicates that it was received.