[Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered


Kai Ren
 

This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

 

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit, https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.

But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide, https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

 

This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.

 

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

 

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_MESH_GATT_PROXY=y

CONFIG_BT_MESH_PB_GATT=y

CONFIG_BT_MESH_PB_ADV=n

 

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?

 

Thanks.

Kai

 

 

 

 


Johan Hedberg
 

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@...> wrote:
This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.
But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html

“This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

CONFIG_BT_PERIPHERAL=y
CONFIG_BT_MESH_GATT_PROXY=y
CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_PB_ADV=n

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?
It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


Kai Ren
 

Hi Johan,
Thank so the reply!
I got the point and I built *mesh* application basing on microbit_gatt.conf, but the compiling console told me that RAM is oversize, 104.03%.

Memory region Used Size Region Size %age Used
FLASH: 105156 B 256 KB 40.11%
SRAM: 17044 B 16 KB 104.03%
IDT_LIST: 120 B 2 KB 5.86

The compiler I used is gcc-arm-none-eabi-8-2018-q4-major.
The commit is 3aa8443ab41202f978258810961dbc5a74ad2727

By the way, could you please share that what compiler you used and the specific version?


_____________________________
Regards,
Kai




On 2019/3/12, 10:54 PM, "Hedberg, Johan" <johan.hedberg@...> wrote:

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@...> wrote:
> This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727
>
> I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master following this guide and target device is micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
> I can compile source code (the compiler is gcc-arm-2018q4) and flash firmware into micro:bit.
> But after board reset, I found that I can’t use iOS app, nRF Mesh, to discover it. However, following this guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/README.html
>
> “This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”
>
> Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:
>
> CONFIG_BT_PERIPHERAL=y
> CONFIG_BT_MESH_GATT_PROXY=y
> CONFIG_BT_MESH_PB_GATT=y
> CONFIG_BT_MESH_PB_ADV=n
>
> Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?

It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


Kai Ren
 

Hi Johan,
I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.
I had done it, the micro:bit can be:
1. provisioned by nRF Mesh and meshctl through PB-GATT
2. don't support provisioningdata persistent storage;
3. model configuration, just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
4. don't support Proxy.
5. basing on Zephyr v1.12 release.

I tried to put it basing on v1.14-rc1, but I think it's impossible.


Best Regards,
Kai

-----Original Message-----
From: Hedberg, Johan <johan.hedberg@...>
Sent: Tuesday, March 12, 2019 10:54 PM
To: Kai Ren <kren@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Hi Kai,

On 12 Mar 2019, at 16.29, Kai Ren <kren@...> wrote:
This is the commit I used: 3aa8443ab41202f978258810961dbc5a74ad2727

I tried to build ./samples/Bluetooth/mesh/ product in Zephyr master
following this guide and target device is
micro:bit,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh
/README.html I can compile source code (the compiler is
gcc-arm-2018q4) and flash firmware into micro:bit.
But after board reset, I found that I can’t use iOS app, nRF Mesh, to
discover it. However, following this
guide,https://docs.zephyrproject.org/latest/samples/bluetooth/mesh/REA
DME.html

“This sample demonstrates Bluetooth Mesh functionality. It has several standard Mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that’s used for the Out-of-Band provisioning procedure.”

Then, I took a look on prj_bbc_microbit.conf in folder./samples/Bluetooth/mesh/, I found that it haven’t defined below:

CONFIG_BT_PERIPHERAL=y
CONFIG_BT_MESH_GATT_PROXY=y
CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_PB_ADV=n

Without these pre-define, how does micro:bit support PB-ADV and PB-GATT?
It doesn’t. It seems like a possible oversight with this configuration file. There’s a second one for this sample app called microbit_gatt.conf which does have PB_GATT=y. Note that the micro:bit with its 16k of RAM was always quite tricky when it came to fitting both the mesh and the provisioning protocols on it. That’s why we’ve done self-provisioning e.g. with samples/bluetooth/mesh_demo since it doesn’t require any provisioning bearer to be compiled in. I’d be curious to hear if you can still fit a Mesh + PB-GATT build onto the micro:bit, since I suspect Zephyr’s RAM footprint may have gone up slightly during the past year.

Johan


Johan Hedberg
 

Hi Kai,

On 15 Mar 2019, at 12.12, Kai Ren <kren@...> wrote:
I had done it, the micro:bit can be:
1. provisioned by nRF Mesh and meshctl through PB-GATT
2. don't support provisioningdata persistent storage;
3. model configuration, just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
4. don't support Proxy.
5. basing on Zephyr v1.12 release.

I tried to put it basing on v1.14-rc1, but I think it's impossible.
I wouldn’t say it’s impossible. I bet there’s still place for memory optimisation, e.g. thread stacks that can be shrunk, buffer sizes & counts that can be lowered, and possibly unneeded features that can be disabled. Someone would just need to find the time to look into this :)

