Date   

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  

 


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

vikrant8051 <vikrant8051@...>
 

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  



time between two packets(advertisement)

swapnil <swapnil2007kadam@...>
 

Hello,
is it possible to change the time or provide a delay between two consecutive packets sent on two different advertising channels?

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?
Thank you in advance.
regards,
Swapnil


Re: payload 251 byte with beacon sample

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

Hi Swapnil,

Legacy advertising channels do not support 251 byte PDUs.

The configuration CONFIG_BT_CTLR_DATA_LENGTH=y, you are setting is only valid for data connections. The beacon sample is only a broadcaster hence the Kconfig warns about the feature being disabled due to connection support dependency.

If you are looking for broadcasting 251 byte PDUs, LE advertising extensions feature is not yet supported in the Zephyr upstream master repository.

Regards,
Vinayak

From: users@lists.zephyrproject.org [mailto:users@lists.zephyrproject.org] On Behalf Of swapnil
Sent: Tuesday, April 24, 2018 12:33 PM
To: users@lists.zephyrproject.org
Subject: [Zephyr-users] payload 251 byte with beacon sample

HELLO, 
i am new to zephyr.  and trying to send a message with 251 byte payload. how can I set the controller.? 
 
i am using following configuration:

CONFIG_BT=y

CONFIG_BT_CTLR = y

CONFIG_BT_DEBUG_LOG=y

CONFIG_BT_DEVICE_NAME="Test beacon"

CONFIG_HAS_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

CONFIG_UART_CONSOLE=n

CONFIG_BT_DEBUG_MONITOR=y

CONFIG_BT_DEBUG_HCI_CORE=y

CONFIG_BT_CTLR_ADV_EXT=y

CONFIG_BT_BROADCASTER=y

CONFIG_BT_DEBUG_HCI_DRIVER=y

CONFIG_BT_CTLR_DATA_LENGTH=y


CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

CONFIG_BT_CTLR_TX_BUFFER_SIZE=251

CONFIG_BT_CONN = y

CONFIG_BT_LL_SW = y

BT_CTLR_DATA_LENGTH_MAX = y

CONFIG_BT_HCI = y

CONFIG_SOC_SERIES_NRF52X = y

CONFIG_BT_CTLR_ADVANCED_FEATURES = y

 

 


but it throws following warnings:

 

/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:15: warning: attempt to assign the value " y" to the undefined symbol SOC_SERIES_NRF52X 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:17: warning: attempt to assign the value " y" to the undefined symbol BT_CTLR_ADVANCED_FEATURES 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:20: warning: attempt to assign the value " y" to the undefined symbol BT_CONN 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:21: warning: attempt to assign the value " y" to the undefined symbol BT_LL_SW 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:23: warning: attempt to assign the value " y" to the undefined symbol BT_HCI 
Parsing Kconfig tree in /home/swap/zephyr/Kconfig
Using /home/swap/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/swap/zephyr/samples/bluetooth/beacon/prj.conf
 
warning: BT_CTLR_DATA_LENGTH was assigned the value "y" but got the value "n" -- check dependencies
 
warning: BT_CTLR_DATA_LENGTH_MAX was assigned the value "251" but got the value "" -- check dependencies
 
what could be the correct configurations to enable 251 byte payload?
 
Thank you in advance,
 
regards,
swapnil


payload 251 byte with beacon sample

swapnil <swapnil2007kadam@...>
 

HELLO, 
i am new to zephyr.  and trying to send a message with 251 byte payload. how can I set the controller.? 
 
i am using following configuration:
CONFIG_BT=y
CONFIG_BT_CTLR = y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_DEVICE_NAME="Test beacon"
CONFIG_HAS_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_BT_DEBUG_MONITOR=y
CONFIG_BT_DEBUG_HCI_CORE=y
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_BROADCASTER=y
CONFIG_BT_DEBUG_HCI_DRIVER=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CONN = y
CONFIG_BT_LL_SW = y
BT_CTLR_DATA_LENGTH_MAX = y
CONFIG_BT_HCI = y
CONFIG_SOC_SERIES_NRF52X = y
CONFIG_BT_CTLR_ADVANCED_FEATURES = y
 
 
but it throws following warnings:
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:15: warning: attempt to assign the value " y" to the undefined symbol SOC_SERIES_NRF52X 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:17: warning: attempt to assign the value " y" to the undefined symbol BT_CTLR_ADVANCED_FEATURES 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:20: warning: attempt to assign the value " y" to the undefined symbol BT_CONN 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:21: warning: attempt to assign the value " y" to the undefined symbol BT_LL_SW 
 
