Hi all,
We have an upcoming install where a remote device is located too far from our main installation to run a direct Ethernet cable. The remote device supports Modbus TCP (Ethernet only — no RS-485/RTU).
We’re using the NCD Enterprise Gateway, which has the built-in DigiMesh 900 MHz module. Since DigiMesh is an open standard, I’m wondering if there’s a way to bring the remote Modbus TCP data in through that same receiver rather than adding a separate network path.
Specifically — is there an NCD node or any DigiMesh-compatible device that could poll a Modbus TCP device locally and transmit that data back through the DigiMesh mesh network to the enterprise gateway?
Thanks in advance!
We have implemented a similar solution in the past. While it may not be the most aesthetically pleasing option, it is functional.
I just conducted a quick test to replicate your setup.
You will need the following hardware:
Industrial IoT Wireless Ethernet Modem
Here are the steps to follow:
- Open the lid and set the jumpers to USB.
- Connect to XCTU.
- Set the destination address to your gateway.
- Change the mode to AT mode.
- Switch the jumpers back to ETH.
You will send data to this modem using the gateway. We have a flow you can use to get started. The modem will receive the Digi payload and transmit it over Ethernet. The Ethernet will then communicate with the slave device via TCP/IP. The slave will respond, and the data will return to the gateway through Digi.
Hey @Bhaskar,
Thank you for the response. This is really interesting. So if I’m understanding correctly, the gateway is polling the Modbus device?
How frequently is the gateway polling the slave?
correct. gateway will send the modbus command and device will respond. the minim polling interval will be 3 sec
Hey @Bhaskar,
I have installed the modem like you prescribed above. When I set the jumpers to USB, do I connect XCTU to the device via the ethernet port still? There is no USB port on the modem so I’m confused on how to connect it to XCTU. Do I need to get a serial to USB cable to connect directly to the XBee chip? Any help you can provide would be greatly appreciated.
Thank you!
Hello @gnelson You should use the USB port to communicate with XCTU and perform the settings as Bhaskar mentioned. It should be a USB port under Ethernet port on your Ethernet Modem.
Could you share a picture of your ethernet modem please?
Thanks.
I was able to find the USB port on the device. I had already mounted in an enclosure and couldn’t see the port. Thank you for the quick response.
Great, please share your results.
Thanks.
Hi,
I’m still unable to get XCTU to discover the radio. Here’s where things stand:
- The jumpers on the unit are set to USB.
- I’ve tried all baud rates during discovery.
- The sequence is consistent: XCTU opens the port and prompts me to reset the radio, I reset it, the dialog disappears and it searches for about 10 seconds, then reports that no radios were found.
I’ve ruled out the Mac side. The board’s FTDI serial port enumerates fine, and XCTU successfully opens it and runs discovery — so this isn’t a cable, driver, or port issue on my end. The problem appears to be that nothing is answering XCTU as an XBee on the other side of that serial connection.
Thank you.
Hi @gnelson sure, could you try with discover radio modules intead:
Then select the COM port,click on the ‘Next’ button, leave the defaults, and click on the Finish button. If detect a module, click on the ‘Add selected devices’.
Additionally, could you share a picture of your setup please.
If you prefer we can schedule a quick call in order to take a look.
Thanks.
I have tried to discovering the radio module as well with similar outcomes. Scheduling a call would be fantastic.
Thank you.
@Eduardo_Mtz & @Bhaskar - I wanted to provide an update:
I wanted to rule out a couple of things and possibly eliminate the NCD carrier board as an issue, but since I didn’t have an XBee-to-USB module I made my own using an Arduino Mega 2560 acting as a USB-serial bridge. Jumpering the Mega’s RESET to GND holds its main chip in reset, so the board becomes a dumb passthrough from its USB-serial chip out to D0/D1. See the picture below:
XCTU found the radio on the first try and I could read and write parameters with no trouble.
So the radio is healthy, and my Mac, cable, driver, and XCTU setup are all fine. The only thing that changes between working and not working is whether I go through the carrier board’s USB port or straight to the radio’s UART. My assumption is the carrier board may need to be replaced, but I’d like to understand what’s actually happening first:
- Does that USB port connect directly to the XBee’s UART, or is there a host processor in between?
- With the jumpers in the USB position, what’s supposed to be connected to what?
Another thing I want to nail down before moving on is the destination address. The Enterprise Gateway’s Node-RED shows some of our other deployed sensors (Gen4 Vibration) using a destination of 4235AA70, with 0000FFFF listed as the broadcast default. Since 00000000 0000FFFF is the standard DigiMesh broadcast address, I’m reading that field as a DL, which would put the gateway radio at 0013A200 4235AA70. So I’m planning to set DH = 0013A200 and DL = 4235AA70. Can anyone confirm that’s right? I don’t have physical access to the gateway to read its SH/SL directly.
Thank you!
This is impressive. Yes, you only need to set the DL as your destination address. Setting the radio directly using XCTU won’t work. In the sensor, there is an MCU that controls this.
As for the modem, there is no host MCU. The USB modem has an FTDI IC, that’s all. so it should connect the xctu without any issue.
Hi @gnelson Thank you for the update. Additionally, you can get the radio module’s MAC address by clicking the left embedded button on the Wireless Gateway node; you will see the complete MAC address appear in the debug window.
You can then click the embedded button again to return the Wireless Gateway node to its normal Ready status.
