2

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.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
user1587457
  • 123
  • 5
  • I don't see how it is an inversion. It could be the case the whole signal is inverted, including the start and stop bits. – Eugene Sh. Jan 15 '18 at 15:28
  • they call it "invert" ; the assumption was it is a bit flip on all bits; however it is not, as you said. I am not sure if there is some form of error correction after the invert is done – user1587457 Jan 15 '18 at 15:31
  • Is this an RS485 bus? – DiBosco Jan 15 '18 at 15:31
  • it is a 6 contact console cable (RJ25) but possibly with a different pin order – user1587457 Jan 15 '18 at 15:36
  • That doesn't tell us whether it's RS485 or 232 (or indeed something else) though. – DiBosco Jan 15 '18 at 15:42
  • it looks like a 232.. i am trying to build an interface to interact with it. – user1587457 Jan 15 '18 at 15:47
  • Can you show us some waveforms? – Eugene Sh. Jan 15 '18 at 15:48
  • am not sure if this is what you need. https://imgur.com/a/Dcpoy – user1587457 Jan 15 '18 at 16:06
  • Is there an "inverted" waveform? Or the SW is not providing it? – Eugene Sh. Jan 15 '18 at 16:11
  • inverted waveform looks the same; the decoder output however, is different – user1587457 Jan 15 '18 at 16:17
  • I see on this waveform that every byte is terminated by *two* consecutive "1"s, so I would guess the protocol is having two stop bits rather than one. But the decoded data seem to assume one of these bit is always data. Do you have a control over this setting? Do you know what is the protocol format of the data? – Eugene Sh. Jan 15 '18 at 16:42
  • "invert(0x35) = 0x4E ("N")..." - How do you that that one number 'equals' the other? – Bruce Abbott Jan 15 '18 at 17:09
  • @EugeneSh. The protocol selected in the logic analyzer is asynchronous serial (8bits), 1 stop bit, baud-rate-9600, no parity. I do not have any control over the transmitter. I have control over the decoder – user1587457 Jan 15 '18 at 17:19
  • Do you have the specs of the source protocol? – Eugene Sh. Jan 15 '18 at 17:19
  • @BruceAbbott.. when i select "invert" on the software on input 0x35 it gives 0x4E – user1587457 Jan 15 '18 at 17:19
  • 1
    But where is this 0x35 on the presented waveform? Please show the data and the corresponding waveform you are talking about. – Eugene Sh. Jan 15 '18 at 17:22
  • @EugeneSh.. could you please explain a bit about what exactly is "specs" of source protocol. I am a beginner :) I am still trying to understand the jargon. The device itself is a blackbox, i do not have visibility on how the protocol is implemented. – user1587457 Jan 15 '18 at 17:23
  • By specs I mean something like "XXX baud rate, Y data bits, Z stop bits, W parity" stated in it's documentation. Does it have it? What is this device anyway? – Eugene Sh. Jan 15 '18 at 17:24
  • 9600 baudrate 8 bits per transfer, 1 stop bit, no parity, LSB sent first and it is a network switch – user1587457 Jan 15 '18 at 17:28
  • 0x35 waveform https://imgur.com/a/Ow9ES 0x4E waveform https://imgur.com/a/PttSk – user1587457 Jan 15 '18 at 17:33
  • You said "inverted waveform looks the same" yet clearly these two waveforms are _not_ the same! – Bruce Abbott Jan 15 '18 at 17:37
  • You really need to show one under the other so we can relate timings – Eugene Sh. Jan 15 '18 at 17:37
  • 1
    RS-232 line drivers and recievers invert the signal, so a "High" out of the UART becomes a "Low" (usually a negative voltage) on the RS-232 cable. – Peter Bennett Jan 15 '18 at 17:40
  • @PeterBennett, are you aware of any console software that is able to read these signals ? I am getting gibberish on the console when i try to read them. And when you say "invert", in order to get the actual data, should i do a bit flip ? – user1587457 Jan 15 '18 at 17:46
  • What kind of protocol is it? Is it binary or ASCII? If it is ASCII you should be able to see it with any serial terminal emulator. No "inversion" should be needed if it is RS-232 and you use a standard serial port to read it. – Eugene Sh. Jan 15 '18 at 17:47
  • @EugeneSh. dont think it is ascii. Because hooking up the data line to serial to usb converter and printing the output to the console shows gibberish. – user1587457 Jan 15 '18 at 17:50
  • So? Then you get what expected. What is the problem then? You want to get it as hex values? Just google something like "hex serial terminal". – Eugene Sh. Jan 15 '18 at 17:51
  • What i am trying to do is understand this "invert" logic in order to decode what is coming from the line. – user1587457 Jan 15 '18 at 17:53
  • 1
    Looks like you are misinterpreting something. The datas on two sides of your `=` are unrelated as it seems. – Eugene Sh. Jan 15 '18 at 17:54
  • Which Saleae logic analyzer do you have, (eg. Logic 4, Logic 8...)? – Bruce Abbott Jan 15 '18 at 17:58
  • @BruceAbbott Logic 8 – user1587457 Jan 15 '18 at 17:59
  • 1
    If the signal is RS-232 levels, any serial terminal emulator program should work with an RS-232->USB adaptor. If you are dealing with a UART signal directly (sometimes called "TTL RS-232"), you will need a TTL Serial-USB adaptor instead, which will not have the RS-232 level inversion. – Peter Bennett Jan 15 '18 at 18:20
  • @PeterBennett I have a Serial to USB adaptor.(FT232H). It doesnt understand inverted signals. (tried with minicom). Now the idea is to write a software program to do this "inversion" and before that understand what exactly "inversion" means.. is it like a bit wise invertor ? or is there any other software logic – user1587457 Jan 15 '18 at 18:43
  • 1
    But why do you think it is "inverted"? Are the docs telling so? Can you show them to us? – Eugene Sh. Jan 15 '18 at 18:49
  • The RS-232 line drivers and receivers are simple inverting amplifiers. When the UART outputs +5V, the line driver outputs -12V, and Zero V from the UART will give +12V from the line driver (RS-232 voltages may vary...). You can get TTL Serial->USB adaptors (without the RS-232 inversion) from Adafruit and others. If your current adaptor is RS-232, then the TTL version should work. If your current adaptor is the TTL version, then an RS-232 type should work. – Peter Bennett Jan 15 '18 at 18:54

1 Answers1

3

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.

Bruce Abbott
  • 55,540
  • 1
  • 47
  • 89
  • 1
    To amplify, what the asker may be missing is that you can't reliably fix this inversion in software *after* the receive path of a typical UART, because an inverted waveform isn't really valid. It might sometimes be detected as some other character consisting of some of the inverted bits, but the framing is wrong. The inversion has to be corrected *before* the serial stream is framed and decoded by the receiver. It can only really be fixed in software when the decoding of the pulses on the wire is done by the software, ie a "Software Serial" type of implementation without a hardware UART. – Chris Stratton Jan 15 '18 at 19:09
  • 1
    Yes, that's why I said "you will have to decode the signal yourself". Once it has passed through a Serial to USB adapter it's too late. I wrote my answer before the asker mentioned using a serial-USB adapter, and assumed (s)he was working on some kind of bit-banged interface with software decoding. – Bruce Abbott Jan 15 '18 at 19:22