Why does hello sensor reverse UUID_HELLO_SERVICE?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Why does the hello sensor firmware "reverse the UUIDs when publishing in the database"? And similarly why does the hello client use the non-reversed UUID values and then reverse them in DeviceSelect.cpp? I don't recall seeing anything like this in the Bluetooth 4 specification.

0 Likes
1 Solution
Anonymous
Not applicable

Hello joe.parness.

Thanks for your question.  Below is a good example of the reversing explanation in the Spec.

The BLUETOOTH SPECIFICATION Version 4.1 [Vol 6] Page 34/174 states:

1.2 BIT ORDERING

The bit ordering when defining fields within the packet or Protocol Data Unit (PDU) in the Link Layer specification follows the Little Endian format. The following rules apply:

  1. The LSB is the first bit sent over the air
  2. Furthermore, data fields defined in the Link Layer, such as the PDU header fields, shall be transmitted with the LSB first.

Also Pages 163/174 describes the LE Test Packet PDU.

However, in our implementation:

If you are asking about Win7 implementation, the processing of the 16 byte UUIDs is a bit "unusual" - (We would recommend to use functions from the sample).  

If you use Win8, Android, or iOS and you want to find the service on the 20732 sensor, you should define it as it is done in the sample.  For example on the client you should use:

// {8AC32D3F-5CB9-4D44-BEC2-EE689169F626}

static const GUID
UUID_HELLO_CHARACTERISTIC_NOTIFY = { 0x8ac32d3f, 0x5cb9, 0x4d44, { 0xbe, 0xc2,
0xee, 0x68, 0x91, 0x69, 0xf6, 0x26 } };

on the 20732 side it should be reversed:

#define
UUID_HELLO_CHARACTERISTIC_NOTIFY    0x26, 0xf6, 0x69, 0x91,
0x68, 0xee, 0xc2, 0xbe, 0x44, 0x4d, 0xb9, 0x5c, 0x3f, 0x2d, 0xc3, 0x8a

Let me know if this answers your question.

JT

View solution in original post

1 Reply
Anonymous
Not applicable

Hello joe.parness.

Thanks for your question.  Below is a good example of the reversing explanation in the Spec.

The BLUETOOTH SPECIFICATION Version 4.1 [Vol 6] Page 34/174 states:

1.2 BIT ORDERING

The bit ordering when defining fields within the packet or Protocol Data Unit (PDU) in the Link Layer specification follows the Little Endian format. The following rules apply:

  1. The LSB is the first bit sent over the air
  2. Furthermore, data fields defined in the Link Layer, such as the PDU header fields, shall be transmitted with the LSB first.

Also Pages 163/174 describes the LE Test Packet PDU.

However, in our implementation:

If you are asking about Win7 implementation, the processing of the 16 byte UUIDs is a bit "unusual" - (We would recommend to use functions from the sample).  

If you use Win8, Android, or iOS and you want to find the service on the 20732 sensor, you should define it as it is done in the sample.  For example on the client you should use:

// {8AC32D3F-5CB9-4D44-BEC2-EE689169F626}

static const GUID
UUID_HELLO_CHARACTERISTIC_NOTIFY = { 0x8ac32d3f, 0x5cb9, 0x4d44, { 0xbe, 0xc2,
0xee, 0x68, 0x91, 0x69, 0xf6, 0x26 } };

on the 20732 side it should be reversed:

#define
UUID_HELLO_CHARACTERISTIC_NOTIFY    0x26, 0xf6, 0x69, 0x91,
0x68, 0xee, 0xc2, 0xbe, 0x44, 0x4d, 0xb9, 0x5c, 0x3f, 0x2d, 0xc3, 0x8a

Let me know if this answers your question.

JT