Date   

Re: BLE Nitrogen

Carles Cufi
 

Hi Gene,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Steve Brown
Sent: 07 December 2017 22:32
To: Zarkhin, Gene <Gene_Zarkhin@bose.com>; Kinder, David B
<david.b.kinder@intel.com>; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] BLE Nitrogen

Hi Gene,

I've got 4 of these and they will only talk with each other and the
Broadcom radio on my RPI3. Neither my ubertooth sniffer nor a CSR 4.0
dongle can decode anything. I have a couple of nRF52840-PDK's, a Redbear
BLEnano2 and a Sparkfun nrf52 breakout board and none of them have this
difficulty.
That is very strange, since the nRF52832 on the Nitrogen is exactly the same as the one on the BLEnano2, and the codebase for the controller should be identical as well.
When you say "decode anything", do you mean you are not able to connect from the CSR 4.0 dongle to the Nitrogen?

Thanks,

Carles


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Fri, Dec 08, 2017, ashish.shukla@corvi.com wrote:
Here is brief about my experimental setup :

1. NODE1 : Proxy enabled, Relay disabled
2. NODE2 : Proxy disabled, Relay disabled

Now, both nodes belong to same group, which means they are subscribed to
same group address. When I published data on the same group address over
GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This
is as it was expected.

NODE2 is programmed for a button interrupt, which submits a task to system
thread with callback function as below

static void pub_presence(struct k_work *work)
{
static unsigned char led = 0;
static unsigned char trans_id = 0;

int err;

bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);

err = bt_mesh_model_publish(&root_models[2]);
if (err) {
printk("Error in publishing message ");
}

}

What I understand is this publishing is over advertising bearer,
Publishing is not tied to any specific bearer, rather the message is
expected to be delivered to all network interfaces the network layer is
connected to, including GATT.

and NODE1 should not be relaying this packet. But NODE1 relays this
packet as well.
What exactly do you mean by relaying? If NODE2 publishes the message
over advertising and NODE1 receives it over advertising, then NODE1
should at least process the message (since it's subscribed to the group
address). However upon receiving the message NODE1 should not forward
the message to any of its GATT clients or relay it back to the
advertising bearer. If you're seeing any of these last two things
happening, then I'd like to see the debug logs with ADV and NET debugs
enabled.

Also note that since NODE2 is subscribed to the same group address the
message will also be delivered locally to NODE2.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

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

Hi Johan,

Here is brief about my experimental setup :

1. NODE1 : Proxy enabled, Relay disabled
2. NODE2 : Proxy disabled, Relay disabled

Now, both nodes belong to same group, which means they are subscribed to same group address. When I published data on the same group address over GATT bearer using android app, NODE1 relays data, while NODE2 doesn't. This is as it was expected.

NODE2 is programmed for a button interrupt, which submits a task to system thread with callback function as below

static void pub_presence(struct k_work *work)

    static unsigned char led = 0;
    static unsigned char trans_id = 0;
   
    int err;    

    bt_mesh_model_msg_init(root_models[2].pub->msg, OP_GEN_ONOFF_SET);
    net_buf_simple_add_u8(root_models[2].pub->msg,led=led^1);
    net_buf_simple_add_u8(root_models[2].pub->msg,trans_id++);

    err = bt_mesh_model_publish(&root_models[2]);
    if (err) {
        printk("Error in publishing message ");
    }   
 


What I understand is this publishing is over advertising bearer, and NODE1 should not be relaying this packet. But NODE1 relays this packet as well.

 

 


--
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


On Thu, Dec 7, 2017 at 6:05 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@... wrote:
> I was not understanding meaning of *CONFIG_BT_MESH_RELAY=n*  correctly.
> Thanks for clarification.
>
> However, when I enabled the proxy feature of a node, and disabled its relay
> feature, it relays messages from mesh network as well. I'm using latest
> version  zephyr-1.10.0-rc3.

As I said earlier, when the Proxy feature is enabled, the proxy *should*
be relaying messages from the network to any connected GATT client,
regardless of the Relay feature being enabled or not. If you don't want
your GATT Client to see network traffic, i.e. to only have access to
elements on the GATT Proxy itself, then you should disable the GATT
Proxy feature (have CONFIG_BT_MESH_GATT_PROXY=y but set cfg.gatt_proxy
to BT_MESH_GATT_PROXY_DISABLED).

If you're really seeing advertising to advertising relaying with rc3
(which does have all the latest fixes) there's something very strange
going on, since the logic for this is now quite simple in the code. You
can check this yourself by looking at the bt_mesh_net_relay() function
and the relay_to_adv() helper function that it uses. Both are found in
subsys/bluetooth/host/mesh/net.c.

Johan


Re: BLE Nitrogen

Steve Brown
 

Hi Gene,

You can program it with drag/drop CMSIS bootloader's disk, pyocd or
openocd over USB. The "make flash" uses pyocd and worked fine for me.

The softdevice is only the Nordic SDK. Zephyr's Bluetooth and mesh
stacks include everything.

I've got some V1.0 and V1.1's. They are identical except for the caps
in the antenna matching network. If you have a newer version, maybe
they have the RF issues sorted out. I went to a Nordic class a few
weeks ago and they said they will qualify the RF layout and components
if the manufacturer sends them samples.

I'm running a Ubuntu distribution and the drive comes up as
/media/<username>/mbed.

