Date   

Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
But as per my testing, zephyr publishing reliability is not good even if I
call bt_mesh_model_publish() from thread which wakes up on interrupt.
This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan


Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Priyanka
 

Hello

My test set up for IPv6 over BLE is following :

At one end : Two boards frdm-kw41z and frdm-k64f are stacked together.
kw41z (flashed with hci_blackbox firmware) is ble controller with k64f as ble host (flashed with zephyr sample IPSP).

At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble controller attached to Linux host. 


[Kw41z  (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble controller)+Linux host]

Issue with testing IPv6 over BLE :

Once the BLE connection is established, within few seconds BLE controller gets disconnected.
Either zephyr (recent master branch) crashes or BLE controller crashes or both. Often it is BLE controller that gets disconnected within few seconds.
Restarting zephyr might enable establishing the connection once again, but then ble controller goes down immediately.

After that, I should disconnect the boards and connect again (via usb connection) in order to set up the ble connection again.

While on Zephyr side, it always prints connection handle 32
On Linux side, the first time connection handle is 32, afterwards it is different (handle 65, 128 etc.,) as shown with "hcitool conn".
btmon log shows for specific handle : remote user terminated connection or connection terminated by local host

On Linux PC
--------------
$ sudo hciattach ttyACMx any 115200 noflow sleep
Device setup complete

$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 32 state 1 lm MASTER


$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 65 state 8 lm MASTER

$ sudo hcitool conn

Connections:


$ sudo hcitool lescan

LE Scan ...

00:04:9F:00:00:15 (unknown)

00:04:9F:00:00:15 Test IPSP node

04:52:C7:64:6C:65 (unknown)


$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 96 state 1 lm MASTER

$ sudo hcitool conn

Connections:

$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 128 state 1 lm MASTER

$ sudo hcitool conn

Connections:



Zephyr (IPSP)
--------------------
During that very short span of connection, ping does not pass, there is a ping time out and then ble controller goes down.

And it prints error

[bt] [ERR] read_payload: Not enough space in buffer


net> iface

Interface 0x2000a020 (Bluetooth)
================================
Link addr : 00:04:9F:00:00:15
MTU       : 1280
IPv6 unicast addresses (max 3):
        2001:db8::1 manual preferred infinite
        fe80::4:9fff:fe00:15 autoconf preferred infinite
IPv6 multicast addresses (max 2):
        ff84::2
        ff02::1
IPv6 prefixes (max 2):
        <none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 9178