Johan


Kai Ren
 

Hi Johan,
Thanks for the prompt reply.
I think you're expert of Zephyr Bluetooth, I have two questions before getting into the detail for optimization:
1. compiling same sample code, like sample/bluetooth/mesh/, compared with v1.12.0, do you think v1.14.0 is hungry or efficient for RAM consumption?
2. as your estimation, how many bytes will be consumed if add persistent storage?



Best Regards,
Kai

-----Original Message-----
From: Hedberg, Johan <johan.hedberg@...>
Sent: Friday, March 15, 2019 6:23 PM
To: Kai Ren <kren@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Hi Kai,

On 15 Mar 2019, at 12.12, Kai Ren <kren@...> wrote:
I had done it, the micro:bit can be:
1. provisioned by nRF Mesh and meshctl through PB-GATT 2. don't
support provisioningdata persistent storage; 3. model configuration,
just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
4. don't support Proxy.
5. basing on Zephyr v1.12 release.

I tried to put it basing on v1.14-rc1, but I think it's impossible.
I wouldn’t say it’s impossible. I bet there’s still place for memory optimisation, e.g. thread stacks that can be shrunk, buffer sizes & counts that can be lowered, and possibly unneeded features that can be disabled. Someone would just need to find the time to look into this :)

Johan


Carles Cufi
 

Hi Kai,

Hijacking the thread a bit here but have you considered using an nRF52-based board instead of the micro:bit? There's quite a few of them in really interesting form factors, including the reel_board and many others:

https://docs.zephyrproject.org/latest/boards/arm/index.html

(unfortunately I cannot filter by nRF52 but you can look around)

Carles

On 15/03/2019, 15:49, "devel@... on behalf of Kai Ren via Lists.Zephyrproject.Org" <devel@... on behalf of kren=bluetooth.com@...> wrote:

Hi Johan,
Thanks for the prompt reply.
I think you're expert of Zephyr Bluetooth, I have two questions before getting into the detail for optimization:
1. compiling same sample code, like sample/bluetooth/mesh/, compared with v1.12.0, do you think v1.14.0 is hungry or efficient for RAM consumption?
2. as your estimation, how many bytes will be consumed if add persistent storage?



Best Regards,
Kai

-----Original Message-----
From: Hedberg, Johan <johan.hedberg@...>
Sent: Friday, March 15, 2019 6:23 PM
To: Kai Ren <kren@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] [Bluetooth mesh]unprovisioned device (micro:bit) can't be discovered

Hi Kai,

On 15 Mar 2019, at 12.12, Kai Ren <kren@...> wrote:
> I had done it, the micro:bit can be:
> 1. provisioned by nRF Mesh and meshctl through PB-GATT 2. don't
> support provisioningdata persistent storage; 3. model configuration,
> just two models here: Configuration Server and Generic OnOff Server. Micro:bit can be configured through PB-GATT.
> 4. don't support Proxy.
> 5. basing on Zephyr v1.12 release.
>
> I tried to put it basing on v1.14-rc1, but I think it's impossible.

I wouldn’t say it’s impossible. I bet there’s still place for memory optimisation, e.g. thread stacks that can be shrunk, buffer sizes & counts that can be lowered, and possibly unneeded features that can be disabled. Someone would just need to find the time to look into this :)

Johan