Hi Mohan,

If you are a slave device you should not start scanning.

So you can probably get rid of those lines:

gecko_cmd_le_gap_set_discovery_timing(1,160,160); gecko_cmd_le_gap_set_discovery_type(1, 1); gecko_cmd_le_gap_start_discovery(1,le_gap_discover_observation);

I recommend doing advertising it in the same way that it is done in the soc-empty example.

    /* This boot event is generated when the system boots up after reset.
       * Do not call any stack commands before receiving the boot event.
       * Here the system is set to start advertising immediately after boot procedure. */
      case gecko_evt_system_boot_id:

        bootMessage(&(evt->data.evt_system_boot));
        printLog("boot event - starting advertising\r\n");

        /* Set advertising parameters. 100ms advertisement interval.
         * The first parameter is advertising set handle
         * The next two parameters are minimum and maximum advertising interval, both in
         * units of (milliseconds * 1.6).
         * The last two parameters are duration and maxevents left as default. */
        gecko_cmd_le_gap_set_advertise_timing(0, 160, 160, 0, 0);

        /* Start general advertising and enable connections. */
        gecko_cmd_le_gap_start_advertising(0, le_gap_general_discoverable, le_gap_connectable_scannable);
        break;

      case gecko_evt_le_connection_opened_id:

        printLog("connection opened\r\n");

        break;

      case gecko_evt_le_connection_closed_id:

        printLog("connection closed, reason: 0x%2.2x\r\n", evt->data.evt_le_connection_closed.reason);

        /* Check if need to boot to OTA DFU mode */
        if (boot_to_dfu) {
          /* Enter to OTA DFU mode */
          gecko_cmd_system_reset(2);
        } else {
          /* Restart advertising after client has disconnected */
          gecko_cmd_le_gap_start_advertising(0, le_gap_general_discoverable, le_gap_connectable_scannable);
        }
        break;

Let me know what is the outcome.

Hi Richard,

How do you stimulate the pin in use for sampling ? In your code I can see that the example uses iadcPosInputPortCPin4. Do you use the same pin in your design ? If yes how is it stimulated.

More generally can you post you code we can have a look ?

I would recommend testing it with the vendor model defined for both element. Additionally, the element index you are using 0x1000 seems to correspond to the first element. Typically, the first argument of that routine should be unicast address + element index.

In your case it would mean that your unicast address would be 0x9FFF, is that the case ? If no, can you try using 0x1001 (if you use unicast address 0x1000).

Hi Richard,

The Vendor model isn't present in your DCD struct for the primary element. Have you tried populating that ?

See the "Vendor models" array in you dcd config (isc file). Looking at your code, if my_model.elem_index points to the first element, it is likely that you are going to get that error.

Hi Richard,

The WSTK isn't good for current measurement because there are a lot of peripheral and devices also drawing current. As you pointed out, the chip is in EM2 when not transmitting/receiving if deep sleep is enabled in the stack config structure.

This explains why you can reach far better figures on your design. 

As for the 17-18ms delay in order to wake up from EM2, that seems like a very long time. Can you elaborate a bit more on that ?

Hi Todor,

There is limited support for Mesh by the BG22 chip. It only support the LPN feature due to memory considerations. Unless you use it as such I recommend not using that chip for anything else than that (from BT mesh perspective obviously).

The error 0x0C02 (returned when trying to manipulate a key or some other resource with an ID that does not exist)  could be due to a class init issue. Is that class init routine corresponding to the health server model is present in your code by any chance ? 

Hi Ming,

The default baud rate supported in our sample apps is 115200. The chip support the "classic" baud rate range and even more -> 9600 to 115200.

Hi mass85,

Two things comes to my mind. On the EFR32 side, have you checked the error code returned by the function that enables the notification on the client ? 

Subsequently, this could well be that either the client or master missed the connection interval. In effect, since you are using NCP, typically this could happen if the controller is busy doing some UART communication or handling the TLS layer whilst trying to maintain the BLE connection.

That could explain the erratic character of the issue you are observing. Can you try increasing your connection interval ?