pyserial 2.7, python 3.3, sending carriage returns

Question

I have been attempting to have a Raspberry Pi interface with an embedded circuit using the UART interface. The UART interface on the Pi is in working order and I can receive messages from the circuit, though I am having trouble sending messages to the circuit.

I am using Python 3.3 with Pyserial 2.7. Sample code is available, though it uses Pyserial 2.6. When used with older versions of Python (<2.6), ser.write() accepts strings, but now it only accepts bytearrays.

The problem I am having is in sending carriage returns... The old code supposedly functioned with just:

ser.write("L1\r")

but now I am using the following:

ser.write(bytearray("L1\r", "ascii"))

The circuit does not respond to the command. I think the resultant message is sending \r as two individual characters rather than a carriage return. How would I make sure my code is outputting commands appended with carriage returns?

Notes: I can reasonably expect that the circuit is working well and that the Pi's UART interface is functional. The circuit is an Atlas Scientific Dissolved Oxygen Circuit. The circuit's documentation demands that commands be written in the form l1<cr> or L1<CR>.

Relevant links:

1. Old sample code (https://www.atlas-scientific.com/_files/code/pi_sample_code.pdf)

2. Documentation describing write method (http://pyserial.sourceforge.net/pyserial_api.html#classes)

Thanks in advance!

EDIT: Netch makes a strong point: ser.write(b'L1\r') works and is much cleaner. Both methods, however, ARE sending a correct '\r' sequence.. The problem is that the circuit still does not regard L1\r as a valid command. At this point, I think my issue may be some property of my serial port.

My port is declared as such:

ser = serial.Serial(
   port = '/dev/ttyAMA0',
   baudrate = 38400,
   bytesize = serial.EIGHTBITS,
   parity = serial.PARITY_NONE,
   stopbits = serial.STOPBITS_ONE,
   timeout = 1
)

This port declaration is done with accordance to the circuit's datasheet (I can only post two links unfortunately :( Google brings it up easily).

Answer 1

[EDIT] For future viewers, I just want to point out that for the newer EZO version of the circuit, the command is "L,1" or really "L,1\r" [/EDIT]

This is a known issue with the circuit. The first read after power up will fail. instead of prepending a \r with every read, just send a bogus command with \r included and then reset input buffer

ser.write('bogus\r'.encode()) # EDIT: had to add .encode() to get it to work. see https://stackoverflow.com/questions/22275079/pyserial-write-wont-take-my-string
ser.flushInput() # or for  pyserial 3+ ser.reset_input_buffer()
#now do your thing

EDIT: had to add .encode() to get it to work. see pySerial write() won't take my string

After powering up the EZO™ class circuit when it is in UART mode the first command sent to it will comeback as an error. This is because the UART buffer will show that it has received a character during power up. Simply send a blank character to the pH circuit after it is powered up, this will clear the buffer.

Answer 2

I have found a solution!! Unfortunately, I cannot explain how it works. Perhaps anyone reading this could elaborate on it and give a proper explanation!

The circuit's documentation demands commands be in the form CMD<CR>. Indeed, sample code provided by the manufacturer sends the L1 command through pyserial as ser.write("L1\r").

Now that ser.write() demands bytes however, I have found that ser.write(b'L1\r') does not work.. The command is received though it is somehow unknown to the circuit.

After toying around for a while, I have discovered that ser.write(b'\rL1\r') works! The debugging led flashes red once before processing the command. It seems like I just need to send a 'dummy command' to get the circuit's attention!

I am not sure if this is the fault of pyserial, the circuit, or my own ignorance. If anyone can shed some light on this, it would be much appreciated! :D

I have linked here the circuits documentation in case anyone is interested. https://www.atlas-scientific.com/_files/_datasheets/_circuit/DO_Circuit_5.0.pdf