i’m having a strange problem with S8 DigiMesh 868MHz Xbee (XB8-DM, Function set: 865/868LP 80k, Firmware version: 8074, Hardware version: 2442) unit in API2 mode. The problem is with the UART interface. When two units are both connected by XCTU I have a normal connection and everything works as it should. The problem arises when I connect the radio to arduino. First let me point out it’s I started with S2Pro 2.4GHz radio and I worked like a charm, so the software and arduino should be fine. But when switching to S8 I get a strange traffic on serial port. I’ve set up ScanaStudio logic analyzer to see the traffic and send a remote AT command (DB command as I want to get an RSSI reading). The problem is the Xbee doesn’t wait for the command to end and immediately sends some data back, which is not in proper API frame. It starts whit 0x7E but the length that follows is incorrect 0xFF 0xF.
So to recap:
S2 ZigBee 2.4GHz unit -> working as it should
S8 DigiMesh (same Xbee adapter, same program, same arduino) as S2 unit:
I tried: - changing adapters
- direct connection
- disable SPI interface, RTS pin
- sleep is set to normal(0) so always awake
and nothing works.
I only got it to work by removing the RX TX wire from arduino, add XBee to XCTU through USB, removing the USB cable reconnecting RX TX wire to arduino, while keeping the power on. In this case it works as it should, so the program and the library should not be the problem. But that is not an option as it stops working when reset.
I can’t tell from your screen shots but you can determine if you have a programmable module or not based off of the part number of the radio.
Also note that in most cases, you need to use a special board to connect an XBee to an arduino. The reason for that is that the Arduinos run at 5V and the XBee is a 3V device. So most of the Shields do some level shifting that is needed for the XBee to talk to the Arduino.
May I also suggest you simply take the radio out of the picture for the moment and just connect the Tx of one Arduino to the Rx of the other device and the Tx of the other device to the Rx of the Arduino. Then get it working. This way you take one less device out of the picture and easier to troubleshoot. Once you then have that working, then you can add the radios in using transparent mode.
Yes I am aware of level shifting and I am using Xbee adapter that does the level shifting for me. Also I’m using Teensy 3.1 arduino board which is run on 3.3V as it is made around arm processor, so no level shifting necessary.
I already tried eliminating Xbee and it worked just fine. And as I mentioned before everything works with Xbee S2. And also if I do a little trick and initialize the Xbee with XCTU and then connect it to arduino without removing power from it, it works. So I just need to find a way to make it start after I power it on. I can make a screen shot of what happens when I add the radio to XCTU if this helps.
I already tried with transparent mode and got the same result.
The serial number on Xbee is: XB8-DMUSB002-revB (is this what u need to determine if the unit is programmable or not?)
Added new pictures of start sequence (initialization) when I manually add Xbee S8 to XCTU. As you can see there is a lot of activity (negotiation) between computer and Xbee before Xbee starts sending back valid API frames. Should I try to mimic these activity or is there another way?
What is the full part number of the XBee modules you are having the issues with? The part number I am looking for is on the white label on the shield side. It will read something like XBP24Z7SIT-004 (ZB versions used as example)?
No, uploading the RF processor firmware is not enough. There is a 2nd processor that stands between the UART pins on the XBee and the RF processor. That processor is a FreeScale processor that you must write and upload an application too before you can communicate with this xbee and an external device.
OK, thank you. I read the user guide again and see I missed that part.
Module operation for the Programmable variant The modules with the programmable option have a secondary processor with 32k of flash and 2k of random-access memory (RAM). This allows module integrators to put custom code on the XBee module to fit their own unique needs. The DIN, DOUT, RTS, CTS, and RESET lines are intercepted by the secondary processor to allow it to be in control of the data transmitted and received. All other lines are in parallel and can be controlled by either the internal microcontroller or the MC9S08QE micro; see the block diagram under Digi XBee 865/868LP RF Module operation on page 29 for details. The internal microcontroller has control of certain lines by default. The internal microcontroller can release these lines by sending the proper command(s) to disable the desired DIO line(s). For more information, see Digi XBee 865/868LP RF Modules command reference tables on page 77. In order for the secondary processor to sample with ADCs, you must connect the XBee pin 27 (VREF) to a reference voltage. Digi provides a bootloader that can take care of programming the processor over the air or through the serial interface. This means that over the air updates can be supported through an XMODEM protocol. The processor can also be programmed and debugged through a one wire interface BKGD (Pin 9).
But if the internal microcontroller disables the DIO lines (I reckon DIO13 and DIO14 needs to be disabled) doesn’t this disable the UART completely?
EDIT: Ok, I see now. I need to disable the FreeScales pins that are connected to the XBee pins. Is this correct?