Electronic – Purpose of inverted channel for UART bus communication

Odd vs Even Parity

This will depend slightly on what communication you are using. I know you said you are using UART, but I am going to answer a bit broader. If you do decide to go with parity, select the option that will cause your "idle" state to require the parity bit to switch.

If you have an active high system, then all 0's is idle. So make it odd parity so that the parity bit will have to change state from idle.

In an active low system you should look at how many bits the parity will be over. If it is 8 bits, then even parity will result in a 0 parity bit, which follows the idea of forcing a change in state for the parity.

Should you use Parity?

Well this is a bit of a difficult questions. In general we like to model the noise as Gaussian noise which means that the bit errors will be completely random. In actuality noise that has an effect on our system is not always random. The reason for this is things that can cause errors on a PCB are radiators from something else. If you think about it, in order for a trace that short to have enough noise to cause bit error then it had to be something rather extreme. When you have a noise source like this, there is a decent chance that you will flip more then one bit. Parity is useless against an even number of bit errors. With out diving into the math, parity will help, but doesn't help tons. If you can't afford to do much processing then parity may be the best that you can do..

Why use a CRC?

First of all, you say you have a built in CRC generator, this means it should be very easy for you to compute. CRCs are much better at catching multiple bit errors. In an environment where you want a very low chance of getting any errors, you really want to use a CRC. In fact, go with the biggest CRC you can afford in your system. One little trick that I know works for atleast crc16 if not others is if you CRC the message you received with the CRC on it you should get 0 as your answer. If you have hardware to compute the CRC then this is a very efficient way of both generating CRC and checking CRC.

data bits per transfer (8? 9 bits?)

Looks like 9. Unusual, but this happens sometimes.

stop bits (1, 1.5, 2?)

This actually looks like 3 or 4 stop bits to me -- but it does not really matter. As long as you only receive data, set your receiver to "1 stop"; any extra bits will be just an idle line.

and could this be a multi-drop bus communication protocol?

Quite possible -- the last bit does look kinda like address select. But it should not matter that much for packer reception.

It seems that now you have enough information to start collecting the data. You'd want to collect at least 20 data packets, then put it into spreadsheet and stare at them for a while. Here is a good example: Reverse Engineering the Maverick ET-732. It is about RF device, but once you got the bits, it does not matter where they come from.

You'd want to record all 9 bits of data, and depending on your dongle, this can be hard. On Linux, you can set PARMRK,INPCK,PARENB,CMSPAR flags together to get your bit 9 info via special escapes in the input stream (see termios(3) for details). However, this requires support from your usb-serial chipset, and in generally, quite a pain. You may be better off scripting your DSO, making a converter from fast Arduino, or just manually saving lots of traces.