in reply to Ascending vs descending bit order
The difference is that "b" is broken because it expects/produces the bits in the wrong order ["001" becomes chr(4)] while "B" is broken because short bit counts only deal with the highest bits ["001" becomes chr(32)]. (: [If multiple adjacent "b"/"B" formats could extract/set successive bits within a single byte, then this combination would be more reasonable.]
So, if you are a normal person, you have to use "B" and pad your binary strings (in front, that is, to the left) to multiples of 8 characters (for pack) and only use multiples of 8 as lengths after the "B" (for unpack).
It is called "ascending" bit order because it is assumed that you are reading the base-2 ASCII string (often confusingly called "binary" despite that term having way too many meanings in the context of pack and unpack) from left to right and, if you do that, the bits ascend in value from bit0=1, bit1=2, bit2=4, etc. While with "descending" bit order the leftmost "0" or "1" represents bit8=128 and the bit values descend from there.
BTW, I find that the documentation for pack/unpack is rather ambiguous/confusing and it is very hard to make it completely unambiguous. I often resort to testing via "perl -de 0" when I have a question about some detail of these two functions. You might find that useful as well.
- tye (but my friends call me "Tye")