Date   

Re: [Zephyr-devel] [ #BluetoothMesh ] possible Bug .. without assigning subscription address to Model, it is reacting to subscription address assign to other Model #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,
It was bug from my side & I've resolved it.
Now everything is working as expected.

Excuse me for that !!

On Wed, May 2, 2018 at 2:31 PM, Vikrant More <vikrant8051@...> wrote:
Hi,

I gone through my code once again & found that it was small bug from my side.
I had forgotten to add "break" in my customized version of $zephyr/samples/bluetooth/mesh .

Extremely sorry for that.

//------------------------------------------------------------------------doer.c----------------------------------------------------------------------------------------------------------------------

#include "common.h"

int8_t  gen_onoff_srv_state, last_gen_onoff_srv_state;
int16_t gen_level_srv_state, last_gen_level_srv_state;

void doer(struct bt_mesh_model *model, struct bt_mesh_msg_ctx *ctx, struct net_buf_simple *buf, uint16_t opcode)
{
    int err=0;

    int8_t tmp8;
   
    int16_t tmp16;

    struct net_buf_simple *msg;

    switch(opcode)
    {

        case 0x8201:    //GEN_ONOFF_SRV_GET

            msg = NET_BUF_SIMPLE(2 + 1 + 4);

            bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x04));

            net_buf_simple_add_u8(msg, gen_onoff_srv_state);

            if (bt_mesh_model_send(model, ctx, msg, NULL, NULL))
            {
                printk("Unable to send GEN_ONOFF_SRV Status response\n\r");
            }
       
           break;


        case 0x8203:    //GEN_ONOFF_SRV_UNACK

            msg = model->pub->msg;

            gen_onoff_srv_state = (unsigned char)global_state;

            if(last_gen_onoff_srv_state != gen_onoff_srv_state )
            {
                last_gen_onoff_srv_state = gen_onoff_srv_state;

                if(gen_onoff_srv_state != 0)
                {
                    NRF_P0->OUT &= ~(1<<13);    //LED ON
                }
                else
                {
                    NRF_P0->OUT |=  (1<<13);    //LED OFF   
                }

                if(model->pub->addr != BT_MESH_ADDR_UNASSIGNED)
                {

                    bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x04));
                    net_buf_simple_add_u8(msg, gen_onoff_srv_state);

                    err = bt_mesh_model_publish(model);

                    if(err)
                    {
                        printk("bt_mesh_model_publish err %d", err);
                    }

                }
            }

            break;

        case 0x8204:    //GEN_ONOFF_SRV_STATUS

            tmp8 = net_buf_simple_pull_u8(buf);

            NRF_P0->OUT ^= (1<<16);

            printk("Acknownledgement from GEN_ONOFF_SRV = %u\n\r",tmp8);

            break;

        case 0x8205:    //GEN_LEVEL_SRV_GET
           
            msg = NET_BUF_SIMPLE(10);

            bt_mesh_model_msg_init(msg, BT_MESH_MODEL_OP_2(0x82, 0x08));

            net_buf_simple_add_le16(msg, gen_level_srv_state);

            if(bt_mesh_model_send(model, ctx, msg, NULL, NULL))
            {
                printk("Unable to send GEN_LEVEL_SRV Status response\n\r");
            }

            break;

        case 0x8207:    //GEN_LEVEL_SRV_UNACK

            msg = model->pub->msg;

            gen_level_srv_state = (int16_t)global_state;

            if(last_gen_level_srv_state != gen_level_srv_state )
            {
                last_gen_level_srv_state = gen_level_srv_state;

                printk("gen_level_srv_state = %d \n\r" , gen_level_srv_state );
               
                if(gen_level_srv_state > 10000)
                {   
                    CLRB(NRF_P0->OUT,15);
                    SETB(NRF_P0->OUT,16);
                }
                else
                {   
                    CLRB(NRF_P0->OUT,16);
                    SETB(NRF_P0->OUT,15);
                }
                               
                if(model->pub->addr != BT_MESH_ADDR_UNASSIGNED)
                {

                    bt_mesh_model_msg_init(msg,BT_MESH_MODEL_OP_2(0x82, 0x08));

                    net_buf_simple_add_le16(msg,gen_level_srv_state);

                    err = bt_mesh_model_publish(model);

                    if (err)
                    {
                        printk("bt_mesh_model_publish err %d", err);
                    }

                }
            }       
   
            break;

        case 0x8208:    //GEN_LEVEL_SRV_STATUS

            tmp16 = net_buf_simple_pull_le16(buf);
            printk("Acknownledgement from GEN_LEVEL_SRV = %d\n\r",tmp16);

            break;

        case 0x820A:    //GEN_DELTA_SRV_UNACK
           
            break;

        case 0x820C:    //GEN_MOVE_SRV_UNACK
           
            break;

        default:

           break;
    }
}



On Wed, Apr 25, 2018 at 9:28 PM, Vikrant More <vikrant8051@...> wrote:
Hi Kai,

Please see attached mesh.zip file for what you had asked. (Refer DEVICE_composition.c for 
static struct bt_mesh_model root_models[] = {};
             static struct bt_mesh_elem elements[] = { }; )

I have break provided #ZephyrBluetoothMesh sample code into multiple files for simplicity.

Have you faced same issue ?

Please let me Know, if there is bug from my side & keep me in loop if you are going to ask further queries based on it.

Thank You !!

On Wed, Apr 25, 2018, 8:39 PM Vikrant More <vikrant8051@...> wrote:
Hi Kai,
Sorry, today I was busy & didn't get time to access my email. Right now I am on the way to my Home. Tomorrow I will definitely share what you have asked.

Thanks !!

On Wed, Apr 25, 2018, 9:21 AM Kai Ren <kren@...> wrote:
Hi vikrant8051,
Could you please share the following definitions?
             static struct bt_mesh_model root_models[] = {};
             static struct bt_mesh_elem elements[] = { };

Thanks!

Kai




Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi to all,

cd $(zephyr_base)
git fetch origin pull/7283/head:BlueZMeshctl
git checkout BlueZMeshctl 

I execute above commands & re-build samples/bluetooth/mesh & try to provision 
it using BlueZ 5.49 #meshctl. And this time, whole process has completed.

Thank You !!



On Tue, May 1, 2018 at 11:01 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
> > That's a good catch. I'm sorry for not realizing it earlier. I've
> > uploaded an untested pull request that attempts to fix this. Could
> > you
> > try it please:
> >
> >     https://github.com/zephyrproject-rtos/zephyr/pull/7283
>
> Works for me.
>
> Provisioning completes on samples/bluetooth/mesh and connects for
> configuration. The identity connection had previously failed.