Steve

On Thu, 2017-12-07 at 22:03 +0000, Zarkhin, Gene wrote:
Steve,
Thanks for your reply.
That is a little discouraging ☹
How do you program them?
I connected the board to Win 7 and it created a CDC device and
MassStorage device.
So on Teraterm I see "Hello World" (very exciting!), which stops
working after printing several lines and disk drive, which does not
have an assigned letter.
Reading some docs - they say it supports drug and drop of the image
(they do not specify format, I hope it is hex) but the drive does not
have a letter (as I already mentioned).
I'll try on Linux machine over the weekend, maybe it will assign a
drive.

Also, Nordic requires soft device to be programmed (has a bootloader
and BLE stack), so it should be drugged and dropped before the app, I
guess.

Maybe in your case they have a wrong soft device, no BLE compatible?


Gene Zarkhin
gene_zarkhin@bose.com
(508) 766-9030 – office
(617) 943-2331 – cell

-----Original Message-----
From: Steve Brown [mailto:sbrown@cortland.com]
Sent: Thursday, December 07, 2017 4:32 PM
To: Zarkhin, Gene <Gene_Zarkhin@bose.com>; Kinder, David B <david.b.k
inder@intel.com>; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] BLE Nitrogen

Hi Gene,

I've got 4 of these and they will only talk with each other and the
Broadcom radio on my RPI3. Neither my ubertooth sniffer nor a CSR 4.0
dongle can decode anything. I have a couple of nRF52840-PDK's, a
Redbear BLEnano2 and a Sparkfun nrf52 breakout board and none of them
have this difficulty.

Steve



On Thu, 2017-12-07 at 20:45 +0000, Zarkhin, Gene wrote:
David,
That is definitely helpful to start working.
Thanks,

Gene Zarkhin
gene_zarkhin@bose.com
(508) 766-9030 – office
(617) 943-2331 – cell

From: Kinder, David B [mailto:david.b.kinder@intel.com]
Sent: Thursday, December 07, 2017 3:26 PM
To: Zarkhin, Gene <Gene_Zarkhin@bose.com>; zephyr-devel@lists.zephy
rp
roject.org
Subject: RE: BLE Nitrogen

I see the http://wiki.seeed.cc/BLE_Nitrogen/ site says, “Zephyr
applications use the nrf52_nitrogen configuration to run on the
nRF52
Nitrogen hardware.”
Check out the http://docs.zephyrproject.org/boards/arm/96b_nitrogen
/d
oc/96b_nitrogen.html documentation and see if that’s what you’re
looking for.

-- david


From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-
dev
el-bounces@lists.zephyrproject.org] On Behalf Of Zarkhin, Gene
Sent: Thursday, December 07, 2017 12:16 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] BLE Nitrogen

Hello,
I purchased several BLE Nitrogen boards and having some problems
finding necessary documentation and making them work.
The web site provided by Digi-Key points to http://wiki.seeed.cc/BL
E_
Nitrogen/ site, which points to https://www.zephyrproject.org/ but
on
that site there is no information about BLE Nitrogen and that board
is
not in the list of supported boards.
Also, I installed provided driver on Win 7 and did not get correct
drive letter for MassStorage device.
If you have some proper documentation on how to work with BLE
Nitrogen, please let me know.
Thanks,

Gene Zarkhin
Software Engineer
gene_zarkhin@bose.com
(508) 766-9030 – office
(617) 943-2331 – cell

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: BLE Nitrogen

Zarkhin, Gene <Gene_Zarkhin@...>
 

Steve,

Thanks for your reply.

That is a little discouraging

How do you program them?

I connected the board to Win 7 and it created a CDC device and MassStorage device.

So on Teraterm I see "Hello World" (very exciting!), which stops working after printing several lines and disk drive, which does not have an assigned letter.

Reading some docs - they say it supports drug and drop of the image (they do not specify format, I hope it is hex) but the drive does not have a letter (as I already mentioned).

I'll try on Linux machine over the weekend, maybe it will assign a drive.

 

Also, Nordic requires soft device to be programmed (has a bootloader and BLE stack), so it should be drugged and dropped before the app, I guess.

 

Maybe in your case they have a wrong soft device, no BLE compatible?

 

 

Gene Zarkhin

gene_zarkhin@...

(508) 766-9030 – office

(617) 943-2331 – cell

 

-----Original Message-----
From: Steve Brown [mailto:sbrown@...]
Sent: Thursday, December 07, 2017 4:32 PM
To: Zarkhin, Gene <Gene_Zarkhin@...>; Kinder, David B <david.b.kinder@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] BLE Nitrogen

 

Hi Gene,

 

I've got 4 of these and they will only talk with each other and the Broadcom radio on my RPI3. Neither my ubertooth sniffer nor a CSR 4.0 dongle can decode anything. I have a couple of nRF52840-PDK's, a Redbear BLEnano2 and a Sparkfun nrf52 breakout board and none of them have this difficulty.

 

Steve

 

 

 

On Thu, 2017-12-07 at 20:45 +0000, Zarkhin, Gene wrote:

> David,

> That is definitely helpful to start working.

> Thanks,

> Gene Zarkhin

> gene_zarkhin@...

> (508) 766-9030 – office

> (617) 943-2331 – cell

> From: Kinder, David B [mailto:david.b.kinder@...]

