Teardown: Moxa NPort 5110 Serial Device Server

As someone with a lot of serial devices, and various retro-inspired experiments, problems with serial co-existence are everyday life. Things like certain USB to serial adapters which don’t put out proper RS-232 levels and only put out TTL, or drivers for those adapters which only support certain modes making them inoperable with dosbox, timing problems which cause buffer underrun/overrun, those only supporting modern API-access to the ports and not “hardware” style base-address/IRQ access or not being operable on certain Windows versions. There is a plethora of causes for incompatibility.

As a result, different applications often have different solutions to these coexistence issues, and one of the main options for industrial users is to opt for a serial device server such as those from Lantronix. I’ve seen them used to interface old building management components to industrial PLCs to networks, and they seem to be the workhorse solution to serial problems.

The one problem? They’re very expensive. But so is the Moxa NPort 5110, a single port RS-232 device server with most of the features that you would find on the Lantronix (close to AU$200). I was lucky enough to luck-out on one on eBay where I won an auction at a very good price, so now I’ve got one to play with!

The Device

2016030311142595 2016030311142596

The device was nothing too flashy, in this case, it had physical damage to one side, but it was mainly cosmetic. The device itself is in an aluminium shell, likely for industrial applications, and has a default IP of 192.168.127.254. Three status LEDs are provided at the top, Ready which is also used as a locater LED, Link which indicates Ethernet link status and Tx/Rx which indicates serial traffic.

2016030311142597

There is the classic RJ45 connection for your network, up to 100Mbit/s (not that the bandwidth is necessary), a reset push button and a DC barrel jack (2.1mm I believe) with an input voltage range of 12-48v DC with positive tip. As it’s not picky with power, you can really run it from almost anything. No power supply was included so I used an external hard drive adapter I had in spare.

2016030311142598

The other end has a serial port, DB-9 (or DE-9) style.

Teardown

2016030311132594

Undoing two screws on the side is all that’s needed to lift the cover off the base.

2016030311092591

The main board is rather compact and has the power circuitry in the bottom left, a main IC labelled MOXA MX-1610C which MOXA claim to be their own processor chip (although I suspect it really could be just a remarked chip that is used in print servers and other applications – e.g. an AMD Am80186, something Realtek MIPS/ARM, or something else entirely).

2016030311102592

Under the label is the ST flash which contains the firmware and a Realtek RTL8201CP PHYceiver. This implies that the MOXA MX-1610C has no integrated PHY, but likely has a MAC.

2016030311112593

The underside has ESMT DRAM, a ZT3243 which is likely to be a MAX3243 RS-232 multi-channel transceiver clone, and a TI LC14A Hex Schmitt-Trigger inverter.

Software

There is a bewildering amount of software available for download from MOXA, but you really only need two of them. The first is DSU2 which helps you administer your devices.

dsu2-find

DSU2 helps you search for devices, using network broadcasts of some sort.

dsu2-list

Once found, you can perform firmware upgrades on the device (as I did) and assign a fixed IP address.

From there, administration can be done using the Web Config as well just by pointing your web browser to the IP address.

web-based-config-1

There are quire a few settings, as you would expect, so I won’t cover them all. Of course, you can change the network name, password for logging in, SNMP, and firewall the device to accept connections from certain IPs as standard features.

port-modes

A wide array of operating modes are provided. Real COM Mode allows for a driver to basically provide a virtual COM port interface over Ethernet which works just like a real COM port as best as it can. TCP server and client mode are available for where applications are written with direct socket control in mind, whereas UDP is for “any device” control. Pair connection modes seem to target null-modem cable usage, whereas Ethernet Modem mode makes the units react to AT commands as if they were modems. Reverse Telnet Mode seems to be used to establish a connection to another telnet server (e.g. dumb terminal access).

packing-settings

You do get to choose some options such as packing or delimiters to make sending more efficient or to minimise latency. By default, with this setting, it seems every single character causes a TCP packet to be emitted.

The other piece of software you need is the Driver Manager. Installing this also lets you search for NPorts, but now you can allocate them real COM port addresses and have the drivers installed to talk to the NPort. It seems that port 950 and 966 are used for real COM port mode.

drvmgr-list

Within this software is the ability to configure some transmit parameters from the PC side.

drvmgr-advmodes

Fast flush can be disabled to force flushes to pass data through to the endpoint to try improving the timing behaviour of the adapter. Encryption also seems to be supported, although its effectiveness hasn’t been tested.

drvmgr-encrypt

There seems also to be an option for binding the outputs to certain interfaces so it doesn’t deal with NPort adapters on other networks.

drvmgr-interfacemap

In my experience, for basic usage, it was no problem at all. I could even have VMs with bridged network connections work with serial devices across the network with reasonable timing and no major flow control issues. A trying test is to send a fax from a VM, and even though it did succeed in the end, the timing wasn’t quite as perfect as with a USB to serial cable where USB is passed through to the VM. At least it wasn’t a crashing failure like passing serial through to the VM entirely.

I also observed that baud rate changes also worked well, and higher baud rates than 115200bps are supported by the unit. In unencrypted mode, aside from adding a few padding characters (maybe liveliness checks) into the data stream, packet captures do clearly show the serial data being transmitted or received, making it semi-useful for analyzing what is happening to a serial device.

Conclusion

I definitely picked up a bargain on this one, and while its’ internals look simple, the software seems to do very well at its job and it manages most needs just as I would expect it to. As a result, it’s now possible to deal with my serial devices over a VPN/SSH tunnel or even over wireless which is pretty cool as Ethernet networks connections are among one of the things we always make sure our machines have.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Telecommunications and tagged , , . Bookmark the permalink.

Error: Comment is Missing!