Thanks for testing. Could you also please add some sort of "tested to be
working" comment in the PR to help it get merged?

> It's curious that the SILabs provisioner reportedly worked.

It'd indeed be interesting for someone to analyze the difference. E.g.
perhaps it doesn't disconnect the link in between, or maybe it connects
to Network ID advertising (however shouldn't meshctl work then as
well?).

Johan


Zephyr hci_usb nrf52840

Nathan Miller
 

Hi all,

I am trying to test an nRF52840 as a USB HCI using the Zephyr hci_usb sample project. I'm running into an issue in which devices I attempt to connect to will disconnect themselves after about 30 seconds, every time I attempt to connect. When I watch btmon, I see this:

< ACL Data TX: Handle 0 flags 0x00 dlen 7                  #15 [hci0] 17.698158
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
< HCI Command: Disconnect (0x01|0x0006) plen 3             #16 [hci0] 49.737234
        Handle: 0
        Reason: Remote User Terminated Connection (0x13)

it appears that the device never receives or never responds to the Exchange MTU Request. I'm using bluetoothctl to establish the connection. I've tried two different device types and both exhibit the problem, and when I attempt to use the internal adapter on my host, I do not have this problem with either device. My host is an x86_64 machine running Ubuntu 16.04.4, kernel version 4.13.0-39, and BlueZ version 5.49. I've attempted it with both a Nordic PCA10056 board and a Rigado BMD-340 dev board. Has anyone seen this before? I'm not entirely sure what steps to take next to debug this. I can provide any additional info necessary.


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could
you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283
Works for me.

Provisioning completes on samples/bluetooth/mesh and connects for
configuration. The identity connection had previously failed.
Thanks for testing. Could you also please add some sort of "tested to be
working" comment in the PR to help it get merged?

It's curious that the SILabs provisioner reportedly worked.
It'd indeed be interesting for someone to analyze the difference. E.g.
perhaps it doesn't disconnect the link in between, or maybe it connects
to Network ID advertising (however shouldn't meshctl work then as
well?).

Johan


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Steve Brown
 

Hi Johan,

On Tue, 2018-05-01 at 16:37 +0100, Johan Hedberg wrote:
Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
It doesn't appear that bt_mesh_proxy_identity_enable() gets called
in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes
the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey:
7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce:
3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey:
b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005,
addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534
type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags
0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB()
added just before bt_mesh_proxy_identity_enable() >>>>>>
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could
you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283

Thanks.

Johan
Works for me.

Provisioning completes on samples/bluetooth/mesh and connects for
configuration. The identity connection had previously failed.

It's curious that the SILabs provisioner reportedly worked.

Steve


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi Steve,

On Tue, May 01, 2018, Steve Brown wrote:
It doesn't appear that bt_mesh_proxy_identity_enable() gets called in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey: 7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce: 3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey: b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005, addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534 type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags 0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB() added just before bt_mesh_proxy_identity_enable() >>>>>>
That's a good catch. I'm sorry for not realizing it earlier. I've
uploaded an untested pull request that attempts to fix this. Could you
try it please:

https://github.com/zephyrproject-rtos/zephyr/pull/7283

Thanks.

Johan


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Steve Brown
 

Hi,

I had a chance to look at this further.

More at the bottom.


On Thu, 2018-04-26 at 15:24 +0300, Johan Hedberg wrote:
Hi,

This was already identified as a bug in meshctl by Steve, a week ago
or
so. However, I haven't seen a patch submitted to BlueZ yet.

Johan

On Thu, Apr 26, 2018, Kai Ren wrote:
Hi Vikrant,
I just did two tests today, the detail is:

1st test. I built “onoff-app” example basing on latest Zephyr
project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of
today, you can see that my log is the same like yours, after close
the connection, need to initial a new connection, but it’s failed.


[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb

Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX: 03 00 10

GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00

Got provisioning data (12 bytes)

01 04 00 01 00 00 06 00 18 00 00 00

GATT-TX: 03 02 00 00 02 04 06

GATT-TX: 03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56

GATT-TX: 93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be

GATT-TX: 75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c

GATT-TX: 3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9

GATT-TX: e9 60

GATT-RX: 03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44

GATT-RX: 68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4

GATT-RX: 01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43

GATT-RX: 49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3

GATT-RX: 4c bf

Got provisioning data (65 bytes)

03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68

cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01

32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49

a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c

bf

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX: 03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3

GATT-TX: 83 c4

GATT-RX: 03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d

GATT-RX: 90 76

Got provisioning data (17 bytes)

05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90

76

GATT-TX: 03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18

GATT-TX: d8 91

GATT-RX: 03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62

GATT-RX: b1 ea

Got provisioning data (17 bytes)

06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1

ea

Confirmation Validated

S-Key 37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14

S-Nonce d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f

Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12

Data 00 00 00 00 00 00 05 01 13

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca

DataEncrypted + mic 5b

GATT-TX: 03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb

GATT-TX: 6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d

GATT-TX: 0f ca 5b

GATT-RX: 03 08

Got provisioning data (1 bytes)

08

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]#


2nd test, I “make clean” and “make”, this time, “onoff-app” is
basing on the commit, c33087d3366f395168d477feb631aae1785a008e on
March 29th, it works well, you can see below screenshot that BlueZ
could get Composition Data.

[meshctl]# provision 135334dd01cf00000000000000000000
Trying to connect Device CF:01:DD:34:53:13 Zephyr
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1915e08
Open-Prov: 0x19149d0
Open-Prov: proxy 0x19124d8
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 03 00 10
GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00
Got provisioning data (12 bytes)
01 04 00 01 00 00 06 00 18 00 00 00
GATT-TX: 03 02 00 00 02 04 06
GATT-TX: 03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4
GATT-TX: 51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4
GATT-TX: 0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7
GATT-TX: fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f
GATT-TX: e1 0f
GATT-RX: 03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e
GATT-RX: 4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18
GATT-RX: 1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2
GATT-RX: e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6
GATT-RX: 7c 49
Got provisioning data (65 bytes)
03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e
1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c
5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3
32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c
49
Request ASCII key (max characters 6)
[mesh] Enter key (ascii string): RZTCNG
GATT-TX: 03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd
GATT-TX: fa f7
GATT-RX: 03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17
GATT-RX: 3c a3
Got provisioning data (17 bytes)
05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c
a3
GATT-TX: 03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27
GATT-TX: dd dc
GATT-RX: 03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64
GATT-RX: b7 9f
Got provisioning data (17 bytes)
06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7
9f
Confirmation Validated
S-Key 2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec
S-Nonce 69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03
DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 1b
DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d
DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71
DataEncrypted + mic 2b
GATT-TX: 03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff
GATT-TX: 3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7
GATT-TX: 3c 71 2b
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 011b
Attempting to disconnect from CF:01:DD:34:53:13
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Write closed
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved no
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

