This is a known issue and has to do with the uart chip found in the Portserver TS16.
The first part of the problem is one of autodetection. Whenever we talk to a device that auto-detects its parameters, there is no way for the device autodetecting to determine the number of stop bits because stop bits are the same as the idle condition and not meant to be interpreted as additional stop bits.
The reason why your autodetecting serial device works with the com port is because PC serial ports are of the 16x50 UART family. These UARTs generate two stop bits if requested but will only ever check for a single stop bit. If more bits are in the idle state, that's fine but not checked for. The Portserver TS16's uart however, when told that the serial settings are for two stop bits actually checks that there is a minimum idle time for two stop bits.
Thus, when an autodetecting device determines the port settings it invariably chooses one stop bit and can receive just fine from anything. However, since it will only place a single stop bit after any transmission on its part, any device that is looking for two stop bits will instead oftentimes see a start bit instead which will generate errors (or in this case garbage).