/home/swap/zephyr/samples/bluetooth/beacon/prj.conf:23: warning: attempt to assign the value " y" to the undefined symbol BT_HCI 
Parsing Kconfig tree in /home/swap/zephyr/Kconfig
Using /home/swap/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/swap/zephyr/samples/bluetooth/beacon/prj.conf
 
warning: BT_CTLR_DATA_LENGTH was assigned the value "y" but got the value "n" -- check dependencies
 
warning: BT_CTLR_DATA_LENGTH_MAX was assigned the value "251" but got the value "" -- check dependencies
 
what could be the correct configurations to enable 251 byte payload?
 
Thank you in advance,
 
regards,
swapnil
 
 
 
 


Re: BLE Nano 2 - LWM2M DTLS demo example

Christos Vasilakis
 

Hi Michael,

Thank you for the detailed step-by-step, greatly appreciated!

It’s working :) 

You are correct, modifying the CONFIG_MBEDTLS_HEAP_SIZE caused the demo to stop working. 

Further, just to point out for other devs coming to this thread, you need to be carefully to issue both of the following commands, one after the other, without a long time gap between them. In my case, I issued the first command, and then notice in the serial logs that I was getting out of memory error. So started to modify the config and eventually modifying also the CONFIG_MBEDTLS_HEAP_SIZE (which further crippled the demo). For reference, a working DTLS config file that I have used, can be found here [1]

$ echo "connect E0:0F:F1:29:76:01 2" > /sys/kernel/debug/bluetooth/6lowpan_control
$ ip address add 2001:db8::2/64 dev bt0

Regarding the suggested changes of moving DTLS and Bluetooth specific settings from "prj.conf" into several config files, makes sense, especially for a newcomer like me.

Regards,

-Christos




On 24 Apr 2018, at 00:16, Michael Scott <michael@...> wrote:

Hi again Christos,


On 04/23/2018 09:34 AM, Christos Vasilakis wrote:
Hi there,

I have recently purchased a BLE Nano 2 kit and I am trying to run the LWM2M client example found here [1]. I have successfully installed and run the simple (non-DTLS) example and works just fine (using a Raspberry PI  6lowpan BLE network as described in [2]). That is, I can successfully ping the Nano node as well as having it register with the Leshan LWM2M server and query it’s objects.

Now I am trying to setup the DTLS example and for this I have done the following:

- setup the pre-shared key on the Leshan server (as suggested in [3])
- enable the dlls configuration in the prj_dtls.conf. A dump of this configuration file can be found here [4]. 

>> Please note that I have lowered the CONFIG_MBEDTLS_HEAP_SIZE from 8192 to 4096 cause I got the following error printed in the console which resulted in a none working BT connection.

I think changing the CONFIG_MBEDTLS_HEAP_SIZE is what's causing the issues you're seeing.  I didn't get the "Unable to get TX packet, not enough memory." error when leaving the CONFIG_MBEDTLS_HEAP_SIZE and using the following changes:


1. Add the following CONFIG lines to the bottom of the prj_dtls.conf:
CONFIG_NET_L2_BT=y
CONFIG_BT_DEVICE_NAME="Test IPSP node"
CONFIG_NET_APP_BT_NODE=y

2. Build the sample for BLENano2 like so:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj_dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

3. NOTE: The host machine where I connect the BLENano2 via 6lowpan has a Leshan server connected to 2001:db8::2.  I'm assuming you have this running on your RPi.

4. I added the following information to the Leshan security settings:
Client endpoint: nrf52_blenano2
Security mode: Pre-Shared Key (already set by default)
Identity: Client_identity
Key: 000102030405060708090a0b0c0d0e0f

5. When monitoring the BLENano2 via UART, it should spew just a few lines like the Zephyr version and some initialization regaring LwM2M objects and then wait until joined via 6lowpan before attempting to connect to the Leshan server.  Also, you use the "net iface" shell command to see detailed information about the bluetooth network interface.