Mesh Proxy Service (00001828-0000-1000-8000-
00805f9b34fb)
Identity for node 011b
Trying to connect to mesh
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid
00002add-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid
00002ade-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Proxy Out Data started
Trying to open mesh session
GATT-RX: 01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4
GATT-RX: 0a 41 fa b0 af 32 0b
iv_upd_state = IV_UPD_NORMAL
Mesh session is open
Characteristic property changed
/org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02
GATT-TX: a7 77 d9 51
GATT-TX: 00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07
GATT-TX: 57 67 06 0c 51 02
GATT-RX: 02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0
GATT-RX: 78 86 79 a1 ea fd
Proxy Whitelist filter length: 0
GATT-RX: 00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e
GATT-RX: 4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d
GATT-RX: 00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb
GATT-RX: 2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9
GATT-RX: 00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39
GATT-RX: 97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71
GATT-RX: 00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc
GATT-RX: 7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30
GATT-RX: 00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92
GATT-RX: ea eb dc 22 e8 61 3e d5 02 5b 3c 12
Composition data for node 011b {
"cid":"05f1",
"pid":"0000",
"vid":"0000",
"crpl":"000a",
"features":{
"relay":true,
"proxy":true,
"friend":false,
"lpn":false
},
"elements":[
{
"elementIndex":0,
"location":"0000",
"models":[
"0000",
"0001",
"0002",
"1000",
"1001"
]
},
{
"elementIndex":1,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":2,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":3,
"location":"0000",
"models":[
"1000",
"1001"
]
}
]
}
GATT-TX: 00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65
GATT-TX: 0b f9 13 7b fb 95 19 e4 a5
[Zephyr-Node-011b]#

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys,
just guessing…

Regards,
Kai



From: Vikrant More <vikrant8051@gmail.com>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@bluetooth.com>, "devel@lists.zephyrproject.org" <
devel@lists.zephyrproject.org>, "users@lists.zephyrproject.org" <us
ers@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh
provisioning & configuration process using #meshctl (5.49)

HI Kai,
Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh
library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did
not complete.

This is complete log,
-----------------------------------------------------------------
-----------------------------------------------------------------
-----------------------------------------------------------------
-------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid
00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid
00002adc-0000-1000-8000-00805f9b34fb
Start notification on
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX: 03 00 10
GATT-RX: 03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX: 03 02 00 00 00 00 00
GATT-TX: 03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX: 2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX: 4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX: 31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX: 52 ea
GATT-RX: 43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX: 10 28 b4 89
GATT-RX: 83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX: 87 b9 2b a3
GATT-RX: 83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX: b7 1a f5 1d
GATT-RX: c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
27
GATT-TX: 03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX: 82 90
GATT-RX: 03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX: 59 d0
Got provisioning data (17 bytes)
05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
d0
GATT-TX: 03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX: a2 b6
GATT-RX: 03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX: f1 88
Got provisioning data (17 bytes)
06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
88
Confirmation Validated
S-Key bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce 1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey 24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 00
DataEncrypted + mic 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
37 19
DataEncrypted + mic 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
50 01
DataEncrypted + mic 67
GATT-TX: 03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX: 37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX: 50 01 67
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed
/org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@gmail.co
m<mailto:vikrant8051@gmail.com>> wrote:
Hi Kai,

Yes, you are right. Thanks for sharing it.

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@bluetooth.com<mailto:kr
en@bluetooth.com>> wrote:

Hi Vikrant8051,

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make
model configuration, use meshctl "menu onoff" to control LED on and
off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last
week, it was successful, so BlueZ works well, the issue may be from
Zephyr.

Kai

It doesn't appear that bt_mesh_proxy_identity_enable() gets called in
prov.c:proxy_data(). The earlier call to bt_mesh_provision() closes the
connection when it calls bt_mesh_proxy_prov_disable().

Here is a snippet of debug output:

[bt] [DBG] prov_data: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) SessionKey: 7b7a94f1ca0aa42fdf79219292e28155
[bt] [DBG] prov_data: (0x20001fc8) Nonce: 3a06c3b351f1ab2b4d6462cb60
[bt] [DBG] prov_data: (0x20001fc8) DevKey: b495b3a317a5b18a708a2f41d3685860
[bt] [DBG] prov_data: (0x20001fc8) net_idx 0 iv_index 0x00000005, addr 0x0100
[bt] [DBG] proxy_segment_and_send: (0x20001fc8) conn 0x20000534 type 0x03 len 1: 08
[bt] [DBG] proxy_send: (0x20001fc8) 2 bytes: 0308
[bt] [INF] bt_mesh_provision: Primary Element: 0x0100
[bt] [DBG] bt_mesh_provision: (0x20001fc8) net_idx 0x0000 flags 0x00 iv_index 0x0005
[bt] [DBG] bt_mesh_proxy_prov_disable: (0x20001fc8)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001fc8) conn 0x20000534
[bt] [DBG] bt_mesh_proxy_gatt_enable: (0x20001fc8)
[bt] [DBG] bt_mesh_adv_update: (0x20001fc8)
[bt] [DBG] bt_mesh_scan_enable: (0x20001fc8)
[bt] [DBG] prov_data: (0x20001fc8) conn 0x00000000 <<<<< BT_DGB() added just before bt_mesh_proxy_identity_enable() >>>>>>

Steve


Re: Going mad about I2C #i2c #stm32 #nrf51822

Yannis Damigos
 

Hi Roman,

you need to update boards pinmux.c file to add the I2C pins. You could
check olimexino_stm32 board's pinmux file for reference.

Yannis
On Mon, Apr 30, 2018 at 10:36 AM Roman Tataurov <diytronic@yandex.ru> wrote:

MCU is this
https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/arch/arm/soc/st_stm32/stm32f1
Using this board
https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/boards/arm/stm32_min_dev

Seems it completely off i2c devices so added to board dts
&i2c1 {
status = "ok";
};
&i2c2 {
status = "ok";
};
To make it work. Together with bug fixed about DTS
https://github.com/zephyrproject-rtos/zephyr/issues/7248 I have now I2C
device created. So code is work now.
But still no activities on device pins. Checked all the pins with logick
analser and found nothing.

I suspect some GPIO setup required.


Re: Going mad about I2C #i2c #stm32 #nrf51822

Roman Tataurov
 

MCU is this https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/arch/arm/soc/st_stm32/stm32f1
Using this board https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/boards/arm/stm32_min_dev

Seems it completely off i2c devices so added to board dts 

&i2c1 {
        status = "ok";
};
 
