A quick way to get familar with the Silicon Labs Bluetooth stack and a Wireless Starter Kit is to create a simple software example to control the WSTK's LEDs with a mobile phone app.  This article will describe these steps.

Requirements

• Wireless Starter Kit
• BRD4153 radio board (though others work if it supports Bluetooth)
• Simplicity Studio IDE with latest Bluetooth SDK
• iOS/Android mobile phone with Blue Gecko app
• LED control example code found on Github

Step 1. Setup the Environment

For this step, the quickstart guide QSG139 provides instructions on how to setup the hardware and software necessary to begin Bluetooth software development.  Proceed through its sections including completing Section 4.3 to setup, compile, and launch an SoC-Empty software example.  We will be using this example for this demonstration.

Step 2. Modify the GATT Database

After setting up the SoC-Empty software example we will need to modify the GATT database so that a mobile app can control the LEDs within the Bluetooth application.  Section 5 of QSG139 describes how to utilize the GATT editor by modifying the .isc file and generating the necessary code.  Instead of setting up a current time service as described in this section, we will instead be utilizing the Automation IO service and the Digital characteristic for our LEDs.

1. Along the left pane, click on the Services tab and highlight the Automation IO service.  
2. Now drag and drop this service below the Silicon Labs OTA service of the Custom BLE GATT profile.  Remove the Analog and Aggregate characteristics, keeping the Digital.
3. “Set properties information” is initially empty. Add the three properties shown. Enabling write "without a response" is useful during development as the mobile app will ignore waiting for a response from the remote in the event your write response routine is not properly setup on your first attempts.  I renamed the ID to 'digital_out' in case I later want to create a different characteristic for the WSTK button inputs.
4. Set the type to "user".  We will be making use of the user event handler portions of the Bluetooth SDK to control and status the LEDs.
5. Click Generate in the upper right corner.  This will update the previously auto-generated files: gatt.xml, gatt_db.h, gatt_db.c.  Anytime you make changes with the GATT editor, click generate to propagate those changes into the application.

Before proceeding let's test to ensure this was correctly setup.  From the menu, select Run, then Debug to compile and program the WSTK, then select Run, then Resume to run the program.  Using a mobile phone with the Blue Gecko app installed, open this app and follow these steps:

1. Select the Bluetooth Browser to scan for active Bluetooth devices nearby
2. Connect to the target remote device (by default the BLE application is named as "Empty Example", but I earlier edited the GATT device name to "BLE Test" for my example)
3. Click on the Unknown Service with UUID 1815. (Note: this app does not label this UUID as the Automation IO as adopted by the Bluetooth SIG)
4. Under this service, there will be an Unknown Characteristic with UUID 2A56, which is our Digital Characteristic.  In it will show the read, write, and write without a response.  Click on it and modify the hex to any valid value.  If you made it this far then you have successfully set up the new service within the GATT database.  For now this service will not do anything by design.  Next up will be writing code to link the LEDs to this characteristic.

Step 3. Adding LED control to the application

To speed things along I have uploaded the code I wrote for this example onto Github.  This code was written with the Bluetooth v2.7 SDK.  You can easily clone this repository and add the led_app.c and led_app.h files as well as replace the main.c file within your Simplicity Studio SoC-Empty software example, then compile and then run this application.  Before we move to the Step 4 section to test the code, allow me to explain how the code leverages the Bluetooth SDK and the SoC-Empty software example.

The led-app file has three functions to initialize, control, and status the two LEDs mounted on the WSTK.  The SDK itself has a lot of useful functions that control the HW peripherals of the EFR32 chipset and I am using the GPIO_Pin software functions.  For the BRD4153, the LEDs on the WSTK are connected to PF4 (LED0) and PF5 (LED1).  This section of code can be modified to support other radio boards that may use different resources to control the LEDs.

void initLEDs(void) {
  // configure as output, initial state low
  GPIO_PinModeSet(gpioPortF, 4, gpioModePushPull, 0);
  GPIO_PinModeSet(gpioPortF, 5, gpioModePushPull, 0);
}

/* LED control function
    bit 0 = LED0 -- PF4
    bit 1 = LED1 -- PF5  */
void LED_control(uint8_t ledRegister) {

  /* LED 0 control */
  if ((ledRegister & 0x01) == 1)
    GPIO_PinOutSet(gpioPortF, 4);
  else
    GPIO_PinOutClear(gpioPortF, 4);

  /* LED 1 control */
  if (((ledRegister >> 1) & 0x01) == 1)
    GPIO_PinOutSet(gpioPortF, 5);
  else
    GPIO_PinOutClear(gpioPortF, 5);

}

/* Return status of the LED pins */
uint8_t LED_status(void) {

  return ((GPIO_PinOutGet(gpioPortF, 5) << 1) | GPIO_PinOutGet(gpioPortF, 4));

}

