Is there a difference in serial data formatting between Linux and Windows?

Question

I am trying to read in serial data from an RS-485 RFID reader using a RS-485 to USB converter found here and a python script running Pyserial.

The issue I'm facing is that when I print out what is read, the right amount but incorrect bytes are displayed in my python terminal on Linux running Ubuntu 18.04.6 LTS. However when I test it on Windows the correct bytes are displayed. I use the exact same code, same hardware (other than OS), and the same reader settings.

My code for Windows:

import serial
import time

ser = serial.Serial('COM6', 19200, timeout = 2, parity = serial.PARITY_EVEN)
time.sleep(2)

while True:
    while(ser.in_waiting > 0):
        x = (ser.readline().hex())
        print(x)
        

Windows output:

020308fe10807c000bcbae9b9e

My code for Linux:

import serial
import time

ser = serial.Serial('/dev/ttyUSB0', 19200, timeout = 2, parity = serial.PARITY_EVEN)
time.sleep(2)

while True:
    while(ser.in_waiting > 0):
        x = (ser.readline().hex())
        print(x)

Linux output:

0203081e1a001c030b0b1d131e

So in both scenarios I get 13 bytes (2 digits per byte), which I converted into a string. The only data that I care about and 100% know should be the same is the RFID tag data which are bytes 8 to and including 12 (000bcbae9b on the windows output). However on the Linux output the data is different (030b0b1d13).

Note: I know that bytes 8 to 12 (not counting from 0) correspond to my tag data because after converting the windows hex value to decimal, the number matches my tag and also the datasheet says.

So does anyone have any idea of why the data is different? Might it be because the systems see/format or interpret the data differently?

Thanks for the help!

The output of stty -F /dev/ttyUSB0 -a

onecup@inventory03:~$ stty -F /dev/ttyUSB0 -a
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0;
parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke -flusho -extproc

For easier visual reference here are the two byte streams again, but spaced and aligned:

Byte nr:  1  2  3  4  5  6  7  8  9 10 11 12 13
Windows: 02 03 08 fe 10 80 7c 00 0b cb ae 9b 9e
Linux:   02 03 08 1e 1a 00 1c 03 0b 0b 1d 13 1e

For additional reference here is the output of a different RFID tag. (bytes 8 to 12 are still the only ones I care about and windows is correct where linux is wrong):

Byte nr:  1  2  3  4  5  6  7  8  9 10 11 12 13
Windows: 02 03 08 fe 2e 80 7c 00 0b bb 9a 80 4b
Linux:   02 03 08 1e 16 00 1c 03 0b 17 1a 01 09

Answer 1

So after more looking I found that it was a problem with the driver. The solution was to update or install a patched version of the CH341 driver.

Instructions found here.

I don't fully understand what was wrong but according to this post here, there might have been an issue with the parity checking of the USB to RS485 converter. Thanks for all the help!

Note: For my system the solution in the second link gave errors and didn't work.