The second in a series breaking down compatibility on MDS SD Master Station, Orbit and SD series remotes operating in transparent mode. Adding Orbit to Legacy SD x710 network
The objective is a general framework to help navigate the 25 years of backward compatibility between the MDS x710, SD, ORBIT series remotes and x790 and MPRS Redundant Master Stations. This guide will focus on Transparent mode change and Orbit and SD integration.
Future post will elaborate more native LN Orbit Operations as the final step in a removing all legacy hardware and operations completing the migration journey
Find a Channel Partner: https://www.gegridsolutions.com/communications/contactus.htm
Please help me improve my post by sharing, offering constructive feedback, corrections and questions you may have. Thank you for visiting.
Written by: Phillip A. Yancey - BCI Technologies Sales and Support Manager.
***Stay tuned for updates on the Serial port connectivity and differences between hardware.
Topics Covered:
Migration Planning Checklist:
System should have a MDS Master station with SD Modules or SD Radio running as Master / Polling Remote for serial broadcast systems.
MPRS SD Master station is limited to SD9 and SD4 series products.
If using SD1 or SD2 you'll need to continue using an SD Remote on frontend.
All remotes should be X710A, SD Series, or Orbit Series devices.
Current goal should be to remove all x710 and all new purchases should be Orbit Series.
Radio operational mode should be Transparent on SD, transparent-serial on Orbit.
Cable and Jumper adaptors
x710 uses N-Male Radio connector and DB25 Serial.
SD uses TNC-Male Radio connector and DB9 Serial.
Orbit uses TNC-Male Radio connector and RJ-45 Serial.
Includes a RJ-45 to DB9 adaptor.
Radio Mode Setup - Compatibility operation
For an MPRS, SD or Orbit to operate in compatibility mode the device must be configured in FSK mode supporting X710 compatibility.
Transparent mode, acts as a transparent bridge between connected devices, passing data packets directly without altering them. This means that the radios do not interfere with the data's content, format, or timing, allowing for the reliable transmission of even proprietary protocols or applications that require specific timing characteristics. In this operation the radio system acts as a broadcast system streaming serial data.
For Orbit Remote backwards compatibility, on the Remote use Radio Mode "Transparent-serial" shown below
For SD Remote/AP backwards compatibility on the SD Remote use Radio Mode "Transparent" shown below.
On the MPRS Master station use Radio mode Transparent, serial Payload Port: COM2 shown below.
In compatibility mode we are limited to using only 5 Watts of power even though the Orbit and Master station is capable of up to 10 Watts. Please reference part 1 for more information on the Master station setup.
Virtual Radio Channels (VRCs) - Radio Setup
GE MDS now GE Vernova, takes advantage of VRCs or Virtual Radio Channels on the SD and Orbit Series products. In this section we'll review the VRC Configurations and their usage for serial compatibility.
First let's review what a VRC (Virtual Radio Channel) is. A VRC creates an independent communication path over a single radio link. It segments the radio spectrum creating distinct channels that enable simultaneous data transmission for different applications and purposes. Think of a VRC as a VLAN for RF that behaves much like multicast UDP without the complexity or overhead associated with IP. In the case of serial data, anything that comes in goes out, similar to legacy serial broadcast.
In backwards compatibility mode you are able to use a single VRC. When using Packet with Mac Mode or Native LN operation, you can use up to 3. VRCs can be used in conjunction with serial data and serial ports or, IP Data and IP Payload.
Both the SD and Orbit are limited to a single VRC, and therefore only a single Communication port when operating in legacy x710 or transparent modes and adding Orbit to Legacy SD x710 network.
The above example is the configuration for the SD COM2 Port, which is the default data port.
By default, the communications port is set to Talk on VRC-1 and Listen to VRC-1. This being the default configuration means all SD radios will talk on the same VRC-1 unless changed. The Listen to means they will listen to only VRC-1 unless changed.
All Orbit LN radios automatically present a virtual serial port called “LnRadio-serial”. Similar to the SD, the ID represents the VRC number and Listen on All can be true or false, or specified by ID.
Unlike the SD, the Orbits VRC is configured "LnRadio-serial" but not assigned to the communications port. Additional VRCs can be added by using the Add button but remember only 1 is available in backwards compatibility operation "Transparent-serial" mode.
Virtual Radio Channels (VRCs) - Serial Port Setup
Unlike the SD, the Orbits communication port is not already assigned and we must create the link between our default "LNradio-serial" VRC to the communication port of the Orbit.
To do so, navigate to Services - Serial - Basic Config:
Then on the Pass-Through sub menu choose Add.
For Port 1 choose COM1 and for Port 2 Choose the "LnRadio-Serial"
It's really that simple to configure serial for backwards compatibility mode. It should also be noted this works for Native Orbit operation as well. There's only one downside, when polling serial data via transparent-serial on the GE MDS Orbit in Native operation, it must be done through an Access point, there's no remote polling.
This setup the link between the Communication port and our VRC but we still need to configure our Serial port parameters.
Here is an example of a common port setup and serial port buffers which we'll review more in later sections
Serial Compatibility
At this point in your migration most of the legacy serial hardware handshaking functions should have already been removed.
If you have already confirmed this, or know for certain only TX, RX, Ground are being used on serial you may skip this entire section by clicking here.
In some cases, RTS and CTS may still be in use and or configured depending on the PLC requirements. It's recommended these be turned off completely as they will now be a ignored or a hindrance, but testing is always recommended.
More information on legacy serial mechanics can be found here: Check out Part 1 here.
Here are a few examples of PLC configurations that allow for the enabling or disabling of CTS/RTS serial controls.
The image below is from the M241 Modicom hardware guide showing the serial pin-outs and looping of CTS and RTS as suggested in Part 1. If the device can't have this mechanism turned off this is the workaround.
Alternatively, below is an example of Allen-Bradley DF-1 setup reflecting DTR and RTS controls and the devices ability to disable.
Let's briefly review what these setting mean.
RTS Control:
Enabled: RTS signal is always on, indicating the device is ready to send data.
Disabled: RTS signal is off, not indicating readiness to transmit data.
Handshake: RTS signal is used in conjunction with CTS (Clear to Send) from the receiving device. Data transmission occurs only when both RTS and CTS are engaged, ensuring coordinated communication.
Toggle: RTS signal toggles on and off, indicating data packets are ready for transmission or pausing between packets.
Moving forward we want to operate the PLC with RTS Control disabled. Our GE MDS radios utilize more sophisticated protocols and can manage data flow and error detection without the need for legacy hardware flow control. By removing such mechanism, we make for more reliable and simpler communication setups while also enhancing performance and compatibility moving forward.
If migrating the GE MDS Orbit or SD Series remotes into a system that is still using or might require CTS / RTS and it can't be disabled, we can enable Hardware Flow Control for compatibility operation.
Let's review and define these parameters:
To enable Hardware flow control for the purpose of CTS /RTS only, we can use 1 of 3 settings below. You may also need a Null modem adapter in some cases.
Hardware Flow Control Modes:
DCE:
CTS follows RTS after a programmable CTS delay.
If the unit’s input buffer approaches a full condition it can deassert CTS regardless of state of RTS.
CTSKEY:
Based on legacy MDS devices including TransNET and SD, the device will act similar to a DTE but will provide signaling on the CTS line instead of the RTS line.
When the first character of a transmission is ready to be sent to the serial port, the unit shall assert CTS and delay for CTS delay time expiration before outputting the first character.
After the last character of a transmission is output from the serial port, the unit shall keep CTS asserted until the expiration of CTS hold time.
CTSKEYPLUS:
The unit shall support flow control (Throttling) on the RTS pin. The device is expected to be wired via null modem to an external DCE device. The CTS line of the external DCE device drives the RTS line of the unit
Configuring a serial port, the VMIN and VTIME settings are required for use with or without HW Flow Control.
VMIN is a number describing bytes that are received from the interface.
VTIME is a delay value in milliseconds.
These parameters act together to control serial data collection and transmission for transparent-serial and terminal server operations and are described below:
In my experience the default settings of 255/100 are too high and long and instead using 10 / 10 seems to work best for most applications but depending on the message size you may need to try different setting to tune in the best timing when adding Orbit to Legacy SD x710 network.
Some protocols, such as DNP3, can generate packets larger than 255 bytes, which is Orbit’s default Vmin value for serial ports. To ensure that large packets are not truncated when they arrive via serial port, set Vmin equal to or larger than the largest expected packet.
For example, a polled TCP server that expects to receive 300-byte packets on COM1 should set COM1’s Vmin setting equal to or larger than 300.
VMIN == 0; VTIME == 0: The Com port will continuously read to see if a byte if data is available and process each byte.
NOTE While this is a valid mode in most cases causes a high processing load on the device that may impact performance of other operations of the device.
VMIN > 0; VTIME == 0: The com port waits to process data until at least VMIN bytes of serial data are received.
VMIN == 0; VTIME > 0: If serial data is received, the Com port will continuously read the number of bytes available until VTIME has elapsed then process the data.
VMIN > 0; VTIME > 0: Once an initial byte of input becomes available the Com port waits until the MIN bytes have been read, or when the inter-byte timeout expires. The timer is restarted after each further byte is received and because the timer is started only after the initial byte is received, at least one byte will be read.
Om the SD series it's recommended to use firmware 6.4.9 to gain access to X170 and Transparent mode communication port buffers show below. You can download firmware for the SD series here.
Similar to the Orbit these buffers manage the serial data out the port. Once again, a setting of 10 is the sweet spot for most devices.
Serial and Radio Statistics
When testing device communications, we can use the serial port and Radio Interface statistics can help us to better understand our data and where it might be having problems.
Let's review communication port statistics on the SD and Orbit radios.
On the SD Series to view serial port statistics we need to navigate to:
Maintenance & Status - Performance - I/O Statistics.
We need to select the COM2 module using the dropdown. Then click Set Module to active. Set a refresh time by clicking Auto to ensure the information updates. In the example below we have an SD radio being polled. COM2 RX is the received serial data into the SD Radio. Since there is no answer, we are not Transmitting any out.
follow the flow of data from our SD to our Orbit Remote. In this instance I had an incorrect baud configurated on my remote device which was preventing the correct data from responding. Until that was corrected the data flowed from the SD over the VRC onto Port-2 of the Orbit VRC LnSerial Radio port. This is linked to COM1 reflected on Port-1,
We polled the COM2 port of the SD which went over our VRC to the Orbit Remote and out it's COM1 Port.
I corrected my baud misconfiguration and then wa-la, I had working data and polling.
The Green circle below shows the return path for our data and is our indication we have working communications. Let's continue on our flow of traffic analogy. Previously, our data came in from the SD on our Port-2 (VRC) and then out Port-1 COM1, then to our end device.
That device responded which was received on our Port-1 RX port. Then our buffers Vmin/Vtime came into play before transmitting back on our TX Port-2 of the VRC.
If the Vmin/Vtime buffers are not correct or don't match the data being transmitted, then problems could still occur in the timing or delivery of our serial messages even when passing data.
By changing my Vmin/Vtime from 10/10 to 250/0 I was able to break polling. That's because my message was very small at 8 bytes, so waiting for 250 bytes to be received before transmitting prevented communications.
Here's a brief video on the serial port, Pass-through, and Serial Status review.
Serial Cable Adaption and Retrofitting
When migrating up from an SD to Orbit or both overtime you can in many cases simply adapt the previous cable. While this isn't recommended as a long-term solution it is helpful in the initial testing and proof of concept.
In this section we'll cover how you can adapt your existing cables to work with the newer devices.
The above image shows an X710 station being retrofitted to an SD Series Radio. In this case we can simply take a straight-thru serial cable with a DB25-Female to DB9-Male and adapt our existing DB25 cable right into the SD2 COM2 data port. These 1-foot DB25 to DB9 cables are becoming more difficult to find so in this case we had to use gender benders.
Continuing our analogy, let's assume this station is now being retrofitted to an Orbit Remote. We can now take our previous DB9-Male adapter cable and connect it directly into the GE Orbits serial adapter. This DB9 to RJ-45 adaptor will allow us to take a standard straight-through Patch able to connect into the GE Orbit RJ-45 Style serial port.
The DB9 to RJ-45 adaptor is provided with every purchase. GE is now including the power connectors inside the same bag with the adaptor so don't throw these out!
This works in most instances, unless CTS/RTS are involved and in those rare cases the need for a null modem may also be required. It's always good to bring a Null modem adaptor with you when performing a retrofit test.
I hope this helps and thank you for visiting and for choosing GE MDS, now GE Vernova!
Last update on: 3/3/2024