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

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

Einar Thorsrud — Tue, 02 Aug 2022 16:25:35 GMT

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.

[quote user="Omer Kati"]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).[/quote]

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.

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

Ömer — Tue, 02 Aug 2022 14:14:20 GMT

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

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

Einar Thorsrud — Tue, 02 Aug 2022 12:12:24 GMT

Hi Omer,

[quote user="Omer Kati"]I mean, when the advertising packet becomes too large, does the antenna still do propagation?[/quote]

No, things stop a long time for that.

[quote user="Omer Kati"]Or since the advertising packet is not well prepared, is there a mechanism to terminate the process?[/quote]

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).

[quote user="Omer Kati"]And most probably, I guess the antenna is not being excited.[/quote]

That is correct.

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

Ömer — Tue, 02 Aug 2022 12:00:21 GMT

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

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

Einar Thorsrud — Tue, 02 Aug 2022 08:06:08 GMT

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;