Extract 4 bits vs 2Bit of Bluetooth HEX Data, why same method results in error

Question

This is a follow on question from this SO (Extract 4 bits of Bluetooth HEX Data) which an answer has been accepted. I wanna understand more why the difference between what I was using; example below; (which works) when applied to the SO (Extract 4 bits of Bluetooth HEX Data) does not.

To decode Cycling Power Data, the first 2 bits are the flags and it's used to determine what capabilities the power meter provides.

guard let characteristicData = characteristic.value else { return -1 }
var byteArray = [UInt8](characteristicData)
// This is the output from the Sensor (In Decimal and Hex)
// DEC [35,  0, 25,  0, 96, 44, 0, 33, 229] Hex:{length = 9, bytes = 0x23001900602c0021e5} FirstByte:100011    

/// First 2 Bits is Flags
let flags = byteArray[1]<<8 + byteArray[0]

This results in the flags bit being concatenate from the first 2 bits. After which I used the flags bit and masked it to get the relevant bit position.

eg: to get power balance, I do (flags & 0x01 > 0)

This method works and I'm a happy camper.

However, Why is it that when I used this same method on SO Extract 4 bits of Bluetooth HEX Data it does not work? This is decoding Bluetooth FTMS Data (different from above)

guard let characteristicData = characteristic.value else { return -1 }
let byteArray = [UInt8](characteristicData)
let nsdataStr = NSData.init(data: (characteristic.value)!)

print("pwrFTMS 2ACC Feature  Array:[\(byteArray.count)]\(byteArray) Hex:\(nsdataStr)")

PwrFTMS 2ACC Feature Array:[8][2, 64, 0, 0, 8, 32, 0, 0] Hex:{length = 8, bytes = 0x0240000008200000}

Based on the specs, the returned data has 2 characteristics, each of them 4 octet long.

doing

byteArray[3]<<24 + byteArray[2]<<16 + byteArray[1]<<8 + byteArray[0]

to join the first 4bytes results in an wrong output to start the decoding.

edit: Added clarification

Answer 1

There is a problem with this code that you say works... but it seems to work "accidentally":

let flags = byteArray[1]<<8 + byteArray[0]

This results in a UInt8, but the flags field in the first table is 16 bits. Note that byteArray[1] << 8 always evaluates to 0, because you are shifting all of the bits of the byte out of the byte. It appeared to work because the only bit you were interested in was in byteArray[0].

So you need it convert it to 16-bit (or larger) first and then shift it:

let flags = (UInt16(byteArray[1]) << 8) + UInt16(byteArray[0])

Now flags is UInt16

Similarly when you do 4 bytes, you need them to be 32-bit values, before you shift. So

let flags = UInt32(byteArray[3]) << 24 
    + UInt32(byteArray[2]) << 16
    + UInt32(byteArray[1]) << 8
    + UInt32(byteArray[0])

but since that's just reading a 32-bit value from a sequence of bytes that are in little endian byte order, and all current Apple devices (and the vast majority of all other modern computers) are little endian machines, here is an easier way:

let flags = byteArray.withUnsafeBytes {
    $0.bindMemory(to: UInt32.self)[0]
}

In summary, in both cases, you had been only preserving byte 0 in your shift-add, because the other shifts all evaluated to 0 due to shifting the bits completely out of the byte. It just so happened that in the first case byte[0] contained the information you needed. In general, it's necessary to first promote the value to the size you need for the result, and then shift it.