I'm using pyserial with most of my project and I often have communication issue. The issues are reported by reading the echo when sending UART message. Sometimes some characters are missing. Below the command that I used to investigate the communication issue: TX: rgb green RX: rgb gree The 'n' is missing in the RX (target echo) And below is the frames captured with scope: Framing error for characters 'n' After this command, the target return the echo with the charaters 'n' missing And below is the same command without error: Frame without issue captured by scope After this command, the target return the echo with all the characters and proccessed the command. Following captures, timing are not equivalent for last low state on 'n' (0x6E) characters. And I wonder what could cause this (and if it's really the point for stop bit issue). I'm using a script that run forever and send uart command to the target (with 0.2s delay between each command). Sometimes it can run for a long time without issues and sometimes communication occurs quickly. As the issue is at the output of the serial converter, I assume that the device is not in cause. This issue occurs with different serial converter and with different target. Note: Here are the environment details: Windows 10 Python 3.11.9 Pyserial 3.5 (installed with pip on venv) port settings: self.port = serial.Serial(self.com_port, baudrate=115200, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE) USB/serial converter used is ESP Programmer from ESPRESSIF EDIT 01: Please find below the code used to send and readback data: def try_send_command(self, command, error_echo_single_char): self.flush_input() if type(command) is str: print(f"TX: {command}") # Write command letter by letter to avoid comm issue with ESP32 (and ESP Prog) for _ in command: self.port.write(_.encode()) if error_echo_single_char: # Check if single character is correctly sent readback_char = self.port.read().decode() print(f"Readback single char: {readback_char}") if not _ == readback_char: print(f"error while redback char: TX:{_} RX:{readback_char}") raise ESP32CommTest.ESP32CommTestException("Echo issue with single char. Command not proccessed !") self.port.write("\n\r".encode()) elif type(command) is bytes: print(f"TX: {command}") self.port.write(command) def send_command(self, command, check_echo=True, timeout=None, try_nb=None, end_flags=[], error_flag=[], error_echo_single_char=False): while try_nb > 0: try: self.try_send_command(command=command, error_echo_single_char=error_echo_single_char) if check_echo: lines = self.read_lines(command, timeout=timeout, end_flags=end_flags, error_flags=error_flag) else: lines = self.read_lines(timeout=timeout, end_flags=end_flags, error_flags=error_flag) if self.config.get("uart_esp32_retry_on_fail", True) and len(error_flag) > 0: for l in lines: if any([f in l for f in error_flag]): raise ESP32CommTest.ESP32CommTestException("Test communication error !") return lines except ESP32CommTest.ESP32CommTestException as ex: print(str(ex)) if error_echo_single_char: raise ex raise ex try_nb -= 1 time.sleep(self.config.get("delay_before_retry_send_command", 2)) #End while raise ESP32CommTest.ESP32CommTestException("Test communication command failed !") And here is the loop to send UART data: def set_rgb(self, color:str=Literal["red", "green", "blue", "white", "off"], timeout:int=None) -> list: """ Change LED color in order to perform measure for each segment using Feasa module aram color: Select the color to be set (or clear with "off") :return: List of output frames receives """ return self.send_command(command=f"rgb {color}", timeout=timeout, end_flags=["OK"], error_flag=["UNKNOWN_COLOR", "UNKNOWN_COMMAND"], check_echo=True, error_echo_single_char=False) def send_cmd_until_fail(self): color = ["red", "green", "blue"] i = 0 c = 0 while True: print(f"Command n°: {i}") self.set_rgb(color[c], timeout=2) time.sleep(0.2) c += 1 if c > 2: c = 0 i += 1 If anyone already has this behavior, or if you have some advises to avoid this problems it would be great. Best regards, Antoine PS: Below the different test performed: Different OS Updating drivers Using different converter Windows can badly manage the COM port that's why I tried with Linux computer and with new driver on windows but still got the same issue Continue reading...