Hi, Viktor

This thread has been moved from 32 bit to Zigbee which is more relevant to your topic. Also, I believe this KB gives some related info:

https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2017/11/22/access_to_siliconla-jk1S

Best,
David

Is it possible to obtain EmberZnet (zigbee) Kit without Wireless Starter Kit. Frankly, the Wireless Starter Kit is too expensive for just hobby development.

Thank you.

Andris,

Regarding time.h specifically, we don't have the retarget methods like we do for printf and we don't have much in terms of resources regarding the use of time.h on our platform.

Our supported method for long term timekeeping is the RTCC hardware block, which has a calendar mode that allows for long term timekeeping without overflows.

That being said your getUnixTime looks more or less complete and it likely doesn't make sense to rework the conversion to unix time from the different data format used by the RTCC. Compared to printf where the underlying methods are stubbed out and can be overwritten by a library like our retargetserial, I'm not certain if that is the case for the std time library.

One resource I can point to is our zigbee stack, which does implement an interface to work with the standard time library for a specific application example. You'll need to download the zigbee packages in Studio to get source access, but the implementation to look out for is in:

/util/third_party/digi_lte/xbee/inc/xbee/time.h of the SDK

Hey Kevin,

Thanks for testing this. For further support I'm escalating this to a support case as I am unable to reproduce this behavior with your configuration and external debugging options on the BGX are limited. 

Best,

David

Hi Kevin,

Thanks for providing the get al contents and for testing uartu. Since this seems to not fix the issue it is likely outside of the uart peripheral. One option is that the disconnect event is not being processed properly in the chip. 

Would it be possible to configure a GPIO to toggle on connect/disconnects to the device, and then observe the state of the GPIO during the disconnect/reconnect. You should be able to configure this with the following command:

gfu 0 con_active

This will change the function of the first bound gpio. It would be interesting to see if this toggles low properly when the device disconnects.

Another option besides uartu may be to send the breakout message over the wired connection. For your configuration you have this set to 0x24 sent three times, which is ends up being

$$$

Do note that you cannot really send this via the App because the app will append a newline character after the message, and that will invalidate the breakout message. The breakout requires a .5 second after the last character before any other characters are sent. This is to avoid false positives in a data stream. 

I agree the reboot is not a very good workaround. Is this only happening on a single device or are multiple parts affected?

Hi Kevin,

Thanks for providing the get al contents and for testing uartu. Since this seems to not fix the issue it is likely outside of the uart peripheral. One option is that the disconnect event is not being processed properly in the chip. 

Would it be possible to configure a GPIO to toggle on connect/disconnects to the device, and then observe the state of the GPIO during the disconnect/reconnect. You should be able to configure this with the following command:

gfu 0 con_active

This will change the function of the first bound gpio. It would be interesting to see if this toggles low properly when the device disconnects.

Another option besides uartu may be to send the breakout message over the wired connection. For your configuration you have this set to 0x24 sent three times, which is ends up being

$$$

Do note that you cannot really send this via the App because the app will append a newline character after the message, and that will invalidate the breakout message. The breakout requires a .5 second after the last character before any other characters are sent. This is to avoid false positives in a data stream. 

I agree the reboot is not a very clear

Thank you for testing. The default behavior of the device on connection (stream mode vs remote command mode) is handled by the rbmode command.

If you set this to remote command mode, then on connecting you should enter that remote command mode automatically. From there if you then manually enter stream mode via str, does the UART connection still die? If that still causes UART to die, then check if connecting and then sending:

uartu

str 

leaves the UART alive.

For the get al results, I'm specifically curious about the bus settings, UART configuration, and sleep mode (sy s m)

https://docs.silabs.com/gecko-os/1/bgx/latest/variables

- Interestingly, I can send a "reboot" command.  The device disconnects, but now when I reconnect and enter stream mode, all is back to normal.  That might be a work-around... like if my app connects but receives no data after some timeout.  

This is via BLE in remote command mode correct? 

Ah right, our client side examples are somewhat limited but we do have a client for our thermometer sample app. This is in the SDK under Bluetooth SOC Basic as SOC - Thermometer - Client

The important bit here is the gecko_evt_le_gap_scan_response_id event and how you handle it in your application (line 283 of main.c in the example). The event returns a struct with a data handle, where the raw data from the advertisement is stored:

evt->data.evt_le_gap_scan_response.data.data

This is then manually parsed to extract useful information, for the sample app this is done in findServiceInAdvertisement() (Line 168 of main.c):

// Parse advertisements looking for advertised Health Thermometer service
uint8_t findServiceInAdvertisement(uint8_t *data, uint8_t len)
{
  uint8_t adFieldLength;
  uint8_t adFieldType;
  uint8_t i = 0;
  // Parse advertisement packet
  while (i < len) {
    adFieldLength = data[i];
    adFieldType = data[i + 1];
    // Partial ($02) or complete ($03) list of 16-bit UUIDs
    if (adFieldType == 0x02 || adFieldType == 0x03) {
      // compare UUID to Health Thermometer service UUID
      if (memcmp(&data[i + 2], thermoService, 2) == 0) {
        return 1;
      }
    }
    // advance to the next AD struct
    i = i + adFieldLength + 1;
  }
  return 0;
}

In the sample, the parser searches for Service Class UUID list data types 0x02 and 0x03, but for your case you'd search for the manufacturer specific data type 0xFF. From there you'd have the manufacturer data, and could base further action on that.

The thermometer and thermometer-client examples are most easily accessed through Simplicity Studio, and are available for BGM13P devices.

Hi Kevin,

Modules supported by our BLE stack, such as the BGM13P, can at the general level support this feature. We have a few related KB articles that should provide some example code and explanation:

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/11/14/bluetooth_advertisin-zCHh

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/12/27/providing_extra_data-0jco