&i2c2 {
        status = "ok";
};
To make it work. Together with bug fixed about DTS https://github.com/zephyrproject-rtos/zephyr/issues/7248 I have now I2C device created. So code is work now. 
But still no activities on device pins. Checked all the pins with logick analser and found nothing.

I suspect some GPIO setup required.


Re: Going mad about I2C #i2c #stm32 #nrf51822

Rodrigo Peixoto <rodrigopex@...>
 

Describe better your environment.

Which board (and no MCU) are you using? Based on the http://docs.zephyrproject.org/boards/arm/nucleo_f103rb/doc/nucleof103rb.html it seems that the i2c_1 that it might be the I2C_0 in Zephyr is on the PORTB. I have added the following line #define CONFIG_I2C_0_NAME "PORTB". For the https://github.com/zephyrproject-rtos/zephyr/tree/d6e3f22fddccf4b542cb5ec780440cb629c12290/samples/drivers/i2c_fujitsu_fram example. It compiles but I don't have the board here to test.

Try this and let us know.

Best regards, Rodrigo Peixoto.


Re: Going mad about I2C #i2c #stm32 #nrf51822

Rodrigo Peixoto <rodrigopex@...>
 

Hi Roman,

I was taking a look at the list and I've found something that may help you. Go to the link https://lists.zephyrproject.org/g/users/message/371 and check the solution. I think that maybe you can try something similar to that. Remember that the hardware used in the example is a nrf52 and yours is a nrf51, but the device names for this case are the same.

The STM32F103 I don't know the dev name. You can check that directly on the source code (board.h -> https://github.com/zephyrproject-rtos/zephyr/blob/d6e3f22fddccf4b542cb5ec780440cb629c12290/boards/arm/nucleo_f103rb/board.h). Maybe the name for the device is PORTA or PORTC it depends on the which one is the I2C port for your project.

I hope it helps.

Best regards, Rodrigo Peixoto. Ayna Tech +55 (82) 98144-8585.


Going mad about I2C #i2c #stm32 #nrf51822

Roman Tataurov
 

Hello!

Today almost whole day frustrating trying to make work I2C on Zephyr.
Tested on 2 different boards with nrf51822 and stm32f103 MCU-s and got no success.

Any options for both MCU-s different than bitbang I2C even return null for device_get_binding so I can't even initialize it. 
In case of bitbang I2C implementation device driver exists but does not work. Mean code executed, but I see nothing on MCU pins. 
Mapped to different GPIO variants, checked with logick analyzer on all the pins but nothing. It just does not work at all.

So can anobody explain right path to make it finally work.

So for STM32 (not a bitbang) used with:

CONFIG_GPIO=y
CONFIG_GPIO_STM32=y
CONFIG_GPIO_STM32_PORTA=y
CONFIG_GPIO_STM32_PORTB=y

CONFIG_I2C=y
CONFIG_I2C_INIT_PRIORITY=60
CONFIG_SYS_LOG_I2C_LEVEL=4
# CONFIG_I2C_0 is not set     <-------- tested with this as well
CONFIG_I2C_1=y 
# CONFIG_I2C_2 is not set
# CONFIG_I2C_3 is not set
# CONFIG_I2C_DW is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_SBCON is not set
CONFIG_I2C_STM32=y
CONFIG_I2C_STM32_V1=y

For nrf51 dont remember but can try again and put config here.

Any help appreciated.



Re: Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto <rodrigopex@...>
 

Vikrant and others, I was wondering here... Is there any way of using Bluetooth mesh by using the Nordic HAL (NRFX) instead of using the Zephyr's one?

Thank you. Best regards, Rodrigo Peixoto.


Re: Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto <rodrigopex@...>
 

Vikrant,
answering inline. 

Working on #DFU_OTA feature is not at top of my priority list. I had just checked it & try to understand overall mechanism. 

Ok.
 
Now I will prefer to wait till 
1) Zephyr #BluetoothMesh stack allow us to save Provisioning & Configuration details on SoC flash

2) plus it should also take care of saving data like sequence no. &  Model states on SoC flash on periodic basis

This is important, because Device firmware upgrade OTA should not changed those data if overall process is going to be automatic for end-user perspective.

There will be roughly four section in SoC flash-

1. for MCUboot
2. for flash memory (which will acts like eeprom)
3. slot_0 (current image)
4. slot_1 ( temporary location for new image after DFU )

This is not yet defined. Plus we don't know how to do DFU_OTA using Android or iOS App. 

So let's us go step by step. Hope upcoming LTS 1.12 come up as complete solution.

I really need that.
 
Meanwhile, we can work on Friend & Low Power Node implementation, design Models which are mentioned in attached image.

Do you need help on that? I am a little bit confusing. 
I was willing to create the sample related to OTA and mesh. But if there is other sample as you said related to mesh, it would be a pleasure to help.

Is there any thing I can do?

Best regards,
Rodrigo Peixoto.


Re: Device Firmware Update + Zephyr + #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Rodrigo,

Working on #DFU_OTA feature is not at top of my priority list. I had just checked it & try to understand overall mechanism. 

Now I will prefer to wait till 
1) Zephyr #BluetoothMesh stack allow us to save Provisioning & Configuration details on SoC flash

2) plus it should also take care of saving data like sequence no. &  Model states on SoC flash on periodic basis

This is important, because Device firmware upgrade OTA should not changed those data if overall process is going to be automatic for end-user perspective.

There will be roughly four section in SoC flash-

1. for MCUboot
2. for flash memory (which will acts like eeprom)
3. slot_0 (current image)
4. slot_1 ( temporary location for new image after DFU )

This is not yet defined. Plus we don't know how to do DFU_OTA using Android or iOS App. 

So let's us go step by step. Hope upcoming LTS 1.12 come up as complete solution.

Meanwhile, we can work on Friend & Low Power Node implementation, design Models which are mentioned in attached image.

Regards,
Vikrant

On Fri, Apr 27, 2018, 7:44 PM Rodrigo Peixoto <rodrigopex@...> wrote:

Hi vikrant.

I could do the integration! Now the SMP_Server sample is integrated to the mesh one. I need to play a little more with it. I have already tested the mcumgr a lot, but not too much the mesh one after the integration. I am considering the possibility of creating a sample with the integrated code.

What do you think? Necessary?

Best regards, Rodrigo Peixoto.


Re: Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto <rodrigopex@...>
 

Hi vikrant.

I could do the integration! Now the SMP_Server sample is integrated to the mesh one. I need to play a little more with it. I have already tested the mcumgr a lot, but not too much the mesh one after the integration. I am considering the possibility of creating a sample with the integrated code.

What do you think? Necessary?

