You may want to try the latest driver candidate:
An actual 0xff in the data is reported as 0xff 0xff, so an 0xff
followed by an 0xff is in fact an 0xff of data.
If IGNBRK is set, a break condition detected on input is ignored that is, not put on the input queue and therefore not read by any process.
If IGNBRK is not set and BRKINT is set, the break condition will flush the input and output queues, and if the terminal is the controlling terminal of a foreground process group, the break condition will generate a single SIGINT signal to that foreground process group. If neither IGNBRK nor BRKINT is set, a break condition is read as a single 0x00, or if PARMRK is set, as 0xff 0x00 0x00.
If IGNPAR is set, a byte with a framing or parity error (other than
break) is ignored.
If PARMRK is set, and IGNPAR is not set, a byte with a framing or parity error (other than break) is given to the application as the three-byte sequence 0xff 0x00 X, where 0xff 0x00 is a two-byte flag preceding each sequence and X is the data of the byte received in error. To avoid ambiguity in this case, if ISTRIP is not set, a valid byte of 0xff is given to the application as 0xff 0xff. If neither PARMRK nor IGNPAR is set, a framing or parity error (other than break) is given to the application as a single byte 0x00."
If you continue to experience problems with this, I recommend obtaing an strace and contacting Digi Tech. Support.