About NCS's/Zephyr's Bluetooth Mesh opcode byte order...

[BlueMike]

Dear NCS exprts,

I'm a little confused with the endian-ness between the firmware application and the controlling Android app. Lets first take a look at the firmware (running on an nRF52832):

Let's assume we're having a company id of 0x6789 (which leads to nice numbers). Defining a new opcode of value 0x01 (for a custom message) using BT_MESH_MODEL_OP_3(0x01, 0x6789) gives us a three byte opcode with a value of 0xc16789.
Bluetooth (including Mesh) uses little endian format for multi byte values. So the value should be transmitted in a buffer reading: 8967c1

When the above message arrives at the Android app, the whole buffer gets logged:

V/AccessLayer: Received Access PDU C18967[Payload follows...]

Now, what's strange here is that the vendor id (0x6789) is (properly) transmitted in little endian format (0x8967). The first bye (0xc1), however, is omitted. Is this the expected behavior for a three byte opcode?

Any clarification is welcome,
Thank you,
Michael.

[Karl Ylvisaker]

Hello Michael,

Now, what's strange here is that the vendor id (0x6789) is (properly) transmitted in little endian format (0x8967). The first bye (0xc1), however, is omitted. Is this the expected behavior for a three byte opcode?

Yes, this is the expected behavior because the first byte is a separate indicator - in this case representing the type of the following value - which is then followed by a two byte value datafield containing the company identifier. If you look at the raw hex values of the received packet these values will appear as 0xc16789, but if you look at it in a sniffer trace you will see how the sniffer has split the 0xc1 from the value of the datafield.
In BLE communication, for example, all datafields will have the first byte indicating length of the datafield, the second indicating type, and the remaining bytes being the payload or value of the indicated datafield.

Best regards,
Karl