Hi Hemant,

The UART config used in NCP is the following : speed 115200/8bits/No parity/1 stop bit. There is no routine in the BGAPI allowing you to modify that. If this has to be modified, you'd have to do it in the code.

That is, in your case, the ncp app code running on the target.

Hi Prasad,

May I ask what part are you working on ? is it a series 1 or series 2 chip ?

As you have pointed out, there isn't such a detailed memory usage description for the BT mesh stack as there is for BLE. Let me gather the figures for you once you will have told me that what chip you are actually using.

As for the peripheral usage, there isn't any extra restriction from the BT mesh point of view. Whether it is BLE  or BT mesh the same peripherals are restricted. That is because BT mesh is built on top of BLE.

Let me know.

  Regards.

Hi Prasad,

May I ask what part are you working on ? is it a series 1 or series 2 chip ?

As you have pointed out, there isn't such a detailed memory usage description for the BT mesh stack as there is for BLE. Let me gather the figures for you once you will have told me that what chip you are actually using.

As for the peripheral usage, there isn't any extra restriction from the BT mesh point of view. Whether it is BLE  or BT mesh the same peripherals are restricted. That is because BT mesh is built on top of BLE.

Let me know.

  Regards.

Hi Prasad,

May I ask what part are you working on ? is it a series 1 or series 2 chip ?

As you have pointed out, there isn't such a detailed memory usage description for the BT mesh stack as there is for BLE. Let me gather the figures for you once you will have told me that what chip you are actually using.

As for the peripheral usage, there isn't any extra restriction from the BT mesh point of view. Whether it is BLE  or BT mesh the same peripherals are restricted. That is because BT mesh is built on top of BLE.

Let me know.

  Regards.

Hi Prasad,

What you are referring to is the heap size as defined in the startup c file of the app image, is that correct (startup_efr32mg21.c for example is worling on mg21) ?

That is in effect different from the memory pool used by the BLE stack. You can set it to 0 (via the compiler directive). What will happen behind the the scene is that the .heap section will be setup to a minimum size (0xC00 located after the RAM section in the case of the mg21).

Hi dmitriy,

you mentioned that the module does not respond to the second command, but does boot properly upon reset ?

In your use case, how does the host update the BGM113's firmware exactly ?

Hi Rohan,

This is likely to be on the RasPi side. There a number of things you can try and test in order to check the advertisement duration.

One thing that comes to my mind is to use the energy profiler in studio. Doing so you should see the current consumption peaks that correspond to the Advertisement TX. In the profiler, you can measure the peak width and so one ...

This would also allow you to see if the consumption peaks are time drifting, thus verify that this part at least is working well.

You could also use the network analyser in studio and check the timestamps (for the drifting). Additionally, in order to understand at what exact time the interrupt is triggered you may try is to simply us a GPIO on the expansion header-> Set it up when entering the ISR and down when exiting. That way you could measure the timing on a scope or using a logic analyzer.

On the RasPi side, what exactly do you get the timestamps ? are you using BlueZ tools (btmgt or hcitools) ? 

Hi Rohan,

This is likely to be on the RasPi side. There a number of things you can try and test in order to check the advertisement duration.

One thing that comes to my mind is using the energy profiler in studio. Doing so you should see the current consumption peaks that correspond to the Advertisement TX. In the profiler, you can measure the peak width and so one ...

This would also allow to see if the consumption peaks are drifting and thus verify that this part at least working well.

You could also use the network analyser in studio and check the timestamps (for the drifting). Additionally, in order to understand at what exact time the interrupt is triggered you may try is to simply us a GPIO on the expansion header-> Set it up when entering the ISR and down when exiting. That way you could measure the timing on a scope or using a logic analyzer.

On the RasPi side, what exactly do you get the timestamps ? are you using BlueZ tools (btmgt or hcitools) ? 

Hi Manigandan,

You are mixing models and models types. Server/Client/Control are model types, the right way to think of models really is to think of it as state machines. Those types only categorize which type of state machine is it.

As a result, trying to get sample code for that is irrelevant. In this particular case I would suggest to read carefully section 2.3 of the Mesh profile spec "Architectural concepts".

Regards.