I encountered a strange problem on capture and Uart serial decoding when 2 data are close.
The real data are: 0x89 and 0xAA, the Picoscope translated by 0x89 and 0xF5, (it does not place well the real position of the Start)
(However, the device receiver translates well 0x89 and 0xAA ...)
RS232 is essentially a signalling protocol but also has some standard asynchronous data handling for a UART (Universal Asynchronous Receiver Transmitter). In order to operate asynchronously it is important that the line is placed in clearly defined states during and in between the transfer of data. In particular the line needs to be in the IDLE state (Logic 1) before and after transmission for at least 1 bit, so that the Start bit can be detected correctly, and also in case of framing errors where the last serial to parallel conversion was corrupted due to decoding a byte starting with data bits instead of the start bit. This is when the conversion has lost synchronization, and needs to resynchronize (which it does by making use of the extra bit/bits before the data byte).
So looking at your data image, bearing in mind that the least significant bit is sent first, starting from the left hand side, if you look at the decoders framing, we have the following:
111111----0----1001----0001----1------00------1-- --0----1010----1111----1----11_____(LSB is received 1st) so we have:
Idle----Start----9--------8----Stop--Ignored--Idle--Start--5--------F----Stop----Idle___Serial decoding gives us:
------------------Data - 89-------------------------------------Data - F5________________which is CORRECT
In order to correctly transmit 0x89 0xAA you need to conform to the specification and make sure that the line retruns to idle for the start bit to be interpreted correctly (and ideally long enough for framing error correction) i.e.:
(Note I haven't tested the use of just 1 idle bit, so it's possible that the decoder may need 2 Idle bits in between data packets, which might be a good idea anyway for UART framing error correction).
In particular the line needs to be in the IDLE state (Logic 1) before and after transmission for at least 1 bit
Are you saying that this "idle" bit is in addition to the STOP bit time?
I know of no uart that requires an idle time after the stop bit... the stop bit IS the idle time.
You should be able to begin another transfer immediately after the stop bit. If the decoder can't handle that it's broken.
Stop--Ignored--Idle--Start-
Those two 00's that you're ignoring and the "idle" are not correct. That should be a Stop--Start-- etc
Sorry my comment was indeed incorrect, and was based upon a software UART that I wrote some time ago (the last time I did any serious RS232 low level comms) which I now remember had to handle UART clock timing differences along with, the overhead of the UART processing at higher transmission speed creating framing errors. Our Decoder software appears to also look for more than one stop bit, so it does NOT conform to the spec.
So, thanks for pointing that out, and thanks to EricF for originally finding the error. I will take this up with our Development team and request a fix to the current implementation.