6. NOTE: Almost all of the RAM on BLENano2 is used by the sample when DTLS enabled (using the default configs).  If you were to enable almost ANY debug CONFIG at all, you would most certainly hit RAM issues.  To help with, you could consider disabling some of the following CONFIG items in prj_dtls.conf:
CONFIG_NET_IPV4=n
CONFIG_NET_APP_NEED_IPV4=n
CONFIG_SYS_LOG_SHOW_COLOR=n

Or tone down the logging output of the sample or disabling the command shell:
CONFIG_NET_LOG=n
CONFIG_NET_BUF_LOG=n
CONFIG_SYS_LOG_NET_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_NET_BUF_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_LWM2M_LEVEL <lowering the # would reduce logging output>
CONFIG_NET_SHELL=n

Let me know how this works on your end.

One last note: I think your experience proves it's too difficult to configure the LwM2M client for extended use-cases (DTLS + Bluetooth networking).  I'm going to submit some patches keeping just the primary "prj.conf" file, move just the DTLS specific settings from "prj_dtls.conf" into "overlay-dtls.conf" and having the Bluetooth enabling configs in "overlay-bt.conf".

This should be easier to maintain over time, *and* hopefully allow more build combinations using the -DCONF_FILE command line option which can take several filenames.
Building and flashing the DTLS-enabled client for BLENano2 would then look something like:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj.conf overlay-bt.conf overlay-dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

- Mike

'[lib/lwm2m_engine] [ERR] lwm2m_init_message: Unable to get TX packet, not enough memory."


Unfortunately the DTLS version doesn’t seem to work. In particular during bootstrap I get error (-72). Here is a dump of the console:

--------------------------------------------------------
***** Booting Zephyr OS v1.11.0-758-g541c3cb18 *****
[lib/lwm2m_engine] [DBG] lwm2m_engine_init: LWM2M engine thread started
[lwm2m_obj_security] [DBG] security_create: Create LWM2M security instance: 0
[lwm2m_obj_server] [DBG] server_create: Create LWM2M server instance: 0
[lwm2m_obj_device] [DBG] device_create: Create LWM2M device instance: 0
[lwm2m_obj_firmware] [DBG] firmware_create: Create LWM2M firmware instance: 0
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: e0:0f:f1:29:76:01 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[lwm2m-client] [INF] main: Run LWM2M client
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/0, value:0x0002f852, len:6
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/1, value:0x0002f85f, len:23
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/2, value:0x0002f87d, len:9
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/3, value:0x0002f88d, len:3
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/9, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/10, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/17, value:0x0002f8b0, len:16
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/18, value:0x0002f8c8, len:5
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/20, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/21, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3303/0
[ipso_temp_sensor] [DBG] temp_sensor_create: Create IPSO Temperature Sensor instance: 0
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3303/0/5700, value:0x2000c310, len:8
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3311/0
[ipso_light_control] [DBG] light_control_create: Create IPSO Light Control instance: 0
prio recv thread stack (real size 748): unused 488      usage 260 / 748 (34 %)
recv thread stack (real size 1324):     unused 424      usage 900 / 1324 (67 %)
[lib/lwm2m_engine] [ERR] lwm2m_engine_start: Cannot connect UDP (-72)
[lib/lwm2m_rd_client] [ERR] lwm2m_rd_client_start: Cannot init LWM2M engine (-72)
[lwm2m-client] [ERR] main: LWM2M init LWM2M RD client error (-72)
prio
--------------------------------------------------------


From the Raspberry PI I can successfully ping the node which implies that connectivity exists and is working.

root@raspberrypi:/home/pi# ping 2001:db8::1. <— BLE Nano 2 
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=221 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=194 ms
^C
--- 2001:db8::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 194.834/208.153/221.472/13.319 ms


I would be grateful if someone can help me to debug the issue.

Thank you in advance

-Christos





Re: BLE Nano 2 - LWM2M DTLS demo example

Michael Scott
 

Hi again Christos,


On 04/23/2018 09:34 AM, Christos Vasilakis wrote:
Hi there,