> Sent: Thursday, December 07, 2017 3:26 PM

> To: Zarkhin, Gene <Gene_Zarkhin@...>; zephyr-devel@...

> roject.org

> Subject: RE: BLE Nitrogen

> I see the http://wiki.seeed.cc/BLE_Nitrogen/ site says, “Zephyr

> applications use the nrf52_nitrogen configuration to run on the nRF52

> Nitrogen hardware.”

> Check out the http://docs.zephyrproject.org/boards/arm/96b_nitrogen/d

> oc/96b_nitrogen.html documentation and see if that’s what you’re

> looking for.

> -- david

> From: zephyr-devel-bounces@... [mailto:zephyr-dev

> el-bounces@...] On Behalf Of Zarkhin, Gene

> Sent: Thursday, December 07, 2017 12:16 PM

> To: zephyr-devel@...

> Subject: [Zephyr-devel] BLE Nitrogen

> Hello,

> I purchased several BLE Nitrogen boards and having some problems

> finding necessary documentation and making them work.

> The web site provided by Digi-Key points to http://wiki.seeed.cc/BLE_

> Nitrogen/ site, which points to  https://www.zephyrproject.org/ but on

> that site there is no information about BLE Nitrogen and that board is

> not in the list of supported boards.

> Also, I installed provided driver on Win 7 and did not get correct

> drive letter for MassStorage device.

> If you have some proper documentation on how to work with BLE

> Nitrogen, please let me know.

> Thanks,

> Gene Zarkhin

> Software Engineer

> gene_zarkhin@...

> (508) 766-9030 – office

> (617) 943-2331 – cell

> _______________________________________________

> Zephyr-devel mailing list

> Zephyr-devel@...

> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: BLE Nitrogen

Steve Brown
 

Hi Gene,

I've got 4 of these and they will only talk with each other and the
Broadcom radio on my RPI3. Neither my ubertooth sniffer nor a CSR 4.0
dongle can decode anything. I have a couple of nRF52840-PDK's, a
Redbear BLEnano2 and a Sparkfun nrf52 breakout board and none of them
have this difficulty.

Steve

On Thu, 2017-12-07 at 20:45 +0000, Zarkhin, Gene wrote:
David,
That is definitely helpful to start working.
Thanks,

Gene Zarkhin
gene_zarkhin@bose.com
(508) 766-9030 – office
(617) 943-2331 – cell

From: Kinder, David B [mailto:david.b.kinder@intel.com]
Sent: Thursday, December 07, 2017 3:26 PM
To: Zarkhin, Gene <Gene_Zarkhin@bose.com>; zephyr-devel@lists.zephyrp
roject.org
Subject: RE: BLE Nitrogen

I see the http://wiki.seeed.cc/BLE_Nitrogen/ site says, “Zephyr
applications use the nrf52_nitrogen configuration to run on the nRF52
Nitrogen hardware.”
Check out the http://docs.zephyrproject.org/boards/arm/96b_nitrogen/d
oc/96b_nitrogen.html documentation and see if that’s what you’re
looking for.

-- david


From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-dev
el-bounces@lists.zephyrproject.org] On Behalf Of Zarkhin, Gene
Sent: Thursday, December 07, 2017 12:16 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] BLE Nitrogen

Hello,
I purchased several BLE Nitrogen boards and having some problems
finding necessary documentation and making them work.
The web site provided by Digi-Key points to http://wiki.seeed.cc/BLE_
Nitrogen/ site, which points to https://www.zephyrproject.org/ but
on that site there is no information about BLE Nitrogen and that
board is not in the list of supported boards.
Also, I installed provided driver on Win 7 and did not get correct
drive letter for MassStorage device.
If you have some proper documentation on how to work with BLE
Nitrogen, please let me know.
Thanks,

Gene Zarkhin
Software Engineer
gene_zarkhin@bose.com
(508) 766-9030 – office
(617) 943-2331 – cell

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: BLE Nitrogen

Zarkhin, Gene <Gene_Zarkhin@...>
 

David,

That is definitely helpful to start working.

Thanks,

 

Gene Zarkhin

gene_zarkhin@...

(508) 766-9030 – office

(617) 943-2331 – cell

 

From: Kinder, David B [mailto:david.b.kinder@...]
Sent: Thursday, December 07, 2017 3:26 PM
To: Zarkhin, Gene <Gene_Zarkhin@...>; zephyr-devel@...
Subject: RE: BLE Nitrogen

 

I see the http://wiki.seeed.cc/BLE_Nitrogen/ site says, “Zephyr applications use the nrf52_nitrogen configuration to run on the nRF52 Nitrogen hardware.”

Check out the http://docs.zephyrproject.org/boards/arm/96b_nitrogen/doc/96b_nitrogen.html documentation and see if that’s what you’re looking for.

 

-- david

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Zarkhin, Gene
Sent: Thursday, December 07, 2017 12:16 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] BLE Nitrogen

 

Hello,

I purchased several BLE Nitrogen boards and having some problems finding necessary documentation and making them work.

The web site provided by Digi-Key points to http://wiki.seeed.cc/BLE_Nitrogen/ site, which points to  https://www.zephyrproject.org/ but on that site there is no information about BLE Nitrogen and that board is not in the list of supported boards.

Also, I installed provided driver on Win 7 and did not get correct drive letter for MassStorage device.