Best regards, Rodrigo Peixoto.


Re: time between two packets(advertisement)

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

Hi Swapnil,

On 25 Apr 2018, at 09:21, swapnil <swapnil2007kadam@gmail.com> wrote:

Hello,
is it possible to change the time or provide a delay between two consecutive packets sent on two different advertising channels?
No, not without changing the implementation. Changing or having such a delay means that the reserved time of BLE event should also be adjusted. And, such a delay would also reduce overall on-air radio utilisation, reducing the implementations throughput.

packet on channel 37 --> delay --> packet on channel 38 --> delay -->packet on channel 39.
(delay = time between the start of the packet on 1 channel and the start of the packet on another channel.)

as per the core specifications delay could be <= 10ms but I checked the existing delay which is less than 200us ( i could be wrong). is it possible to change the delay by changing some value in ctrl.c or somewhere else?
Under non-connectable advertising, if I remember correct, the end of packet on one channel to the start of packet on another channel is as low as 70 us in the nRF52 series implementations (lower the better!).
No, no simple change of value in ctrl.c would provide you such delay.

You are asking a very difficult feature, to reduce radio utilisation/throughout ;-). But yes, if we can “design" with radio utilisations inside these delays, such a feature is reasonable, but so far there is no such strong requirement to delay or expand an advertising event time beyond its lowest possible event length.

Thank you in advance.
regards,
Swapnil
Regards,
Vinayak


Re: NXP MCUX RTC implementation

Franco Saworski <franco.saworski@...>
 

Thanks to everyone offering help.
We finished the project and pushed a pullrequest [1] to add an NXP MCUX RTC driver to Zephyr.

Kind regards,
Franco


On Sun, 1 Apr 2018 at 12:32 Michael Hope <michaelh@...> wrote:
Hi Franco.  I don't know of any technical limitation, but from what I've seen so far the Zephyr community takes a broad but shallow approach - for example, I've been adding support for the SAMD21 used in the Arduino Zero so I've focused on the SPI, USB, Flash, and GPIO drivers that I need and skipped others like PWM or ADC.

-- Michael
On Wed, 28 Mar 2018 at 16:20 Franco Saworski <franco.saworski@...> wrote:
Hi,

we at blik are working with Zephyr on one of our hardware units, and would like to use a lowpower mechanism along with an RTC wakeup.

Unfortunately RTC implementations are sparse, with only one implementation present. Is there a technical limitation or reason for this?
As far as I understand, SoC lowpower implementations are omitted in Zephyr, because they are usually usecase specific. I can't imagine the same for RTC.

Furthermore, we are looking for someone to develop the RTC driver and ultimately upstream it, as a small paid project. Please feel free to message me, if you're interested.

Kind regards,
Franco Saworski


--

Embedded Engineer

blik GmbH
transparent real-time data

HRB: 233881 | Amtsgericht München
Geschäftsführer: Bastian Burger, Philip Eller, Victoria Hauzeneder

Information in this email - including any attachments - may be privileged, confidential and is intended exclusively for the addressee(s). If you are not the intended recipient, please notify the sender and delete all copies from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone.
_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
--

Embedded Engineer

blik GmbH
transparent real-time data

Leonrodstraße 68 | 80636 München
HRB: 233881 | Amtsgericht München
Geschäftsführer: Bastian Burger, Philip Eller, Victoria Hauzeneder

Information in this email - including any attachments - may be privileged, confidential and is intended exclusively for the addressee(s). If you are not the intended recipient, please notify the sender and delete all copies from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone.


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Johan Hedberg
 

Hi,

This was already identified as a bug in meshctl by Steve, a week ago or
so. However, I haven't seen a patch submitted to BlueZ yet.

Johan

On Thu, Apr 26, 2018, Kai Ren wrote:
Hi Vikrant,
I just did two tests today, the detail is:

1st test. I built “onoff-app” example basing on latest Zephyr project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of today, you can see that my log is the same like yours, after close the connection, need to initial a new connection, but it’s failed.


[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX: 03 00 10

GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00

Got provisioning data (12 bytes)

01 04 00 01 00 00 06 00 18 00 00 00

GATT-TX: 03 02 00 00 02 04 06

GATT-TX: 03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56

GATT-TX: 93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be

GATT-TX: 75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c

GATT-TX: 3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9

GATT-TX: e9 60

GATT-RX: 03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44

GATT-RX: 68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4

GATT-RX: 01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43

GATT-RX: 49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3

GATT-RX: 4c bf

Got provisioning data (65 bytes)

03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68

cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01

32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49

a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c

bf

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX: 03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3

GATT-TX: 83 c4

GATT-RX: 03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d

GATT-RX: 90 76

Got provisioning data (17 bytes)

05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90

76

GATT-TX: 03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18

GATT-TX: d8 91

GATT-RX: 03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62

GATT-RX: b1 ea

Got provisioning data (17 bytes)

06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1

ea

Confirmation Validated

S-Key 37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14

S-Nonce d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f

Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12

Data 00 00 00 00 00 00 05 01 13

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca

DataEncrypted + mic 5b

GATT-TX: 03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb

GATT-TX: 6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d

GATT-TX: 0f ca 5b

GATT-RX: 03 08

Got provisioning data (1 bytes)

08

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]#


2nd test, I “make clean” and “make”, this time, “onoff-app” is basing on the commit, c33087d3366f395168d477feb631aae1785a008e on March 29th, it works well, you can see below screenshot that BlueZ could get Composition Data.

[meshctl]# provision 135334dd01cf00000000000000000000
Trying to connect Device CF:01:DD:34:53:13 Zephyr
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1915e08
Open-Prov: 0x19149d0
Open-Prov: proxy 0x19124d8
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 03 00 10
GATT-RX: 03 01 04 00 01 00 00 06 00 18 00 00 00
Got provisioning data (12 bytes)
01 04 00 01 00 00 06 00 18 00 00 00
GATT-TX: 03 02 00 00 02 04 06
GATT-TX: 03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4
GATT-TX: 51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4
GATT-TX: 0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7
GATT-TX: fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f
GATT-TX: e1 0f
GATT-RX: 03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e
GATT-RX: 4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18
GATT-RX: 1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2
GATT-RX: e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6
GATT-RX: 7c 49
Got provisioning data (65 bytes)
03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e
1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c
5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3
32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c
49
Request ASCII key (max characters 6)
[mesh] Enter key (ascii string): RZTCNG
GATT-TX: 03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd
GATT-TX: fa f7
GATT-RX: 03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17
GATT-RX: 3c a3
Got provisioning data (17 bytes)
05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c
a3
GATT-TX: 03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27
GATT-TX: dd dc
GATT-RX: 03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64
GATT-RX: b7 9f
Got provisioning data (17 bytes)
06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7
9f
Confirmation Validated
S-Key 2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec
S-Nonce 69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03
DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 1b
DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d
DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71
DataEncrypted + mic 2b
GATT-TX: 03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff
GATT-TX: 3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7
GATT-TX: 3c 71 2b
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 011b
Attempting to disconnect from CF:01:DD:34:53:13
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Write closed
Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:
Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:
Services resolved no
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