I have recently purchased a BLE Nano 2 kit and I am trying to run the LWM2M client example found here [1]. I have successfully installed and run the simple (non-DTLS) example and works just fine (using a Raspberry PI  6lowpan BLE network as described in [2]). That is, I can successfully ping the Nano node as well as having it register with the Leshan LWM2M server and query it’s objects.

Now I am trying to setup the DTLS example and for this I have done the following:

- setup the pre-shared key on the Leshan server (as suggested in [3])
- enable the dlls configuration in the prj_dtls.conf. A dump of this configuration file can be found here [4]. 

>> Please note that I have lowered the CONFIG_MBEDTLS_HEAP_SIZE from 8192 to 4096 cause I got the following error printed in the console which resulted in a none working BT connection.

I think changing the CONFIG_MBEDTLS_HEAP_SIZE is what's causing the issues you're seeing.  I didn't get the "Unable to get TX packet, not enough memory." error when leaving the CONFIG_MBEDTLS_HEAP_SIZE and using the following changes:

1. Add the following CONFIG lines to the bottom of the prj_dtls.conf:
CONFIG_NET_L2_BT=y
CONFIG_BT_DEVICE_NAME="Test IPSP node"
CONFIG_NET_APP_BT_NODE=y

2. Build the sample for BLENano2 like so:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj_dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

3. NOTE: The host machine where I connect the BLENano2 via 6lowpan has a Leshan server connected to 2001:db8::2.  I'm assuming you have this running on your RPi.

4. I added the following information to the Leshan security settings:
Client endpoint: nrf52_blenano2
Security mode: Pre-Shared Key (already set by default)
Identity: Client_identity
Key: 000102030405060708090a0b0c0d0e0f

5. When monitoring the BLENano2 via UART, it should spew just a few lines like the Zephyr version and some initialization regaring LwM2M objects and then wait until joined via 6lowpan before attempting to connect to the Leshan server.  Also, you use the "net iface" shell command to see detailed information about the bluetooth network interface.

6. NOTE: Almost all of the RAM on BLENano2 is used by the sample when DTLS enabled (using the default configs).  If you were to enable almost ANY debug CONFIG at all, you would most certainly hit RAM issues.  To help with, you could consider disabling some of the following CONFIG items in prj_dtls.conf:
CONFIG_NET_IPV4=n
CONFIG_NET_APP_NEED_IPV4=n
CONFIG_SYS_LOG_SHOW_COLOR=n

Or tone down the logging output of the sample or disabling the command shell:
CONFIG_NET_LOG=n
CONFIG_NET_BUF_LOG=n
CONFIG_SYS_LOG_NET_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_NET_BUF_LEVEL <lowering the # would reduce logging output>
CONFIG_SYS_LOG_LWM2M_LEVEL <lowering the # would reduce logging output>
CONFIG_NET_SHELL=n

Let me know how this works on your end.

One last note: I think your experience proves it's too difficult to configure the LwM2M client for extended use-cases (DTLS + Bluetooth networking).  I'm going to submit some patches keeping just the primary "prj.conf" file, move just the DTLS specific settings from "prj_dtls.conf" into "overlay-dtls.conf" and having the Bluetooth enabling configs in "overlay-bt.conf".

This should be easier to maintain over time, *and* hopefully allow more build combinations using the -DCONF_FILE command line option which can take several filenames.
Building and flashing the DTLS-enabled client for BLENano2 would then look something like:
$ cd samples/net/lwm2m_client
$ mkdir build && cd build
$ cmake -GNinja -DBOARD=nrf52_blenano2 -DCONF_FILE="prj.conf overlay-bt.conf overlay-dtls.conf" ..
$ ninja
$ pyocd-flashtool -ce -t nrf52 zephyr/zephyr.bin

- Mike

'[lib/lwm2m_engine] [ERR] lwm2m_init_message: Unable to get TX packet, not enough memory."


Unfortunately the DTLS version doesn’t seem to work. In particular during bootstrap I get error (-72). Here is a dump of the console:

