GE MDS Orbit - Using DF1 - Can't make it work.

I bought these things a year ago and have yet to make them work. We have to use SAF because of topology and nothing we or GE can do makes these work. We have been personally responsible for several of the last couple firmware revisions because SAF wouldn't work over simplex.
I'm just venting mostly - I don't expect anyone here can help, but it would be nice to hear from anyone that actually has these working using the Allen Bradley DF1 protocol especially if they had to jump through some hoops that we haven't thought of.
 
Did you get this resolved? How many remotes are on the system? I'm not an AB guy but am I correct in saying DF1 is serial protocol? Update to the latest firmware (9.0.3 now) and do transparent-serial to Com1.

The Orbit can do up-to 3 VRC (Virtual radio Channels) now called Transparent-serial this is similar to UDP but less overhead. This should be a simple setup but I understand you frustration and sorry you to hear about your troubles.
 
Yes, DF1 is a half duplex protocol with embedded addressing. The protocol seems to be the problem, ethernet devices on these radios work fine. Looking at the traces, it looks like responses get intermingled even though I only poll one endpoint at at time. Its a weird situation made worse by age of the protocol, the 5 conversation requirement over a slow bandwidth and that the folks that could really engage in the problem are all retired.

Oh and I forgot to add that SAF will not work with this protocol. It's been a bad time for serial comms.
 
Are you polling via serial into the AP?
Is it a Master PLC or SCADA doing the polling?
Are you using DSR, CTS, RTS pins?

Are you open with sharing a redacted configuration of serial port setup. I'm with BCI, we are a GE MDS industial communication distributor covering Fl, Al, MS, NC, SC, TN.

I would think using transparent-serial on remote and AP should work, have you tired this setup before?

We added serial dump and TCP dump with the ability to export captures into the Orbit, is that what your looking at?

If you can get transparent-serial working it should work over the SNF but there's always challenge with these. If they are working with ethernet now, I think we can help you.
 
I love your enthusiasm, I have worn out my integrator, both Brett and Tyler at GE, Prosoft, a contractor and anyone else that comes into contact with these things.
These Orbits are new to GE and are nothing like the SD series in their ability to handle DF1 traffic. There is no ENI equivalent option for these and no interest in creating one. They are also glitchy as hell when configuring them leaving config bits behind when configs are uploaded. Even showed support the GUI with the NTP box checked and the CLI report where NTP was shown to be false. There have been many of these kinds of things. I'm trying to stick with CLI going forward, it seem to be more reliable.

I do find it so very odd that I have it working reasonable well on frequency A at a different hilltop with identical pieces, but the main hilltop at Freq B will not work well no matter what I try. Ethernet works from both so on the surface it's not an RF issue.

The Comm path is as follows: A/B L-81 PLC -> Ethernet network to Hilltop -> Prosoft PLX51 -> 3 wire serial -> Orbit MCR Radio -> RF -> Orbit MCR Radio -> 1785-KE serial to DH+ module/ PLC5.
Complex maybe, but worked on a different radio system that understands DF1 AND works reasonably well from the other hilltop albeit with fewer clients.

Started off using "serial passthrough" (I think "transparent serial" is a term from a different radio model maybe?) And still use that mode on the working Hilltop. Attempted to use "Terminal Server" on the troublesome one in an effort to "tunnel" the serial traffic better but it made no difference and none of the experts believe there would be.

I'm pretty sure I killed serial comms completely recently and I don't yet know how but no great loss at the moment.

Store N Forward is a dead issue with me now. I changed the radios into simplex and split the workload onto 2 hilltops instead of hopping over them with a duplex system that was even worse.

I would be happy to share the config, there is not much to it, what do you want to see exactly?
 
The Orbit has glitches, but in my opinion it’s as open source and transparent as propriety can get. Their firmware "known errata" section is always an interesting read. I’m not an engineer and I don’t know DH+ and serial very well but I’m going to forward this around internally next week.

You mentioned it working on different radio, was that maybe Inets or were you using SD series prior to Orbits
Did you migrate using Orbits in compatibility mode or just replace out-right?
Are you using Master stations or just standard remotes for the Access points?
  • MastersStations can offer continuous 10 Watts (remotes are 10 watts but not continuous) MasterStations also have additional filtering.

