I try to set up a simple demo with two USB-development boards (XBIB-U-DEV), equipped with XB24-B. One of these modules is set as router/end device (API, ver. 1347), the other as coordinator (API, ver. 1047). The router is configured to send input data samples on a regular basis (IR=0x1388=5 seconds). I expected that the coordinator send the received packets via UART to the PC but nothing happens. I’ve set the same PAN on both devices, set DH and DL of the router equal to SH and SL of the coordinator - no change.
Both boards are connected to the same computer (the router only for power input). Is this a problem? Or doeas the coodinator not send the incoming packets to the UART?
Please, help me since I don’t know what to do now.
If both the router and coordinator ends are using API firmware loads, your data would need to be formed into API packets. In other words, you’ll need an application encoding and decoding the data into/from API on both ends.
My problem is that one XBee should send the analog and digital inputs on a regular basis (using the sampling time) to the other one. I’d like to receive the sampled data via UART at the computer. I don’t want to send a packet to the sampling XBee, the samples should be sended without requests. Reading the OEM manual, the chapter 4.5.3 is what I want:
Periodic sampling allows an XBee / XBee-PRO module to take an IO sample and transmit it to a remote device at a periodic rate. The periodic sample rate is set by the IR command. If IR is set to 0, periodic sampling is disabled. For all other values of IR, data will be sampled after IR milliseconds have elapsed and transmitted to a remote device. The DH and DL commands
determine the destination address of the IO samples. DH and DL can be set to 0 to transmit to the coordinator, or to the 64-bit address of the remote device (SH and SL). Only devices running API firmware can send IO data samples out their Uart. Devices running AT firmware will discard received IO data samples. A sleepy end device will transmit periodic IO samples at the IR rate until the ST timer expires and the device can resume sleeping. See section 5.3 for more information on sleep.
So, my coordinator has API firmware and should be abler to send the received data out its UART. But it doesn’t.
If your coordinator has firmware version 1047, it is an AT coordinator and will not send IO samples out the UART. You must reprogram the coordinator with 1147 firmware (API Coordinator) for it to send IO sample data out the UART.
Also keep in mind that reprogramming to 1147 may cause the reprogrammed (API) coordinator to start on a different channel than before. After reprogramming the coordinator to API firmware, send an NR0 command to the router to force it to leave and join the coordinator on its new channel.
Hey reviewing the Xbee ZNet 2.5 manual, I realize about a note that I had never seen in section 6,04 (API frames) and say: * Transmit option 0x08 is not supported…
That means that if I want to read a param with this API frame I won´t get an answer?..
for example, if I want to read de RSSI from the last packet receive, I can´t send (from a host application) to the ZNet module an API frame with API ID 0x08 and in the AT field “DB” and then wait the answer from the module…if this is not possible could some one tell me how to achive this…I mean using API how can I read the RSSI from the last Tx (in the coordinator for example)?
The note about transmit option 0x08 refers to the options byte in the API transmit frame (0x10). The image for the API transmit frame shows a 0x08 transmit option bit, but it is not supported (an error in the graphic).
You can use the AT command frame (0x08) to query the RSSI. So you have the right idea - when data is received, you can use the AT command API frame (0x08) to query the DB command. Keep in mind that DB indicates the RSSI of the last HOP of the last received packet. If a packet traverses multiple HOPS from source to destination, RSSI will not indicate the quality of the entire link - only of the last hop.
Hi Damons, thanks for your help, you´ve clear my mind about this.
Hey another thing, in the manual it said that the ZNet 2,5 support Point to Point networks, that means that it´s not necessary to make a mesh network (multihop) to communicate 8 modules (max number of child join to a parent) with a coordinator, How can I achieve this kind of network architecture, I mean, do I have to set some param in order to make this kind of network (maybe, use an special firmware). The number of hops param has to do with this…If I set it to one I just will have one hop…
ZNet 2.5 can support point-to-point networks, but the 802.15.4 firmware is much better suited for such networks. For example, each ZNet transmission requires MAC and Network layer acknowledgments, whereas 802.15.4 transmissions only require MAC acknowledgments (fewer transmissions in 802.15.4 = better latency & throughput). Also, 802.15.4 is not limited to 8 end devices like ZNet is (per router/coordinator).
If you still decide to use ZNet, you only need to have one coordinator and up to 8 end devices. Make sure to set SP the same on all devices.
BTW - ZB firmware is generally a better solution than ZNet if you are working with end devices. ZB firmware runs on the same hardware as ZNet.
Thank you for clarifying that, but the problem is that I already have 4 ZNet2,5 (serie 2) modules. But right now I realize that for my new application are better the modules that are made to support 802.15.4 (serie 1), that´s why I´m asking if there are ways to achive the same properties that series 1 has with series 2. It is possible? would you mind seeing the new post I´ve made in “need help implementing a s1 project in s2” topic? I wrote it yesterday …Thanks and thanks.
ahh I forgot something…just to reafirm…Does Znet 2.5 hardware support 802.15.4.firmware (XB24=108x,10Ax,10CD)?, NO! right?..when you talk about 802.15.4 firmwares you´re talking about XB24-ZB (20xx-21xx-22xx-23xx-28xx-29xx), aren´t you?
ZNet hardware does not support 802.15.4 firmware. The ZB firmware you mention (20xx, 21xx, 22xx, 23xx, 28xx, 29xx) IS supported on the ZNet hardware, but it is similar in functionality to ZNet. ZB is based on the ZigBee-PRO feature set and is a mesh solution.