--------------------------------------------------------
***** Booting Zephyr OS v1.11.0-758-g541c3cb18 *****
[lib/lwm2m_engine] [DBG] lwm2m_engine_init: LWM2M engine thread started
[lwm2m_obj_security] [DBG] security_create: Create LWM2M security instance: 0
[lwm2m_obj_server] [DBG] server_create: Create LWM2M server instance: 0
[lwm2m_obj_device] [DBG] device_create: Create LWM2M device instance: 0
[lwm2m_obj_firmware] [DBG] firmware_create: Create LWM2M firmware instance: 0
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: e0:0f:f1:29:76:01 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[lwm2m-client] [INF] main: Run LWM2M client
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/0, value:0x0002f852, len:6
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/1, value:0x0002f85f, len:23
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/2, value:0x0002f87d, len:9
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/3, value:0x0002f88d, len:3
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/9, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/10, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/17, value:0x0002f8b0, len:16
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/18, value:0x0002f8c8, len:5
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/20, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/21, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3303/0
[ipso_temp_sensor] [DBG] temp_sensor_create: Create IPSO Temperature Sensor instance: 0
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3303/0/5700, value:0x2000c310, len:8
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3311/0
[ipso_light_control] [DBG] light_control_create: Create IPSO Light Control instance: 0
prio recv thread stack (real size 748): unused 488      usage 260 / 748 (34 %)
recv thread stack (real size 1324):     unused 424      usage 900 / 1324 (67 %)
[lib/lwm2m_engine] [ERR] lwm2m_engine_start: Cannot connect UDP (-72)
[lib/lwm2m_rd_client] [ERR] lwm2m_rd_client_start: Cannot init LWM2M engine (-72)
[lwm2m-client] [ERR] main: LWM2M init LWM2M RD client error (-72)
prio
--------------------------------------------------------


From the Raspberry PI I can successfully ping the node which implies that connectivity exists and is working.

root@raspberrypi:/home/pi# ping 2001:db8::1. <— BLE Nano 2 
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=221 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=194 ms
^C
--- 2001:db8::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 194.834/208.153/221.472/13.319 ms


I would be grateful if someone can help me to debug the issue.

Thank you in advance

-Christos




Re: BLE Nano 2 - LWM2M DTLS demo example

Michael Scott
 

Hi Christos,


On 04/23/2018 09:34 AM, Christos Vasilakis wrote:
Hi there,

I have recently purchased a BLE Nano 2 kit and I am trying to run the LWM2M client example found here [1]. I have successfully installed and run the simple (non-DTLS) example and works just fine (using a Raspberry PI  6lowpan BLE network as described in [2]). That is, I can successfully ping the Nano node as well as having it register with the Leshan LWM2M server and query it’s objects.

Now I am trying to setup the DTLS example and for this I have done the following:

- setup the pre-shared key on the Leshan server (as suggested in [3])
- enable the dlls configuration in the prj_dtls.conf. A dump of this configuration file can be found here [4]. 

>> Please note that I have lowered the CONFIG_MBEDTLS_HEAP_SIZE from 8192 to 4096 cause I got the following error printed in the console which resulted in a none working BT connection.

'[lib/lwm2m_engine] [ERR] lwm2m_init_message: Unable to get TX packet, not enough memory."
While I have worked extensively with the BLENano2 using an out-of-tree LwM2M client, I haven't specifically tested the in-tree sample using DTLS with that HW.  This is a very good exercise and I appreciate your very well documented email to the list.



Unfortunately the DTLS version doesn’t seem to work. In particular during bootstrap I get error (-72). Here is a dump of the console:
The -72 (-ECANCELED) comes from here:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/app/client.c#L845
Meaning that the TLS thread isn't being initialized before the timeout hits.  This could be for a variety of reasons.