Within main.c we've made a few additions within the event handler.  To initialize the LEDs we added a call to the initLEDs() function under the gecko_evt_system_boot_id event:

case gecko_evt_system_boot_id:

  /* Set LEDs to their initial condition  */
  initLEDs();

For this LED control demonstration, the mobile app serves as the trigger to either poll the current status or manipulate the state of the LEDs.  This is why in the GATT editor the value type "user" was chosen.  This also allows us to then utilize the gecko_evt_gatt_server_user_write_request and  gecko_evt_gatt_server_user_read_request user event handles for our demonstration.  If the mobile app performs a read or write on the digital characteristic it will trigger these portions of the event handler.  Greater detail on how this works is found in the Bluetooth API reference manual.

Since there is already the gecko_evt_gatt_server_user_write_request event handle within the SoC - Empty software example we just need to append our code to respond to the write request on the digital characteristic.  I placed it within the user write event id, before the default code routine that supports the OTA feature.

case gecko_evt_gatt_server_user_write_request_id:

  /* Automation IO digital control */
  if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_digital_out) {
    LED_control(evt->data.evt_gatt_server_attribute_value.value.data[0]);
    gecko_cmd_gatt_server_send_user_write_response(
      evt->data.evt_gatt_server_user_write_request.connection,
      gattdb_digital_out,
      bg_err_success);
    }

  /* Check if the user-type OTA Control Characteristic was written.
   * If ota_control was written, boot the device into Device Firmware Upgrade (DFU) mode. */

 if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_ota_control) {

I then added a new case statement under the write request to support read requests of the Digital characteristic:

case gecko_evt_gatt_server_user_read_request_id:

  /* returns the state of the LEDs */
  ledState = LED_status();
  gecko_cmd_gatt_server_send_user_read_response(
    evt->data.evt_gatt_server_user_read_request.connection,
    gattdb_digital_out,
    bg_err_success,
    sizeof(ledState),
    &ledState);

  break;

To support the read response function I also declared uint8_t ledState = 0; above the main function.

Step 2. Testing the Custom Application

From the Simplicity Studio menu, select Run, then Debug to compile and program the WSTK, then select Run, then Resume to run the program. Connect to it with the Blue Gecko App.  Traverse to the Digital characteristic and you should now see the hex and decimal value = 0 which is our initial default state.  LED0 is controlled with bit 0, LED1 with bit 1.

Next, write to the service with a hex = 1 and save.  The service should now be equal to 1 and the LED0 on the WSTK should be illuminated.  Then, try hex = 2 to see only LED1 illuminated, hex = 3 to see both LEDs illuminated and then hex = 0 to extinguish both LEDs.

If you are able to do this you have completed this demonstration.  

To help you experiment further, I purposely wrote this application so that it exposes how to manipulate the GPIO within the chipset.  From this point, it is relatively simple to add button inputs and even other GPIOs found on the EXP header.  If you end up leveraging this demonstration for something more interesting than manipulating LEDs, do share your code example with rest of us!

Resources:

• QSG139
• Bluetooth API reference manual
• https://github.com/jasonrock21/led-ble-demo

If you go here, you can create a specific Si570 with your chosen startup frequency, voltages, I2C address, etc.

http://www.silabs.com/products/clocksoscillators/pages/oscillator-part-configure.aspx?partnumber=Si570

Datasheet says go here: http://www.silabs.com/VCXOPartNumber  but the other link I attached above gets you directly to the Si570 customization page.

You'll know you did it correctly when you fill out the information and get an email confirmation with the part number.  From there you have options to getting the custom device you created with the new startup frequency.   There should be an online cart option to then purchase what you created.

Just in case someone searches and runs across this post chain .. distributors like Digikey are carrying many of Silicon Labs' custom oscillators pre-configured to the popular standard frequencies like 25 MHz, 100 MHz, 125 MHz, 156.25 MHz.

http://www.digikey.com/short/7jdwh9

I'm a big fan of Digikey because they are one of the few distributors that don't require large minimum quantities (unless the provider requires them to!) and they can overnight ship.

I further filtered down to 25MHz and 20ppm and 12 Silicon labs Si501 oscillators popped up:

http://www.digikey.com/short/7jdwr5

 Hi jperch,

That's really awesome that you & your wife are doing that!

We're actually planning a kids demonstration the 2015 SXSW interactive show where Silicon Labs is the main sponsor of the SX Create 2015.  If you (or anyone else that is reading this) is in town you should stop by!

More information about the event: SXSW Create - March 13, 2015 to March 15, 2015 

Hi msonal ... Thanks!

When you say magnet breakout boards, I assume you are referring to this:  http://littlebits.cc/bits/proto

I've definitely become a big fan of LittleBits for helping my nieces and nephews visualize how basic electronic components work.  I can wire the proto onto a breadboard and then let them swap out resistors, capacitors, even NPNs and then use the LittleBits LEDs, buzzers, motors modules to show how changing component values causes different effects.

I discovered my passion for electrical circuits when I was a child. For fun I would disassemble toys and electronics extracting their parts for my diverse experiments with electricity. As I constructed these projects my untrained soldering skills was definitely a limitation. I was also unaware that solder material available was composed of a high percentage of lead metal which is quite toxic for children if not handled with care. 

Thankfully today, with STEM education becoming a national focus children have a multitude of solder-less electrical project options at their disposal such as the LittleBits eco-system. Every LittleBits module magnetically snaps together without solder. If you can build with LEGOs, one can now easily construct a working LittleBits circuit. 

Since 2014, Silicon Labs has been increasing their focus on sponsoring STEM education in order to foster the next generation of technical innovation. This endeavor got me thinking about how to incorporate a Silicon Labs device into LittleBits. For this project I chose a Si1102 proximity sensor as its concept is pretty simple to understand: If an object is detected, assert a signal. Using the Si1102 will allow us to build a proximity alarm circuit.

Step 1: Getting the Materials

For this project most are found within LittleBits kits, however a few items had to be individually bought:

• Si1102-EK proximity demo board
• LittleBits power module
• LittleBits proto module
• LittleBits inverter module
• One or more LittleBits output modules, preferably the bright LED and buzzer for alarm indication
• Three wires to connect power, ground, signal

Step 2: Evaluating the Proximity Sensor
The Si1102 is very a simple device to setup. With the Si1102EK demo board, it is just a matter of powering it up and testing it. After flipping the power switch to on, wave your hand over the Si1102 and the blue LED in the upper corner of the board is activated.

To activate the LED the Si1102 proximity sensor has a PRX pin that asserts low to sink electrical current across the LED. This is the signal we want to bring into the LittleBits module. Along the bottom of the board is a single row header of every signal that connects to the Si1102’s 8-pin device. For the LittleBits module we will need VDD (power), GND (signal ground) and PRX (presence detected by pulling the output low). The Si1102 can operate with a power supply voltage from 2.0 to 5.25 V, which is great because LittleBits modules carry +5V across their circuit chain.

Step 3: Hacking the LittleBits Proximity Sensor Module
To make use of the LittleBits 5V as the power supply for the Si1102EK, I removed the CR2032 coin-cell battery located in the rear of the demo board.

Next, to incorporate the Si1102EK demo board into the LittleBits eco-system I have connected three wires to these signals and then connected them to the LittleBits proto module’s VDD and GND into the VDD (H1 pin 3) and GND (H1 pin 1) of the Si1102EK demo board. The Si1102EK’s PRX (H1 pin 4) is wired into the signal input of the proto module and depopulated the middle jumper the LittleBits proto module. Since PRX is an active low signal, I added a LittleBits inverter module to correct the signal polarity to make it friendlier to the LittleBits output modules which operate based on active-high input signaling. Also note it is important to leave the demo board’s switch to ON as this switch was to preserve the life of the coin-cell battery. In this setup, the only way for the module to receive power is if it is part of a LittleBits circuit connected to a power module.

Step 4: Building a proximity alarm circuit
Now that you have the proximity module created, it can be used in an alarm circuit. To complete this circuit, besides the power module I chose the bright LED and buzzer output modules as whenever a nearby object is detected, one wants visible and audible noise to draw attention. Waving your hand over the Si1102 proximity sensor device, now not only is the original LED activated, but now the downstream output modules within the LittleBits circuit are also activated as well.

Step 5: Final test
Once this is setup, the final test will be to get an excited LittleBits volunteer to try out the new module.

Watch the video: Creating a LittleBits Proximity Sensor 

Hi, 

There is a way using the ZCL CLI commands and to read the cluster's attributes.  For a light the notable clusters are the on-off cluster (0x0006) and the level cluster (0x0008).  You'll also need to determine the index number (indexNum) of the target device.

To read you'll want to use this command format:

zcl global read [cluster] [attribute]

To read the on-off cluster of a device with index 1, here are the two commands:

zcl global read 0x0006 0

custom send 1

To read the level cluster of a device with index 6, here are the two commands:

zcl global read 0x0008 0

custom send 6

Using v1.1.0 you'll then need to pack it into the MQTT publish command structure:

MQTT topic: gw/<eui64_id>/command

JSON Payload:  

{

  commands:[

    {

      command:<String>,

      postDelayMs: <time>   // optional

    },

    {

      command:<String>

    }

  ]

With v1.1.0 to see the command execute, subscribe to MQTT topic:

MQTT topic:  gw/<eui64_id>/executed

JSON Payload:  

{

  "commands":

    [

      {

        "command":<String>

      }

    ]

}

For more options, you'll want to look for the AF CLI document within your ZNET stack release to read more on the available ZCL commands.

Good luck,

Jason