If you have some proper documentation on how to work with BLE Nitrogen, please let me know.

Thanks,

 

Gene Zarkhin

Software Engineer

gene_zarkhin@...

(508) 766-9030 – office

(617) 943-2331 – cell

 


Re: BLE Nitrogen

Kinder, David B <david.b.kinder@...>
 

I see the http://wiki.seeed.cc/BLE_Nitrogen/ site says, “Zephyr applications use the nrf52_nitrogen configuration to run on the nRF52 Nitrogen hardware.”

Check out the http://docs.zephyrproject.org/boards/arm/96b_nitrogen/doc/96b_nitrogen.html documentation and see if that’s what you’re looking for.

 

-- david

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Zarkhin, Gene
Sent: Thursday, December 07, 2017 12:16 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] BLE Nitrogen

 

Hello,

I purchased several BLE Nitrogen boards and having some problems finding necessary documentation and making them work.

The web site provided by Digi-Key points to http://wiki.seeed.cc/BLE_Nitrogen/ site, which points to  https://www.zephyrproject.org/ but on that site there is no information about BLE Nitrogen and that board is not in the list of supported boards.

Also, I installed provided driver on Win 7 and did not get correct drive letter for MassStorage device.

If you have some proper documentation on how to work with BLE Nitrogen, please let me know.

Thanks,

 

Gene Zarkhin

Software Engineer

gene_zarkhin@...

(508) 766-9030 – office

(617) 943-2331 – cell

 


BLE Nitrogen

Zarkhin, Gene <Gene_Zarkhin@...>
 

Hello,

I purchased several BLE Nitrogen boards and having some problems finding necessary documentation and making them work.

The web site provided by Digi-Key points to http://wiki.seeed.cc/BLE_Nitrogen/ site, which points to  https://www.zephyrproject.org/ but on that site there is no information about BLE Nitrogen and that board is not in the list of supported boards.

Also, I installed provided driver on Win 7 and did not get correct drive letter for MassStorage device.

If you have some proper documentation on how to work with BLE Nitrogen, please let me know.

Thanks,

 

Gene Zarkhin

Software Engineer

gene_zarkhin@...

(508) 766-9030 – office

(617) 943-2331 – cell

 


unique ID for flash devices

Puzdrowski, Andrzej
 

I’m planning to implement abstraction over flash devices driver similar to this what Mynewt has in flash_mam module.

This is using description of different flash areas. Some of this flash areas could be the embedded flash, some else could be an external.

 

https://github.com/apache/mynewt-core/blob/master/sys/flash_map/include/flash_map/flash_map.h

 

One of features is to provide identification of flash devices for each flash_area. It is important to have “a hard link” in manner which would support

correctlly Identification for a few application existing in one SoC (like case of having common flash memories description for Bootloader and Application)

 

So fare in zphyr API each device is identified by its (configrable) name.

One idea is to introduce fixed Id numbers for each driver and a LUT for making possible to find the link between this ID and the device NAME.

This ID will be used by flash_area descriptions.

 

Maybe someone has got better idea or even my idea is totally wrong – please comment then.

 

Andrzej Puzdrowski

 


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@corvi.com wrote:
I was not understanding meaning of *CONFIG_BT_MESH_RELAY=n* correctly.
Thanks for clarification.

However, when I enabled the proxy feature of a node, and disabled its relay
feature, it relays messages from mesh network as well. I'm using latest
version zephyr-1.10.0-rc3.
As I said earlier, when the Proxy feature is enabled, the proxy *should*
be relaying messages from the network to any connected GATT client,
regardless of the Relay feature being enabled or not. If you don't want
your GATT Client to see network traffic, i.e. to only have access to
elements on the GATT Proxy itself, then you should disable the GATT
Proxy feature (have CONFIG_BT_MESH_GATT_PROXY=y but set cfg.gatt_proxy
to BT_MESH_GATT_PROXY_DISABLED).

If you're really seeing advertising to advertising relaying with rc3
(which does have all the latest fixes) there's something very strange
going on, since the logic for this is now quite simple in the code. You
can check this yourself by looking at the bt_mesh_net_relay() function
and the relay_to_adv() helper function that it uses. Both are found in
subsys/bluetooth/host/mesh/net.c.

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

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

Hi Johan,
I was not understanding meaning of *CONFIG_BT_MESH_RELAY=n*  correctly. Thanks for clarification.

However, when I enabled the proxy feature of a node, and disabled its relay feature, it relays messages from mesh network as well. I'm using latest version  zephyr-1.10.0-rc3.   


--
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