--------------------------------------------------------
***** Booting Zephyr OS v1.11.0-758-g541c3cb18 *****
[lib/lwm2m_engine] [DBG] lwm2m_engine_init: LWM2M engine thread started
[lwm2m_obj_security] [DBG] security_create: Create LWM2M security instance: 0
[lwm2m_obj_server] [DBG] server_create: Create LWM2M server instance: 0
[lwm2m_obj_device] [DBG] device_create: Create LWM2M device instance: 0
[lwm2m_obj_firmware] [DBG] firmware_create: Create LWM2M firmware instance: 0
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: e0:0f:f1:29:76:01 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[lwm2m-client] [INF] main: Run LWM2M client
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/0, value:0x0002f852, len:6
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/1, value:0x0002f85f, len:23
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/2, value:0x0002f87d, len:9
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/3, value:0x0002f88d, len:3
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/9, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/10, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/17, value:0x0002f8b0, len:16
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/18, value:0x0002f8c8, len:5
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/20, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/21, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3303/0
[ipso_temp_sensor] [DBG] temp_sensor_create: Create IPSO Temperature Sensor instance: 0
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3303/0/5700, value:0x2000c310, len:8
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3311/0
[ipso_light_control] [DBG] light_control_create: Create IPSO Light Control instance: 0
prio recv thread stack (real size 748): unused 488      usage 260 / 748 (34 %)
recv thread stack (real size 1324):     unused 424      usage 900 / 1324 (67 %)
[lib/lwm2m_engine] [ERR] lwm2m_engine_start: Cannot connect UDP (-72)
[lib/lwm2m_rd_client] [ERR] lwm2m_rd_client_start: Cannot init LWM2M engine (-72)
[lwm2m-client] [ERR] main: LWM2M init LWM2M RD client error (-72)
prio
--------------------------------------------------------


From the Raspberry PI I can successfully ping the node which implies that connectivity exists and is working.

root@raspberrypi:/home/pi# ping 2001:db8::1. <— BLE Nano 2 
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=221 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=194 ms
^C
--- 2001:db8::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 194.834/208.153/221.472/13.319 ms


I would be grateful if someone can help me to debug the issue.

Give me a few hours to setup the BLENano2 and test the current master branch the way you've described and I'll report back what I find.

Thanks again for bringing this up on the list.

- Mike


Thank you in advance

-Christos




BLE Nano 2 - LWM2M DTLS demo example

Christos Vasilakis
 

Hi there,

I have recently purchased a BLE Nano 2 kit and I am trying to run the LWM2M client example found here [1]. I have successfully installed and run the simple (non-DTLS) example and works just fine (using a Raspberry PI  6lowpan BLE network as described in [2]). That is, I can successfully ping the Nano node as well as having it register with the Leshan LWM2M server and query it’s objects.

Now I am trying to setup the DTLS example and for this I have done the following:

- setup the pre-shared key on the Leshan server (as suggested in [3])
- enable the dlls configuration in the prj_dtls.conf. A dump of this configuration file can be found here [4]. 

>> Please note that I have lowered the CONFIG_MBEDTLS_HEAP_SIZE from 8192 to 4096 cause I got the following error printed in the console which resulted in a none working BT connection.

'[lib/lwm2m_engine] [ERR] lwm2m_init_message: Unable to get TX packet, not enough memory."


Unfortunately the DTLS version doesn’t seem to work. In particular during bootstrap I get error (-72). Here is a dump of the console:

--------------------------------------------------------
***** Booting Zephyr OS v1.11.0-758-g541c3cb18 *****
[lib/lwm2m_engine] [DBG] lwm2m_engine_init: LWM2M engine thread started
[lwm2m_obj_security] [DBG] security_create: Create LWM2M security instance: 0
[lwm2m_obj_server] [DBG] server_create: Create LWM2M server instance: 0
[lwm2m_obj_device] [DBG] device_create: Create LWM2M device instance: 0
[lwm2m_obj_firmware] [DBG] firmware_create: Create LWM2M firmware instance: 0
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: e0:0f:f1:29:76:01 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[lwm2m-client] [INF] main: Run LWM2M client
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/0, value:0x0002f852, len:6
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/1, value:0x0002f85f, len:23
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/2, value:0x0002f87d, len:9
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/3, value:0x0002f88d, len:3
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/9, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/10, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/17, value:0x0002f8b0, len:16
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/18, value:0x0002f8c8, len:5
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/20, value:0x2000c2f7, len:1
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3/0/21, value:0x2000c2f4, len:4
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3303/0
[ipso_temp_sensor] [DBG] temp_sensor_create: Create IPSO Temperature Sensor instance: 0
[lib/lwm2m_engine] [DBG] lwm2m_engine_set: path:3303/0/5700, value:0x2000c310, len:8
[lib/lwm2m_engine] [DBG] lwm2m_engine_create_obj_inst: path:3311/0
[ipso_light_control] [DBG] light_control_create: Create IPSO Light Control instance: 0
prio recv thread stack (real size 748): unused 488      usage 260 / 748 (34 %)
recv thread stack (real size 1324):     unused 424      usage 900 / 1324 (67 %)
[lib/lwm2m_engine] [ERR] lwm2m_engine_start: Cannot connect UDP (-72)
[lib/lwm2m_rd_client] [ERR] lwm2m_rd_client_start: Cannot init LWM2M engine (-72)
[lwm2m-client] [ERR] main: LWM2M init LWM2M RD client error (-72)
prio
--------------------------------------------------------


