Looks like its manchester encoded to me. Where a '1' is encoded as a 01, and a 0, is encoded as a 10.
The first lot of pulse trains are to train the RF receiver, to remove any DC offset (so there is no DC level, as RF recievers work on AC, so the signal must be balanced). So, it sends alternate 1's and 0's. Measure that bit period, and you have your datarate.
After the 10 pulses, there is a 'start of packet', which looks like 111000111101001011 ...etc.. This purposefully violates the manchester protocol, so it only ever appears as a 'start of packet', and is never repeated when sending data. Making the reciever 'find' the start of packet much easier. It is difficult to find the point where the 'start of packet' ends, and data begins.
Since after the SOP, there seems to be the same bits send for a while, I would imagine thats an address, then the bits that are different each time would be the temperature.
Your best bet is to write a small program for your Arduino, or whatever micro you're using, this should look for the start of packet, then decode everything after that with a manchester decoder. I'm sure there is source code available for this somewhere on the web, if not I have some for both PIC and AVR.
Also, at the end of the packet, there also appears to be the same data, this means it probably isn't a CRC checksum (which would be different for different data) so its probably a 'end of packet' bit string.
So two options?
1) do it manually
convert all the waveforms to 1's and 0's in notepad, look for common bit strings. Even if you don't decode using manchester, your micro just has to look for the 'common elements', and record the parts that change. After this you have manchester encoded temperature data, which you can then also write down manually and decode it to see what the numbers are, and how they correspond to the temperature. - It may simply be a 8,10,12,16 bit number, or sometimes they send BCD (binary coded decimal) in which case its just a byte for each digital of the temperature. Example: 070.7F = bytes <0x00><0x07><0x00><0x07>.
2) Program your micro to do most of the work for you. Perhaps rigging up an LCD display to show the bits in the packet which are 'different'. Each time looking for the sync, start of frame, data, end of frame, but only recording the data.
Remember, there is no set standard that says the sync, SOF, EOF should be bytes, or a multiple of 8 bits... they could be anywhere from 6 to 20 bits long, since its a custom protocol. That means that, if you do it manually (in note pad) work in BITS rather than bytes. The same goes for using a micro, although it makes life difficult since 8-bit micro's can only store numbers as bytes.
I'll give it a closer look tomorrow
Blueteeth.