Manipulating DO

I have have gone through every piece of documentation I can find and cannot find anything that explains how to accomplish the following. If anybody can point me in the right direction, I would be forever grateful.

I have two formerly series 1 Xbees (non pro). I want to turn the DO pins on and off on the remote module with UART commands going to the base module. This is what I tried to make D3 high

7e 00 10 17 01 00 13 a2 00 40 4A E8 7C FF FE 01 33 65 05 A9

No dice. I have the two modules communicating in transparent mode and line passing (I have enabled API since then). I am using firmware 10C8 which is meant for the XBEE pro but works for everything else. Thanks in advance.

I’ll have a go at the DO question…

Your packet ends in the bytes 01 33 65 05 A9.

01 is the options byte, which I think should be 02 to apply the change immediately or 00 to queue the change until the next AC command. I use 02 in my own code, with success.

33 65 should be the ASCII codes for “D3”, but they’re actually the codes for “3A”.

So try 02 68 33 05 at the end of the packet.

I’ll let someone else answer the DO question. I just wanted to clarify that the 10C8 firmware is for both XBee and XBee-PRO.

That is good to know. Digi should update the website. When you select the non pro version in the firmware update page it takes you to 10A5 firmware. The Pro selection takes you to the firmware file that contains 10C8.

Yeah, I discovered the same thing so I spoke with the product manager this morning. The reason things appear that way for the OEM module is because this is the version which ships on them when they’re purchased seperately. If you look on the XBee 802.15.4 adapters page you’ll see the 10C8, which is what ships on them. Confusing I know, but that’s how they want it until the newer version ships on the XBee 802.15.4 OEM modules too.

I have replaced the string with
7E 00 10 17 01 00 13 A2 00 40 4A E8 7C FF FE 02 68 33 05 A5 with no success. I know the modules are communicating because I get a return string from the remote module. I am unsure of what else could be the problem. Thanks for the help so far.

In all fairness, “I get a return string from the remote module” isn’t a helpful way of asking what’s wrong. The return string may contain the necessary clue. Could you post the byte values in the command you sent and the byte values in the string that came back?

Sorry, I had no idea that was of any value. All of this is pure magic to me. But anyway, here is the response from the remote module.

7E 00 0F 97 01 00 13 A2 00 40 4A E8 7C 12 34 68 33 02 E1

Thanks again for the help.

My deepest apologies. The response does indeed indicate the problem, which was that I made a stupid mistake in my “correction” of your original packet.

Well, the response packet looks clear enough:
7E 00 0F // packet header and length
97 // packet type: remote AT response
01 // frame id, reflected from the command packet
00 13 A2 00 40 4A E8 7C // 64-bit address of the remote
12 34 // 16-bit address of the remote
68 33 // “D3” (or not - see below!)
02 // status byte - non-zero indicates an error
E1 // checksum

It’s the status value that shows the problem. The value of 02 in this case means “invalid command”.

I suggested ending your packet like this:
02 68 33 05
Oops. The 68 33 should be the hex ASCII codes for “D3” but 68 is the decimal value for D. Instead of 68, try 44.

Again, my apologies. Consider my wrist thoroughly slapped.

The apology is ridiculous. It works and I couldn’t be happier. Thanks for the explanation that came with it. That will go a long way to me helping myself on other problems. Thanks again.