Strange serial communication over UART

[slsimic]

Hello all.
I have a device which I need to read over serial communication. When I use plain serial terminal app to send request and receive answer everything is OK. But when I try to do it with MicroPython thru RPi2 Pico over UART I get strange results.
Serial communications is 1200bps 7E2 so UART is initialized with

uart0 = UART(0, baudrate=1200, parity=0, stop=2, bits=7, tx=Pin(12), rx=Pin(13))

but when receiving answer I get only few starting bytes OK and then garbage

b'00004360972 00\x18\x18\x18LLt\x18\x18LL&3\x13}&3\x13\x02\x02\x03\x0300\x18\x18\x18LLt\x18\x18LL&3\x13}&3\x13\x02\x02\x03\x030034119 2000000 022\x18N6\x03k'

while the expected answer should be

b'00004360972 0000000 0000000 0000000 0000000 0000000 0000000 0034119 2000000 0220928 \r'

and I get it right on Pico but when I change Parity to None.
On the other hand, when I change Parity to None in my serial terminal, I get garbage there.
I tried both, UART0 and UART1 with same results.
I don't, know if this could be MicroPython or RPI2Pico related issue.
Does anyone have similar problem with "non-standard" (other than 8N1) serial communication or have an idea what could be the problem?

[robert-hh]

I made a cross check, with sending this message with the said setting and receiving it back at the Pico, while monitoring it with two different logic analyzers. The data was received properly by the pico, and the logic analyzer showed a proper decode with 7 bits, 2 stop bits, even parity.

[peterhinch]

This looks like a slight mismatch of baudrates: the receiver is experiencing framing errors after a period. Removing the parity bit fixes it, allowing the receiver to re-synchronise on each character. I would take a bet that changing the stop bits setting to 1 would also work. Unless you're also transmitting, using 1 stop bit is valid.

If you have suitable testgear you could measure the incoming baudrate.

[slsimic]

Yes, first 14 bytes are received OK and then off-sync starts garbage, then resync and then again goes off-sync.
You're right about 1 stop bit. 7E1 gets me same, correct answer I expect.
I have no equipment to measure baud rate but I tested communications a bit more with USB/TTL serial converter and get the same results as @robert-hh
Pico <> SerialConv, 7E2 works just fine, both ways
SerialConv <> Slave, 7E2 also fine, both ways
Pico <> Slave, 7E2 works only for REQ but answer is OK only with 7N2 or 7E1

I don't get it, why the same slave device answer is interpreted differently on Pico and on serial terminal with parameters set to 7N2
Maybe it's just a problem with my slave device I try to read...

[peterhinch]

On further thought, if I'm right about this it does imply an error in the UART receiver design. The serial protocol should tolerate baudrate mismatches of up to 5% or so. At risk of telling everyone what they already know, the way the RX should work is as follows.

The stop bit(s) are guaranteed to be followed by a start bit: this provides a guaranteed low-to-high transition. The RX should use this to re-synchronise. It shouldn't care about the length of the stop bit. This is how it achieves tolerance of slight mismatches of clock frequencies.

[robert-hh]

I do not have that serial terminal here, which had sent the data. The only thing I did was sending by the Pico and receiving, while monitoring the communication with a logic analyzer and Oscilloscope. The data was received fine by the Pico, and the both the logic analyzer and the oscilloscope decoded the data fine, and the bit timing is at 835µs == 1198 baud.
If I receive by the second UART of the Pico, set to 1200 Baud, and change the baudrate of the fist UART, sending from the first to the second, transfer works fine in the range of 1150 to 1250 baud. So the Pico receiver looks fine.

[peterhinch]

In which case I'm baffled. It should be impossible for a receiver to lose and regain synchronisation in the way @slsimic is seeing.

@robert-hh Did you do your variable baudrate test with the data and UART settings that @slsimic is using?

[slsimic]

If you compare correct answer and garbled one you can see that occasionally correct bytes shows up, not only on the start. Strangely but they do. I bold that characters
b'00004360972 00\x18\x18\x18LLt\x18\x18LL&3\x13}&3\x13\x02\x02\x03\x0300\x18\x18\x18LLt\x18\x18LL&3\x13}&3\x13\x02\x02\x03\x030034119 2000000 022\x18N6\x03k'
b'00004360972 0000000 0000000 0000000 0000000 0000000 0000000 0034119 2000000 0220928 \r'

[robert-hh]

@peterhinch Yes, I use 7 data bits/even parity/2 stop bits, and 1200 baud for the receiver, 1150-1250 baud for sending. And I verified with an oscilloscope that the bit times matched the varying baud rates.
@slsimic I still conclude that there is a problem with the serial terminal. But we will not know until the real bit timing of the serial terminal is known. Mayb they use 1.5 stop bits. So you have a few options.

• since 1 stop bit works, two stop bits do not, you could try to set the Pico at a slightly higher baud rate, like 1250 baud.
• Try to use 1 stop bit for receiving and sending.
• You could also set the receive to 1 stop bit and the send to 2 stop bits. You have to use two UART for that, since both receive and send is buffered. Or you use uart.flush() to wait until all data has been sent.

[kjm1102]

Probably not relevant to your problem but I had an episode with an rpi 2040 where the uart could only receive max 32 characters after a deepsleep. The fix was to reinitialise (uart=UART(0)) before each receive.