Mesh Proxy Service (00001828-0000-1000-8000-00805f9b34fb)
Identity for node 011b
Trying to connect to mesh
Adapter property changed
[CHG] Controller 00:1B:DC:08:01:4A Discovering: no
Connection successful
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002add-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002ade-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d
AcquireNotify success: fd 7 MTU 69
Notify for Mesh Proxy Out Data started
Trying to open mesh session
GATT-RX: 01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4
GATT-RX: 0a 41 fa b0 af 32 0b
iv_upd_state = IV_UPD_NORMAL
Mesh session is open
Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b
AcquireWrite success: fd 8 MTU 69
GATT-TX: 02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02
GATT-TX: a7 77 d9 51
GATT-TX: 00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07
GATT-TX: 57 67 06 0c 51 02
GATT-RX: 02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0
GATT-RX: 78 86 79 a1 ea fd
Proxy Whitelist filter length: 0
GATT-RX: 00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e
GATT-RX: 4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d
GATT-RX: 00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb
GATT-RX: 2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9
GATT-RX: 00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39
GATT-RX: 97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71
GATT-RX: 00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc
GATT-RX: 7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30
GATT-RX: 00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92
GATT-RX: ea eb dc 22 e8 61 3e d5 02 5b 3c 12
Composition data for node 011b {
"cid":"05f1",
"pid":"0000",
"vid":"0000",
"crpl":"000a",
"features":{
"relay":true,
"proxy":true,
"friend":false,
"lpn":false
},
"elements":[
{
"elementIndex":0,
"location":"0000",
"models":[
"0000",
"0001",
"0002",
"1000",
"1001"
]
},
{
"elementIndex":1,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":2,
"location":"0000",
"models":[
"1000",
"1001"
]
},
{
"elementIndex":3,
"location":"0000",
"models":[
"1000",
"1001"
]
}
]
}
GATT-TX: 00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65
GATT-TX: 0b f9 13 7b fb 95 19 e4 a5
[Zephyr-Node-011b]#

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys, just guessing…

Regards,
Kai



From: Vikrant More <vikrant8051@gmail.com>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@bluetooth.com>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>, "users@lists.zephyrproject.org" <users@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49)

HI Kai,
Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX: 03 00 10
GATT-RX: 03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX: 03 02 00 00 00 00 00
GATT-TX: 03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX: 2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX: 4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX: 31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX: 52 ea
GATT-RX: 43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX: 10 28 b4 89
GATT-RX: 83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX: 87 b9 2b a3
GATT-RX: 83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX: b7 1a f5 1d
GATT-RX: c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
27
GATT-TX: 03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX: 82 90
GATT-RX: 03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX: 59 d0
Got provisioning data (17 bytes)
05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
d0
GATT-TX: 03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX: a2 b6
GATT-RX: 03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX: f1 88
Got provisioning data (17 bytes)
06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
88
Confirmation Validated
S-Key bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce 1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey 24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data 18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data 00 00 00 00 00 00 05 01 00
DataEncrypted + mic 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic 67
GATT-TX: 03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX: 37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX: 50 01 67
GATT-RX: 03 08
Got provisioning data (1 bytes)
08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@gmail.com<mailto:vikrant8051@gmail.com>> wrote:
Hi Kai,

Yes, you are right. Thanks for sharing it.

Regards,
vikrant


On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@bluetooth.com<mailto:kren@bluetooth.com>> wrote:

Hi Vikrant8051,

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr.

Kai


Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #meshctl #bluetoothmesh

Kai Ren <kren@...>
 

Hi Vikrant,

I just did two tests today, the detail is:

 

1st test. I built “onoff-app” example basing on latest Zephyr project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of today, you can see that my log is the same like yours, after close the connection, need to initial a new connection, but it’s failed.

 

[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service0006

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x176ae78

Open-Prov: 0x176e470

Open-Prov: proxy 0x176aec8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX:     03 00 10 

GATT-RX:     03 01 04 00 01 00 00 06 00 18 00 00 00 

Got provisioning data (12 bytes)

       01 04 00 01 00 00 06 00 18 00 00 00 

GATT-TX:     03 02 00 00 02 04 06 

GATT-TX:     03 03 46 29 4e 55 9b ff 27 e0 b9 58 5a c2 ee 56 

GATT-TX:     93 aa 38 35 2e 4e de 6b 78 af b8 c7 6c 42 0e be 

GATT-TX:     75 78 94 af 19 c1 24 e8 78 0f 1d 57 25 ea 03 5c 

GATT-TX:     3e a6 81 48 37 f8 9b 94 e1 35 bd 34 c1 97 dc d9 

GATT-TX:     e9 60 

GATT-RX:     03 03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 

GATT-RX:     68 cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 

GATT-RX:     01 32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 

GATT-RX:     49 a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 

GATT-RX:     4c bf 

Got provisioning data (65 bytes)

       03 44 3e 0c 3c b7 4a 37 f0 68 3c 73 b3 59 44 68 

       cf 67 e0 b7 7d f1 f0 cf aa 97 74 e4 04 49 c4 01 

       32 fb 92 82 bc 15 32 de 52 e1 b2 9a 4a 01 43 49 

       a9 24 ab 1a a6 27 d3 a7 08 72 33 25 0b 36 f3 4c 

       bf 

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): 7GG0LQ

GATT-TX:     03 05 2b 9f 92 6f ca de 51 48 f8 26 2f f1 b0 b3 

GATT-TX:     83 c4 

GATT-RX:     03 05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 

GATT-RX:     90 76 

Got provisioning data (17 bytes)

       05 c7 f4 8a cf de 22 92 b3 30 66 9f e5 64 3d 90 

       76 

GATT-TX:     03 06 0b 86 f5 06 69 65 6f 51 3d 75 d2 6e 3b 18 

GATT-TX:     d8 91 

GATT-RX:     03 06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 

GATT-RX:     b1 ea 

Got provisioning data (17 bytes)

       06 0a 31 b0 f9 0d a7 a2 42 32 c4 cd 0f 62 62 b1 

       ea 

Confirmation Validated

S-Key  37 6f 39 7f f4 aa b3 a2 b8 3b b3 25 52 e1 fe 14 

S-Nonce       d2 d2 f8 72 f0 74 38 2e 77 11 3a 51 eb 

