The first thing to say is that you are probably converting to a floating point format, rather than a decimal one. The next thing to notice is that your numbers are 24 bits long, this is not the normal way that modern floating point numbers are encoded they tend to be 32 bit (for example see Wikipedia). From memory I think there was an IBM 24 bit float format from the 1970s.

As you say the bigendian/littleendian split is worth looking at, also sometime these things are written backwards as well (giving 4 combinations of bit order).

The approach I would take is to get as many examples as you can, see if you can encode numbers that are related to each other, for example 1.25, 2.5, 5, 10, 20 and 40. Also select "simple" numbers, like 0.0, 1.0, -1.0 etc and simple relationships, for example compare 0.5, 1.0 and 1.5. Then rewrite every one in binary and see what the patterns are. If you look at the numbers you gave:

0b00111100 10110100 00010101 = 888.997500
0b00000000 01110001 00000010 = 100.000000
0b00000000 00110101 00001100 = 500.000000
0b00000000 01101010 00011000 = 1000.000000
0x00110000 00000101 00010101 = 860.99000
0x10000000 10101001 00000011 = 150.000000
0x11000000 01011110 00000100 = 179.00000
[download]

There are obviously too few numbers here to see the pattern but I do notice that 500 and 1000 have an obvious relationship.

Once I understand the conversion I would then use pack (especially with "b") to unpick the parts (for a float that would be the sign, mantissa and exponent and don't forget any implied MSB).