With the IDE Monitor, I expect the coordinator to receive A, B etc… but nothing happens.
What I also noticed is that when I completely power OFF the end device, and turn it on again, the monitor receives some garbage. What I noticed amongst the garbage however is the NI of the end device… What am I missing please?
With this code and JUST THE ARDUINO, I can actually turn on the serial monitor, type something and receive it back immediately. This would mean that if the End Device (on the Arduino) receives something from the Coordinator, it would relay it back immediately too right?
With the last configuration (that of the Arduino relaying everything back) nothing has worked. So I decided to send API packets maybe the XBEEPRO2 can interpret it.
I am trying to send the letter ‘a’ with the following
Ok so I have some news… I kept everything the same, but simply changed the firmware of both coord and end device from API to AT and I can now see some light
the problem is that I need API because I need more control… any help ?
While dealing with API, when the xbee joins the network, you will get modem status frames. If you are sending data using Transmit request frame than you will get as the acknowledgment Transmit Status Frame. It seems you need to take care of these frames in your code. You can also disable the Transmit Status frame by some parameter in the Transmit Request frame.
Switching from AT to API firmware will require more work in your application, since you’re now having to packetize all of your data, including the calculation of a checksum for each packet.
Since it sounds as if you have already decided that you need API for your application, your best bet is to look for one of the free (open source) libraries for API communication.
I seem to recall some out on google code as well as sourceforge. These libraries should provide you with the functions that will do most of the dirty work for you.
Otherwise, if you want to keep it simple and you’re not going to be dealing with mulitple radios in your final application, then you can flash back to AT and continue to send bytes over the serial port using the standard Arudino Processing serial library.
You said a couple of posts earlier that you sent this API packet:
7E0001619E
and got no response. That’s not too surprising, because the packet isn’t a legal one - and XBees quietly ignore illegal packets.
If you check the pinned posts at the top of this forum (802.15.4) you’ll see mention of the packet-check program which I wrote and still maintain. Here’s what it says about your packet:
=======================
[john@henry ~]$ packet-check
API Packet analyzer version 1.5 for XBees (802.15.4, DigiMesh, ZNet, ZB)
Note: if it prompts for more bytes and you’re done, hit return
Enter packet: 7E0001619E
Packet: 7E 00 01 61 9E
7E // Correct packet header byte
00 01 // payload length (decimal 1)
61 // Illegal packet type
9E // checksum - correct
ERRORS:
Illegal packet type
============================
So I think maybe you should look over the product manual section on API packets for your version of XBee in a bit more detail to see which packet types will actually help you.
Plus: although I publish the packet-check program only in the 802.15.4 forum, it’s supposed to work with packets for all the XBee types. So you could use it as a guide while you’re composing packets.
Which brings me to the other point - you’ve posted this in the 802.15.4 forum and that may not be the best place for your question. The 802.15.4 forum is for Series 1 XBees running the 802.15.4 firmware, and if your firmware version is 1x47 it indicates that you’re running a series 2 XBee with ZNet2.5 firmware. Don’t get me wrong - you’re perfectly welcome here. I’m only trying to suggest that if you ask questions in the ZNet2.5 forum you’re more likely to have them seen by the people who know the answers.