The limitations are that the pulse train is that and cannot be modified; from your observations, correct, it appears that there is no start bit, a transmission that does not conform to any standard... this is what I understand from the observations you made... or am I wrong?
are you sure there's not start bit? what are you starting you're capture on? or does the data stream always start is a value where the MSB is opposite the idle state of the line?
i determined that the narrow pulse is ~75 and a data bit is ~475.
i took your rise/fall times a plotted them in blue.
using the narrow pulse as the start, i then drew orange lines starting from the rising edge of the narrow pulse + 2*75 + 475/2 and every 475 for the next 7 bits
it's odd that the least significant bit (LSB) is never set
and if there is no narrow start bit preceeding the first data, then either it is a preamble used to determine the width of pulses or always has it's MSB set
I assume the data always starts with 0xAA (pattern 10101010) so one scans for that and then treats the narrow pulses as separators between bytes, e.g. between 0x07 and 0xCB
I have worked on various bit-bash protocols (transmit/receive synchronous and asynchronous, e.g. RS232, I2C, etc) never seen one like this
i'm convinced the 0xAA pattern is a preamble indicating the start of a message. the distinct single bits allow the bit period to be determined, perhaps allowing various speeds.
the reason for prefixing commands with AT is that those 2 charaters which are 0x41 and 0x54 allow both the bit rate and parity to be determined from them to auto-configure a modem
i can't explain the last narrow pulse, see no purpose for it