An issue related to the 31-byte limit of sent data in BLE

[Ömer]

Hey Nordic,

Currently, I am doing an internship about the applications of nRF52833 with SDK 17.1.0, and I am using this project file right now.

When I do "make -j all" and "make flash", I can see my device on nRF Connect app.

But when I also uncomment only the following code:

 //   int8_t tx_power                   = -4;// Set Power Level
 //   advdata.p_tx_power_level = &tx_power;

After saving, "make -j all" and "make flash" commands, my device doesn't appear in the scanned devices.

I remember that a senior engineer said when I try to send more data, something like overflow happens -at least this is what I remembered-. He said we have a limit of 31 bytes in BLE applications. But the concept didn't become clear for me. Could you explain or direct me to a reference?

Also, we discussed the propagation-reception concept. I believe that the antenna of the nRF52833 gets the information from the buffer, and when we have a longer sequence, there will be always some remaining part to the next sequence. Thus, the detection will not be able to done at the receiver side. This is my point of view.

On the other hand, he says, since the BLE sequence doesn't have the expected length, the DK will not even allow the antenna to propagate any sequence.

I might have explained both views in the not desired way but at least which one is the closest? Could you also direct me to a related reference about this issue?

Thanks,

Omer

[Einar Thorsrud]

Hi Omer,

There is no minimal packet length in BLE, but a normal advertising packet is maximum 31 bytes. This includes headers, so in practice you can use up to 27 bytes of manufacturer specific data. If you add Tx power, you will use 3 byte more (1 for type, one for length and 1 for the actual value). See What’s the Maximum Data Size you can send in a Bluetooth Advertising Packet?.

If you uncomment the code snippet with your tx_power and where advdata.p_tx_power_level is set, the latter will no longer be NULL (as you memset advdata to 0), so the Tx power will also be included, and then the advertising packet becomes too large. Have you done any debugging to see if everything looks good on the nRF side? If so you should see that you got an error because of that.

As you are also using a scan response packet and that is not full, you could consider including the Tx power there instead, by moving the code block down a few lines and modifying it like this:

    int8_t tx_power                   = -4;// Set Power Level
    srdata.p_tx_power_level = &tx_power;

[Ömer]

Hey Einar,

Actually, your answer was quite explanatory but I am also wondering how the propagation happens.

I mean, when the advertising packet becomes too large, does the antenna still do propagation? Or since the advertising packet is not well prepared, is there a mechanism to terminate the process?

I tried to use NRF_LOG_INFO() function for debugging in PuTTY, and I even don't see my log message of log_init() function -very first function to be executed in main.c- in the terminal of PuTTY. I don't see any errors while flashing but probably not seeing any messages means that actually my code doesn't work. And most probably, I guess the antenna is not being excited.

Thanks,

Omer

[Einar Thorsrud]

Hi Omer,

Ömer said:

I mean, when the advertising packet becomes too large, does the antenna still do propagation?

No, things stop a long time for that.

Ömer said:

Or since the advertising packet is not well prepared, is there a mechanism to terminate the process?

Yes. If you try to debug the application or simply enable debug logging and observe the log (and not just observe that "it does not work") you will see that generating the advertising packet will fail with the error code NRF_ERROR_DATA_SIZE returned from ble_advdata_encode(), and this is because the packet is too large. When I test a debug build with your firmware unmodified (except for uncommenting), I get this log, which is expected:

<info> app_timer: RTC: initialized.
<error> app: ERROR 12 [NRF_ERROR_DATA_SIZE] at C:\Users\eith\SDK\nRF5_SDK_17.1.0_ddde560\examples\other_projects\myproject_293207\main.c:276
PC at: 0x0002B655
<error> app: End of error report

When this happens, the error handler will either reset (so your device ends up in a reset loop) or enter an eternal loop to conserve the system state dependin on if you are testing a release build or a debug build (see An introduction to error handling in nRF5 projects for an intro to this).

Ömer said:

And most probably, I guess the antenna is not being excited.

That is correct.

[Ömer]

How do you do this debugging? I was told that debugging is not possible in the hardware level (I am compiling using vscode), and I only tried to use adding NRF_LOG_INFO() functions even to the "init" functions but I couldn't see any log message in PuTTY (in the case of included tx power).

Thanks for your detailed answer,

Omer

[Einar Thorsrud]

Hi Omer,

Debugging is certainly possible and is essential in all embedded development. As you are using GCC via VS Code setting up debugging requires a bit of work and is a bit more complex, so I would suggest using SES when debugging if you want something working out of the box. You are using an example application, and the SES project files are also part of the zip file you uploaded, and it builds out of the box. That is just a suggestion though, but as SES is free for use with Nordic ICs and time is money, that is what I would do. See 
Getting started with nRF5 SDK and SES (nRF51 & nRF52 Series) for a basic intro.

Ömer said:

adding NRF_LOG_INFO() functions even to the "init" functions but I couldn't see any log message in PuTTY (in the case of included tx power).

It could be that the log is not output in time if using a release build and using deferred logging (which is enabled by default). So you could modify the logging, make sure you define DEBUG and DEBUG_NRF in your Makefile or select Debug from the build configuration dropdown if migrating to SES (to make a debug build), and that way you should see the log.