On Thu, Dec 7, 2017 at 4:20 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@... wrote:
> Hi everyone !!!
>
> I'm trying to disable relay feature of node by making these two changes
>
> 1. setting  *CONFIG_BT_MESH_RELAY=n* in the prj.conf file.
>
> 2. static struct bt_mesh_cfg_srv cfg_srv = {
>    * .relay = BT_MESH_RELAY_DISABLED,*

Setting CONFIG_BT_MESH_RELAY=n will actually force the value of
cfg.relay to BT_MESH_RELAY_NOT_SUPPORTED when you initialize mesh, so
trying to set it to disabled shouldn't have any effect. When the value
is NOT_SUPPORTED it can't be changed to any other value at runtime
(which is probably why your attempts with SiLabs don't succeed).

> #if defined(CONFIG_BT_MESH_GATT_PROXY)
>     .gatt_proxy = BT_MESH_GATT_PROXY_ENABLED,
> #else
>     .gatt_proxy = BT_MESH_GATT_PROXY_NOT_SUPPORTED,
> #endif
>     .default_ttl = 5,
>
>     /* network retransmissions with 20ms interval */
>     .net_transmit = BT_MESH_TRANSMIT(5, 20),
>         /* relay retransmissions with 20ms interval */
>     .relay_retransmit = BT_MESH_TRANSMIT(5, 20),
> };
>
> After these two changes, node relays all the messages it receives except
> ones intended for itself.
> What else needs to be done to disable relay feature?
>
> Even Android app by Silicon Labs for bluetooth mesh is not able to disable
> relay feature.

Are you using the latest master branch, since there were fixes for this
feature earlier this week?

Also note that since you're setting gatt_proxy to BT_MESH_GATT_PROXY_ENABLED
it means that the node *is* expected to relay packets between the mesh
network and the GATT Client (however *not* relay packets from the mesh
network back to the mesh network).

Johan


Re: Disabling Relay feature of a node of bluetooth mesh

Johan Hedberg
 

Hi Ashish,

On Thu, Dec 07, 2017, ashish.shukla@corvi.com wrote:
Hi everyone !!!

I'm trying to disable relay feature of node by making these two changes

1. setting *CONFIG_BT_MESH_RELAY=n* in the prj.conf file.

2. static struct bt_mesh_cfg_srv cfg_srv = {
* .relay = BT_MESH_RELAY_DISABLED,*
Setting CONFIG_BT_MESH_RELAY=n will actually force the value of
cfg.relay to BT_MESH_RELAY_NOT_SUPPORTED when you initialize mesh, so
trying to set it to disabled shouldn't have any effect. When the value
is NOT_SUPPORTED it can't be changed to any other value at runtime
(which is probably why your attempts with SiLabs don't succeed).

#if defined(CONFIG_BT_MESH_GATT_PROXY)
.gatt_proxy = BT_MESH_GATT_PROXY_ENABLED,
#else
.gatt_proxy = BT_MESH_GATT_PROXY_NOT_SUPPORTED,
#endif
.default_ttl = 5,

/* network retransmissions with 20ms interval */
.net_transmit = BT_MESH_TRANSMIT(5, 20),
/* relay retransmissions with 20ms interval */
.relay_retransmit = BT_MESH_TRANSMIT(5, 20),
};

After these two changes, node relays all the messages it receives except
ones intended for itself.
What else needs to be done to disable relay feature?

Even Android app by Silicon Labs for bluetooth mesh is not able to disable
relay feature.
Are you using the latest master branch, since there were fixes for this
feature earlier this week?

Also note that since you're setting gatt_proxy to BT_MESH_GATT_PROXY_ENABLED
it means that the node *is* expected to relay packets between the mesh
network and the GATT Client (however *not* relay packets from the mesh
network back to the mesh network).

Johan


Disabling Relay feature of a node of bluetooth mesh

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

Hi everyone !!!

I'm trying to disable relay feature of node by making these two changes

1. setting  CONFIG_BT_MESH_RELAY=n in the prj.conf file.

2. static struct bt_mesh_cfg_srv cfg_srv = {
    .relay = BT_MESH_RELAY_DISABLED,
    .beacon = BT_MESH_BEACON_ENABLED,

#if defined(CONFIG_BT_MESH_GATT_PROXY)
    .gatt_proxy = BT_MESH_GATT_PROXY_ENABLED,
#else
    .gatt_proxy = BT_MESH_GATT_PROXY_NOT_SUPPORTED,
#endif
    .default_ttl = 5,

    /* network retransmissions with 20ms interval */
    .net_transmit = BT_MESH_TRANSMIT(5, 20),
        /* relay retransmissions with 20ms interval */
    .relay_retransmit = BT_MESH_TRANSMIT(5, 20),
};

After these two changes, node relays all the messages it receives except ones intended for itself.
What else needs to be done to disable relay feature?

Even Android app by Silicon Labs for bluetooth mesh is not able to disable relay feature.

--
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: uart_pipe spinning problem for stm32

Dmitry Shmidt
 

On Wed, Dec 6, 2017 at 12:29 AM, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:
Ok, can you raise an issue in github?
We'll get it fixed.
Done, thanks!
https://github.com/zephyrproject-rtos/zephyr/issues/5308

On 5 December 2017 at 19:02, Dmitry Shmidt <dimitrysh@google.com> wrote:

On Tue, Dec 5, 2017 at 8:17 AM, Erwan Gouriou <erwan.gouriou@linaro.org>
wrote:
Hi Dmitry,

Could you try something like:
static int uart_stm32_irq_is_pending(struct device *dev)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

return ((LL_USART_IsActiveFlag_RXNE(UartInstance) &&
LL_USART_IsEnabledIT_RXNE(UartInstance)) ||
(LL_USART_IsActiveFlag_TXE(UartInstance) &&
LL_USART_IsEnabledIT_TXE(UartInstance)));
}
This is working, thanks!


Erwan

On 1 December 2017 at 08:55, Michael Hope <michaelh@juju.nz> wrote:

Hi Dmitry. If it helps, uart_console is also used by the
qemu_cortex_m3
board for the host networking interface. The serial driver [1] uses the
masked interrupt status reg (UARTMIS) [2 pg 460] and not the raw status
(UARTRIS).

-- Michael

[1]

https://github.com/zephyrproject-rtos/zephyr/blob/f3f0c03b86753f5c80570564832bd0159e2fa67f/drivers/serial/uart_stellaris.c#L546
[2] http://www.ti.com/lit/ds/symlink/lm3s6965.pdf


On 30 November 2017 at 18:48, Dmitry Shmidt via Zephyr-devel
<zephyr-devel@lists.zephyrproject.org> wrote:

Hi Erwan,

On Thu, Nov 30, 2017 at 1:28 AM, Erwan Gouriou
<erwan.gouriou@linaro.org>
wrote:
Hi Dmitri,


Can you explicit the functional issue, before we do any change?

About TXE:
TXE is "TX ready", hence indeed likely to be often 1 indeed.

Then, this code is located in isr callback, hence it is hit only on
UART
IRQ.
Having TXE set to TRUE at this step should not be an issue since we
check
rx_ready before read to discriminate if IRQ was actually raised for
RX.

Did I missed something?
The problem is in uart_pipe_isr() logic. It is never-ending (spinning)
after first
time entrance: it is still processing RX but its nature doesn't allow
any
user
threads to get control.

uart_pipe_isr() is called on RX interrupt:

static void uart_pipe_isr(struct device *unused) {
while (uart_irq_update(uart_pipe_dev)
&& uart_irq_is_pending(uart_pipe_dev)) {
...
}

uart_irq_update() is always 1 and uart_irq_is_pending()
is also always 1 (at least in case of stm32):
return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
LL_USART_IsActiveFlag_TXE(UartInstance));

So possible solutions as I can see are:
1) Use uart_irq_rx_ready() instead of uart_irq_is_pending() in
while() in uart_pipe.c
2) Change uart_stm32_irq_is_pending() to return only RNXE -
however other drivers also return RXE || TXE
3) Mask TXE as Michael suggested that is actually (2).

