(900HP) XBee baud rate/packetization making them invisible to xctu?

XBee & XBee Gateway XBee - DigiMesh
,
1

Hello,

I have a XBP9B-DM (non-programmable) (two, actually) that I programmed with specific settings, with the intention of increasing throughput. Supplying data to one through UART, I was able to receive with the following settings

<setting command="CM">00FFFFFFFFFFF7FFFF</setting>
<setting command="ID">2015</setting>
<setting command="NH">1</setting>
<setting command="MR">0</setting>
<setting command="NI">send_fast_spi+uart</setting>
<setting command="BD">8</setting>
<setting command="RO">0</setting>
<setting command="AP">1</setting>
<setting command="D1">1</setting>
<setting command="D2">1</setting>
<setting command="D3">1</setting>
<setting command="D4">1</setting>
<setting command="P2">1</setting>

However, even though they seemed to work for several runs, I am now having trouble discovering/adding the devices in XCTU (both current and legacy versions). I have a vague sense that it may have something to do with these settings being too “lossy/aggressive” (230400 baud and constant stream of bytes is no good?).

However, to my confusion, any attempts at using the in-built XBee Recovery Tool (Alt+shift+X in XCTU) appear to recover the device successfully – the tool says “bootloader found, transmitting firmware”, and device restored successfuly, or something to that tune. But then, the device does not show up when running a seemingly-sufficient set of options on Scan.

Things like pressing Commissioning button three times, etc. do not seem to be working. Am I right in thinking that this is an issue with “serial speeds” (excuse the imprecise language) and is there anything compelling I should try doing to recover these?

Sorry for the lengthy description, I’m able to provide further details. Any help is greatly appreciated.

2

Also wanted to note that I have tried doing the USB optimization as documented (reducing tx and rx bytes and the delay). The recovery process claims to be successful under these port settings, but still doesnt seem to make the device appear.

3

You are Enabling the SPI bus. Doing so turns off the UART. So any communications must then occur via the SPI bus instead of the UART.

4

Thanks for the swift reply

I thought enabling SPI and UART means that the first channel communication is received over is “active”

To enable the UART port, DIN (DIO14) and DOUT (DIO13) must be configured as peripherals. To enable the SPI port, SPI_MISO, SPI_MOSI, SPI_nSSel, and SPI_Clk must be enabled as peripherals. If both ports are enabled then output will go to the UART until the first input. Other rules for serial port selection are platform specific as follows:

(From An introduction to SPI on XBee radios | Digi International)

Also, if this is the case, why does the device “claim” to have been “recovered” successfully? Does that recovery not restore default firmware settings? I do not doubt what you say, mostly want to understand the problem better.

I will try programming the device over SPI and see if I can have a success.

5

The recovery function uses and forces the bootloader via the UART. That is why that works.

Not sending data over the UART and having the SPI lines active can enable the SPI port.

6

I see.
What would you recommend as a “simple” way to force UART operation on these (that has both SPI and UART enabled) so they can be reprogrammed via XCTU+Grove development board and a computer? Does such a method exist?

7

https://www.digi.com/resources/documentation/digidocs/90002173/#reference/r_select_serial_port.htm?TocPath=Operation%257CConfiguration%2520considerations%257C_____1

8

Also XBee®-PRO 900HP and XSC RF Modules User Guide