tx_mode 1 with EMS+ on version 1.9.x gives corrupt telegrams

[proddy]

I was testing EMS+ on a RC300 with @moustic999 and he was seeing corrupted telegrams come in using the latest UART code logic we call txmode2. Like:

(00:02:32.413) Sending raw: 0B 90 FF 00 0A 01 A5 (CRC=B1) #data=16
(00:02:32.476) Corrupt telegram: 0B 90 FF 00 0A 01 A5 B1 00 10 0B FF 00 01 A5 80 00 01 20 16 00 20 2A 01 (CRC=85) #data=18

This bug was reproduced on these firmware versions which all use the same UART logic for sending telegrams:

1.8.3 using tx_mode 2
1.9.1 using tx_mode 1
txmode2 branch

It looks like the BRK is not sent, perhaps a timing issue? Next thing to try would be the jabber mode.

[proddy]

adding @susisstrolch

[moustic999]

Note that with 1.8.3 with tx-mode 2, I have not always corrupted messages, it is sporadic, it works most of the time...

[susisstrolch]

@proddy that doesn't look like a Tx problem. The telegram consists of two parts:

• the echo
• the reply
  It looks like the break isn't detected propperly. I saw this also sometimes with my 0x10 device.
  That's something we can't influence by UART configuration - or by marginally increasing the baudrate a few percent, so the obviously to short break would appear longer.

[proddy]

I should have mentioned, it works in the other modes (like EMS+) but no in the generic txmode2 implementation. So I suspect the problem is in the txcode2 code.

[proddy]

@moustic999 do you still get corrupted messages with tx_mode 1 and 2 with the latest 1.9.1 beta?

[proddy]

I saw a similar issue and the latest dev (1.9.2) fixes it. Closing issue - please reopen if there is still corruption seen with EMS+