Erwan

On 30 November 2017 at 01:07, Dmitry Shmidt via Zephyr-devel
<zephyr-devel@lists.zephyrproject.org> wrote:

Hello,

In uart_pipe.c code:
static void uart_pipe_isr(struct device *unused)
{
ARG_UNUSED(unused);

while (uart_irq_update(uart_pipe_dev)
&& uart_irq_is_pending(uart_pipe_dev)) {
...
}

uart_irq_update() is returning 1 and
uart_irq_is_pending() is always TRUE for stm32, because
despite RXNE is cleared, TXE is always 1.
static int uart_stm32_irq_is_pending(struct device *dev)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
LL_USART_IsActiveFlag_TXE(UartInstance));

TXE is always 1 probably by design because poll_out is working
properly:
static unsigned char uart_stm32_poll_out(struct device *dev,

unsigned char c)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

/* Wait for TXE flag to be raised */
while (!LL_USART_IsActiveFlag_TXE(UartInstance))
;

Please advise what is the right way to fix this issue:
1) Use uart_irq_rx_ready() instead of uart_irq_is_pending() in
while() in uart_pipe.c
2) Change uart_stm32_irq_is_pending() to return only RNXE -
however other drivers also return RXE || TXE
3) Clear TXE during input processing

Thanks,
Dmitry
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Bluetooth power efficiency

Primini
 

Hi Vinayak and Carles!

First of all, thank you so much for your time. I will check the consumption numbers and send back to you.

Regards, 

Tiago.

On Wed, Dec 6, 2017 at 2:43 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
Hi Tiago,

There is no need to power down the Radio peripheral, if all states are disabled and roles are disconnected in the controller, the peripherals used by the controller will all return back to low power mode. POWER register as documented, is used to reset registers to initial state, otherwise this register is not required to be used in the SoC.

What are the current consumption numbers you are observing with no states and roles?

Regards,
Vinayak


On 6 Dec 2017, at 17:25, Cufi, Carles <Carles.Cufi@...> wrote:

Additional note: NRF_RADIO->TASKS_DISABLE is set every time the roles are disabled and in fact on every ISR, so this hopefully should be enough to power down the radio without even having to care about the NRF_RADIO->POWER register:
 
 
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Cufi, Carles
Sent: 06 December 2017 16:57
To: Tiago Primini <primini@...>; zephyr-devel@lists.zephyrproject.org; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no>
Subject: Re: [Zephyr-devel] Bluetooth power efficiency
 
Hi Tiago,
 
I’ve copied Vinayak on this email since he’s the person with the most in-depth knowledge of the BLE controller, but my take on this is that you don’t need to do anything special with the registers at all. The BLE stack will become completely idle whenever no roles (advertising, scanning, master or slave) are running, and It will do that by itself. Then the CPU core will automatically enter the idle state which will put it into low-power mode until an interrupt is triggered.
I noticed that our current controller HAL does not power down the radio unless it resets it, which powers it up again immediately:
which happens whenever a role becomes active.
 
So it should be safe for you to power down the radio using the NRF_RADIO->POWER register as long as there is no BLE activity going on. Whether that will actively save you power, and the confirmation of the same, I will leave to Vinayak.
 
Regards,
 
Carles
 
 
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Tiago Primini
Sent: 06 December 2017 13:36
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Bluetooth power efficiency
 
