Startup developer issues

We will use 4 ProXR boards.
What we have now for development:

  • Order #540144 Nov 2023 - Relay Controller 8-Channel General Purpose SPDT + 8 Channel ADC ProXR Lite
    with 900MHz (North America) Long-Range Wireless Mesh XBee-Pro® Communications Module
  • PR55-17B - purchased 1+ year ago, never used, for a previous project
  • both devices have the module XBee pro 539. both powered by power supply from you.

This is the Web-i page for the PR55-17B. All default except for static address It proves we are communicating with that modem.

  • We bring up NCD Base application.
  • The initial selection page comes up, finds the modem at .2.60. We click OK.
  • We click “device identification”. This is what we get “Communications Error. Device did not respond as expected”
  • if we click OK on the error box, this “loading information” box appears but does nothing. Clicking multiple times, it shows a little more green each time but the error box reappears.

NOTE: We even rebooted the PC that is running BASE software, and ensured only that is communicating with the PR55 modem (we understand only 1 socket is supported).

We have read the multiple linked quick start guides (incidentally, some info is out of date. Some say no password for the Web-i login, finally found the “admin” mention.)

So our questions:

  1. what is the “device identification” problem?
  2. how do we see our ProXR Lite relay controller?
  3. hmmm we see the “COMM Operator” is a paid app?
  4. we will use sockets in our large control system to talk to the PR55-17B modem (no intermediate Node-Red, MQTT etc). We have found the guide ProXR Quick Start Guide - with binary commands for our relay controller. Some help please:
  • We understand that we send those binary strings to port 2101 at the modem - correct?
  • Can you save us some time - we once saw a reference that said we will need to use AT commands to tell the PR55 to talk to a specific relay controller (per above, we’ll have 4 at this site). Can’t find it now, please direct us.

Thanks for the help. We look forward to controlling HVAC with NCD devices!


NCD Base Station is not designed to communicate to remote relay controllers over the 900MHz modem. Doing this requires an API layer and targeting mechanism that isn’t in place in the software.

  1. The device identification problem indicates that Base Station is attempting to identify the modem to see if it is a device it supports. Base Station is expecting a relay controller, potentiometer, or ADC at the other end of the connection so this identification fails.

  2. The most straightforward way would be to use node-red and send the commands from it as it takes care of the API portion of the packet and all you need to do is state an address and command payload.

Outside of that the most straightforward way is to set the Mode of the modem to Transparent mode. You can then just open a socket to the modem, use the AT commands to set the destination address, and then send the command. You can use Digi’s XCTU software to change this parameter over the USB connection on the modem.

  1. Correct COM Operator is a third party paid software

  2. Yes, this is how this setup would work, but we don’t generally provide support for using the Digimesh API these modules use outside of our software as it can get very deep quickly.

This document outlines how to change to Command mode to set the destination address when you are in AT/Transparent mode. See section Modes of Operation > Command mode for information on entering command mode and sending AT commands:

Setting the DH command which you should only need to send once as the DH is common amongst all S3B modules. You can find information on setting this under section “DH (Destination Address High)”

Setting the DL which will need to be done each time you want to talk to a different device as each S3B has a unique Lower address. You can find information on this command under section “DL (Destination Address Low)”

Thank you for your multiple responses. We have read your links, obviously we have not worked with XBee before.

A - Have we indeed purchased the correct combination? Are those 2 devices supposed to communicate, e.g. form an Xbee network?
On the ProXR Lite “buy” page it explicitly links to the PR55-17B.
We are now concerned because in:

Travis said: “It looks like you purchased an Enterprise series Modem along with a ProXR Relay controller which is an industrial series device. This is why they are not communicating”

In our previous post:

Travis said “You can utilize either the USB or Ethernet modem to connect to your software”

B - The Base Station software says it supports all products and communication.

C - So you say we need to connect to the modem via USB to change to Transparent mode?
In the Web-i at our address, under “Basic Settings”, what is the “socket Setting” “Start Mode”? Options are “Data Mode” or “AT command mode” - is the latter what you refer to as “AT/Transparent mode”? See F-1 below, concerned it wouldn’t survive a power cycle. We cannot risk having to go onsite, perhaps far away, to reset it.

D - Do you have a document which further explains the following, in one place? We get concerned when needing to utilize multiple documents that something will be missed or some revision inconsistency will break the data flow.

E - We note Travis’ comment in a 2022 post that transparent mode is slow. And that to switch to API mode would be faster but definitely would want to use your interface library due to its complexity.

F - So if we initially use transparent mode:

  1. Somehow put the modem in “AT/Transparent mode” per above. Either XTCU via USB (very awkward) or Web-i if that works per above, or via XBee commands (after any power cycle).
  2. Set the DH using command mode – guessing this does not survive a power cycle/restart
  3. Before sending commands for a specific PR60-1_R85PL (which happens frequently since we are controlling HVAC heat/cool etc) , we need to send to the modem, per your reference:
  • one second, +++, one second
  • ATDL
  • ATDH – maybe each time for safety
  • CN (return to data mode)
  1. Then we send the binary strings in ProXR Quick Start Guide - to control/read the relays.
  • send binary string
  • send (GT + CC + GT) to flush buffer
  • wait for & verify response

Thanks again. Lots of details, we appreciate your help.