From the Raspberry PI I can successfully ping the node which implies that connectivity exists and is working.

root@raspberrypi:/home/pi# ping 2001:db8::1. <— BLE Nano 2 
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=221 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=194 ms
^C
--- 2001:db8::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 194.834/208.153/221.472/13.319 ms


I would be grateful if someone can help me to debug the issue.

Thank you in advance

-Christos



Low power node and friend #bluetoothmesh

Diana Rivera
 

Hello,

I'm currently trying to implement a bluetooth mesh that includes not only relay nodes but low power nodes and their respective friends. So far I'm having a bit of trouble trying to do this. Is there an existent sample code for this functionality? Otherwise, could you please let me know the steps needed to establish a friendship?
Finally, I read in https://www.zephyrproject.org/announcing-bluetooth-mesh-support-in-zephyr-project/ that the friend functionality hadn't been implemented yet. Has this changed? Or am I trying to do something that's still not being supported?

Thanks in advance!

DRV


Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

vikrant8051 <vikrant8051@...>
 

Hi Aaron,

CONFIG_BT_MESH_LOW_POWER
CONFIG_BT_MESH_FRIEND

By enabling these parameters you could test LPN & Friend node features.
It has nothing to do with Flash storage.

But if your are planning to create complex n/w, then make sure that all dev kit will
get continuous power supply after Provisioning. Otherwise you have to re-provision NODE which
get disconnected from power.
---------------------------------------------------------------------------------------------------------------------------------------------



On Sun, Apr 22, 2018 at 5:08 AM, Aaron Xu <overheat1984@...> wrote:
Hi Vibrant,

Glad to know that zephyr have this road-map. Do you mean the  Friend & Low Power Node feature will be implemented in zephyr June 2018 with LTS tag ? 

Yes, I think this feature should be very useful for sensor, like environmental or motion sensors. I think remember two cases.
Forgot where to see this use case, It is a photo, a nice house with swimming pool, there are few outdoor temperature/humidity/motion sensors which are solar powered.

Another more reasonable use case is the industry use case. For example some factory need a lot of sensors, they prefer wired not wireless solution, even if they spend a lot of money on the very first set up.
Because the maintenance cost and reliability, but the most important is wired network can works for more then teen years and no need changing battery.
As SIG said, they want the Bluetooth Mesh enter the industry, I suppose it should be commercial, anyway for the industry sensor network on Bluetooth Mesh must works above 10 years with 2 AA batteries.
So I think the  Friend & LPNode feature should be the only solution for such kind of use case.


Regares,
Aaron





Vikrant More <vikrant8051@...> 于 2018年4月21日周六 22:34写道:
Hi Aaron,
I wanna too do that.

But to create complex mesh network, it is required that node should save provisioning & configuration data on
SoC flash. And I hope from next version onwards we could do that which is going to release in June 2018 with LTS tag.

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

....As per my understanding, once this PR get merged into Zephyr main project tree,
that will be the first step towards saving Mesh generated data on SoC flash. 

I'm not able to visualize where we could use Friend & Low Power Node feature in day to day life
experience, so ignore it. Do you have any such example, where we can use Friend & LPNode ?

regards,
vikrant


On Sat, Apr 21, 2018 at 3:43 PM, Aaron Xu <overheat1984@...> wrote:
Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:
Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
Initializing...
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized
[bt] [INF] bt_mesh_prov_init: Device UUID: 00000000-0000-0000-0000-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron







Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

Aaron Xu <overheat1984@...>
 

Hi Vibrant,

