BLE advertisement not working well with Silicon BGM111 scanner

[Lumisoft]

Dear,

We have project using normal advertisement (not extended) on a nrf5340 module (Raytac MDBT53-1M) to send data using Manufacturer data.

We have a product already on market using a silicon BGM111 BLE module to get these advertisement data, and another one which will be replace by the one using nrf5340 which is doing for now the advertisement, so to say the data emission.

Problem is, the reception on BGM111 is working really badly when using the nrf5340: advertisement is often not detected or only when being really near (~2m). In the opposite, old emitter is working fast and from far (more than  50m).

I tried to reduced advertisement intervals like follow:

static struct bt_le_adv_param *adv_param =

BT_LE_ADV_PARAM(BT_LE_ADV_OPT_NONE, /* No options specified */

//32, //20ms

//64, //40ms

32, //20ms

48, //30ms

NULL);

I also tried to increase TxPower with these Kconfig in my prj.conf:

CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y
CONFIG_BT_USER_PHY_UPDATE=y
CONFIG_BT_CTLR_TX_PWR_MINUS_20=y
CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

However, it is not helping a lot. Are there some parameters that could be optimized (channels, tx power) so to reproduce the default parameters from BGM111 emitter so to be compatible with on market receptor product? Thanks a lot for your help.

Kind regards,

Michael

[Turbo J]

Check antenna design constraints. Sound like the signal is not radiated properly, BTLE tends to "work" within 1-2m with an open antenna port...

[Lumisoft]

I am using the Raytac MDBT53-1M with integrated antenna. When using an Android or iOs device for reception, I can get results over 50m and fast without problem, so I am thinking there could be something more specific with channels?

[Bendik Heiskel]

Hi Michael,

Which version of the nRF Connect SDK are you using?

The TX power configuration for the nRF5340 must be done in the config file for the image running on the network core.

The configs you show sets two TX powers, -20dBm and 8dBm, the nRF5340 have a maximum output power of 3dBm so the 8dBm setting will not work.

 

Have the recommended module placement as show in the module datasheet been followed?

 

Best regards,

Bendik

[Lumisoft]

Hi Bendik,

Thanks for you reply, I am using nrf SDK 2.7.0. I found indeed I should not exceed 3dBm for nrf5340, so I replaced with CONFIG_BT_CTLR_TX_PWR_PLUS_3=y in hci_ipc.conf. I noticed I had sometimes issues when calling BT_HCI_VS_LL_HANDLE_TYPE_ADV commands to get/set current Tx. If you have suggestion how to be able to set/get tx power and sys build (no child image use), would be maybe better for me (future NCS upgrade ready)?

In hci_ipc.conf I have

CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y
CONFIG_BT_CTLR_TX_PWR_PLUS_3=y

However, when calling:

	int8_t tx_power = 0;
	get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV, 0, &tx_power);
	LOG_WRN("Actual Tx Power: %d", tx_power);

I get error -1 with error:

bt_hci_core: opcode 0xfc0f status 0x01

Same errorstrying with zephyr/samples/bluetooth/hci_pwr_ctrl.

The PCB module placement is respected as you remind me on the picture (ground area respected).

Also, I am using a 3V regulator, would it be useful to use a 3.3v one? Would it help for the Tx?

Thanks a lot for your support.

Kind regards,

Michael

[Lumisoft]

One part of the question is answered, I found if not having as compilation root configuration file one "prj.conf" filename, it is leading to have cpunet core firmware missing some hci_ipc commands. Strange, but having for the compilation variant one prj_light.conf in addition to one prj.conf file is fixing this (even content is only split in the both files).
Sadly, I am now limited to this +3dBm Tx power, so question of changing regulator is still open. Thanks for you help.

Regards,

Michael