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

Nrf beacon example packet size

Can we increase the packet size in Nrf52 Beacon example ? I want to send UUID=16 Bytes + Major=4 Bytes, Minor= 4 Bytes + RSSI= 1 Byte i.e Total =25 Bytes. I am using SDK13.

Parents
  • Hello,

    You may not increase the advertising packet size over its 31 byte limit. You should also keep in mind that there are 2 byte overhead with each bitfield, that you must also send.
    Please see this previous ticket on the subject - it is old, but still relevant.
    Or, could it be that you are asking about Advertising extension?

    Best regards,
    Karl

  • I made these changes #define

    APP_BEACON_INFO_LENGTH 0x1D 
    #define APP_ADV_DATA_LENGTH 0x1B 

    after this its not working.

  • I think I don't have repeated question for you not to respond.

  • Hello,

    Manoj Hiwarkar said:
    I think I don't have repeated question for you not to respond.

    I will attempt to answer the questions you have raised.

    Manoj Hiwarkar said:
    I made these changes

    Are you working out of one of the Beacon example?
    If so, please share all the changes you have made to the example.
    The example already sends a 16 byte UUID, 2 byte Major, 2 byte Minor and measured RSSI. Could I ask why you are looking to increase the major and minor length?
    The major and minor fields are just used to differentiate between different beacons, which 4 bytes should suffice to do, unless you are planning to have an enormous amount of beacons.

    Manoj Hiwarkar said:

    I made these changes #define

    APP_BEACON_INFO_LENGTH 0x1D 
    #define APP_ADV_DATA_LENGTH 0x1B 

    after this its not working.

    This does not give me anything to work with, since you make no mention of where or how you are using these defines. Furthermore, it would be beneficial if you were more specific regarding how it does not work - does it not compile or does it behave unexpectedly? If so, what is the unexpected behavior?

    Manoj Hiwarkar said:
    But my question is can we remove few fields liked flags and increase the major and minor size ?

    I think you will need at least 1 byte of flags, for your advertising packets - but you are free to attempt to remove it all together and see if it works, but I doubt it will.

    Best regards,
    Karl 

  • Ok let me put it in this way. The Nrf connect app raw data is 0x0201041AFF590000150112233445566778899AABBCCDDEEFF0FFFFFFFFC3. Here the first five bytes 0201041AFF are occupying my space.  In other words i want to a custom advertisement in which I can remove these bytes and can increase the major and minor values.

  • Hello again,

    Manoj Hiwarkar said:
    Here the first five bytes 0201041AFF are occupying my space.

    This is the significance of the bytes in question:
    - 0x02 0x01 0x04 = length: 2, type: FLAG, content:  BR/EDR(Classic Bluetooth is not supported)
    - 0x1A 0xFF = length: 26, type: MANUFACTURER SPECIFIC

    If you intend to comply with the BLE specifications, none of these bytes can be removed.
    If you would like to pursue a proprietary radio protocol please let me know.

    You may remove the flags from your advertising data by commenting out the line 184 in the Beacon example, where it is added to the advertising data:

    advdata.flags                 = flags;


    Have a look in Core Specification Supplement (CSS) v7: "The Flags data type shall be included when any of the Flag bits are non-zero". Since our Softdevice only supports Bluetooth LE the "BR/EDR not supported"-bit must always be set and hence, the Flags data type must be included.

    You are free to remove the flags yourself - you may do whatever you want with your application - but you will not be complying to the BLE specification by removing this flag.
    Furthermore, I suspect this will cause troubles when communicating with devices using both BLE and classic Bluetooth- such as SmartPhones.
    But once again, you are free to do this yourself.

    I ask again, is there a particular reason why you need the major and minor to be 4 bytes?
    If you are struggling fitting all your data into your advertising data, you might want to look into using scan responses to provide the excess data.

    Best regards,
    Karl

Reply
  • Hello again,

    Manoj Hiwarkar said:
    Here the first five bytes 0201041AFF are occupying my space.

    This is the significance of the bytes in question:
    - 0x02 0x01 0x04 = length: 2, type: FLAG, content:  BR/EDR(Classic Bluetooth is not supported)
    - 0x1A 0xFF = length: 26, type: MANUFACTURER SPECIFIC

    If you intend to comply with the BLE specifications, none of these bytes can be removed.
    If you would like to pursue a proprietary radio protocol please let me know.

    You may remove the flags from your advertising data by commenting out the line 184 in the Beacon example, where it is added to the advertising data:

    advdata.flags                 = flags;


    Have a look in Core Specification Supplement (CSS) v7: "The Flags data type shall be included when any of the Flag bits are non-zero". Since our Softdevice only supports Bluetooth LE the "BR/EDR not supported"-bit must always be set and hence, the Flags data type must be included.

    You are free to remove the flags yourself - you may do whatever you want with your application - but you will not be complying to the BLE specification by removing this flag.
    Furthermore, I suspect this will cause troubles when communicating with devices using both BLE and classic Bluetooth- such as SmartPhones.
    But once again, you are free to do this yourself.

    I ask again, is there a particular reason why you need the major and minor to be 4 bytes?
    If you are struggling fitting all your data into your advertising data, you might want to look into using scan responses to provide the excess data.

    Best regards,
    Karl

Children
No Data
Related