DevKey bd 5b db c6 fb 68 5d 9b f3 d0 d4 0a 7a 2b b9 1f 

Data   18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12 

Data   00 00 00 00 00 00 05 01 13 

DataEncrypted + mic 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 6c 00 

DataEncrypted + mic 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 0f ca 

DataEncrypted + mic 5b 

GATT-TX:     03 07 31 0c 91 f7 33 89 40 40 8d 10 53 0e 5c cb 

GATT-TX:     6c 00 69 a7 4c ba e1 af 28 6b 2b a0 b2 da ba 2d 

GATT-TX:     0f ca 5b 

GATT-RX:     03 08 

Got provisioning data (1 bytes)

       08 

Provision success. Assigned Primary Unicast 0113

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

[meshctl]# 

 

 

2nd test, I “make clean” and “make”, this time, “onoff-app” is basing on the commit, c33087d3366f395168d477feb631aae1785a008e on March 29th, it works well, you can see below screenshot that BlueZ could get Composition Data.

 

[meshctl]# provision 135334dd01cf00000000000000000000

Trying to connect Device CF:01:DD:34:53:13 Zephyr

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Provisioning Out Data started

Open-Node: 0x1915e08

Open-Prov: 0x19149d0

Open-Prov: proxy 0x19124d8

Initiated provisioning

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX:     03 00 10 

GATT-RX:     03 01 04 00 01 00 00 06 00 18 00 00 00 

Got provisioning data (12 bytes)

       01 04 00 01 00 00 06 00 18 00 00 00 

GATT-TX:     03 02 00 00 02 04 06 

GATT-TX:     03 03 e5 28 0b b0 20 40 5e f4 e4 92 f1 ff 1b a4 

GATT-TX:     51 96 0a 9a 85 e4 e1 2b 13 50 8f 5d 27 19 d3 b4 

GATT-TX:     0c 99 bc 73 dd 1d b9 3e 11 3f c7 03 45 3d d4 b7 

GATT-TX:     fb 1e 28 e5 1e b2 d4 dc 88 31 82 49 0c 78 82 3f 

GATT-TX:     e1 0f 

GATT-RX:     03 03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 

GATT-RX:     4e 1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 

GATT-RX:     1c 5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 

GATT-RX:     e3 32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 

GATT-RX:     7c 49 

Got provisioning data (65 bytes)

       03 8a 48 c5 d5 c9 13 9f fd c6 5b 59 b3 87 9e 4e 

       1d a7 0b 6c 1a e6 65 ea f4 f4 07 a0 5f 10 18 1c 

       5d 00 eb a2 31 33 ca 73 95 a3 ff aa f7 72 c2 e3 

       32 4a 13 93 21 bf 8c 01 1e 32 74 25 ad 9e e6 7c 

       49 

Request ASCII key (max characters 6)

[mesh] Enter key (ascii string): RZTCNG

GATT-TX:     03 05 00 99 fd 99 5e c7 d9 49 41 f5 27 8a 45 dd 

GATT-TX:     fa f7 

GATT-RX:     03 05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 

GATT-RX:     3c a3 

Got provisioning data (17 bytes)

       05 5a ca d3 3f bb ef cb e5 31 e5 27 d6 91 17 3c 

       a3 

GATT-TX:     03 06 d4 9f a5 2d d3 f5 c8 b3 6b 21 36 81 64 27 

GATT-TX:     dd dc 

GATT-RX:     03 06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 

GATT-RX:     b7 9f 

Got provisioning data (17 bytes)

       06 76 86 6c ef 49 43 18 21 51 f2 0a cb 13 64 b7 

       9f 

Confirmation Validated

S-Key  2f 1d 94 8c cd 5b 4a 23 e2 63 38 45 4b 95 f2 ec 

S-Nonce       69 4e 98 62 2f 09 45 2f 10 8a 8b 12 03 

DevKey 85 a0 58 ab 9c 9a cc 84 4c 94 ba a6 f1 f9 fa 70 

Data   18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12 

Data   00 00 00 00 00 00 05 01 1b 

DataEncrypted + mic e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 3a 4d 

DataEncrypted + mic a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 3c 71 

DataEncrypted + mic 2b 

GATT-TX:     03 07 e6 d2 b9 87 fd e0 fd a2 96 80 ea 3a 16 ff 

GATT-TX:     3a 4d a4 6e 81 0b ca 33 b8 27 09 1d f2 e6 12 f7 

GATT-TX:     3c 71 2b 

GATT-RX:     03 08 

Got provisioning data (1 bytes)

       08 

Provision success. Assigned Primary Unicast 011b

Attempting to disconnect from CF:01:DD:34:53:13

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Write closed

Service added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b:

Char added /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d:

Services resolved no

SetDiscoveryFilter success

Discovery started

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: yes

 

              Mesh Proxy Service (00001828-0000-1000-8000-00805f9b34fb)

              Identity for node 011b

Trying to connect to mesh

Adapter property changed 

[CHG] Controller 00:1B:DC:08:01:4A Discovering: no

Connection successful

Services resolved yes

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b, uuid 00002add-0000-1000-8000-00805f9b34fb

Found matching char: path /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d, uuid 00002ade-0000-1000-8000-00805f9b34fb

Start notification on /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000d

AcquireNotify success: fd 7 MTU 69

Notify for Mesh Proxy Out Data started

Trying to open mesh session

GATT-RX:     01 01 00 d4 76 79 43 3f db 10 4a 00 00 00 05 f4 

GATT-RX:     0a 41 fa b0 af 32 0b 

iv_upd_state = IV_UPD_NORMAL

Mesh session is open

Characteristic property changed /org/bluez/hci0/dev_CF_01_DD_34_53_13/service000a/char000b

AcquireWrite success: fd 8 MTU 69

GATT-TX:     02 f4 e2 f9 cb d9 47 7b c5 4d 23 04 3b 32 74 02 

GATT-TX:     a7 77 d9 51 

GATT-TX:     00 f4 27 cd 77 9a de f7 06 74 c4 1f e9 e5 e7 07 

GATT-TX:     57 67 06 0c 51 02 

GATT-RX:     02 f4 44 af 19 fa 89 51 83 cb db b1 08 10 97 f0 

GATT-RX:     78 86 79 a1 ea fd 

Proxy Whitelist filter length: 0

GATT-RX:     00 f4 0d 8b ee 59 96 9c da b5 73 39 4f 13 da 2e 

GATT-RX:     4d 30 47 06 7b d5 b0 15 71 fc ab b1 87 2d 

GATT-RX:     00 f4 8e 31 9b dd 67 26 c6 08 60 f6 2a 3e a0 eb 

