• State Verified Answer
  • Replies 1 reply
  • Subscribers 86 subscribers
  • Views 344 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 260338
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Use a UUID for my app

QuentinD

Hello

I have several questions regarding the UUID (Bluetooth):

  • If I create an application using your nus bluetooth service (ble_nus.c), should I change the NUS_BASE_UUID (0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0, 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00 , 0x40, 0x6E)?
  • If I create an app that will use a modified version of your nus service, do I need to change the NUS_BASE_UUID? If I have to, how can I determine the value of the UUID I should provide? (I have a Comany Identifier assigned by the Bluetooth SIG)

Thank you

Parents
  • +1

    Hi,

    It depends on if you modify our service or not. If you don't modify it then you can use the same UUID. However, the point that you modify the service then it's no longer BLE_NUS but rather your modified version of BLE_NUS which results in you having to use your own custom UUID.  

    f I have to, how can I determine the value of the UUID I should provide?

     From our service tutorial:

    A UUID is an abbreviation you will see a lot in the BLE world. It is a unique number used to identify services, characteristics and descriptors, also known as attributes. These IDs are transmitted over the air so that e.g. a peripheral can inform a central what services it provides. To save transmitting air time and memory space in your nRF52 there are two kinds of UUIDs:

    The first type is a short 16-bit UUID. The predefined Heart rate service, e.g., has the UUID 0x180D and one of its enclosed characteristics, the Heart Rate Measurement characteristic, has the UUID 0x2A37. The 16-bit UUID is energy and memory efficient, but since it only provides a relatively limited number of unique IDs there is a rule; you can only transmit the predefined Bluetooth SIG UUIDs directly over the air. Hence there is a need for a second type of UUID so you can transmit your own custom UUIDs as well.

    The second type is a 128-bit UUID, sometimes referred to as a vendor specific UUID. This is the type of UUID you need to use when you are making your own custom services and characteristics. It looks something like this: 4A98xxxx-1CC4-E7C1-C757-F1267DD021E8 and is called the “base UUID”. The four x’s represent a field where you will insert your own 16-bit IDs for your custom services and characteristics and use them just like a predefined UUID. This way you can store the base UUID once in memory, forget about it, and work with 16-bit IDs as normal. You can generate base UUIDs using nRFgo Studio. It is very easy and you can look in the Help menu to learn how.

    A little fun fact about UUIDs: There is no database ensuring that no one in the world is sharing the same UUID, but if you generate two random 128-bit UUIDs there is only a ~3e-39 chance that you will end up with two identical IDs (that is ~1/340,000,000,000,000,000,000,000,000,000,000,000,000).

Reply
  • +1

    Hi,

    It depends on if you modify our service or not. If you don't modify it then you can use the same UUID. However, the point that you modify the service then it's no longer BLE_NUS but rather your modified version of BLE_NUS which results in you having to use your own custom UUID.  

    f I have to, how can I determine the value of the UUID I should provide?

     From our service tutorial:

    A UUID is an abbreviation you will see a lot in the BLE world. It is a unique number used to identify services, characteristics and descriptors, also known as attributes. These IDs are transmitted over the air so that e.g. a peripheral can inform a central what services it provides. To save transmitting air time and memory space in your nRF52 there are two kinds of UUIDs:

    The first type is a short 16-bit UUID. The predefined Heart rate service, e.g., has the UUID 0x180D and one of its enclosed characteristics, the Heart Rate Measurement characteristic, has the UUID 0x2A37. The 16-bit UUID is energy and memory efficient, but since it only provides a relatively limited number of unique IDs there is a rule; you can only transmit the predefined Bluetooth SIG UUIDs directly over the air. Hence there is a need for a second type of UUID so you can transmit your own custom UUIDs as well.

    The second type is a 128-bit UUID, sometimes referred to as a vendor specific UUID. This is the type of UUID you need to use when you are making your own custom services and characteristics. It looks something like this: 4A98xxxx-1CC4-E7C1-C757-F1267DD021E8 and is called the “base UUID”. The four x’s represent a field where you will insert your own 16-bit IDs for your custom services and characteristics and use them just like a predefined UUID. This way you can store the base UUID once in memory, forget about it, and work with 16-bit IDs as normal. You can generate base UUIDs using nRFgo Studio. It is very easy and you can look in the Help menu to learn how.

    A little fun fact about UUIDs: There is no database ensuring that no one in the world is sharing the same UUID, but if you generate two random 128-bit UUIDs there is only a ~3e-39 chance that you will end up with two identical IDs (that is ~1/340,000,000,000,000,000,000,000,000,000,000,000,000).

Children
No Data
Related
Terms of service