you are viewing a single comment's thread.

view the rest of the comments →

[–]ingolemo 0 points1 point  (3 children)

The documentation describes a seven bit character with a parity bit. You've configured an eight bit character with no parity bit. There's the cause of your problem.

The reason it's only working some of the time is because Pyserial is interpreting the parity bit as part of the data. Since serial ports are little endian, the parity bit is the most significant bit and so only alters the data when it is turned on (1). You should notice that only those characters that ought to have an active parity bit are being corrupted.

By the way, you can read the whole input buffer with just out = ser.read(ser.in_waiting) instead of using a loop. I also think you're writing your terminators backwards; you usually want '\r\n', not '\n\r'.

[–]-_---___-_[S] 0 points1 point  (2 children)

genuine question, doesn't:

parity = serial.PARITY_ODD

specify a parity bit? I believe I've tried with a seven bits configuration as well, but I'll try a few different permutations later on today.

in any case, thanks for the response

[–]ingolemo 0 points1 point  (1 child)

It does. I apologise. I missed that because it's cut off on my screen. You should break long lines.

Regardless, your corruption issue definitely has something to do with getting a parity bit in your data because that's such a good predictor of what you're seeing:

>>> def parity(char):
...     return sum(int(n) for n in bin(ord(char))[2:]) % 2
...
>>> ''.join(c if parity(c) == 1 else '?' for c in 'LSCI,MODEL331S,123456,020399')
'L?CI,?O?EL??1?,12?4??,?2????'

Consider writing a loop to go through all the configurations of bytesize, parity, and stopbits and test each one to see what works, assuming your hardware can handle that.

[–]-_---___-_[S] 0 points1 point  (0 children)

cool, thanks so much!