Hi vneehu,

      The ADC can attenuate the input signal so that the full scale voltage (VFS) can be higher than the reference. On EFR32xG13, for instance, you can attentuate the signal by a factor of 1,2,5. This is documented in the reference manual under the ADC section.

Steve

Hi,

    In an unprogammed device, assuming its actually blank, you won't go to EM2 sleep. 15 uA average current for the parameters you mentioned sounds a little high. A slave that only needs to respond every 5 seconds or so should have a lower average current. Could it be that the device is also sending out scannable advertisements? This would raise the current consumption.

If you want someone to take a closer look, please open a ticket in our support portal.

Steve

Hi,

    Error codes are documented in the API guide. 0x185 means timeout, so the friend seems to have stopped responding for some reason. Similarly, 0xC08 means "no friend offer". Based on this information, it sounds like the friend/LPN relationship is not stable. The first step I'd suggest is to look at a packet trace to see the communication between the friend and LPN. Its difficult to offer advice without more information. It may be that the friend and LPN are out of range or it could be that the friend has relationships with too many LPNs already.

Steve

Hi,

   I don't think the spec forbids this but I haven't tried it because I haven't seen a use-case for doing so. The configuration client is responsible for assigning publish and subscribe addresses, so you can assign these with calls to gecko_cmd_mesh_config_client_add_model_pub()/gecko_cmd_mesh_config_client_add_model_sub() in your provisioner.

Steve

Jeff,

   It is only possible to advertise on the 1M and 125k PHY. The reason being that 125k (S8) PHY provides the longest range. To use the 500k (S2) PHY you can connect on 125k and then switch to 500k.

Steve

Hi,

I am using EFR32 based EVK for BLE mesh. I am able to connect the devices through mobile app and the boards running with Ble_switch and BLE_light applications. I can control BLE_light from BLE_switch. But not vice-versa. Also I want to know how to control one BLE_light device from another BLE_light device?  

Is there any sample code available for this? Pls share if any. 
Else pls share the details to setup the same.

Hi,

    The way to do many to many in BLE mesh is by using group addresses for publishing and subscribing. The switch is implemented as a generic on/off client, so by publishing a message to a group address. The lights are implemented as generic on/off servers and subscribe to this group address. If you want the lights to control each other, then you can make them clients as well as servers. You can add the client model in the isc file for the project.

I don't have example code to do this, but you can look at the switch sample code to see how publishing is done and port that over to your light.

Steve

Introduction

This article includes a code example that implements a Bluetooth mesh provisioner that can be run on one of our Bluetooth capable development kits.

To understand how the provisioning and configuration of mesh nodes works, it is recommended that you first try out the mesh Android app as explained in the quickstart guide QSG148.

The example presented in this article can perform the same operations as the mobile app but it is more autonomous and requires only minimal input from the user. When the provisioner sees an unprovisioned beacon, it prints the UUID of this device to the debug console and then you can either:

- push button PB1 to provision and configure the device (*

- push button PB0 to ignore this beacon and continue scanning for other beacons (*

*) Alternatively, you can press key 'y' / 'n' on the terminal to provision or ignore the found device (starting from version v6)

The purpose of this example is to show how the Silicon Labs BT mesh stack can be used in provisioning mode. The main steps in provisioning and configuration are summarized below, along with a list of related API calls.

NOTE: This example is intended only for small scale experimental use. It is not meant to be used as a basis for any production use and the code.

Known limitations:

• The provisioning data is stored in the EFR32 internal flash and has limited capacity, the maximum number of nodes this example can support is around 10-15

• the max number of SIG and vendor models is limited to 16 and 4, respectively (see definition of struct tsDCD)

• This example is missing many important features that are needed in a real production quality provisioner, such as:

  • key refresh, blacklisting of devices

  • removing nodes from the network

Provisioning and configuration basic steps

The main steps included in provisioning a device into the network and configuring the node are summarized in the following table. This is just a compact list of what operations and API calls are involved in the process. More detailed information about provisioning and configuration in Bluetooth mesh can be found in:

• Mesh Profile specification by Bluetooth SIG, rev 1.0 (Chapter 5 Provisioning)

• https://blog.bluetooth.com/provisioning-a-bluetooth-mesh-network-part-1

• https://blog.bluetooth.com/provisioning-a-bluetooth-mesh-network-part-2

Code example

The sample code is attached in a zip file. The zip file includes a readme.md file that explains step-by-step how this code can be installed on top of one of the examples in the Bluetooth mesh SDK.

The Silicon Labs Bluetooth Mesh SDK performs consistency checks on the non-volatile storage areas, that hold information such as keys, at startup. These areas are not erased when flashing a new application. If the application on the EFR32 is changed from embedded provisioner to something else, like a light or switch node, or from such a node to embedded provisioner, the entire contents of flash must be erased to avoid errors during initialization. This can be accomplished with Simplicity Commander

(commander device recover)

Version history:

Composition Data and Memory Configuration

In order for the provisioner to configure the nodes there are a few requirements that must be met.

Firstly, the config client must be added to the device composition data (DCD) as shown

The memory configuration tab contains several settings which must be modified as well. These parameters should all be set to non-zero, the default values for each are zero.

• max provisioned devices

• max provisioned device netkeys

• max foundation client commands

For detailed descriptions of these settings please refer to section 3 of UG366.