Pasquale 'sid' Fiorillo

The PySerial documentation says that if you pass the parity parameters to the __init__(), the “parity checking” feature is enabled. Easy, but it doesn’t work!

The hack is to manually set the right termios flags importing the termios library in addition to the serial lib.

The right termios input flags (c_iflag) are: PARMRK, INPCK and IGNPAR.

Here is an example:

import serial
import termios

ser = serial.Serial (....)

# Get termios settings
iflag, oflag, cflag, lflag, ispeed, ospeed, cc = termios.tcgetattr(ser)

# Enable input parity checking & parity mark with \xff\x00
iflag |= termios.PARMRK | termios.INPCK
iflag &= ~termios.IGNPAR

# Apply termios settings
termios.tcsetattr(ser, termios.TCSANOW, [iflag, oflag, cflag, lflag, ispeed, ospeed, cc])

The parity error will reported as 0xFF, 0x00 prefix.

I have three USB-UART adapters, the first is a PL2303 from “Prolific Technology”, the second one is a CH340 from “QinHeng Electronics” and the other is a CP2102 from “Silicon Labs” and I tried to use them in a project involving non-standard baud-rate (1600 bps) on the serial bus.

The PL2303 and the CH340 are capable of non-standard baud-rate talking as long as a fixed parity setting (ODD, EVEN, NONE, MARK or SPACE) is used.

The CP2102 is not capable of non-standard baud-rate communication at all.

I checked with a logic analyzer and some python lines, here are the results.

The test code

import time
import serial

ser = serial.Serial(
    port='/dev/ttyUSB0',
    baudrate=1200, # 1200 or 1600
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    timeout=None
)

while True:

    ser.write(b'\x01\x02\x03\x04\x05\xFF\x00')
    time.sleep(2)

Silicon Labs CP2102 test restults

Prolific Technology PL2303 test results

QinHeng Electronics CH340 test results

How about 9-Bit framing also know as Multi-Drop Bus (MDB)?

Neither device is capable of talking on a Multi-Drop Bus.

Serial communication with 9-Bit framing (9-Bit protocol, 9 bit mode) is mainly used to identify the address byte within messages running on a RS-485/RS-232 multi-drop network.

On this type of network one “master” controls one or many “slaves”, the 9th bit is used to distinguish the address from the data.

This type of protocol is not a POSIX-standard, but some devices supports the Mark/Space Parity (CMSPAR) and can use the “Parity Bit” to emulate the 9th data bit.

Acting as TX device, the UART parity settings needs to be set accordly with the type of byte to send: sending an address the parity needs to be set to “MARK” (logic 1), for the data parts the parity needs to be set to “SPACE” (logic 0).

Changing MARK to SPACE parity settings on the fly (reconfigure the UART without closing and reopening the port) is supported by PySerial, but my devices are not behaving as expected.

Acting as RX device, the value of the 9th bit can be recovered observing the parity-error. For example: settings the UART with SPACE parity, we should receive a parity-error when an “address” is received.

Unfortunately, this does not work with any of my devices via PySerial library.

Splashtop is a remote support software that enables remote computer access for IT support included in several RMM (Remote monitoring and management) like NinjaOne.

Unlike “Splashtop for Business”, “Splashtop for RMM” is not available for Linux, but you can run it with Wine adding a “st-rmm://” protocol handler to your system.

Tested with NinjaOne, Splashtop for RMM v3.4.6.1, Ubuntu 22.04 LTS with wine-7.22 (Staging).

Check this repo for all the needed: https://github.com/siddolo/splashtop-for-rmm-linux