BIP148 was not a soft fork deployment on its own, so it did not have a BIP9 version bits signal associated with it.
The actual softfork deployment was SegWit itself, defined in BIP141 and signalled by bit 1 in the version field.
Any block signaling soft fork readiness with BIP9 must have the top three bits set to
/** What bits to set in version for versionbits blocks */
static const int32_t VERSIONBITS_TOP_BITS = 0x20000000UL;
Readiness for SegWit was signaled by bit 1 or
1 << 1 in 32-bit hexadecimal:
Therefore all blocks signaling SegWit during the BIP9 STARTED phase had the version
In Bitcoin the block version number is serialized as little-endian, meaning on the wire and on disk the first few bytes of a SegWit signaling block look like this:
bitcoin-cli getblock 000000000000000000f288b3ff879d0ef11d3197f88dcdc1e29c3933b9c0e5af 0
Note the expected version bits in the first four bytes, little-endian.
To address your question specifically about the version in binary, all SegWit-signaling blocks would have a version field like this (shown here as big-endian to match your example)
00100000 00000000 00000000 00000010
Miners do crazy things and some miners during this time signaled extra bits for various other reasons, but the two bits shown here must be set to signal SegWit.
On to the question of BIP148: It had no extra signals except for ASCII strings encoded in the coinbase scriptSig. In block 469345 the coinbase scriptSig is:
Which, decoded to ASCII:
BIP148 nodes also included a similar string in their user-agents. Otherwise they provided no signal to the network that they would reject non-SegWit-signaling blocks after the flag date. They required no network majority to enforce their rules.