Is it possible to turn on a digital output on a remote Xbee by sending a packet from a local XBee?
I have read through the manual and I understand that through I/O line passing, it is possible to read digital and analog inputs on the remote but I didn’t anything that talked about digital outputs on the remote. Thanks.
What you are looking for is called a remote AT command. The remote AT commands will only be available in firmware versions of 1xcx and above. I do not think that an official relase has been made of this release. It should be realtively soon though. When it does become available however, use this as an example:
Two radios are configured with 1xCx firmware. Radio 1 is given a source address (MY) = 1 and the API is turned on to API = 1. The second, receiving radio is at default except the source address is set to MY = 2
7E = Start Delimiter
00 10 = Length bytes
17 = API identifier for remote AT command
01 = Frame ID (set to a non zer value such that an AT command response will be given)
00 00 00 00 00 00 00 00 = 64 bit address of node is set to zero (16 bit source address is being used instead)
00 02 = 16 bit source address of receiving module
44 31 = AT command (D1 values given in ASCII equivalents)
04 = AT command parameter value (setting the D1 parameter to a 04 value)
6A = Checksum
If you do that, you are only reprograming the XBEE. For that reason the timer doesn’t work.
I found that the only way to change the state of remote output is changing that DIO in the local XBEE. That DIO in the Local XBEE has to be as an input. The same DIO in the remote has to be as an output.
Sorry for my english.
Please if somebody can do it with an API, just write it.
Thanks
This packet is not correct and does not work. There is for some reason and extra “02” in the packet and not in the explanation, without this the length is 0F, with this the length is 10. With or without the extra 02 the packet does not work.
I can only get a transmit when I use 64-bit addressing, this shows that the packet is at least leaving the device I am talking to but it does not under any circumstance initiate a change in the settings of a remote unit.
When is the 1XCX documentation going to be released, I am sick of trying to reverse engineer these things. It is almost a year since I bought them and still I can’t get them to work properly.
I found the 10C0 firmware on the ftp server of Digi.
link: ftp://ftp1.digi.com/support/firmware
I suppose the XB24_15_4_10C0.zip version for the xbee and the XBP24_15_4_10C0.zip for the xbee pro version. But I’m not sure.
I also found this article in the knowledge base: http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=2208
Does this mean that the 10C0 version is already released for the xbee? If the 10C0 version is still the actual version, where can I find the documentation of the new features of this release?
I found this thread while trying to understand the XBee, and it helped me to get things going. Perhaps I can now add to it, in the hope of helping someone else.
I’m using firmware version 10C8, and I find that (mostly) the remote AT command does work. Here’s a slightly updated description of the command packet from an earlier post; here I’m using the BD command to read the baud rate setting on the remote:
7e # packet start byte
00 0f # length of payload
17 # packet type: remote AT command
01 # frame id (choose at random, but not 0 if you want a response)
00 13 a2 00 40 4A 17 7E # 64-bit address of remote
FF FE # network id (see note below)
02 # apply change immediately (set to 00 if change is to be queued). Irrelevant here, but the byte still needs to be present.
42 44 # command (“BD”)
To change a parameter, insert new value here (binary)
8E # checksum
Note: the network id gave me some trouble. I tried using the PAN id without success, but the kind folks at Digi support suggested FFFE and it worked. I’ve also found that 0000 works, but I don’t know why.
The response packet looks like this:
7e # packet start byte
00 13 # payload length
97 # packet type (remote AT response)
01 # frame id, reflected from the request packet
00 13 a2 00 40 4A 17 7E # 64-bit address of remote
00 00 # network address of remote???
42 44 # AT command (“BD”)
00 # status (00 = “OK”, also see below)
00 00 00 03 # parameter value (3 = 9600 baud)
0A # checksum
Status note:
0 OK
1 ERROR
2 INVALID COMMAND
3 INVALID PARAMETER
4 NO RESPONSE
5 I don’t know, but the ND command returns it.
Although the remote AT command isn’t listed in the out-of-date documentation for the Series 1 XBees, it is documented in the product manual for the Series 2.5 modules. (It took me a while to latch on to that.) The status values of 2 and 3 above are from the 2.5 manual, though I haven’t yet seen them in practice and I’m only guessing that they would have the same meanings on a Series 1 chip. Status values 4 and 5 don’t seem to be documented anywhere; Digi support told me the meaning of 4, but I haven’t yet asked about 5.
I said above that the remote AT command “mostly” works. It’s trying to use ND that’s the exception. It seems valid to want to know how the remote sees the network, but I’ve had no success with it so far.
“ND” (Node Discovery) shouldn’t be considered a Remote command, but a Local one. As far as result code 5, I’m not sure what it means but the question is, would this result be returned when running the command locally?
Thanks to all the great info on this thread, I was able to get this to work on the XBEE-PRO DIGIMESH 900. I ordered the XBee-PRO DigiMesh 900 Development Kit w/ 4 XBee-PRO Modules for $199.
The Modems are XBP09-DM Firmware version 1820.
I used the X-CTU modem utility to enter a remote AT command to turn on / off the remote node’s LED#2 on the XBIB-R-DEV board. Note that this LED is labeled LED4 in the schematic, but LED2 on the silkscreen of the PCB.
This command turns the remote node’s LED on:
7E 00 10 17 01 00 13 A2 00 40 53 89 04 FF FE 02 50 31 05 8D (Set P1=5 in device id 013a20040538904)
This command turns the remote node’s LED off:
7E 00 10 17 01 00 13 A2 00 40 53 89 04 FF FE 02 50 31 04 8E (Set P1=4 in device id 013a20040538904)
You will get a response back on each of the above commands as discussed in the thread.
One of the things that threw me off for a bit was that the Serial Number High (SH) that is displayed in the X-CTU modem utility does not show the leading “00”. Once I added the “00” to the command string in byte 6, it started working.
When I run ND locally (in API mode) I get the expected response - an 88 packet with information for my single remote node, followed by an empty 88 packet to signal the end of discovery. Both packets have status zero.
Now that I know it’s not meant to work remotely, I’ll stop banging my head against that particular wall.
Do you happen to know whether the same applies to Active Scan and Energy Scan? I haven’t got round to those yet.