Electronic – Asynchronous serial inversion logic

saleae-logic-analyzerserial

I am using Saleae logic analyzer to reverse a console port. Saleae is able to successfully decode the signal (asynchronous serial) after performing an "invert" operation on the received signals.

I am trying to figure out how this transform(invert) works in order to write a custom program to interface with the console port. The protocol is asynchronous serial with a baud rate of 9600, one stop bit and no parity.

invert(0x35) = 0x4E ("N")
invert(0x17) = 0x65 ("e")
invert(0x11) = 0x74 ("t")

Is this a standard inversion algorithm for asynchronous serial communication? Am a beginner in this field and hence a bit confused.

Best Answer

The 'invert' function causes the protocol analyzer to interpret a logic '0' as logic '1' and vice versa. This may be necessary to decode a waveform which is 'inverted' relative to the 'normal' logic levels for that protocol.

RS232 specifies +3~15V for the Start bit and '0' data bits, and -3~15V for '1' data bits and the Stop bit(s). However when translated to and from TTL/CMOS logical levels the signal is usually inverted. In 'TTL serial' the Start bit is low and Stop bit is high, and data bits match positive TTL logic levels (ie. high level = '1', low level = '0').

The analyzer detects the start of a word by looking for the transition between Stop/idle and Start bit. The detected start point will vary depending on the signal polarity and data present, so an 'inverted' signal will show decoded words in different positions and there won't be any obvious relationship between the detected bits.

To transform the signal in your own custom program, all you have to do is interpret high level as logic '0' and low level as logic '1'. You will have to decode the signal yourself, by looking for the beginning of a Start bit (transition from '1' to '0') skipping 1.5 bit periods to read the level in the middle of each data bit, and finally checking for the Stop bit.

Related Solutions

Electronic – Asynchronous serial bit transmission/reception

if you are building up a number in binary, the 'right hand' bit is the least significant, and the processes is usually counting 'up' the index, or 'bit position' which goes left towards the most significant bit. This of course is entirely related to the "endian-ness" of the system architecture - which determines if it's the 7th or the zero-th bit as most significant.

A psuedo code for the receiver in a shift register of a UART might be:

Oh look, i detected a start bit!
oh look here are more bits coming in which match my baud rate settings! (timeout hasn't occurred, and not too fast to be considered noise, etc)
for each bit, starting index 0, if bit is high, put a 1 into the shift register, else put a zero into the shift register
after the x number of data bits (could be 8-10 data bits in a serial frame) process is finished, and set flag for microcontroller to read my receive data register!

All of this is followed of course by 1 or 2 stop bits, and then the data line is kept at whatever idle level (usually high?) until the next transmission is detected.

Same style of thinking is used for bit-banging by software serial - as the pin level changes, increase the bit index and set/reset the bit on a "received byte" variable. It's essentially based on endian-ness of the system (little or big endian) and the fact that programmers like to use 0-indexing and starting at the lower end of a variable. Hardware UART transmit shift registers usually shift data out "backwards" than what you expect, as you mentioned in your question.

Electronic – Reverse Engineer Serial Signal

My first thought (based on the async decoded data only) was this could be Manchester encoded signal, instead of async serial. Now I think the data is encoded by supressing alternate clock pulses.

Here's why:

With the exception of the 0x80 (which may be a "start byte"), the async serial 8N1 claims that the messages are composed of only 10 distinct symbol bytes:

0x55 01010101 (139 occurrence) 
0x57 01010111 (32 occurrence) 
0x5d 01011101 (16 occurrence) 
0x75 01110101 (45 occurrence) 
0x77 01110111 (49 occurrence) 
0xd5 11010101 (5 occurrence) 
0xd7 11010111 (5 occurrence) 
0xdd 11011101 (24 occurrence) 
0xf5 11110101 (11 occurrence, only at end of message) 
0xfd 11111101 (2 occurrence, only at end of message)

Looking at the binary it looks like the message bitstream is composed of long and short pulses, and may not be correctly synced up with the start and stop bits of the async serial. The only bit patterns that have more than three 1's in a row are 0xFD and 0xF5, but that occurs only at the end of a message -- and remember, async serial is LSB-first. So those longer sequences of 1's in the MSB may be after the end of the underlying Manchester encoded signal. Similarly the 0x80 at the start of each message may precede the underlying signal.

Atmel's primer on Manchester Coding Basics gives a good overview of encoding and decoding: http://www.atmel.com/images/atmel-9164-manchester-coding-basics_application-note.pdf

waveform capture picture

Now that I see the waveform, it's definitely not Manchester coding... Looks like idle-high, with a long pulse as a header, followed by a very long string of clock pulses -- with occasional missing clock pulses. At this point I'd guess the pulses alternate between Clock pulses and Data pulses. So a 0 is encoded as two clock pulses, and a 1 is encoded as one clock pulse and one "missing" pulse. I'm not sure what this is called but I think I've seen it before, a long time ago...

Best Answer

Related Solutions

Electronic – Asynchronous serial bit transmission/reception

Electronic – Reverse Engineer Serial Signal

Related Topic