Yes the signal has 75 bits.  It can also be described as 76 bits, in which the first bit is required to be zero, but I prefer to think of the first on pulse as being a start pulse which provides the timing reference for the subsequent edges.  I've chosen a convention that a negative going edge denotes a zero and a positive going edge denotes a one.

More than half of all IR protocols transmit bits with the least significant bit of the data sent first.  Typically the reversal is done on byte boundaries. RS-232 has worked the same way for the last half century, and it makes reading the data on an oscilloscope difficult.   IR protocols designed in the last several years tend to be msb-- they send the most significant bit first.

All of the signals posted in this thread start 0x3FF1010.  Since they all do this, we can't know anything about their purpose, but I choose to think that the 3FF is a constant behavior of all Pro.Relay signals, but the 1010 carries data.  I infer that because it is 2 bytes with a repeated value, and the other 3 words with repeated bytes clearly contain data which varies with the commanded functions.

So why do I believe that the negative edge is a zero, and that the bits are sent in lsb format?  Partly because it provides simple correlation to relay number and actions, but mostly because it gives a very reasonable interpretation of the duration-- an exact match.  0xC80  (not 0x380; I don't know where you got that) is 3200 decimal and 3.125 mSec times 3200 is  10.000 seconds.  All the other durations derived from the IR signals follow this rule.

Many IR protocols try to check for transmission errors.  NEC, for example, originally sent the complement of the 1st and 3rd bytes in the 2nd and 4th bytes.  Most modern signals use a check sum or XOR computation to detect errors.  Lutron uses an elaborate scheme of parity bits and Gray encoding, which allows them to detect and correct a single bit transmission error.  Here I suppose that ProControl has made an attempt to detect errors by sending the same byte twice.  That's not very efficient, and it won't detect some types of systematic errors, but it still is quite a bit better than nothing.  With the posted Pronto Hex, there is no possibility of a transmission error (a typo is still possible), so I consider the repeated bytes to be redundant information.