Official Blog of Silicon Labs

    Publish
     
      • What to Do When Your CEO Isn't Really Your CEO

        MicheleG | 03/91/2016 | 07:21 PM

        ThinkstockPhotos-87660951-2.jpgIn our world of sophisticated security infringements and major data breaches, we sometimes forget that the biggest scams can come from the simplest of means. By now, most of us have the common sense not to respond to obvious email phishing attempts at home. However, you might not think twice about responding to an urgent email request at work from your CEO.  

         

        Security software firm Trend Micro claims an astonishing 91 percent of cyberattacks begin with a common, social engineering tactic called “spear phishing.” Spear phishing occurs when cyber criminals research and target specific people in the company. They use a fake email request seemingly from an executive to gain access to sensitive, secure information.

         

        On March 30 we discovered that Silicon Labs was the subject of a successful email phishing scheme, which resulted in an unauthorized party obtaining a copy of 2015 W-2 forms. The information in these documents can be used for identity theft and to file fraudulent U.S. federal and state tax returns.  

         

        Unfortunately, we were not alone. Other technology companies across the country were similarly targeted. In all cases, an employee received email appearing to come from someone inside the company they trust. When they replied to the email, they sent company-confidential information to a third party instead of the intended recipient.

         

        These schemes are so widespread that in February the U.S. Internal Revenue Service (IRS) renewed a consumer alert on the topic. The IRS has seen a 400 percent surge in phishing and malware incidents this tax season alone. In fact, even the IRS isn't safe. Last year, hackers stole W-2 information on more than 330,000 people directly from the IRS website.  

         

        Take Action 

        To help others in similar situations where employees have unintentionally released confidential information, I want to share our actions. I hope that others will be willing to share similar lessons learned and best practices. The more aware we are of cyber crime, the less likely phishing schemes like this will succeed in the future.  

         

        In our case, immediately upon discovering the situation, we took the following Top 8 Actions:

         

        Assess & Plan

        • Deployed an action response team including outside legal and security experts
        • Verified the phishing email scheme was an isolated occurrence

         

        Communicate & Protect

        • Reported the incident to law enforcement
        • Provided free credit monitoring, identify theft protection, and credit repair services for impacted employees
        • Notified all employees of the situation and recommended action items
        • Launched a dedicated email address to answer employee questions 
        • Assigned an HR rep to directly help employees already impacted
        • Strengthened our email protocols for employees with access to confidential information

        We are using this experience to strengthen our data policies.  We continue to educate our employees about cybersecurity guidelines and perform practice drills with our workforce using test phishing emails.

         

        The most important thing you can do in this situation is work diligently to take care of your employees, learn from the mistake, and do everything you can to prevent incidents like this from happening in the future. 

      • Home Automation: Wireless Technologies and Connected Lighting

        WYALLEN | 03/89/2016 | 02:19 PM

        If you want to talk to your lights wirelessly, how do you know what technology to use?

         

        Wi-Fi is ubiquitous. With an existing infrastructure, it is easy to develop and add a device to a Wi-Fi network. The downside is that the stack is heavy and requires large amount of memory and processing power. There is also a limitation on how many lights can be on the same network. Bluetooth with low energy functionality is another technology that is well known. It is great for accessing and controlling a few devices when you are next to them with your mobile phone. But the number of devices is also limited.

         

        Lighting.png

         

        For a lighting system with tens up to hundreds of lights connected to a single network, these lights need to respond instantaneously, and without fail. The ZigBee networking technology is designed to form robust, self-healing, and scalable local mesh networks, giving the user that “instantaneous” response no matter where the light is on the network. ZigBee also has a dedicated cluster library that defines the exact behavior of lights and other home automation devices. So a ZigBee light switch knows exactly how to talk to a ZigBee light regardless who makes the light. The ZigBee cluster library also introduces standardized way to control the RGB color, color temperature and dimming of lights. Now your lights can easily bring different colors, moods, or brightness to any room.

         

        ZigBee is a local area network (LAN). This means the devices can talk to each other on the same network quickly and efficiently. There is a routing table on a gateway that calculates the lowest cost to reach each node on the network that includes the signal strength and number of hops to reach the node. This way, the user can be sure to reach each node in the most efficient and robust way. To reach the LAN from outside, one can use the gateway to pass the data. It can serve as a bridge between the internet over Wi-Fi, and the LAN. So now, you can control your light from anywhere in the world.

         

        Get started with our collection of ZigBee Connected Home Reference Designs.

      • Wireless Development, Simplified

        Lance Looper | 03/89/2016 | 10:05 AM

        Today we announced the Blue Gecko BGM113 Bluetooth Smart Module, a fully integrated, certified Bluetooth® low-energy module designed for low-power, short-range wireless applications. This module includes everything you need for energy-sensitive IoT applications, including best-in-class module size (9.2 mm x 15.8 mm x 1.83 mm), on-board software stack, and global certifications.

         

        This combination of features, small design footprint, and support means you can get your Bluetooth project up and running much faster without compromising the current consumption and battery.

         

        Other features include:

         

        • Output power: up to +3 dBm supporting range of up to 50 meters
        • Blue Gecko SoC combining a 2.4 GHz transceiver with a 40 MHz ARM Cortex-M4 core and 256 kB flash and 32 kB RAM
        • Hardware cryptography accelerator supporting advanced AES, ECC and SHA algorithms
        • Easy-to-use development tools including Simplicity Studio, Energy Profiler, BGScript

        BGM113 copy.jpg

         

        It’s also footprint-compatible with the popular BLE113 module, making it possible to migrate to an ARM Cortex-M4 Bluetooth platform with higher application processing power and lower power consumption while opening a path for Bluetooth 4.2 upgrades. Similar technical features and identical software and APIs make it easier to migrate from a module design to an SoC design. For more information about choosing a module or an SoC, check out this whitepaper.

         

        BGM CTA 2.jpg

      • IoT Security Part 3: What’s the Deal with Block Cipher Block Modes?

        kberringer | 03/84/2016 | 03:44 PM

        A cipher block mode is a method of manipulating blocks of data using the AES cipher to improve security. The AES cipher is an atomic operation on 128-bits of data. Normally the plaintext goes into the cipher and the ciphertext comes out of the cipher. But there are other ways to use the cipher.

         

        Why should we use a block cipher mode? First, consider the case where we are encrypting many blocks of data. If we encrypt data using the same key every time and using the same method, we give a clue about the encryption. If we just use the basic cipher in the electronic code book mode using the same key, we are opening ourselves up to a black box brute force attack.

         

        The block cipher modes mix it up a bit. Each block of data is encrypted differently than the last block. This makes it harder to guess the encryption key. It is effectively like using a different key each time. For data security encryption, the most commonly used cipher block mode is the counter (CTR) mode.

         

        The counter mode uses the basic cipher in a convoluted way. Instead of encrypting the plaintext, the cipher encrypts the counter value. The counter value is concatenated together with a Nonce before encryption. A Nonce is a “number used once” and is similar to an initialization value. Both the sender and the recipient must use the exact same Nonce for it to work. The output from the cipher is exclusive OR’ed with the plaintext.

         

        Counter Mode Encryption.png

         

        The exclusive OR operation is very commonly used in block cipher modes. Any time plain text is exclusive ORed with some secret key, it is impossible to determine the original key from the ciphertext. This is known in cryptography as a One Time Pad.

         

        The counter mode potentially improves the security of the system by extending the 16-byte AES cipher to an arbitrary long cipher. It converts a block cipher to a stream cipher. To decrypt data encrypted using the counter mode, we need to know the key, the Nonce, and the block count.

         

        Because the block count changes each time, the encrypted data for each block is unique. Suppose we encrypted the same 16 bytes of data repeating four times. The electronic code book (ECB) mode would be to just apply the AES cipher to each block of code. When using the ECB mode, if the data repeats, then the encrypted data will also repeat. Unlike the electronic code book mode, the counter mode encrypted data would not repeat.

         

        Encrypted Data.png

         

        If data changed only one bit each time, the ECB mode might give use information that will help us guess the key. Changing one bit each time using the counter mode will not give us much information. The CTR mode provides protection against a Replay attack. A replay attack is a systematic cryptographic attack that involves eaves dropping on a conversation, and then playing back part of the encrypted conversation, a password for example. If the counter value is different each time, this ensures uniqueness.

         

        In IEEE802.15.4 networks, the counter value starts at zero and increments for each block in the payload. The Nonce security material includes the frame counter and the key sequence counter. The frame counter increments with each frame transmitted. Thus, it is the Nonce and not really the counter value that establishes a session and ensures session uniqueness.

         

        Theoretically, the counter mode allows random access. Suppose we encrypt data and store it in an external Flash using CTR mode. We don’t have to decrypt the entire Flash from the beginning. We can just read out the block we want, use the address for the counter value, and decrypt it.

         

        There are several different methods to implement counter mode on an MCU with built in AES encryption. The method will depend on the hardware resource of the particular MCU. The Gecko devices have an AES block with XOR capability. The AN0033 explains the Block Cipher Modes in detail and how to implement them on EFM devices.

         

        The new Wireless Gecko EFR32 SoCs and the Pearl and Jade Gecko 32-bit microcontrollers have a Crypto module, which has programmable hardware to implement the different block cipher modes. This improves performance and minimized the amount of software computation required.

         

        Most authenticated block cipher modes use the counter mode for encryption and the cipher block chaining mode for authentication. The CBC mode for authentication will be the subject of the next blog, and don't forget to check out the previous installment in this series

      • Cadence and Silicon Labs Talk Wireless Geckos at Embedded World 2016

        Lance Looper | 03/83/2016 | 09:29 PM

        As you know, we introduced our Wireless Gecko IoT Portfolio at Embedded World last month and the response has been terrific. At the event, Craig Cochran of Cadence Design Systems caught up with Daniel Cooley to discuss how Cadence mixed-signal low power solutions helped bring Wireless Gecko to life.

         

        Check out the interview below:

      • Chapter 10.3: Control an accelerometer over I2C Part 3 - Read from the accelerometer

        lynchtron | 03/81/2016 | 11:48 AM

        10_i2c_teaser.jpg

         This is part 3 of a four-part series on using the I2C bus to interface an accelerometer.  In part 1 and 2, we learned about the I2C bus and how to read a register on the I2C accelerometer, proving that we can successfully communicate with the sensor.  In this section, we will learn how to configure the accelerometer for measurement, and how to set up the interrupt pin to watch for interesting events to happen.  We will then output that measurement data to a computer where the measurement data can be graphed.  Finally, we will trigger LEDs on the Starter Kit to illuminate when activity or free fall is detected by the accelerometer.

         

        Configure the ADXL345 and Fetch Acceleration Data

        Now we need to configure the ADXL345 so that it will measure accelerometer values.  At power up, the ADXL345 is asleep to save power, so we need to configure it for the g-range, set an appropriate data rate for I2C, and then tell it to start measuring.

         

        In order to write registers, we need a function for that, which is similar to the read register function:

         

        // Write a config register on an I2C device
        // Tailored for the ADX345 device only i.e. 1 byte of TX
        void i2c_write_register(uint8_t reg_offset, uint8_t write_data)
        {
              cmd_array[0] = reg_offset;
              data_array[0] = write_data;
              i2c_transfer(ADXL345_ADDRESS, cmd_array, data_array, 1, 1, I2C_FLAG_WRITE_WRITE);
        }

        There are a lot of registers in the ADXL345.  We don’t want to have to go through all of that and transpose the addresses and create enumerations for all of the possible values.  So I searched the internet for existing drivers and found one on my very first search hit.  Just Google “adxl345 driver” which should bring you to a Git repository from Adafruit for this very module.  The library is written for Ardruino, but that’s OK, because we can still use the header file with a little bit of modification.  You can see the original file here.  I had to comment out the C++/Arduino function prototypes and the compiler switches at the top, but otherwise all of the register and register value enumerations could be used directly in our adxl.h header file as follows:

         

         

        /*=========================================================================
            I2C ADDRESS/BITS
            -----------------------------------------------------------------------*/
            #define ADXL345_ADDRESS                 (0x53) << 1   // Modified for em_i2c.h library
        /*=========================================================================*/
        
        /*=========================================================================
            REGISTERS
            -----------------------------------------------------------------------*/
            #define ADXL345_REG_DEVID               (0x00)    // Device ID
            #define ADXL345_REG_THRESH_TAP          (0x1D)    // Tap threshold
            #define ADXL345_REG_OFSX                (0x1E)    // X-axis offset
            #define ADXL345_REG_OFSY (0x1F) // Y-axis offset
        #define ADXL345_REG_OFSZ (0x20) // Z-axis offset
        #define ADXL345_REG_DUR (0x21) // Tap duration
        #define ADXL345_REG_LATENT (0x22) // Tap latency
        #define ADXL345_REG_WINDOW (0x23) // Tap window
        #define ADXL345_REG_THRESH_ACT (0x24) // Activity threshold
        /////////////
        // // etc... This goes on for a while, and then there are some helpful enums and typedefs: //
        /////////////
        /* Used with register 0x2C (ADXL345_REG_BW_RATE) to set bandwidth */ typedef enum { ADXL345_DATARATE_3200_HZ = 0b1111, // 1600Hz Bandwidth 140µA IDD ADXL345_DATARATE_1600_HZ = 0b1110, // 800Hz Bandwidth 90µA IDD ADXL345_DATARATE_800_HZ = 0b1101, // 400Hz Bandwidth 140µA IDD ADXL345_DATARATE_400_HZ = 0b1100, // 200Hz Bandwidth 140µA IDD ADXL345_DATARATE_200_HZ = 0b1011, // 100Hz Bandwidth 140µA IDD ADXL345_DATARATE_100_HZ = 0b1010, // 50Hz Bandwidth 140µA IDD ADXL345_DATARATE_50_HZ = 0b1001, // 25Hz Bandwidth 90µA IDD ADXL345_DATARATE_25_HZ = 0b1000, // 12.5Hz Bandwidth 60µA IDD ADXL345_DATARATE_12_5_HZ = 0b0111, // 6.25Hz Bandwidth 50µA IDD ADXL345_DATARATE_6_25HZ = 0b0110, // 3.13Hz Bandwidth 45µA IDD ADXL345_DATARATE_3_13_HZ = 0b0101, // 1.56Hz Bandwidth 40µA IDD ADXL345_DATARATE_1_56_HZ = 0b0100, // 0.78Hz Bandwidth 34µA IDD ADXL345_DATARATE_0_78_HZ = 0b0011, // 0.39Hz Bandwidth 23µA IDD ADXL345_DATARATE_0_39_HZ = 0b0010, // 0.20Hz Bandwidth 23µA IDD ADXL345_DATARATE_0_20_HZ = 0b0001, // 0.10Hz Bandwidth 23µA IDD ADXL345_DATARATE_0_10_HZ = 0b0000 // 0.05Hz Bandwidth 23µA IDD (default value) } dataRate_t; /* Used with register 0x31 (ADXL345_REG_DATA_FORMAT) to set g range */ typedef enum { ADXL345_RANGE_16_G = 0b11, // +/- 16g ADXL345_RANGE_8_G = 0b10, // +/- 8g ADXL345_RANGE_4_G = 0b01, // +/- 4g ADXL345_RANGE_2_G = 0b00 // +/- 2g (default value) } range_t;

         

        Now, assuming they didn’t make any typos, we just saved ourselves a few minutes of transposing values into code.  We include the adxl.h file at the top of our main C file and created an ADXL_init() function using these newly-found values.  Also move the I2C bus init instructions inside of it as well:

         

        #include "adxl.h"
        void ADXL_init(void)
        {
              I2C_Init_TypeDef i2cInit = I2C_INIT_DEFAULT;
              I2C_Init(I2C0, &i2cInit);
         
              uint16_t value = i2c_read_register(ADXL345_REG_DEVID);
         
              // Set an LED on the Starter Kit if success
              if (value == DEVICE_ID)
              {
                    set_led(1,1);
              }
         
              // Set range to 16g and FULL resolution
              i2c_write_register(ADXL345_REG_DATA_FORMAT, ADXL345_RANGE_16_G);
         
              // ADXL_BW_RATE = 50 hz, limited by I2C speed
              i2c_write_register(ADXL345_REG_BW_RATE, ADXL345_DATARATE_50_HZ);
         
              // Start measurement
              i2c_write_register(ADXL345_REG_POWER_CTL, 0x08);
        }

        Next, create a data structure to store X, Y, and Z data values, which span two 8-bit registers in the ADXL345.  Note that the data is interpreted with a 2’s compliment signed representation so that the accelerometer can indicate positive or negative g’s, and this means that each data member is defined as an int16_t type.

         

        typedef struct accel_sample_data
        {
              int16_t x;
              int16_t y;
              int16_t z;
        } accel_sample_struct;
         
        accel_sample_struct sample;

         

        Now we need a function that can read the X, Y, and Z data values from the accelerometer.  Since measurement data is stored in a contiguous 6-byte region of register memory starting at the first byte of the X data, we can use a single 6-byte I2C read cycle to fetch all three axes of data in one I2C transaction:

         

        accel_sample_struct read_accel_data(void)
        {
              // Measurement data starts at DATAX0, and ends at DATAZ1, 6 bytes long
              cmd_array[0] = ADXL345_REG_DATAX0;
         
              // Read 6 bytes at once
              i2c_transfer(ADXL345_ADDRESS, cmd_array, data_array, 1, 6, I2C_FLAG_WRITE_READ);
         
              // Now pack the return structure with meaningful data
              sample.x = (data_array[1] << 8) | data_array[0];
              sample.y = (data_array[3] << 8) | data_array[2];
              sample.z = (data_array[5] << 8) | data_array[4];
         
              return sample;
        }

        Finally, place this read_accel_data function inside of the main function, and add a few print statements that will put the result of each measurement on the serial port so that we can view the results on a terminal emulator program.  Notice that the use of the /r without a /n in the print formatting will cause the same line of text on the terminal emulator write over itself, so that you get a live view of the data on the accelerometer. 

         

        int main(void)
        {
              CHIP_Init();
         
              enter_DefaultMode_from_RESET();
         
              setup_utilities(USART1);
         
              delay(100);
         
              ADXL_init();
         
              // Print header
              print("\n   x      y    z\r\n");
         
              // Infinite loop
              while (1)
              {
                    sample = read_accel_data();
         
                    // The \r will cause the last line to be overwritten
                    print("\r%5d %5d %5d", sample.x, sample.y, sample.z);
                    delay(100);
              }
        }

        I am pleased that the main function, at a high level, is very simple and accomplishes the reading of the accelerometer without a lot of setup code clouding the solution.  The initialization routines are all encapsulated in three calls, one to set up the I2C and other peripherals, one to set up the print utilities, and one for the ADXL345-specific initialization. 

         

        Connect the CP2104 USB-to-UART adapter to your Starter Kit so that the RXD pin is connected to PD0 (which is USART1_TX, location 1) and TXD pin is connected to PD1 (which is USART1_RX, location 1).  Don’t forget to also connect a ground wire between the two devices.  This device was covered in lesson eight if you recall.  Then open your terminal emulator program and configure it for 115200 baud rate, and you should be able to see the X, Y and Z acceleration values on the screen, updated live from the accelerometer. As you move your accelerometer around  and turn it in different directions, you will see the effect on your terminal emulator program in real time.

         

            x     y    z

            0    -3    28

         

        You will see that there is some error in the reading, as keeping the device flat on the table will result in two of the readings being near zero (+/- 3 or so) and the other axis, in this case the Z axis, is around 30.

        To take it a bit further, you can graph the accelerometer data in real time on your computer.  Download the Processing IDE, which is available for Windows, Mac or Linux computers.  There is an open-source library called RealtimePlotting that is built for Processing that reads the data from the serial port to create a real time graph of the accelerometer data.  You will need add a /n to the print formatting statement in the main C function (the code that runs on the Starter Kit) to get a scrolling list of values.

         

        Detect Freefall and Collisions with Interrupts

        Perhaps your gadget doesn’t need to analyze the XYZ data, but would rather go to sleep and save power until something interesting happens.  In that case we can configure the interrupt pin on the ADXL345 to wake up the EFM32 and process the event. 

         

        Connect PB11 on the Starter Kit to INT1 on the ADXL345 breakout board.  Connect PB12 to INT2.  These signals will be used to trigger interrupts on the MCU.

         

        The following code will configure the activity interrupt to trigger an interrupt on pin INT1 of the ADXL345 breakout board and a free fall interrupt source on INT2.   This was added to the ADXL_Init() function from the above code, inserted right before measurement is started.

         

              // Set up threshold for activity, found through trial and error
              i2c_write_register(ADXL345_REG_THRESH_ACT, 0x90);
         
              // Turn on the axes that will participate
              i2c_write_register(ADXL345_REG_ACT_INACT_CTL, ADXL345_ACT_ac_dc | ADXL345_ACT_X | ADXL345_ACT_Y | ADXL345_ACT_Z);
         
              // Set up free fall thresh
              i2c_write_register(ADXL345_REG_THRESH_FF, 0x6);
         
              // Set up free fall time
              i2c_write_register(ADXL345_REG_TIME_FF, 0x10);
         
              // Set up interrupt outputs
              i2c_write_register(ADXL345_REG_INT_ENABLE,
              //i2c_write_register(ADXL345_REG_INT_ENABLE, ADXL345_INT_FREE_FALL );
         
              // Route ADXL345_INT_Activity to INT1 and ADXL345_INT_FREE_FALL to INT2
              i2c_write_register(ADXL345_REG_INT_MAP, ADXL345_INT_FREE_FALL);
         
              // Clear interrupts by reading the INT_SOURCE register
              i2c_read_register(ADXL345_REG_INT_SOURCE);

        Next, create some new GPIO interrupt configuration routines in our ever-evolving utilities.c file.  The following code makes use of the gpiointerrupt driver, which can be found in your Silicon Labs folder in the emdrv folder: C:\SiliconLabs\SimplicityStudio\v3\developer\sdks\efm32\v2\emdrv\gpiointerrupt.  Be sure to copy both the gpiointerrupt.h and the gpiointerrupt.c files to your src folder in Simplicity Studio.

         

        // Enables the GPIO pin and sets up interrupts
        // Sends control back to your own function in callbackPtr when it occurs
        // Function prototype is like this: int GPIO_int_callback(uint8_t pin)
        // Interrupts are automatically cleared before the callback is returned
        void set_gpio_interrupt(uint8_t port, uint8_t pin, bool rising_edge, bool falling_edge, GPIOINT_IrqCallbackPtr_t callbackPtr)
        {
              if (!gpio_interrupts_configured)
              {
                    GPIOINT_Init();
                    gpio_interrupts_configured = true;
              }
         
              // Enable the GPIO and filter with the 1 on DOUT
              GPIO_PinModeSet(port, pin, gpioModeInput, 1);
         
              // Register the callback function
              GPIOINT_CallbackRegister(pin, callbackPtr);
         
              //(port, pin, risingEdge, fallingEdge, enable)
              GPIO_IntConfig(port, pin, rising_edge, falling_edge, true);
              GPIO_IntEnable( 1<<pin);
        }

        We then are free to create our own function that will be called whenever a GPIO event occurs. Once we have set everything up, we can then put the MCU in a deep sleep state, saving power until something interesting happens.

         

        // This will get called whenever the GPIO interrupt occurs
        // when we pass it into the set_gpio_interrupt function below
        int GPIO_int_callback(uint8_t pin)
        {
              bool pin_state = GPIO_PinInGet(gpioPortB, pin);
         
              // Set the appropriate LED based on the state of the INT1/INT2 pin
              if (pin == ACTIVITY_INT_PIN) set_led(0,pin_state);
              if (pin == FREE_FALL_INT_PIN) set_led(1,pin_state);
         
              return 0;
        }
        int main(void)
        {
              CHIP_Init();
         
              enter_DefaultMode_from_RESET();
         
              setup_utilities(USART1);
         
              delay(100);
         
              ADXL_init();
         
              set_gpio_interrupt(gpioPortB,  ACTIVITY_INT_PIN, true, false, (GPIOINT_IrqCallbackPtr_t) GPIO_int_callback);
              set_gpio_interrupt(gpioPortB,  FREE_FALL_INT_PIN, true, false, (GPIOINT_IrqCallbackPtr_t) GPIO_int_callback);
         
              while (1)
              {
                    EMU_EnterEM2(false);
         
                    // Wait a second
                    delay(1000);
         
                    // Clear interrupts by reading the INT_SOURCE register
                    i2c_read_register(ADXL345_REG_INT_SOURCE);
         
                    // Clear the LED for both (could clobber one that just came in)
                    set_led(1,0);
                    set_led(0,0);
              }

        The tricky syntax at the end of the set_gpio_interrupt function call is what is known as typecasting.  We are passing a pointer to our own function called GPIO_int_callback to another function.  In order to keep the compiler from warning about a type mismatch, we type the pointer to the function as a GPIOINT_IrqCallbackPtr_t, which is what the compiler is expecting.  This is how to hush compiler warnings when you know what you are doing.

         

        Tap the ADXL345 breakout board with your finger on any axis and an LED0 should light.  Drop the Starter Kit and ADXL345 breakout board onto a pillow and the other LED1 should light.  Note that an activity event always seems to nullify the freefall interrupt so it might be hard to spot just the freefall LED by itself, unless you increase the threshold of the tap event such that a pillow collision will not trigger the tap event.  Try it!

         

        In the next section, we will use Energy Profiler to take a look at power consumption of this algorithm.

         

        PREVIOUS | NEXT

      • Simplify Wireless Development with RAIL

        Lance Looper | 03/81/2016 | 09:53 AM

        Last month we released our Wireless Gecko EFR32 portfolio of SoCs, which we feel represents a major step forward for providing connectivity and flexibility for IoT applications. Included in this news was the Flex Gecko family, designed to provide flexibility (get it?) for proprietary wireless protocols.

         

        RAIL Highlight Image.png

        For Bluetooth, ZigBee, and Thread, the radio configuration is known because they’re set by the alliances or consortiums responsible for those standards. However, most proprietary wireless customers will work with the radio at a lower level than standards-based products. While there are  advantages to proprietary stacks, like security and legacy, there are also trade-offs. Most notably, a proprietary approach means you’ll need to understand every aspect of the device, from the physical layer and regulatory requirements to the network and applications layer. This makes porting your legacy protocol to a new radio an extremely time-intensive and complicated process, made more complex by the large number of hardware registers that accompany increasingly sophisticated SoCs.  Abstracting away those complexities becomes critical for getting to market in a reasonable time.

         

        RAIL for Development

        This is where our new Radio Abstraction Interface Layer (RAIL) comes in. RAIL is essentially a library of functions built on top of the radio itself. Example code for things like collision avoidance, address filtering, and other features is built on top of the RAIL layer and a graphical user interface (GUI) lets you customize RF parameters so you can get what you need from the radio. And you can build your own proprietary protocol on top of RAIL.  

         

        For example, the new Wireless Gecko SoCs have a transmit power of 20 dBm. Until now, with a proprietary wireless protocol, configuring that meant you had to touch each register on the device that relates to the power amplifier. With hundreds of registers on an SoC, each having dependencies on one another, writing code and tweaking each register becomes a monumental task. But with RAIL, you only need to know one command. RAIL then takes that command and sets up your registers for you.

         

        This not only dramatically simplifies the process, but RAIL will expand with new devices. As you move to new platforms, you can port your software without learning a new radio interface. The RAIL library will know which Silicon Labs chip it’s running on and the process will be fully transparent to the user.

         

        Much of the hesitation to moving to a new platform is because of the time investment that comes with porting the software. RAIL eliminates that concern because you can take whatever software stack (whether for a proprietary protocol or a standards-based protocol) you’ve written for your existing radio and use the same code for the new one. The time saved by using RAIL will translate directly to faster application development.

         

        RAIL for Manufacturing Test

        RAIL can also simplify hardware testing during the manufacture/production process.  RAIL has an application called RAIL Test that makes it easy to do simple functions, such as setting the radio to transmit and receive during an FCC test event.

         

        This is a big change from the traditional node testing, where a binary image had to be custom built to the specific hardware specifications for each customer.  With RAIL, product developers do not need to contact the chip manufacturer as they build the test. Instead, the production team has the ability to create the build themselves, removing the chip vendor from the process and speeding test and production. This provides more control and less waste during the production process because you can react faster if something goes wrong on the manufacturing line.

         

        So, What Do I Get with RAIL?

        The RAIL Software Development Kit (SDK) included the RAIL Library and RAIL Configurator. The RAIL SDK, which can be downloaded here, includes a library of functions, sample applications such as range test and bidirectional transmit/receive provided as source code, and API documentation with release notes and a Quick Start guide. The RAIL Configurator, which is part of Simplicity Studio, includes the GUI we discussed earlier where you’ll be able to customize your RF requirements and create RAIL-based projects.

         

        Learn RAIL Application Development Fundamentals here

        Get started with RAIL and Wireless Geckos

        Download RAIL SDK here.

      • 20th Anniversary: Spotlight on Innovation with James Jeffries, CEO of Mobilogix

        Lance Looper | 03/76/2016 | 05:34 PM

        Silicon Labs customers are as varied and fascinating as they are innovative. One such customer is Mobilogix, a Machine-to-Machine (M2M) systems integrator that improves and simplifies communications in the daily lives of people and companies globally. The company’s focus is on creating intelligent solutions that connect people to machines through core telemetry, web, and mobile platforms.

         

        Recently, we had a chance to speak with Mobilogix CEO, James Jeffries, about how he got his start, Mobilogix’s innovative approach, and the impact a more connected world has on the way we work and live.

         

        Screen Shot 2016-03-16 at 4.13.09 PM.png

         

        Tell me how you got started working with wireless technology.

        I've been in the wireless space, since 1991. I started out, believe it or not, in one-way paging. I worked for my dad’s industrial water treatment company and I carried a pager as I ran around to all the different refineries in Texas to test and treat their water cooling systems.

         

        I started thinking, what else could I do with this pager? An engineering buddy of mine and I started playing with it. We hooked it up to a relay and connected that to a lamp. When we paged it, we could turn the lamp on and off. Soon we put multiple input/outputs on a breadboard and stuck it in a car. We were locking, unlocking doors, flashing lights, sounding the horn – and even actually killing the engine, which as you might imagine wasn't very safe!

         

        At that time, I was 29 years old. I quit my job and started a little company, Satronics. I had a lot of ideas, but the technology wasn’t quite ready yet. A cellular modem back in 2003 was $75. A GPS engine board was $50.

         

        How did Mobilogix come about?

        In 2005, I decided to take few years off, but I couldn’t stay away from the industry. A few years later I got back into the wireless space again. It was a revelation – everything I wanted to do before, I could now do. Modems were smaller, more power efficient, and lower cost. So you could put together a business solution with the ROI that would enable that solution to become successful. That's what started Mobilogix.

         

        What is the most unique thing about Mobilogix?

        When I was talking to carriers and other companies, their biggest struggle was to develop a connected solution. They had to work with three or four different companies. In the Internet of Things (IoT), the ecosystem is usually hardware, firmware, middleware, and wireless connectivity or data.

         

        At Mobilogix, the strategy was to be a true end-to-end IoT systems integrator. I tried to bring it all in under one roof and that definitely streamlines communication. All the pieces are here and we are focused on one thing: to get our customers or our partners a solution in-hand and, in the process of doing that, we're reducing costs and speeding time to market.

         

        I keep our development costs as low as possible because I want to eliminate the barriers to entry. And one of the biggest barriers of entry is cost. Development cost. So by doing this and streamlining those processes, or components of the overall solution, we are improving our chance of success.

         

        Silicon Labs was founded in 1996, so this year we’re celebrating our 20th anniversary. Technology changed dramatically since then. What are your thoughts on that change and where it is going in the future with the IoT?

        I grew up in NASA Bay right across from Johnson Space Center, so I grew up really interested in the space program. A lot of my friends’ dads were astronauts or engineers at NASA. It’s hard to comprehend, but one of the old flip phones in the mid-nineties – not one of today’s smartphones – had more computing power in it than the first lunar lander did.

         

        It’s incredible. In the early 90s I had a buddy who was a pilot. He flew checks – paper checks – from bank to bank. That's all he did. He’d pick up a bunch of checks in Houston, and fly them up to Dallas. Take Dallas checks and fly them to New Orleans. That's how they cleared checks in the 90s. There wasn’t an electronic check clearing process.

         

        It’s speeding up all the time. We used to double technology every three years. Now it's every six months. And the scary thing is, no matter how far you stretch your imagination in the IoT space, you're not even close to where we can go. So everything that we think about, chances are in four years you're going to look back and snicker at it and say, are you kidding me?

         

        We are in the middle of the next industrial revolution. In the 19th century it was steam engines, then the Ford assembly line, then the advent of computers. Now, we have the Internet of Things. We've only just begun to see the benefits of smart devices. They can do things that not too long ago required a human interface – somebody had to actually go out there and touch that machine. Now devices are going be able to take on more of the decision-making processes in our personal and professional lives. This is a very exciting, dynamic period to be in this business. Mobilogix is very fortunate to be a part of it.

         

        How do you think a more connected world will change the way we work and live?

        I think the things that come to mind quickly are improved efficiency, lean and more effective processes, and unique customer experiences.

         

        The more you think about a person as a creature of habit, the more intelligent devices will come into play. Already today, there are smart refrigerators. When I go to the store, I pretty much buy the same things. What if your refrigerator could know what you were almost out of and automatically order it and have it delivered? These smarter devices mean that many of our normal routines and busywork will simply disappear. Within the next 10 to 20 years, we will all be fully connected and it will drive levels of innovation that are hard to imagine right now.

         

        What makes Silicon Labs an ideal partner for you guys?

        Silicon Labs has been great to work with. They’ve got a very strong technology roadmap, which makes for a complementary relationship. The support and responsiveness that they provided enabled us to deliver a large-scale solution ahead of schedule and under cost.

         

        At the time, we were working with Bluetooth module development which was new for us, so Silicon Labs support was critical. We could call 24/7 and got a very quick turnaround on replies. We delivered a working sample to our customer in two weeks.

         

        That goes back to the benefits of Mobilogix. We are not a big company, but we have a very in-depth knowledge of the technology, the connectivity options, and solutions. That makes us very nimble.

         

        Last but not least, the big question. What does a more connected world mean to you?

        My simple answer – is it eliminates physical constraints and accelerates innovation.

         

      • 3 Obstacles to Cracking the Connected Home Market

        Lance Looper | 03/75/2016 | 10:23 AM

        The connected home is one of the largest, fastest-growing segments in the Internet of Things (IoT). But before the connected home makes the leap from early adopters to mainstream consumers, some important challenges need to be addressed. Questions about technology standards, business models, and data collection need to be answered in a way that will satisfy all stakeholders in the connected home ecosystem.

         

        1. Technology and Trade-Offs

        A typical connected home network features one or more smart devices (possibly hundreds) connected to each other and to the Internet so that end users can control, customize and monitor their environment. Applications driving adoption include sensors, actuators and controls for security and environmental systems, entertainment consoles and TVs, and appliances.

         

        These devices are capable of sharing data and commands with the rest of the home ecosystem because they integrate widely available low-power embedded controllers, wireless chips and sensors. Leading semiconductor and software suppliers already offer the mix of components and development tools that lets connected device designers and service providers avoid the risks of adopting a single standard.

        Additional required technologies that support the connected home —such as operating systems, application development platforms and connectivity protocols—draw from a rich legacy of embedded industrial and mobile IoT applications, so are also readily available to developers.

         

        However systems that are simple to install and manage, while power users may prefer systems that let them tweak and push the limits of what the system can deliver. The differences among home users impacts technical requirements for the installation experience, including device discovery, feature configuration and security management. 

         

        Home users have a choice of suppliers to create the desired mix of do-it-yourself or do-it-for-me connected devices. Each of these stakeholders has different requirements when engaging with the home user. For example, a service provider catering to a do-it-for-me customer will be concerned about battery life in devices they install to minimize labor and replacement costs during the life of the contract, while a retailer catering to a do-it-yourself customer will emphasize a low purchase price with less concern about energy consumption and battery life.

         

        1. Balancing Business Models

        In addition to user experience, there are several issues that directly affect industry stakeholders. What are the business models that let stakeholders innovate and contribute to the connected home ecosystem while providing revenue for the benefits they enable? Who owns the data collected by the connected home ecosystem, and how is that data made available to each stakeholder? Who is responsible for security? How will physical and logical security be ensured in the connected home ecosystem as well as stakeholders’ remote or cloud-based services?

         

        The connected home ecosystem is different from traditional embedded systems. Each component is not isolated and devices must interoperate within the ecosystem. For example, a device such as a smart thermostat may require data from other devices, such as a mesh network of motion detectors. This is how the device makes intelligent decisions about when to dynamically adjust lighting and climate settings to appropriately meet the conditions in the environment it is monitoring and controlling.

         

        There are already a variety of application frameworks, operating systems and communication protocols vying for leadership in the connected home ecosystem and it is unlikely that the market will converge to a single set of standards. What is more likely is that there will be a give and take in how each device, peripheral and hub responds to each other to protect home users’ investment and protect stakeholders from some of the risk of supporting unsuccessful standards.

         

        The evolution of remote controls is an example that suggests how business models may adjust to address these issues. Remote controls have never complied with a standard form factor, key layout or command protocol. This has been a deliberate decision made by manufacturers who tightly coupled remote control designs with their products. If remote controls were interchangeable, product manufacturers would not be able to ensure the user experience, especially if a remote control from one manufacturer did not implement important capabilities of another manufacturer’s product.

         

        Universal remote controls eventually came about as a workaround, with discrepancies between remote control commands and device operation typically attributed to the universal remote.

         

        1. Data Ownership and Security

        Icontrol Networks’ 2015 survey of consumers considering connected home products reveals that users are more worried about the possibility of a data breach that results in their personal data being stolen than the cost of the technology. They are also fearful that their data will be collected and sold.

         

        The ability for connected home devices to collect and communicate usage and sensor data to the cloud transforms them from a single user transaction to an ongoing relationship. Applying analysis to the data collected by all connected devices may allow the connected home ecosystem to deliver valuable capabilities not even imagined today. Additional benefits are possible if big data analysis can identify trends among groups of users across different homes. But to unlock this potential, stakeholders must address data ownership and security at the device, platform and service level.

         

        Business models rely on the assumption that information that can be collected from connected home devices will generate additional value for the user and the stakeholder. However, business models based on analyzing this collected information must address user concerns about opting-in or out (both before and after data has been collected), offering recourse if data is lost or stolen and providing access to external audits of how stakeholders are using the information.

         

        Complicating the issue are the differing views on security by connected device manufacturers. For example, a door lock manufacturer may hold significantly higher security concerns compared to a light switch manufacturer. As a result, security becomes a multi-level issue. This can include integrating security protections and hardening the chips in designs, working within standards bodies to ensure usage of appropriate security protocols in the standards, working on software implementations to ensure proper security review and hardening, and working with home users to ensure they use the appropriate level of security for their devices.

         

        Taming the Connected Home

        The connected home has become the fastest-growing and largest segment within the IoT, but competing requirements make succeeding in this market more complex for device and service providers to address than other IoT segments. Taming the connected home depends on an ecosystem that enables new stakeholders to thrive while adding complementary products and services that add value to consumers.

        For more information about the connected home, click here.

      • The Top 5 Things Overheard in the Silicon Labs SXCreate Booth

        Lance Looper | 03/74/2016 | 11:14 AM

        We spent the weekend hanging out at SXCreate coloring robots, racing tricked-out pinewood derby cars, and playing video games. All in a day’s work when SXSW happens in your backyard.

         

        As you can see from the pics below we had a blast. And here are the top 5 things we overheard over three days of car racing, robot coloring, video game playing fun.

         

        Number 5...“Which bee am I again?”

        Number 4...“My purple robot is far superior to your green robot.”

        Number 3...“Ready, set, go!”

        Number2...“Can I have another turn?”

         

        And the number one thing heard at SX Create this year…

        "Does it connect?”

         

        IMG_5578.jpg

        IMG_5559.jpg