You are right that this is a bit complicated because you are communicating through XBee Digi Mesh modules through an Ethernet modem so you have to handle two protocols. To further complicate things Digi(manufacturer of the Digi Mesh Modules) does not provide software resources for configuring settings through an Ethernet/TCP connection. Their X-CTU software only supports COM/Serial USB modem connectivity.

You will need to read through their user guide here to get more information on the commands for interacting/configuring settings in the module.

This guide explains how to configure the module and how to send transmissions from software to the end device(relay controller). The ProXR guide Jacob linked above outlines commands for controlling the relays.

If I were you I would utilize the API mode commands to send transmit requests to the relay controller. This will be the most efficient use of the DigiMesh modules and will work better if you ever add additional relay controllers to the application.

Thank you,
Travis Elliott

Thanks again, Travis. We appreciate the timely responses from you and Jacob. We’re getting there. We still don’t understand some fundamental points. Remember we will have 4 relay boards at this first site. Now:

  1. We had misunderstood API mode. Yes, we will use that formatting of the packets. It is very simple.
  2. We understand that we will send those API mode-formatted packets to the modem via a socket to port 2101. Thus there will be an address packet, then a data packet. And then wait for its response on the socket. We obviously need to protect the modem’s current address target in our multi-threaded system.
  3. We have the ProXR relay board & PR55-17B modem powered up. Have they formed a XBee network by discovery? What do we have to do, if not? We haven’t discovered your document that describes that per #7 below.
  4. How do we find the high/low address bytes of the ProXR, to set the modem to talk to it, per #2 above?
  5. So, again, Base Station does not support functionality via an IP to XBee connection as we do, correct? We can address its management UI on port 80.
  6. Are we to assume that E3C is not available to us?
  7. We keep seeing references to Digi documents, USB connections, configuration, etc. We need to understand how those relate to each other and to #3 & #4 above.

Once it’s working, we’ll not bother you again. We just haven’t got over these key initial humps. We had assumed that buying your modem model with an Ethernet interface (preferred in our system architecture) was equivalent to the USB interface. Thanks.

ok, we acknowledged that we have to connect the modem to the PC with USB to set up. This post applies to #3 & #7 above. Some questions in the above post remain.

  • We used your video
  • We downloaded, started up XCTU software.
  • Below are screen shots of results. (We’re on windows). We did change baud rate to 115200 per your video. It evidently finds the modem on COM3 (when we try changing to COM1, it displays a ‘nothing found’ dialog). But the reset, which we do indeed do manually per the popup, evidently fails.
  • also - we assume eventually when this works, it will find our relay board, but you say in the video that the package for that board has the MAC / XBee address on it. It came in a plastic anti-static pouch, no address info.

Thank you again.

We have tried every combination of the following on the “Add a radio module” dialog box of XCTU.

  • “Select the Serial/USB port” which lists COM3 or enter COM3 in “provide a port name manually”
  • baud rate = 9600 (Digi default), 115200 (what your video recommends)
  • “The radio module is programmable” check/uncheck (suggested by final failure box above).

It always results in the above “Could not find any radio module”.

Sorry, we need your help to get past this. If you prefer, we can phone or screen share to work through this. Thanks.

@TravisE_NCD_Technica @jacob
We appreciate your answers earlier this week. Per our last 3 replies in this thread, this is becoming quite serious for our project, we’ve already had to delay install into January.

Travis, note in our first post in this thread the PR55 was bought last year (for the school CO2 project that didn’t happen) and the ProXR is just a few weeks ago.
We feel like we’ve tried all combinations, see above. We’ll be happy if it’s something simple we’re doing wrong!


If you disconnect the USB from the Modem does COM3 disappear? You can check window’s device manager under Ports to confirm.

Is there another software like node-red or Base Station that could be consuming this port?

Ah, good thought, we hadn’t thought of that. However, seems not the issue.
We are not running node-red, Base Station not up.
Here’s our test, think it confirms that:

Also to further test that, using XCTU & clicking “add radio module”:

Thank you yet again, Jacob!

Can you check the ETH and USB pins on the Modem and check that they are in the USB position? If the pin closest to the USB position is exposed you’ll need to move the jumpers over one pin to the USB position.

Thanks Jacob. Moving the pins to “USB” (where were we supposed to find that information?) enabled the following:

  • Powered up modem & relay board.
  • Note: relay board is about 25’ from modem, we had seen that they should not be too close.
  • Connected modem to USB on dev PC
  • Brought up XCTU, it found the modem! Got the long list of parameters in right pane of window
  • Clicked on the “find devices” icon
  • Got this “Discovering the radio modules …” popup. Waited over 5 minutes, it never found the relay board.

Next idea?

From here it depends on how you want your software to interact with the digimesh protocol and whether you want to use Base Station.

The relay controllers don’t use the encryption option by default so you’ll either need to set the same Encryption enable and AES Encryption key into the modem and all of the relays by swapping the module in the modem or just disable encryption on the modem.

To work with Base Station or to use AT commands to switch targets you’ll need to set the API Enable property of the modem to Transparent [0] and set the DH and DL to the serial address of one of the relay controllers.

If you want to use the Digimesh API mode you should be ready after just disabling or changing encryption on all modules.

Disabling the encryption setting on the modem did it, now XCTU finds the relay board. Thanks for pointing that out.

Due to the extended development cycle for this, we had to take a different approach for this current project. We’ll experiment with API mode and control of the relay board later & keep you posted. You can consider this thread resolved, we’ll start a new one if we have further control questions.

1 Like