This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

setting tx_power_level

Hi,

I'm following this tutorial. In challenge 1, I was asked to change the transmit power level of the device.

Challenge 1: Try to add and populate the "p_tx_power_level" field in "advdata" with a value of your own choice and see what happens in MCP. This field is meant to advertise the transmit power of your device. This enables other units to roughly estimate the distance to your device.

I add these two lines in the advertising_init() function but the device couldn't be discovered in MCP.

int8_t tx_power_level[] = {0, -20};
advdata.p_tx_power_level 					= tx_power_level;

I also tried following this question but no luck.

How can I change the current project to do challenge 1?

Parents
  • As Chris said and also:

    Edit - This is an answer to your question below and a response to your comment in the advertising tutorial. Your problem is that you have already squeezed 29 bytes into your advertising packet, dangerously close to the maximum allowed 31 bytes.

    Lets have a look at the content of your packet. First, this is what I see in my MCP with your code:

    image description

    Below I have used a nRF51 Dongle and Wireshark software to sniff the advertising packet to see what the packet contains:

    image description

    As you can see I have marked the Advertising Packet field at the top and the blue lines at the bottom represent the bytes in the packet. If you count the marked bytes you will find that it is already 29 of them. The rest of the bytes in the window are various link layer, address and CRC bytes (if you look closely you will, e.g., recognize the 6 Address bytes from the MCP in reverse order in the second line).

    Now, you can see that there are 4 main data fields in the advertising packet: Device Name, Appearance, Flags and 16-bit Service Class UUIDs.

    Have a look at the following screenshot:

    image description

    Here I have highlighted the Device Name field. Again you can see that the actual byte values are highlighted at the bottom and if you count them you will see that there are 8 of them. And why 8 when your name is just 6 bytes long? That is because the Device Name field in the advertising packet is structured this way:

    1. Length byte, value 7 (the length byte doesn't count it self), one single byte.
    2. Type byte, value 8, one single byte. (Here is a list of type bytes and you can recognize 0x08 that is «Shortened Local Name»).
    3. Actual name bytes, value "ThisIs", 6 bytes.

    Result = 8 bytes.

    Now that we understand the structure of the packet we can count all of the bytes:

    1. Device name field: 8 bytes
    2. Flag field: Length (1), type (1), flag(1) = 3 bytes
    3. 16-bit Service Class UUID: Length(1), type(1), UUID(2) = 4 bytes
    4. Manufacturer Specific: Lenght(1), type(1), company ID(2), data(10) = 14 bytes

    Result = 29 bytes!

    Now what happens if you add a TX power level field? Then you will add an additional Lenght byte, type byte and tx power level byte, i.e. 3 more bytes and you are up in a total of 32 bytes, 1 more than the allowed 31 bytes. So your solution will be to shorten your Device Name field or Manufacturer Specific data field with at least one byte.

    I know I should probably have added this in the tutorial, but I figured it was too much extra reading.

Reply
  • As Chris said and also:

    Edit - This is an answer to your question below and a response to your comment in the advertising tutorial. Your problem is that you have already squeezed 29 bytes into your advertising packet, dangerously close to the maximum allowed 31 bytes.

    Lets have a look at the content of your packet. First, this is what I see in my MCP with your code:

    image description

    Below I have used a nRF51 Dongle and Wireshark software to sniff the advertising packet to see what the packet contains:

    image description

    As you can see I have marked the Advertising Packet field at the top and the blue lines at the bottom represent the bytes in the packet. If you count the marked bytes you will find that it is already 29 of them. The rest of the bytes in the window are various link layer, address and CRC bytes (if you look closely you will, e.g., recognize the 6 Address bytes from the MCP in reverse order in the second line).

    Now, you can see that there are 4 main data fields in the advertising packet: Device Name, Appearance, Flags and 16-bit Service Class UUIDs.

    Have a look at the following screenshot:

    image description

    Here I have highlighted the Device Name field. Again you can see that the actual byte values are highlighted at the bottom and if you count them you will see that there are 8 of them. And why 8 when your name is just 6 bytes long? That is because the Device Name field in the advertising packet is structured this way:

    1. Length byte, value 7 (the length byte doesn't count it self), one single byte.
    2. Type byte, value 8, one single byte. (Here is a list of type bytes and you can recognize 0x08 that is «Shortened Local Name»).
    3. Actual name bytes, value "ThisIs", 6 bytes.

    Result = 8 bytes.

    Now that we understand the structure of the packet we can count all of the bytes:

    1. Device name field: 8 bytes
    2. Flag field: Length (1), type (1), flag(1) = 3 bytes
    3. 16-bit Service Class UUID: Length(1), type(1), UUID(2) = 4 bytes
    4. Manufacturer Specific: Lenght(1), type(1), company ID(2), data(10) = 14 bytes

    Result = 29 bytes!

    Now what happens if you add a TX power level field? Then you will add an additional Lenght byte, type byte and tx power level byte, i.e. 3 more bytes and you are up in a total of 32 bytes, 1 more than the allowed 31 bytes. So your solution will be to shorten your Device Name field or Manufacturer Specific data field with at least one byte.

    I know I should probably have added this in the tutorial, but I figured it was too much extra reading.

Children
Related