From what I’ve collected:
  • You have two P2MP networks using simplex licensed frequencies.
  • Both hilltops are using the same hardware and are setup with seemingly identical geography.
  • Hilltop A is working, while Hilltop B is not ATM or is poor and troubled.
  • Serial pass-though is working well on Hilltop A but it has fewer remotes then B.
    • How many remotes on A verses B?
  • Hilltop B is having it’s messages get intermingled.
  • Ethernet Traffic is passing so it appears to not be an RF Issue.
    • How confident in the ethernet links are you? Have you performed any testing like ping fail rate etc?
    • What other ethernet devices or traffic do you have, if any? HMI, Routers, Managed switches.
  • “The conversation requirement over a slow bandwidth”
    • Are you seeing excessive ARP and Keep-lives traffic?
    • Are you using any non-default firewall policies or QOS (Quality of service) policies?

You are not using serial buffering in orbit does 3 wires meaning GND, TX, RX only?
  • Is RTS/CTS Jumpered at port or just not used.

On the newer firmware for the Ln radio, they added Advanced and Advanced polling operations.
  • Are you using Standard or one of these new modes?
    • I’d also recommend using Advanced mode over Standard.
  • Are the remotes in Auto or fixed baud rates?
    • For LN I find Auto works very well.
Since A is working, I might do a NX capture on it’s LN interface and exported for viewing in Wireshark.
  • Check the avg. packet size using and adjust your Concatenation which is 600 by default, maybe try adjusting to 300 or just over this average size. (Ideally lower not higher)
  • The theory here is if we are getting a lot of errors or retires the radio will do less packet concatenation thus decreasing retries and errors. ( Concat is cramming smaller packets into a larger single packet)
I believe Advance mode enables FEC by default, but I’d try and look into FEC and test different options.

Firmware after 7.6.5 (9.0.3) has been working well for me, you can add up-steam and TX Error/ drops.
  • Instead of a script seeing what the overall network health looks like might make more since at the moment.

Some other things to consider and I’m sure you have are things like aged or overloaded power supplies, they will cause a lot of issues with RF and can cause GUI issues and RF data transmit issues. I’ve also seen excessive power or RF prevent traffic while showing a seemingly good link.

I'm on Linkedin if you would rather connect via Phone sometime in the future; I have a pair of LN2 i could setup for a live demo if it would benefit you at all.
 
Their firmware "known errata" section is always an interesting read
Yes it is... more of a "what did they break this time?... apparently the ability to DL captures through the GUI in 9.0.3... seriously GE ??

You mentioned it working on different radio, was that maybe Inets or were you using SD series prior to Orbits
Did you migrate using Orbits in compatibility mode or just replace out-right?
Are you using Master stations or just standard remotes for the Access points?

Radios were (well still are since I can't get these to work yet) Esteem 192C, still running in parallel. No Master station yet... not till I can count on these working but that is the plan. The esteems can run Fdx at both ends and they work out th e handshaking themselves.

How confident in the ethernet links are you? Have you performed any testing like ping fail rate etc?
pretty confident. I can SSH into them easily, ping times are good when I'm not trying to access a remote stations GUI. 200mhz band is just too slow to run a GUI over and their GUI is poorly constructed for over the air application.

There was some STP traffic from the microwaves that carry the network to the hill but I think I have those filtered out at the managed switch now. Same with ARP.
no firewall or QOS in place yet either. Capturing of ethernet traffic over LnRadio shows little extraneous traffic last time I looked at it. I haven't captured since filtering the switch port.


“The conversation requirement over a slow bandwidth”
each DF1 message consists of a 5 conversation handshake in the form of: Hello#2, Yes?, I need this string of registers, OK here they are, thank you.
It looked like the radio sees a response from for example, station #3 while waiting for station #10's response.... like the Internet Explorer memes if you are familiar with them.


You are not using serial buffering in orbit does 3 wires meaning GND, TX, RX only?
Is RTS/CTS Jumpered at port or just
not used.
Tx Rx and Gnd only. Remainder are properly jumpered. I think the MDS can use a couple of them but I have never been advised to attempt that.

using Advanced mode (not Advanced Polling). Version 8.3, havent updated to 9 yet as I dont wasn to lose my ability to gather captures through the GUI. CLI for that requires TFTP and IT balks when I set one of those up.

All fixed baud rates, these are set with Dip switches at the remote endpoints at 19,200.

I will look into your other suggestions this week and post back.
Are the LN2 you have 200mhz? I would imagine that the 900mhz versions are better at this due to better bandwidth and that's all my integrators have so we are comparing Apples and Oranges. I can even send you the configs from each so you can see them on your end if you like.

I have far too many irons in the fire these days and I switch between them so I may not look at radios for a week, but if you have something to suggest I will drop what I am doing as soon as I can.
 
For anyone that made it this far, the root cause was the protocol translator ahead of the radio. It would mangle the TNS (Sequence number of the packets) and reassemble them in a different order making a reply appear to come from a different device ID than the message was intended for... so the data was deemed invalid and a TCP reset was issued..So, not a Radio problem at all.
 
Top