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



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...