1 Reply Latest reply on Feb 25, 2014 10:08 AM by jota_1939431

    Why does hello sensor reverse UUID_HELLO_SERVICE?

      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.

        • 1. Re: Why does hello sensor reverse UUID_HELLO_SERVICE?

          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:

          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.