Glad to know that zephyr have this road-map. Do you mean the  Friend & Low Power Node feature will be implemented in zephyr June 2018 with LTS tag ? 

Yes, I think this feature should be very useful for sensor, like environmental or motion sensors. I think remember two cases.
Forgot where to see this use case, It is a photo, a nice house with swimming pool, there are few outdoor temperature/humidity/motion sensors which are solar powered.

Another more reasonable use case is the industry use case. For example some factory need a lot of sensors, they prefer wired not wireless solution, even if they spend a lot of money on the very first set up.
Because the maintenance cost and reliability, but the most important is wired network can works for more then teen years and no need changing battery.
As SIG said, they want the Bluetooth Mesh enter the industry, I suppose it should be commercial, anyway for the industry sensor network on Bluetooth Mesh must works above 10 years with 2 AA batteries.
So I think the  Friend & LPNode feature should be the only solution for such kind of use case.


Regares,
Aaron





Vikrant More <vikrant8051@...> 于 2018年4月21日周六 22:34写道:

Hi Aaron,
I wanna too do that.

But to create complex mesh network, it is required that node should save provisioning & configuration data on
SoC flash. And I hope from next version onwards we could do that which is going to release in June 2018 with LTS tag.

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

....As per my understanding, once this PR get merged into Zephyr main project tree,
that will be the first step towards saving Mesh generated data on SoC flash. 

I'm not able to visualize where we could use Friend & Low Power Node feature in day to day life
experience, so ignore it. Do you have any such example, where we can use Friend & LPNode ?

regards,
vikrant


On Sat, Apr 21, 2018 at 3:43 PM, Aaron Xu <overheat1984@...> wrote:
Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:
Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
Initializing...
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized
[bt] [INF] bt_mesh_prov_init: Device UUID: 00000000-0000-0000-0000-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron






Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

vikrant8051 <vikrant8051@...>
 

Hi Aaron,
I wanna too do that.

But to create complex mesh network, it is required that node should save provisioning & configuration data on
SoC flash. And I hope from next version onwards we could do that which is going to release in June 2018 with LTS tag.

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

....As per my understanding, once this PR get merged into Zephyr main project tree,
that will be the first step towards saving Mesh generated data on SoC flash. 

I'm not able to visualize where we could use Friend & Low Power Node feature in day to day life
experience, so ignore it. Do you have any such example, where we can use Friend & LPNode ?

regards,
vikrant


On Sat, Apr 21, 2018 at 3:43 PM, Aaron Xu <overheat1984@...> wrote:
Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:
Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
Initializing...
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized
[bt] [INF] bt_mesh_prov_init: Device UUID: 00000000-0000-0000-0000-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron






Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

Aaron Xu <overheat1984@...>
 

Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:

Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
Initializing...
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized
[bt] [INF] bt_mesh_prov_init: Device UUID: 00000000-0000-0000-0000-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron





Re: #BluetoothMesh guest key implementation #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Fri, Apr 20, 2018, vikrant8051 wrote:
https://www.bluetooth.com/bluetooth-technology/topology-options/le-mesh/mesh-faq

As per this link, under the heading of #VisitorAttacks we could see :

"*Visitor attacks* are prevented by giving guests and visitors temporary
and limited access to the network using a separate set of keys. These guest
keys have a limited lifetime."

How to implement guest key concept with #ZephyrBluetoothMesh ?
It's more of a provisioner issue than a Zephyr issue. On the Zephyr side
all you need to do is make sure your configuration allows at least two
network keys. Then you need to make your provisioner add the key to all
nodes, including the guest node, for the duration that you want the
guest to have access, and then go and remove the key from all nodes once
you want to revoke access (it doesn't matter if the guest is not around
anymore since no other node has that key). You'd probably also want to
do the same thing with the application key, i.e. use a separate one for
the guest (I think that's what's meant by "set of keys" instead of
talking about a single key).

Johan


#BluetoothMesh guest key implementation #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,


As per this link, under the heading of #VisitorAttacks we could see :

"Visitor attacks are prevented by giving guests and visitors temporary and limited access to the network using a separate set of keys. These guest keys have a limited lifetime."

How to implement guest key concept with #ZephyrBluetoothMesh ?

Thank You !!


2061 - 2080 of 2802