BLE advertisment flags problem

[dautor]

Is there a way to advertize without having to advertize advertisment flags?

The problem is because of these flags I only have 26 bytes left instead of full 29 bytes. It is crucial for me to have no less than 29 bytes.

I'm on the sdk version 11, nrf52832 being the chip I'm using.

Edit:

The MBED packet looks like this: "0x1EFF0000..." - [LEN=30, TYPE=0xFF, VALUE=0x0000...] On the other hand the packed I advertise via nRF_SDK looks like: "0x0201061BFF0000...", which is [LEN=2, TYPE=0x01, VALUE=0x06], [LEN=27, TYPE=0xFF, VALUE=0x0000...]. When I set the flags to 0 nrf connect says the packet is just empty.

I don't care about these flags and I can't get rid of them.

[Joakim Jakobsen]

Hi dautor!

There's several threads regarding this around DevZone.
Take a look at Sigurd's answer in this thread.

Best regards,
Joakim.

[dautor]

I see. The problem is that if I set it to 0 (omit flags) it does not recognize the packets and if i look at the in the raw window via nRF Connect it says empty. I have a program that was made with Mbed's implementation of BLE and there I'm able to send a packet that contains no flag information but is still recognizable by nRF Connect. Is there no way to replicate this behavior?

[RK]

can you sniff your MBED packet and see what's in it? And then sniff your no-flags nordic packet and see in what ways they differ? Something will be different.

[RK]

You don't care about them but the bluetooth standard DOES care about them and the Nordic softdevice is compliant with the standard. The MBED packet, if indeed it's BLE is an illegal and an ill-formed packet.

The Nordic functions which create advertising packets will only create standards-compliant ones.

If you make an actual product and do this, you will not pass BLE certification.

Of course since you have access to the raw advertising buffer you can do whatever you want, just don't go trying to get certified.