Hi everyone!
 
I am using Nordic nrf52832 in my project and I have to set Bluetooth power consumption to a minimum level if possible in a certain period of times. I read in Nordic dev zone (https://devzone.nordicsemi.com/question/13984/completely-disabling-bluetooth/) some alternatives but it is not so clear how to achieve this. 
 
In my point of view stopping advertisement and disconnect all connected devices (which are possible using only Zephyr Bluetooth API) is enough for the hardware entering in a minimum power consumption level (like a disable/disconnected radio state). But if it does not, I could write a radio power register setting the radio to off in an intrusive way (http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&cp=2_1_0_22_13_45&anchor=register.POWER). If I do that, is Zephyr Bluetooth driver able to handle the power off/on without any unwanted side effects? I mean, would be this a correct approach?
 
Regards,
 
T. Primini



Re: Bluetooth power efficiency

Chettimada, Vinayak Kariappa
 

Hi Tiago,

There is no need to power down the Radio peripheral, if all states are disabled and roles are disconnected in the controller, the peripherals used by the controller will all return back to low power mode. POWER register as documented, is used to reset registers to initial state, otherwise this register is not required to be used in the SoC.

What are the current consumption numbers you are observing with no states and roles?

Regards,
Vinayak

On 6 Dec 2017, at 17:25, Cufi, Carles <Carles.Cufi@...> wrote:

Additional note: NRF_RADIO->TASKS_DISABLE is set every time the roles are disabled and in fact on every ISR, so this hopefully should be enough to power down the radio without even having to care about the NRF_RADIO->POWER register:
 
 
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Cufi, Carles
Sent: 06 December 2017 16:57
To: Tiago Primini <primini@...>; zephyr-devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: Re: [Zephyr-devel] Bluetooth power efficiency
 
Hi Tiago,
 
I’ve copied Vinayak on this email since he’s the person with the most in-depth knowledge of the BLE controller, but my take on this is that you don’t need to do anything special with the registers at all. The BLE stack will become completely idle whenever no roles (advertising, scanning, master or slave) are running, and It will do that by itself. Then the CPU core will automatically enter the idle state which will put it into low-power mode until an interrupt is triggered.
I noticed that our current controller HAL does not power down the radio unless it resets it, which powers it up again immediately:
which happens whenever a role becomes active.
 
So it should be safe for you to power down the radio using the NRF_RADIO->POWER register as long as there is no BLE activity going on. Whether that will actively save you power, and the confirmation of the same, I will leave to Vinayak.
 
Regards,
 
Carles
 
 
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tiago Primini
Sent: 06 December 2017 13:36
To: zephyr-devel@...
Subject: [Zephyr-devel] Bluetooth power efficiency
 
Hi everyone!
 
I am using Nordic nrf52832 in my project and I have to set Bluetooth power consumption to a minimum level if possible in a certain period of times. I read in Nordic dev zone (https://devzone.nordicsemi.com/question/13984/completely-disabling-bluetooth/) some alternatives but it is not so clear how to achieve this. 
 
In my point of view stopping advertisement and disconnect all connected devices (which are possible using only Zephyr Bluetooth API) is enough for the hardware entering in a minimum power consumption level (like a disable/disconnected radio state). But if it does not, I could write a radio power register setting the radio to off in an intrusive way (http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&cp=2_1_0_22_13_45&anchor=register.POWER). If I do that, is Zephyr Bluetooth driver able to handle the power off/on without any unwanted side effects? I mean, would be this a correct approach?
 
Regards,
 
T. Primini


Re: Bluetooth power efficiency

Carles Cufi
 

Additional note: NRF_RADIO->TASKS_DISABLE is set every time the roles are disabled and in fact on every ISR, so this hopefully should be enough to power down the radio without even having to care about the NRF_RADIO->POWER register:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hal/nrf5/radio.c#L429

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Cufi, Carles
Sent: 06 December 2017 16:57
To: Tiago Primini <primini@...>; zephyr-devel@...; Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Subject: Re: [Zephyr-devel] Bluetooth power efficiency

 

Hi Tiago,

 

I’ve copied Vinayak on this email since he’s the person with the most in-depth knowledge of the BLE controller, but my take on this is that you don’t need to do anything special with the registers at all. The BLE stack will become completely idle whenever no roles (advertising, scanning, master or slave) are running, and It will do that by itself. Then the CPU core will automatically enter the idle state which will put it into low-power mode until an interrupt is triggered.

I noticed that our current controller HAL does not power down the radio unless it resets it, which powers it up again immediately:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hal/nrf5/radio.c#L108

which happens whenever a role becomes active.

 

So it should be safe for you to power down the radio using the NRF_RADIO->POWER register as long as there is no BLE activity going on. Whether that will actively save you power, and the confirmation of the same, I will leave to Vinayak.

 

Regards,

 

Carles

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tiago Primini
Sent: 06 December 2017 13:36
To: zephyr-devel@...
Subject: [Zephyr-devel] Bluetooth power efficiency

 

Hi everyone!

 

I am using Nordic nrf52832 in my project and I have to set Bluetooth power consumption to a minimum level if possible in a certain period of times. I read in Nordic dev zone (https://devzone.nordicsemi.com/question/13984/completely-disabling-bluetooth/) some alternatives but it is not so clear how to achieve this. 

 

In my point of view stopping advertisement and disconnect all connected devices (which are possible using only Zephyr Bluetooth API) is enough for the hardware entering in a minimum power consumption level (like a disable/disconnected radio state). But if it does not, I could write a radio power register setting the radio to off in an intrusive way (http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&cp=2_1_0_22_13_45&anchor=register.POWER). If I do that, is Zephyr Bluetooth driver able to handle the power off/on without any unwanted side effects? I mean, would be this a correct approach?

 

Regards,

 

T. Primini


Re: Bluetooth power efficiency

Carles Cufi
 

Hi Tiago,

 

I’ve copied Vinayak on this email since he’s the person with the most in-depth knowledge of the BLE controller, but my take on this is that you don’t need to do anything special with the registers at all. The BLE stack will become completely idle whenever no roles (advertising, scanning, master or slave) are running, and It will do that by itself. Then the CPU core will automatically enter the idle state which will put it into low-power mode until an interrupt is triggered.

I noticed that our current controller HAL does not power down the radio unless it resets it, which powers it up again immediately:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/hal/nrf5/radio.c#L108

which happens whenever a role becomes active.

 

So it should be safe for you to power down the radio using the NRF_RADIO->POWER register as long as there is no BLE activity going on. Whether that will actively save you power, and the confirmation of the same, I will leave to Vinayak.

 

Regards,

 

Carles

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tiago Primini
Sent: 06 December 2017 13:36
To: zephyr-devel@...
Subject: [Zephyr-devel] Bluetooth power efficiency

 

Hi everyone!

 

I am using Nordic nrf52832 in my project and I have to set Bluetooth power consumption to a minimum level if possible in a certain period of times. I read in Nordic dev zone (https://devzone.nordicsemi.com/question/13984/completely-disabling-bluetooth/) some alternatives but it is not so clear how to achieve this. 

 

In my point of view stopping advertisement and disconnect all connected devices (which are possible using only Zephyr Bluetooth API) is enough for the hardware entering in a minimum power consumption level (like a disable/disconnected radio state). But if it does not, I could write a radio power register setting the radio to off in an intrusive way (http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&cp=2_1_0_22_13_45&anchor=register.POWER). If I do that, is Zephyr Bluetooth driver able to handle the power off/on without any unwanted side effects? I mean, would be this a correct approach?

 

Regards,

 

T. Primini


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

Vikrant More <vikrant8051@...>
 

Thank you for the clarification. 

Could you please tell me, what should I do next ?

I need agenda to deeply understand concept of #BluetoothMesh.



On Dec 6, 2017 6:56 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Wed, Dec 06, 2017, Vikrant More wrote:
> static void publish(struct k_work *work)
> {
>
>     static unsigned char onoff=0;
>     static unsigned char tid=0;
>     int err;
>
>     struct net_buf_simple *msg = NET_BUF_SIMPLE(2+4+2);
>
>     bt_mesh_model_msg_init(msg, OP_GEN_ONOFF_SET_UNACK);
>     net_buf_simple_add_u8(msg, onoff=onoff^0x01);
>         net_buf_simple_add_u8(msg, tid++);
>
>     printk("Interrupted....data_send=%u\n\r",onoff);
>
>     *root_models[2]*.pub->msg=msg;

This is not safe since the publishing buffer is not expected to be
allocated on the stack. It will cause a crash as soon as the Publish
Retransmit state is set to a non-zero value. I pointed this out earlier
to Steve and also tried to document it better:

https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-November/008457.html

So in your case you'd want to create the buffer when you define the
publication struct, i.e. something like:

static struct bt_mesh_model_pub pub = {
        .msg = NET_BUF_SIMPLE(2+4+2),
};

And then before publishing you'd do the same bt_mesh_model_msg_init()
and net_buf_simple_add_u8() calls as you do now.

> When I publish using  *root_models[2] *then function
> bt_mesh_model_publish(struct bt_mesh_model *model) from
> zephyr/subsys/bluetooth/host/mesh/access.c
> execute properly after pressing the Button1 on nRF52840-PDK.
>
> root_models[2] is server model.
>
> Its publish address assigned by provisioner = 0xC000
> It is subscribed to address = 0xC001
>
> So all other nodes not changed their LED1 status when I pressed Button1
> from any one of the Board since others are subscribed to 0xC001.
>
> But when I hard-coded ctx.addr = 0xC001; in bt_mesh_model_publish(struct
> bt_mesh_model *model) then ohter boards start to toggle LED1.

This looks like an issue with the provisioner (or how you use it) since
it seems it should also be setting the publication address to 0xc0001.

> So I used root_model[4] i.e BT_MESH_MODEL_ID_GEN_ONOFF_CLI.
>
> In this case, after pressing button, function bt_mesh_model_publish() returns
> error as -> bt_mesh_model_publish: err:-49
>
> On investigating, I found that this is because of
>
> if (pub->addr == BT_MESH_ADDR_UNASSIGNED) {
>         return -EADDRNOTAVAIL;
>     }
>
> That means Silicon Labs MESH APP does not assign any Public address to this
> client model.
> Ideally it should be 0xC001 since other NODEs are subscribed to it. Am I
> right ?

Yes, sounds correct to me, i.e. this is an issue on the
provisioner/configuration client side.

Johan

4241 - 4260 of 8046