4

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
16
  • Please post the output of stty -F /dev/ttyUSB0 -a and also please use ser.read(Bcount) preferably to ser.readline since ser.read fits better to binary data exchanges ( vs ASCII only)
    – MC68020
    May 4 at 2:59
  • Hi thanks for the reply, I posted the output above. Also I have already tried using ser.read() but found that the data remains the same as if I used ser.readline(), but I will change it. May 4 at 4:17
  • 1
    It's much easier to compare the data received when you separate the bytes with a space and have Windows & Linux outputs on adjacent lines in your question, vertically aligned
    – roaima
    May 4 at 6:14
  • 1
    If you're expecting even parity how can you receive valid byte values 0b and cb?
    – roaima
    May 4 at 6:14
  • 1
    @roaima Sorry about the formatting I'll remember for next time. I just assumed there was only 1 stopbit, that information was never provided. However, even when I specify/change the number of stop bits in the serial class call (i.e. serial.Serial('/dev/ttyUSB0', ... , stopbits = serial.STOPBITS_TWO)) to 1, 1.5 or 2 the output of the program remains the same May 4 at 11:21

1 Answer 1

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.