IPv6 retransmit timer    : 0
net> ping 2001:db8::2
Sent a ping to 2001:db8::2
[bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006db4 len 57
[bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg 0x20006bf8 len 59
[bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len 59 credits 3
[bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
[bt] [DBG] bt_conn_send_cb: (0x20001210) conn handle 32 buf len 63 cb 0x00000000
[bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040 sent 57 total_len 57
[bt] [DBG] bt_conn_process_tx: (0x200006f8) conn 0x200008d4
[bt] [DBG] send_buf: (0x200006f8) conn 0x200008d4 buf 0x20006bf8 len 63
[bt] [DBG] send_frag: (0x200006f8) conn 0x200008d4 buf 0x20006bf8 len 63 flags 0x00
[bt] [DBG] bt_conn_notify_tx: (0x200006f8) conn 0x200008d4
[bt] [DBG] add_pending_tx: (0x200006f8) conn 0x200008d4 cb 0x00000000
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8) Adding conn 0x200008d4 to poll list
Ping timeout

btmon log shows for specific handle : remote user terminated connection or connection terminated by local host

$ sudo btmon

< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                             [hci0] 56.603853
        Handle: 32
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.605669
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 56.623140
        Num handles: 1
        Handle: 32
        Count: 0
> HCI Event: Disconnect Complete (0x05) plen 4                                                                             [hci0] 56.623895
        Status: Success (0x00)
        Handle: 32
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2



$ sudo btmon
Bluetooth monitor ver 5.37
= New Index: 00:60:37:00:00:16 (BR/EDR,UART,hci0)                                                                           [hci0] 0.420344
= Open Index: 00:60:37:00:00:16                                                                                             [hci0] 0.420346
= Index Info: 00:60:37:00:00:16 (NXP Semiconductors (formerly Philips Semiconductors))                                      [hci0] 0.420347
> HCI Event: LE Meta Event (0x3e) plen 19                                                                                  [hci0] 25.087469
      LE Connection Complete (0x01)
        Status: Success (0x00)
        Handle: 32
        Role: Master (0x00)
        Peer address type: Public (0x00)
        Peer address: 00:04:9F:00:00:15 (Freescale Semiconductor)
        Connection interval: 18.75 msec (0x000f)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 32000 msec (0x0c80)
        Master clock accuracy: 0x00
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                           [hci0] 25.087749
        Handle: 32
@ Device Connected: 00:04:9F:00:00:15 (1) flags 0x0000
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 25.090858
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12                                                                                  [hci0] 25.160087
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 32
        Features: 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
< ACL Data TX: Handle 32 flags 0x00 dlen 7                                                                                 [hci0] 25.160299
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 25.197003
        Num handles: 1
        Handle: 32
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                  [hci0] 25.216210
      LE Data Length Change (0x07)
        Handle: 32
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> ACL Data RX: Handle 32 flags 0x02 dlen 7                                                                                 [hci0] 25.291092
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 65
< ACL Data TX: Handle 32 flags 0x00 dlen 11                                                                                [hci0] 25.291176
      ATT: Read By Group Type Request (0x10) len 6
        Handle range: 0x0001-0xffff
        Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 25.309459
        Num handles: 1
        Handle: 32
        Count: 1
< HCI Command: LE Create Connection (0x08|0x000d) plen 25                                                                  [hci0] 56.599500
        Scan interval: 2.500 msec (0x0004)
        Scan window: 2.500 msec (0x0004)
        Filter policy: White list is not used (0x00)
        Peer address type: Public (0x00)
        Peer address: 00:04:9F:00:00:15 (Freescale Semiconductor)
        Own address type: Public (0x00)
        Min connection interval: 18.75 msec (0x000f)
        Max connection interval: 18.75 msec (0x000f)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
        Min connection length: 0.625 msec (0x0001)
        Max connection length: 0.625 msec (0x0001)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.603808
      LE Create Connection (0x08|0x000d) ncmd 1
        Status: Success (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                             [hci0] 56.603853
        Handle: 32
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.605669
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 56.623140
        Num handles: 1
        Handle: 32
        Count: 0
> HCI Event: Disconnect Complete (0x05) plen 4                                                                             [hci0] 56.623895
        Status: Success (0x00)
        Handle: 32
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2

> HCI Event: Disconnect Complete (0x05) plen 4                                                                            [hci0] 495.817382
        Status: Success (0x00)
        Handle: 96
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2


< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                          [hci0] 559.455648
        Handle: 128
@ Device Connected: 00:04:9F:00:00:15 (1) flags 0x0000
> HCI Event: Command Status (0x0f) plen 4                                                                                 [hci0] 559.458269
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)

> HCI Event: LE Meta Event (0x3e) plen 12                                                                                 [hci0] 559.552125
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 128
        Features: 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
< ACL Data TX: Handle 128 flags 0x00 dlen 7                                                                               [hci0] 559.552334
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 559.589004
        Num handles: 1
        Handle: 128
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                 [hci0] 559.608138
      LE Data Length Change (0x07)
        Handle: 128
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> ACL Data RX: Handle 128 flags 0x02 dlen 7                                                                               [hci0] 559.683143
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 65
< ACL Data TX: Handle 128 flags 0x00 dlen 11                                                                              [hci0] 559.683325
      ATT: Read By Group Type Request (0x10) len 6
        Handle range: 0x0001-0xffff
        Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 559.701758
        Num handles: 1
        Handle: 128
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                 [hci0] 564.727345
      LE Remote Connection Parameter Request (0x06)
        Handle: 128
        Min connection interval: 30.00 msec (0x0018)
        Max connection interval: 50.00 msec (0x0028)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
< HCI Command: LE Remote Connection Parameter Request Reply (0x08|0x0020) plen 14                                         [hci0] 564.727418
        Handle: 128
        Min connection interval: 30.00 msec (0x0018)
        Max connection interval: 50.00 msec (0x0028)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
        Min connection length: 0.000 msec (0x0000)
        Max connection length: 0.000 msec (0x0000)
@ New Conn Param: 00:04:9F:00:00:15 (1) hint 1 min 0x0018 max 0x0028 latency 0x0000 timeout 0x0c80
> HCI Event: Command Complete (0x0e) plen 6                                                                               [hci0] 564.731202
      LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
        Status: Success (0x00)
        Handle: 128
> HCI Event: LE Meta Event (0x3e) plen 10                                                                                 [hci0] 564.971598
      LE Connection Update Complete (0x03)
        Status: Success (0x00)
        Handle: 128
        Connection interval: 30.00 msec (0x0018)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 32000 msec (0x0c80)
< ACL Data TX: Handle 128 flags 0x00 dlen 18                                                                              [hci0] 577.871547
      LE L2CAP: LE Connection Request (0x14) ident 1 len 10
        PSM: 35 (0x0023)
        Source CID: 64
        MTU: 1280
        MPS: 230
        Credits: 10
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 577.902129
        Num handles: 1
        Handle: 128
        Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 18                                                                              [hci0] 578.113503
      LE L2CAP: LE Connection Response (0x15) ident 1 len 10
        Destination CID: 64
        MTU: 1280
        MPS: 65
        Credits: 20
        Result: Connection successful (0x0000)
< ACL Data TX: Handle 128 flags 0x00 dlen 46                                                                              [hci0] 578.119173
      Channel: 64 len 42 [PSM 35 mode 0] {chan 2}
        28 00 79 4b 00 16 3a 00 05 02 00 00 01 00 8f 00  (.yK..:.........
        6f 74 00 00 00 01 04 00 00 00 ff 02 00 00 00 00  ot..............
        00 00 00 00 00 01 ff 00 00 16                    ..........      
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.142511
        Num handles: 1
        Handle: 128
        Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 50                                                                              [hci0] 578.211240
      Channel: 64 len 46 [PSM 35 mode 0] {chan 2}
        2c 00 7b 3b 3a 01 88 00 b2 32 20 00 00 00 fe 80  ,.{;:....2 .....
        00 00 00 00 00 00 02 60 37 ff fe 00 00 16 02 02  .......`7.......
        00 60 37 ff fe 00 00 16 00 00 00 00 00 00        .`7...........  
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.232753
        Num handles: 1
        Handle: 128
        Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 39                                                                              [hci0] 578.236748
      Channel: 64 len 35 [PSM 35 mode 0] {chan 2}
        21 00 7b 49 3a 02 01 ff 00 00 15 87 00 0c 2c 2a  !.{I:.........,*
        52 a7 7a fe 80 00 00 00 00 00 00 00 04 9f ff fe  R.z.............
        00 00 15                                         ...             
< ACL Data TX: Handle 128 flags 0x00 dlen 39                                                                              [hci0] 578.263150
      Channel: 64 len 35 [PSM 35 mode 0] {chan 2}
        21 00 7b 49 3a 02 01 ff 00 00 16 87 00 43 9b 00  !.{I:........C..
        00 00 00 fe 80 00 00 00 00 00 00 02 60 37 ff fe  ............`7..
        00 00 16                                         ...             
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.292505
        Num handles: 1
        Handle: 128
        Count: 1


--------------------------------------------------------

samples/bluetooth/ipsp$ prj.conf

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_DEVICE_NAME="Test IPSP node"
CONFIG_NETWORKING=y
CONFIG_NET_IPV6=y
CONFIG_NET_IPV4=n
CONFIG_NET_UDP=y
CONFIG_NET_TCP=y
CONFIG_TEST_RANDOM_GENERATOR=y
CONFIG_NET_LOG=y
CONFIG_NET_L2_BT=y
CONFIG_NET_DEBUG_L2_BT=y
CONFIG_SYS_LOG_SHOW_COLOR=y
CONFIG_INIT_STACKS=y
CONFIG_NET_STATISTICS=y
CONFIG_NET_PKT_RX_COUNT=10
CONFIG_NET_PKT_TX_COUNT=10
CONFIG_NET_BUF_RX_COUNT=20
CONFIG_NET_BUF_TX_COUNT=20
CONFIG_NET_IF_UNICAST_IPV6_ADDR_COUNT=3
CONFIG_NET_IF_MCAST_IPV6_ADDR_COUNT=2
CONFIG_NET_MAX_CONTEXTS=6

CONFIG_NET_SHELL=y
CONFIG_BT_SHELL=y

CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
CONFIG_NET_APP_PEER_IPV6_ADDR="2001:db8::2"
CONFIG_NET_APP_BT_NODE=y

CONFIG_NET_L2_ETHERNET=n
CONFIG_ETH_MCUX=n
CONFIG_ETH_MCUX_0=n

#CONFIG_BT_DEBUG_HCI_DRIVER=y
#CONFIG_BT_DEBUG_HCI_CORE=y

CONFIG_BT_PRIVACY=n
#CONFIG_BT_DEBUG=y
#CONFIG_BT_DEBUG_HCI_CORE=n
CONFIG_BT_DEBUG_CONN=y
CONFIG_BT_DEBUG_KEYS=y
CONFIG_BT_DEBUG_L2CAP=y
CONFIG_BT_DEBUG_SMP=y
CONFIG_BT_DEBUG_SDP=y


Thanks

Priyanka


Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Hello,

I need simple clone of of "Light_Switch" demo (part of nordic semiconductor mesh SDK) using Zephyr.
In that demo, we can control Led1 on Servers using publishing data from client. Reliability is 100% even entire demo is based on only ADV-Bearer.
They used one client & 3 Servers. Client itself acts like provisioner.

Unfortunately, Nordic uses only ADV-Bearer & so we can't use available Silicon Labs Mesh App as provisioner.

So I shift to Zephyr since at least I can test working of Mesh using Provisioner APP.

But as per my testing, zephyr publishing reliability is not good even if I call bt_mesh_model_publish() from thread which wakes up on interrupt.

I want to publish 0 and 1 (toggle) after pressing button on one device to all other available nodes in vicinity. (individually using Unicast addresses & for many using Group address  )

So please release such full working demo like Nordic using Zephyr OS.
 
Or help me in details so that I can release behalf on Zephyr Community.

Thank You!!


Re: [Zephyr-devel] mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Johan Hedberg wrote:
On Tue, Dec 05, 2017, Vikrant More wrote:
I applied your recent patch (that is https://github.com/
zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App)
if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.
Are you talking about adv-adv relaying or GATT-adv relaying (or
vice-versa)? Steve seemed to confirm that the current code works as it
should.
I took a second look at the logic in bt_mesh_net_relay() and indeed it
was still buggy. Thanks for catching this. The following pull request
(which I'm still doing a bit of testing on) should fix the issue:

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

Johan


Re: [Zephyr-devel] mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Johan Hedberg wrote:
Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs
Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte
of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".
Are you sure nRF connect isn't juts holding on to cached GATT database
information. When provisioning is complete Zephyr will remove the
provisioning service and replace it with the GATT proxy service. This
means that the GATT Proxy service will likely get the same attribute
handle values as the provisioning service. The Zephyr GATT server will
send out appropriate service changed indications for this, but if the
client doesn't support this it might get confused (thinking the old
service is there even though it has actually been replaced with another
one). You'd probably need to find a way to force re-discovery of
services (possibly by disconnecting & reconnecting).
For the record, I just did a quick test with the LigthBlue app (similar
to nRFConnect) and it correctly shows that the Provisioning service
(UUID 0x1827) gets replaced by the GATT Proxy service (UUID 0x1828)
after provisioning.

Johan


Re: [Zephyr-devel] mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Vikrant,

Please try to avoid top-posting, especially if the existing thread is
using inline quoting.

On Tue, Dec 05, 2017, Vikrant More wrote:
I applied your recent patch (that is https://github.com/
zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App)
if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.
Are you talking about adv-adv relaying or GATT-adv relaying (or
vice-versa)? Steve seemed to confirm that the current code works as it
should.

Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs
Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte
of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".
Are you sure nRF connect isn't juts holding on to cached GATT database
information. When provisioning is complete Zephyr will remove the
provisioning service and replace it with the GATT proxy service. This
means that the GATT Proxy service will likely get the same attribute
handle values as the provisioning service. The Zephyr GATT server will
send out appropriate service changed indications for this, but if the
client doesn't support this it might get confused (thinking the old
service is there even though it has actually been replaced with another
one). You'd probably need to find a way to force re-discovery of
services (possibly by disconnecting & reconnecting).

Johan


Re: samples/basic/button code not working on nrf52840

Laurence Pasteau
 

Hi,


I think you have maybe the answer here :

https://github.com/zephyrproject-rtos/zephyr/issues/4008


Does it help you ?


Regards,

Laurence


De : zephyr-users-bounces@... <zephyr-users-bounces@...> de la part de ashish.shukla@... <ashish.shukla@...>
Envoyé : mardi 5 décembre 2017 05:29
À : Johan Hedberg; zephyr-users@...; zephyr-devel@...
Objet : [Zephyr-users] samples/basic/button code not working on nrf52840
 
Hi,

I'm trying to work with button interrupt available in samples/basic/button example on nrf52840. I'm unable to figure out why it isn't working.
Code compiles successfully but interrupt is never enabled. Any help would be appreciated. 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: [Zephyr-devel] mesh: relay traffic when relay state is 0x02 (not supported)

Vikrant More <vikrant8051@...>
 

I applied your recent patch (that is https://github.com/zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App) if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".


Please re-check & confirm this.
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



On Sun, Dec 3, 2017 at 7:42 PM, Vikrant More <vikrant8051@...> wrote:
Sir I'm talking about this(attached image) ON/OFF setting which available during configuration of Device.

As per my observation, whatever we set here doesn't get reflected at device side. Means if we turn off relay, NODE still relaying the received packets.

>>The GATT service should be gone. After provisioning, if you disconnect,
>>reconnect, and are still able to discover the provisioning service UUID
>>in the GATT database, then that's a bug.


After provisioning, Silicon Labs Mesh App is not able to discover the NODEs. But it get detected in nRFConnect App (App provided by Nordic Semiconductor) as unknown device (not as Zephyr). We can easily connect with it & easily access Mesh Provising Service using the same App.

When I send some random data via it, on terminal of NODE we get error as "message is too short". Means NODE accepts data from any device. 

If possible please try all my observations using SiliconLabs App & nrf52840_pca10056 board.

Correct me if I'm wrong somewhere.

Thank You !!

On Dec 3, 2017 2:00 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Sun, Dec 03, 2017, Vikrant More wrote:
> If I configured Relay OFF/ Proxy Off using Silicon Labs Bluetooth Mesh App
> that does not change anything in reality.  If Relay is ON as per firmware
> then it remains ON.

What do you mean by this? That the state value remains 0x01 or that the
node keeps relaying regardless of the value? If you have GATT Proxy
enabled then you're observing the same thing as Steve reported, and this
should get fixed by my latest pull request.

> Plus even after provisioning, I can connect to #MeshProvisioningService on
> NODE using #nRFconnect App and also able to send data to it.

The GATT service should be gone. After provisioning, if you disconnect,
reconnect, and are still able to discover the provisioning service UUID
in the GATT database, then that's a bug.

Johan



samples/basic/button code not working on nrf52840

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi,

I'm trying to work with button interrupt available in samples/basic/button example on nrf52840. I'm unable to figure out why it isn't working.
Code compiles successfully but interrupt is never enabled. Any help would be appreciated. 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


MQTT-SN support

Flavio Arieta <flavioarieta@...>
 

Hi,


I was studying the MQTT protocol and got in doubt why the rtos implements it instead of MQTT-SN.

There is an email from April 2016 on the Zephyr-devel mailing list saying that there are little dependencies to implement the MQTT-SN and on the roadmap it could be implemented first, then CoAP and finally MQTT itself.
Is there any updates about this apart from the single reply that it received back in 2016?



Thanks, 
Flávio Arieta Netto.


Re: [Zephyr-devel] GPIO interrupt not linked using zephyr API

Tomasz Bursztyka <tomasz.bursztyka@...>
 

Hi,

You shouldn't have to deal with low level hardware specific code.
Zephyr provides a generic way to manipulate gpios and all.

Have a look at samples/drivers/gpio/

And to include/gpio.h as well.

Tomasz

Hello,

//-------------------------------------------------------------------
---------------------------------------------------------

#include <zephyr.h>
#include <misc/printk.h>

#include "nrf_delay.h"
#include "nrf_gpio.h"

#include "board.h"


#define SETB(x,y) (x|=(1<<y)) //for o/p
#define CLRB(x,y) (x&=(~(1<<y))) //for o/p
#define TGLB(x,y) (x^=(1<<y)) //for o/p
#define CHECKB(x,y) (x&(1<<y)) //for i/p

void GPIOTE_IRQHandler(void *arg)
{
if(NRF_GPIOTE->EVENTS_IN[0]==1)
{
NRF_GPIOTE->EVENTS_IN[0]=0;
NRF_P0->OUT ^= (1<<15); //LED3
}
}

void gpio_init(void)
{

NRF_P0->DIR |= 0x0001E000;
NRF_P0->OUTSET |= 0x0001E000;

NRF_P0->PIN_CNF[11]=0x0000000C;


NRF_GPIOTE->INTENSET |= 0x00000001;
NRF_GPIOTE->CONFIG[0] |= 0x00000001 | (11<<8) | (2<<16);

//NVIC_EnableIRQ(GPIOTE_IRQn);

IRQ_CONNECT(6,1,GPIOTE_IRQHandler,0,0);
irq_enable(6);
}

void main(void)
{
printk("Hello World! %s\n", CONFIG_ARCH);
gpio_init();

while(1)
{
NRF_P0->OUT ^= (1<<13); //LED1
nrf_delay_ms(20);

/*(Polling Method)
if(CHECKB(NRF_P0->IN,11)==0)
{

while(CHECKB(NRF_P0->IN,11)==0){}

printk("Button Pressed !!\n\r");

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

}
*/
}
}

//-------------------------------------------------------------------
--------------------------------------------------------------------

This is my simple code in which I want to enable button pressed
interrupt.

My board is nrf52840_pca10056.

Button1 is attached to P0.11.
Using polling method, I'm able to toggle on board LED4. But same is
not happing with interrupt.
Code gets compile without any error. But don't know why interrupt is
not working.

I've also add following config parameters in prj.conf

CONFIG_GPIO=y
CONFIG_GPIO_NRF5_P0=y
CONFIG_GPIO_NRF5_P0_DEV_NAME="SW0_GPIO_PIN"
CONFIG_GPIO_NRF5_PORT_P0_PRI=6



For reference I'm using this link -> http://docs.zephyrproject.org/ke
rnel/other/interrupts.html
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Publishing user data

Johan Hedberg
 

Hi Ashish,

On Mon, Dec 04, 2017, ashish.shukla@corvi.com wrote:
In a project, I need to publish specific data to neighboring nodes
utilizing TTL value. For this sake, I've configured all the nodes to be a
relay node and publish address for the model is set to 0xFFE, which has
been done so that it publishes to all relay nodes.Is my understanding of
address 0xFFE correct?
The "all relays" group address is 0xfffe and not 0xffe. In most cases
it's unwise (inefficient) to have all nodes of a mesh network acting as
relays, so you may want to rethink your setup. It might make more sense
to use a normal group address instead. Note that with a normal group
address, after configuring model publication, you'll also need to
configure model subscription by having your provisioner send Config
Model Subscription Add messages to your nodes.

Now, when I configured this node using android app, publish address of the
model is over-written by the app.
What do you mean that it's overwritten? The provisioner (the "android
app" in this case I suppose?) is the entity that in most normal
situations is expected to configure the model publication. I.e. the
publication address wouldn't be set to anything until the app sends a
Config Model Publication Set message to your node.

Should I modify this address to 0xFFE before using bt_mesh_model_publish()
API ?
What do you mean by "modify"? Normally it would be the provisioner that
configures the model publication with through the configuration model.

Johan


Publishing user data

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi everyone !

In a project, I need to publish specific data to neighboring nodes utilizing TTL value. For this sake, I've configured all the nodes to be a relay node and publish address for the model is set to 0xFFE, which has been done so that it publishes to all relay nodes.Is my understanding of address 0xFFE correct?

Now, when I configured this node using android app, publish address of the model is over-written by the app.

Should I modify this address to 0xFFE before using bt_mesh_model_publish() API ? 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: help with building and cmake.

Felipe Neves
 

Hi all,

@Graham:

cmake –DBOARD=ardino_101 ../..

The recommended way to build a sample should be:

from the sample directory type:

mkdir build 
cd build

Then:

cmake –DBOARD=arduino_101 .. (note we only to go to the upper directory from build)

Then:

make -j


In build/zephyr you’ll find the file <target_name>.bin ( the generic name is zephyr.bin) and you will be able to flash it to your target.

Plese let me know if this was helpful to you.

Best

Felipe

Em sábado, 2 de dezembro de 2017, Cufi, Carles <Carles.Cufi@...> escreveu:

Hi Graham,

 

The first release after the transition from Make/Kbuild to CMake will be 1.10.

If you are building 1.9.2 then you need to use Make just as you did with  1.7.0. You can generate the documentation for 1.9.2 by running “make htmldocs” from the root of the git repo.

 

Regards,

 

Carles

 

From: <zephyr-users-bounces@lists.zephyrproject.org> on behalf of Graham Stott <gbcstott1@...>
Date: Saturday, 2 December 2017 at 05:20
To: "zephyr-users@lists.zephyrproject.org" <zephyr-users@lists.zephyrproject.org>
Subject: [Zephyr-users] help with building and cmake.

 

I am trying to move my project from zephyr v1.7.0 to v1.9.2. I am using a new Ubuntu 16.04 LTS 64 bit system and therefore I am starting from scratch.

 

I followed the “Getting Started Guide” and first did the “Development Environment setup for Linux”.  I installed cmake version 3.10.0.  I also installed the 0.9.2 SDK.

 

I then follow the “Getting Started Guide” for Building and Running an Application.  In step 4,  it has an example of building the “Hello World” example.  When I enter the following command:

 

cmake –DBOARD=ardino_101 ../..

 

I get  the following error:

 

CMake Error:  “The source directory /home/gstott/zephyr-v1.9.2 /samples/hello_world” does not appear to contain CMakeLists.txt

 

I do not see any instructions on how this file is generated.

 

What am I missing?

 

Graham



--
Felipe S. Neves 
Embedded software & systems engineer
Skype: fneves1989
+55 11 96610 – 0855 


Re: understanding of logic behind address used in Publish-Subscribe mechanism for Bluetooth Mesh

Johan Hedberg
 

Hi Vikrant,

On Sat, Dec 02, 2017, Vikrant More wrote:
unsigned char elem_idx = model->elem->addr - bt_mesh_primary_addr();
What do you need this for? If you need to access the element it's right
there in model->elem.

Data(set)= *0 or 1*
Data(set) unicast_addr = *1*
Data(set) pub_addr = *0xC000 <--------------------------What is
significance of this address ??*
Data(set) sub_addr =

*0XC001 *

*when I control Led individually , source address = 0x2001 & destination
address = 0x0001*

*when I control Led using master control , source address = 0x2001 &
destination address = 0xC001.*

*Then tell me what is roll or use of 0xC000 ?*

*Or how it will help us ?*
That's just some group address the provisioner has apparently configured
this model to publish to.

Johan


GPIO interrupt not linked using zephyr API

Vikrant More <vikrant8051@...>
 

Hello,

//----------------------------------------------------------------------------------------------------------------------------

#include <zephyr.h>
#include <misc/printk.h>

#include "nrf_delay.h"
#include "nrf_gpio.h"

#include "board.h"


#define  SETB(x,y)   (x|=(1<<y))     //for o/p
#define  CLRB(x,y)   (x&=(~(1<<y)))  //for o/p
#define  TGLB(x,y)   (x^=(1<<y))     //for o/p
#define  CHECKB(x,y) (x&(1<<y))      //for i/p

void GPIOTE_IRQHandler(void *arg)
{
  if(NRF_GPIOTE->EVENTS_IN[0]==1)
  {
    NRF_GPIOTE->EVENTS_IN[0]=0;
    NRF_P0->OUT ^= (1<<15); //LED3
  }
}

void gpio_init(void)
{
 
  NRF_P0->DIR |= 0x0001E000;
  NRF_P0->OUTSET |= 0x0001E000;

  NRF_P0->PIN_CNF[11]=0x0000000C;


  NRF_GPIOTE->INTENSET |= 0x00000001;                         
  NRF_GPIOTE->CONFIG[0] |= 0x00000001 | (11<<8) | (2<<16);

  //NVIC_EnableIRQ(GPIOTE_IRQn);

  IRQ_CONNECT(6,1,GPIOTE_IRQHandler,0,0);
  irq_enable(6);
}

void main(void)
{
    printk("Hello World! %s\n", CONFIG_ARCH);
    gpio_init();

    while(1)
    {
        NRF_P0->OUT ^= (1<<13); //LED1
        nrf_delay_ms(20);

        /*(Polling Method)
        if(CHECKB(NRF_P0->IN,11)==0)
        {

            while(CHECKB(NRF_P0->IN,11)==0){} 

            printk("Button Pressed !!\n\r");

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

        }
        */
    }
}

//---------------------------------------------------------------------------------------------------------------------------------------

This is my simple code in which I want to enable button pressed interrupt.

My board is nrf52840_pca10056.

Button1 is attached to P0.11.
Using polling method, I'm able to toggle on board LED4. But same is not happing with interrupt.
Code gets compile without any error. But don't know why interrupt is not working.

I've also add following config parameters in prj.conf

CONFIG_GPIO=y
CONFIG_GPIO_NRF5_P0=y
CONFIG_GPIO_NRF5_P0_DEV_NAME="SW0_GPIO_PIN"
CONFIG_GPIO_NRF5_PORT_P0_PRI=6



For reference I'm using this link -> http://docs.zephyrproject.org/kernel/other/interrupts.html


Re: help with building and cmake.

Carles Cufi
 

Hi Graham,

 

The first release after the transition from Make/Kbuild to CMake will be 1.10.

If you are building 1.9.2 then you need to use Make just as you did with  1.7.0. You can generate the documentation for 1.9.2 by running “make htmldocs” from the root of the git repo.

 

Regards,

 

Carles

 

From: <zephyr-users-bounces@...> on behalf of Graham Stott <gbcstott1@...>
Date: Saturday, 2 December 2017 at 05:20
To: "zephyr-users@..." <zephyr-users@...>
Subject: [Zephyr-users] help with building and cmake.

 

I am trying to move my project from zephyr v1.7.0 to v1.9.2. I am using a new Ubuntu 16.04 LTS 64 bit system and therefore I am starting from scratch.

 

I followed the “Getting Started Guide” and first did the “Development Environment setup for Linux”.  I installed cmake version 3.10.0.  I also installed the 0.9.2 SDK.

 

I then follow the “Getting Started Guide” for Building and Running an Application.  In step 4,  it has an example of building the “Hello World” example.  When I enter the following command:

 

cmake –DBOARD=ardino_101 ../..

 

I get  the following error:

 

CMake Error:  “The source directory /home/gstott/zephyr-v1.9.2 /samples/hello_world” does not appear to contain CMakeLists.txt

 

I do not see any instructions on how this file is generated.

 

What am I missing?

 

Graham


understanding of logic behind address used in Publish-Subscribe mechanism for Bluetooth Mesh

Vikrant More <vikrant8051@...>
 

static void gen_onoff_set(struct bt_mesh_model *model,
              struct bt_mesh_msg_ctx *ctx,
              struct net_buf_simple *buf)
{   
   
        static volatile unsigned char copy1=NULL;

        unsigned char elem_idx = model->elem->addr - bt_mesh_primary_addr();

        unsigned char boo = net_buf_simple_pull_u8(buf);

        if( boo != copy1)
        {   
       
         printk("Data(set)= %u \n\r",boo);
         printk("Data(set) unicast_addr = %u \n\r",model->elem->addr);
         printk("Data(set) pub_addr = %u \n\r",model->pub->addr);
         printk("Data(set) sub_addr = %u \n\r",model->groups[0]);
   
         switch(elem_idx)
         {
            case 0:   
                     if(boo!=0)
                        NRF_P0->OUT &= ~(1<<13);
                    
                     else
                        NRF_P0->OUTSET |= (1<<13);                             
                    
                     break;

             case 1:     
                  if(boo!=0)
                     NRF_P0->OUT &= ~(1<<14);
                  else
                     NRF_P0->OUTSET |= (1<<14);                             
                 
                 break;   
          }

          copy1=boo;

       }//end of if

}



I have edited gen_onoff_set function for onoff server as mentioned above.

I'm using Silicon Labs Bluetooth Mesh App to provision & configure my nrf52840_pca10056 Board.


After controlling LED using GUI from App, above function is executing normally.

And it prints ...

Data(set)= 0 or 1
Data(set) unicast_addr = 1
Data(set) pub_addr = 0xC000 <--------------------------What is significance of this address ??
Data(set) sub_addr = 0XC001

when I control Led individually , source address = 0x2001 & destination address = 0x0001

when I control Led using master control , source address = 0x2001 & destination address = 0xC001.

Then tell me what is roll or use of 0xC000 ?
Or how it will help us ?


   

 




help with building and cmake.

Graham Stott <gbcstott1@...>
 

I am trying to move my project from zephyr v1.7.0 to v1.9.2. I am using a new Ubuntu 16.04 LTS 64 bit system and therefore I am starting from scratch.

 

I followed the “Getting Started Guide” and first did the “Development Environment setup for Linux”.  I installed cmake version 3.10.0.  I also installed the 0.9.2 SDK.

 

I then follow the “Getting Started Guide” for Building and Running an Application.  In step 4,  it has an example of building the “Hello World” example.  When I enter the following command:

 

cmake –DBOARD=ardino_101 ../..

 

I get  the following error:

 

CMake Error:  “The source directory /home/gstott/zephyr-v1.9.2 /samples/hello_world” does not appear to contain CMakeLists.txt

 

I do not see any instructions on how this file is generated.

 

What am I missing?

 

Graham


Re: about success rate of publish-subscribe mechanism of Zephyr Bluetooth Mesh

Johan Hedberg
 

Hi Vikrant,

On Fri, Dec 01, 2017, Vikrant More wrote:
if (bt_mesh_model_send(&root_models[2], &ctx1, msg1, NULL, NULL)) {
Note that strictly speaking this isn't publishing. For publishing you'd
use the bt_mesh_model_publish() API. The bt_mesh_model_send() is
primarily intended to be used for responding to messages when you're
implementing a server model.

I am calling this function from Button interrupt
The Mesh APIs aren't designed to be called directly from interrupt
context since they need to potentially block while waiting for buffers
to become available. The encryption procedures also consume a lot of CPU
time, which is unacceptable e.g. for the controller code which relies on
low-latency interrupts. So I'd recommend deferring the calls to thread
context using e.g. k_work, like the mesh_demo app does for the BBC
micro:bit button presses.

But on an average only 6 out 10 times, exact data get received by all
*Subscribers*.

Silicon Labs Bluetooth Mesh App has functionality of *Master Control *(on/off
switch which control LED on all nodes in single click).
It is working perfectly. Success rate is 100%.

But if I try the same with (*Publisher*) node based on Zephyr as mentioned
above then it is not 100% reliable.

Is there anything that I am missing in my code ?
The SiLabs Android app only uses GATT, and GATT is a 100% reliable
bearer. The advertising bearer is not, so you may easily get lost
packets. This is why the Mesh specification comes with all sorts of ways
for fine-tuning transmission reliability. You've e.g. got the Network
Transmit state as well as the Publish Retransmit state that can be used
to increase the number of transmissions that your node does when sending
out data over the advertising bearer.

Johan

2321 - 2340 of 2659