I have a PIC that I am going to connect to my XBEE. I am connecting DIN, DOUT, GND for now. Do I need to connect CTS as well? or is that sufficient. I am sending sets of 24 bits data (x, y, z accelerations) to the XBEE. Furthermore, I am using XCTU to configure the RF module so I do not need to configure with PIC. Any help is appreciated. Thanks.
I have gotten the two modems to communicate each other. The one connected to the PC is recieving data from the other connected to a PIC
The two modems were both configured using XCTU, but I only made sure the PAN ID are the same. My question is, is there anything I need to do on PIC side beside sending raw data to the DI of the XBee? Like commands to write, address, etc? Or did the XCTU take care all that for you? Thanks.
Also, do i need to update the firmware to the PIC?
I don’t use PICs, so I can’t answer anything specific about them. As far as your data, yeah, just send the raw data a byte at a time on through the data lines. You should see your data appear on the data in line of the other XBee (you’re reading it through a terminal program, right?).
sylvie369:
I don’t use PICs, so I can’t answer anything specific about them. As far as your data, yeah, just send the raw data a byte at a time on through the data lines. You should see your data appear on the data in line of the other XBee (you’re reading it through a terminal program, right?).
Yes, I am receiving data on one end, but not the right data. I tried sending all 0s or all ones, but I am getting values such as D5, FE, etc on the terminal. Would this because of the configuration? LIke do i need to set the pins to be digital from analog?
Make sure that the XBee modules are configured to run at the same baud rate as your PIC program. You can set the XBee baud rate via X-CTU (it defaults to 9600).
If your PIC program opens the serial connection at a different baud rate (say for example 19200) than what the XBee’s are configured for, you will get incorrect data (and probably even the wrong number of bytes.)
Also remember, that by default, the XBees are sending data in plain ASCII text, so this means if you transfer a ‘0’, its actually sending a hex value of 30 across the air.
I’m not a PIC programmer, so I cannot speak to the other questions…
Second about communicate mode, I chose broadcast mode. because in the other mode-----unicast mode, rx xbee will send a ACK to tx xbee, while my tx xbee is sending data continuously. I used 57600baud. Delay is necessary when you send data from pic to pic uart port.
Actually I am not quite clear about broadcast mode and unicast mode, but in those days, I chose broadcast according to friend’s recommend. He said that it is experience.
Do you mean that if i send “0x00” hex to the Xbee, on the XCTU terminal, I will see hex 30?
How do you change the baud rate for the PIC? I know both the radios are set to 9.6k baud rate… should I add a delay in the PIC program to alter the rate? How would I know how much delay to put? Thanks.
I don’t think I am broadcasting it, so my remote XBee is receiving some sort of clock at the output which I am not sure what it means.
the first, if you send 0x00 in TX XBEE, you should receive a 0x00 in RX XBEE.
Second, in PIC uart there is a SPBRG register, you can change the value to set different buad of uart port.
third,if you only send a couple of bytes, you need not use delay. But delay is necessary if you send a continuous bytestream.
fourth, communication mode is chose by setting value of DH,DL,MY . see datasheet.
about your last question, I am not quite clear.
Thanks for the reply.
I am looking into the UART baud, right now, I am writing to the SDO of the PIC and connecting SDO to the RX pin of XBee. I have a question in general, if I do not use the PIC and just connect the RX to the 5V supply, isn’t that the same as PIC sending all 1’s to the XBee? I have tried that to test and it seemed that it does not even activate the transmission?
And yes I am sending my X, Y, Z accelerations in sequence continuously, so I guess I would need some sort of delay in this case.