python: Trouble with connecting via pyserial/FTDIfriend

[Rob]

I’m having a hard time issuing commands to the a5 using python and an FTDI friend.

For example, this code should make the clock read HELLO:

import serial
ser = serial.Serial(‘<USB DEVICE>’, 19200)
header = chr(0xFF)
ser.write(header)
ser.write(“A0”)
ser.write(“HELLO”)
ser.write(” “)

I have to run it three times in order for it to have any affect on the clock, and the the display changes to something more like HELlA, not HELLO.

I’m fairly certain this is an encoding problem at play, but it has stumped me. I’m on a M1 macbook, using python2.7.

Any suggestions would be much appreciated!

[Windell Oskay]

If it’s working *sometimes* or partially, then I’d suspect an electronics or reset issue first.

Are things acting stable and reliable otherwise?

If you have auto-reset enabled, you may be resetting the device when you open communication– I don’t see a delay there, so make sure that you’re waiting a moment for reset to complete before trying to send data.

[Rob]

Thanks for the reply.
Things are perfectly stable otherwise. In fact, I’m able to interface with the clock exactly as expected using processing. It’s only once I tried to port my work over to python that I encountered this problem.

There’s no reset happening from what I can tell, and I’ve tried adding in a delay, but this hasn’t had any affect.

I’m running the code using the pycharm IDE in a virtual python2.7 environment (because I was having a hard time getting pyserial to play nice with my local python3 runtime). Do you think my environment could somehow be to blame?

[Rob]

Actually scratch that, once I added more 500ms delays between each .write() method, I am able to get it to work reliably as expected.

Do you understand why the timing is so much more touchy in python than it is in processing?

Cheers, and thanks for your help!

[Windell Oskay]

On an M1, I would say (to start with) that any pyserial version less than 3.5 is absolutely, positively unreliable, and I personally would not even try on 2.7. The IDE and virtual environment shouldn’t cause any issues so far as I know off hand.

That you are able to communicate on Processing does very much suggest that this is a software-specific issue.

In Python3, the following works reliably for me:

import serial
import time
ser = serial.Serial("/dev/cu.usbserial-FTE55RTK", baudrate=19200)
time.sleep(3)
header = b'\xFF'
command = b'A0'
data = b'ABCDE'
space = b' '
ser.write(header + command + data + space)
time.sleep(10)
ser.close()


[Windell Oskay]

I don’t think that you need time between individual writes — my example doesn’t have them — but my script has time added for the reset after starting communication, a different word (so that HELLO WORLD isn’t confusable with the word I’m writing) and a “display” delay time after writing the text before the restart.

[Rob]

Following up for closure. After a sleeping on it, I realized my code was occasionally sending over a 3 or 4 letter word without whitespace padding to equal it all up to five characters. This meant that I was not sending over the complete 13 byte command that the clock was expecting, and thus my subsequent command was appended to the previous command. As I hadn’t been resetting the clock, this truncation was being compounded and even my simple debug code was being affected by it.

Thanks for your help (I also took your advice and got python 3.9 and pyserial2.5 running.)

Cheers!

Sample code to recreate the problem:

import serial
import time
ser = serial.Serial('/dev/cu.usbserial-AC013VIR', baudrate=19200)
time.sleep(3)
theseWordsWork = ["TRUSS", "SPIED", "WHACK", "BOGUS", "METER", "SLIDE"]
theseWordsDontWork = ["TRUSS", "SPIE", "WHAC", "BGUS", "METER", "SLIDE"]
for word in theseWordsDontWork:
    header = b'\xFF'
    command = b'A0'
    data = word.encode()
    space = b'     '
    ser.write(header + command + data + space)
    time.sleep(1)
ser.close()

[Author]

Posts