GATT-RX:     2e 1b c6 d2 49 8c 14 11 53 54 e9 47 a2 a9 

GATT-RX:     00 f4 28 4e de 68 59 e5 37 f0 50 12 6b bc 5a 39 

GATT-RX:     97 70 64 01 9b 77 2b 51 90 e3 04 11 91 71 

GATT-RX:     00 f4 b1 dd 9d 38 17 1b 10 60 32 90 b1 f9 dd cc 

GATT-RX:     7e 71 ad a6 6e 08 3f df 7b 0a 9e 12 6b 30 

GATT-RX:     00 f4 d9 1e 75 e2 77 1f 9f e7 c7 73 4e fa 86 92 

GATT-RX:     ea eb dc 22 e8 61 3e d5 02 5b 3c 12 

       Composition data for node 011b {

  "cid":"05f1",

  "pid":"0000",

  "vid":"0000",

  "crpl":"000a",

  "features":{

    "relay":true,

    "proxy":true,

    "friend":false,

    "lpn":false

  },

  "elements":[

    {

      "elementIndex":0,

      "location":"0000",

      "models":[

        "0000",

        "0001",

        "0002",

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":1,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":2,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    },

    {

      "elementIndex":3,

      "location":"0000",

      "models":[

        "1000",

        "1001"

      ]

    }

  ]

}

GATT-TX:     00 f4 64 37 a5 e0 5f c0 3b 3c 90 42 cc f9 55 65 

GATT-TX:     0b f9 13 7b fb 95 19 e4 a5 

[Zephyr-Node-011b]

 

I guess there may be a bug in Bluetooth or Bluetooth mesh subsys, just guessing…

 

Regards,

Kai

 

 

 

From: Vikrant More <vikrant8051@...>
Date: Thursday, April 26, 2018 at 12:38 PM
To: Kai Ren <kren@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49)

 

HI Kai,

Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App )
DEVICE using #meshctl, in this case too provisioning process did not complete.

 

This is complete log,
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

provision f81d4fae7dec4b53a1540cb44f9726db
Trying to connect Device DB:26:97:4F:B4:0C DB-26-97-4F-B4-0C
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service0001
Service added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d:
Char added /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
AcquireNotify success: fd 7 MTU 23
Notify for Mesh Provisioning Out Data started
Open-Node: 0xfeeb10
Open-Prov: 0x1001c20
Open-Prov: proxy 0xffd7f0
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
AcquireWrite success: fd 8 MTU 23
GATT-TX:     03 00 10
GATT-RX:     03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
     01 01 00 01 00 00 00 00 00 00 00 00
GATT-TX:     03 02 00 00 00 00 00
GATT-TX:     03 03 1b 79 c0 dd 6e f0 60 4d bf 01 92 de ed b7
GATT-TX:     2d 48 e0 bb 42 ec 36 cf d0 76 cc 60 aa 2a fa 9f
GATT-TX:     4d 1f ba 3d b5 43 a8 a7 0d 80 b5 e3 08 34 2d d5
GATT-TX:     31 6c 02 0d 1b 36 b4 1d 44 36 84 91 a2 26 da c8
GATT-TX:     52 ea
GATT-RX:     43 03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c
GATT-RX:     10 28 b4 89
GATT-RX:     83 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64 14 fe
GATT-RX:     87 b9 2b a3
GATT-RX:     83 63 22 b8 4e bb 58 ac 71 c8 a2 5e b7 bf ab 25
GATT-RX:     b7 1a f5 1d
GATT-RX:     c3 a9 19 52 a8 61 85 d9 27
Got provisioning data (65 bytes)
     03 f0 ef 67 07 66 32 7b c8 df 2c 6a 4f c2 6c 10
     28 b4 89 b2 17 cb f8 ff 9f cc 32 e4 2f 16 40 64
     14 fe 87 b9 2b a3 63 22 b8 4e bb 58 ac 71 c8 a2
     5e b7 bf ab 25 b7 1a f5 1d a9 19 52 a8 61 85 d9
     27
GATT-TX:     03 05 2a 0b bf ec e6 45 80 06 89 67 b6 c2 e4 30
GATT-TX:     82 90
GATT-RX:     03 05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d
GATT-RX:     59 d0
Got provisioning data (17 bytes)
     05 d7 93 53 dc 12 36 90 ea 85 b5 fe 1a 79 9d 59
     d0
GATT-TX:     03 06 16 6f b0 65 5a c6 da 55 15 6a 83 22 45 c3
GATT-TX:     a2 b6
GATT-RX:     03 06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1
GATT-RX:     f1 88
Got provisioning data (17 bytes)
     06 70 86 ff 82 75 05 3a b9 cb f5 32 2d 1b a1 f1
     88
Confirmation Validated
S-Key     bf c7 ea 9f dd 95 76 cd 5d fe d0 ba 56 23 a7 25
S-Nonce     1a 5c 5d 8b 57 85 fb ef d9 d4 b8 42 8e
DevKey     24 c9 87 84 71 3a 4a 5b c0 30 ed 3e de 4a e5 44
Data     18 ee d9 c2 a5 6a dd 85 04 9f fc 3c 59 ad 0e 12
Data     00 00 00 00 00 00 05 01 00
DataEncrypted + mic     6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd 37 19
DataEncrypted + mic     44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67 50 01
DataEncrypted + mic     67
GATT-TX:     03 07 6f 6e 24 26 aa 65 f5 b1 de 16 1d 16 03 cd
GATT-TX:     37 19 44 6d f7 3c f8 27 dd da d0 0f 1c d7 33 67
GATT-TX:     50 01 67
GATT-RX:     03 08
Got provisioning data (1 bytes)
     08
Provision success. Assigned Primary Unicast 0100
Attempting to disconnect from DB:26:97:4F:B4:0C
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000f
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_DB_26_97_4F_B4_0C/service000c/char000d
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller 28:F0:76:2F:42:BB Discovering: yes

 

On Wed, Apr 25, 2018 at 9:10 PM, Vikrant More <vikrant8051@...> wrote:

Hi Kai, 

 

Yes, you are right. Thanks for sharing it. 

 

Regards,

vikrant

 

 

On Wed, Apr 25, 2018, 8:43 AM Kai Ren <kren@...> wrote:

Hi Vikrant8051, 

I had tried this one month ago, my testing environment is:
BlueZ v5.49;
nRF52832-DK;

I can provision the DK which run "onoff-app" firmware and make model configuration, use meshctl "menu onoff" to control LED on and off.

By the way, I also use BlueZ 5.49 to provision SiLabs kit in last week, it was successful, so BlueZ works well, the issue may be from Zephyr. 

Kai  

 

2041 - 2060 of 2797