Official Blog of Silicon Labs

    Publish
     
      • IoT Hero: Tim Gipson from Mide

        deirdrewalsh | 07/211/2015 | 07:53 PM

        Tim IoT Hero

         

        Growing up in the 90s, I love early rap.  One of the best songs played at my 8th grade dance was "Slam by Onyx."  That's why I was excited to interview our community member and IoT Hero, Tim Gipson (or as you know him Drmn4ea) on the Slam Stick X, along with other cool thinks like flying helicopters blind.  

         

        So, tell me a little bit about yourself. 

        I'm Tim Gipson, director of electrical engineering at Mide Technology Corp. I've been here about ten years now. We're a small company and an even smaller EE department, so my experience has included the full range of analog and digital design, mechatronics, prototyping, technical writing, and, of course, lots of programming, ranging from low-level (firmware in assembly and C) to high (mostly Python). In my spare time, I contribute to hardware jailbreaking efforts and dabble in open-source electronics projects such as Mosquino, an energy-harvesting Arduino derivative, and a networked RGB LED lighting system.

         

        Tell me a bit about your Mide. 

        Mide specializes in "smart materials" applications, using materials, such as shape memory alloys, hydrogels and piezoelectrics, to solve specific problems. For example, we've used SMAs in self-deploying structures, high-efficiency UAV propulsion and safer pyrotechnic devices that won't explode in a fire. We use reversible hydrogels in a bulkhead shaft seal for Navy ships; this is installed where the propulsion shaft passes through a bulkhead wall, activating on contact with water to seal and isolate ship compartments in the event of a hull breach. We use piezomaterials for vibration energy harvesting, actuation and damping, high-speed valves, micro-positioning and high-fidelity haptic devices. The skin is a wide channel of mostly-untapped sensory bandwidth; we're currently building intuitive haptic vests and control interfaces for soldiers and pilots - you can actually fly a helicopter blindfolded with this, using only tactile signaling. I sat in with someone doing exactly that in one of the country's most advanced rotorcraft simulators; it was very impressive to see (and feel)!

         

        More recently, Mide and its partners have been working on distributed condition-based maintenance applications, in which wireless sensor nodes distributed throughout a mechanical system work together to identify degrading components in the system and estimate their remaining life. With this, maintenance can be performed only where needed, rather than blindly replacing parts based on a calendar or usage-hours schedule, and maintenance downtimes can be planned more efficiently, saving billions industrywide. We're especially focusing on applications where ultralow-power electronics and environmental energy harvesting enable truly maintenance-free, "stick on anywhere" solutions.

         

        I know you guys make the awesome Slam Stick X.  Can you talk about what it is, why it's cool, and how people are using it today? 

         

        The Slam Stick X is a high-fidelity portable vibration data logger in a USB thumb drive. There are many other accelerometer data logging options, but some things that set Slam Stick X apart are high sampling rates, high g-level ranges (up to 2000g), user-configurable hardware antialiasing, event triggers (such as altitude), and the certification considerations that make it suitable for demanding applications. This includes military-grade EMI/EMC qualification (MIL-STD-461F), FOD (foreign object damage) design considerations for use in aircraft avionics bays, and fully NIST-traceable calibration over a wide temperature range. You can pull it out of your pocket and stick it on a structure using double-sided tape, and get results on par with a rackful of expensive equipment requiring hours of setup time per test.

         

        Slam Stick X was initially designed for the US Navy to perform in-flight qualification testing on F-18s; they needed a standalone shock & vibration measurement tool that could be easily stuck onto just about any part of an aircraft, inside or out, and safely flown - without wiring or aircraft modifications. Previously, such testing was done with a set of specially-instrumented aircraft, with racks of custom equipment and wiring everywhere. The safety clearances for such wired instrumentation are surprisingly expensive and take ages; since there were only a couple modified aircraft to support this, there was also a very long waiting list to get access to one for a test. Now, the setup time is in minutes and with whatever aircraft is handy.

         

        Many customers don't say what exactly they're using it for, but we know they include a well-known smartphone company, a well-known search engine company, and manufacturers of products ranging from helicopters to professional movie cameras to bulldozers to breakfast cereals. Product development and qualification seems to be the most common use for Slam Stick X.

         

        We've also heard from customers using them for human-factors analysis on vehicles and power tools (allowable vibration transmitted to the user), to optimize and size vibration energy harvesters, instrument fragile shipments, measure small variations in equipment performance, and instrument race cars. One customer inquired about using Slam Stick data to guide policy in a historic building district by comparing the impact of nearby heavy vehicle traffic on the building foundations to earthquake-equivalent magnitudes, following the collapse of one of the buildings. Another is using them to identify and reduce damage sources to fleet vehicles - in one case they were able to correlate an unusually high occurrence of a specific damage pattern (broken rear springs and axles) to a specific set of speed bumps in a housing estate, which drivers were cutting through on their way back to depot. They've even been used to measure rocket launch forces. 

         

        [video]

         

        I understand that it uses the Silicon Labs EFM32.  Why did you choose that MCU?

         

        A combination of factors, but our main reason for selecting the EFM32 family was their low-energy features. A well-designed EFM32 application allows a lot to happen autonomously while the CPU core sleeps, which both lets us record longer on a single battery charge and perform more processing with a modest CPU speed. In particular, the combination of ADC scan mode, hardware-accelerated oversampling, Peripheral Reflex System and DMA is a killer combination that lets us scale down power usage with sample rate while still providing good noise reduction across the board.

         

        Some other features that drew us to EFM32 were the strong support for open-source development tools, and the API consistency of the vendor-supplied libraries between devices in the Gecko family. The current device targets high-speed measurements on the order of hours to days, but we plan to offer additional products based on its design, targeting operating ranges more in the months-years range. Being able to squeeze down power consumption even further and move freely between larger and smaller devices will allow us to offer this kind of variety more easily.

         

        Cool! Well, it’s a big question, but in your opinion, what does the future of IoT look like? 

         

        "IoT" has been around the hype cycle a few times. A decade ago, the rallying cry was "control your home thermostat remotely" and "put your toaster on the internet" and the natural response was "Why would I want to do that?" I think we're at a point now where both the technology infrastructure and application mindset are finally catching up to that hype enough that it could take off this time.

         

        On the technology side, modern low-power sensors, CPUs and wireless technology will enable the deploy-anywhere-and-walk-away sensing applications that will make IoT devices approachable to nonengineers just trying to solve a problem. The ongoing adoption of IPv6, cheap cellular and other emerging data services will remove cost and infrastructure barriers, which until recently have led us to "small local networks of things dangling off cable modems," and requiring proprietary 3rd-party cloud services to mediate contact with one another across NATs and firewalls.  Finally, implementors are now envisioning and promoting more realistic applications, ones that solve real problems and promise real returns on the investment.

         

        So I guess I see the IoT growing, but with more of a sustained simmer than an explosion for now. It won't be in every home soon, and our toasters won't be on the internet, but there will still be millions of nodes deployed in targeted niche applications like smart metering, condition-based maintenance and health monitoring, distributed environmental sensing, smart asset tracking and the like. Many fleet vehicles already report back their GPS location and various status variables, but this will filter increasingly down to things like dumpsters, shipping crates, bicycles, port-a-johns and pet collars. Mostly commercial and industrial users at first, with the bulk of the end-consumer-facing applications coming later.

         

        Most of the industry won't be buying "IoT" for its own sake though; they're interested in solutions, however they work under the hood. I expect to see many more networked CBM sensors in the near future; this is one niche where inexpensive collections of networked sensors can provide large and immediate paybacks. And yes, networked Slam Sticks are definitely in the plans - but no one company can release every sensor or solve every problem. Multi-vendor interoperability following open standards is what will really enable the applications that sell IoT solutions to industry.

         

        If you have a question for Tim, comment below. 

         

      • UV Sensors Protect from Harmful Sun Exposure

        lethawicker | 07/210/2015 | 03:27 PM

        Being 6th might not seem like something to make a big fuss about, but when it comes to common types of cancer, melanoma of the skin and its 6th place ranking is something worth considering. Skin cancer can occur anywhere on the body, but it is most common in skin that is often exposed to sunlight. Don’t believe us? Check out this video.

         

         

        It's fairly easy to protect yourself from the warming but potentially lethal rays from the sun. Wearing sunscreen or protective clothing helps block UV radiation, but how do you know how much ultraviolet rays you have been exposed to or when excessive levels are reached? Passive and disposable bracelets and portable measuring devices exist today. Because of their disposable nature and lack of user-friendliness, these temporary solutions are not something you would carry with you all day, every day.

         

        UVsensor1.pngOn the other side of the coin, companies like Basis, Fitbit, Garmin, Misfit and lately Apple provide durable fitness trackers and smart wearables and watches. Traditionally, these devices do a great job at tracking steps and heart rate and even blood oxygen levels. However, they have lagged behind when it comes to including UV exposure to the list of metrics they track.  

         

        These manufacturers now have the ability to include tiny sensors that measure UV exposure, and actively warn the user of dangerous levels and too much time spent in the sun. Silicon Labs’ Si1132/4x sensor family is the industry’s first single-chip, digital UV index sensor IC solution designed to track UV sun exposure. In addition it supports heart/pulse rate and blood oximetry, and provides proximity/gesture control for smartphone and wearable computing products.

         

        Silicon Labs’ Si1132/4x UV sensors have won the prestigious EE Times and EDN UBM ACE Award for 2015. We hope to start seeing UV sensing added to the standard measurements of every wearable device, so that no one is ever caught by surprise by their UV exposure again.

         

        So remember, whether you are playing on the beach or in sunny mountains, make sure you protect yourself and your skin, and check out our award-winning UV sensor

         

      • Meet the 15 Finalists for the Your IoT Contest!

        lethawicker | 07/209/2015 | 09:55 AM

        Poblinds

        We’ll announce the three winners on August 3rd, but until then check out our fifteen finalists. These finalists were determined by number of votes from the community. There are some brilliant ideas here, so make sure to take a look and root for your favorite.

         

        Check back on August 3rd to find out which three IoT projects will win $10,000 in Silicon Labs components from Silicon Labs and Digi-Key.

         

      • Two Years, Two UBM Canon ACE Awards for Silicon Labs’ Sensor Family

        lethawicker | 07/204/2015 | 03:35 PM

        For the second year in a row, the Silicon Labs Sensor Family won top honors in the highly competitive UBM Canon ACE Awards. This year, our Si1132 and Si114x sensor family won for functionality, innovation and integration. The winning sensors come in a 2 mm x 2 mm package (about as big as this-->x), and integrates all this sensor functionality:

         

        • UV index
        • Ambient light
        • IR sensor for the 2D/3D gestures
        • Proximity
        • Heart rate/pulse
        • Blood oximetry

        The part is perfect for IoT, wearables and smart home devices such as “wake-on-approach” thermostats.

         

        Check out the Si114x Sensor with the “Sensor Puck” demonstration platform.

         

        sensor puck and display

         

        “The ACE Awards celebrate the highest achievements in innovation and creativity in electronics design, and selecting one organization or individual that stands out above the rest is incredibly challenging. We are pleased to be able to celebrate their achievements,” said Suzanne Deffree, executive editor at UBM Canon's EDN.

         

        For more information about the ACE awards program, visit http://ubm-ace.com/. For more information about Silicon Labs’ Si1132 and Si114x UV index sensors and comprehensive sensor portfolio, please visit www.silabs.com/sensors.

      • Chapter 5 MCU Clocking Part 5 -- Fading Multiple LEDs at Once

        lynchtron | 07/204/2015 | 05:00 AM

        makersguide_ch5_5.png 

         

         

        Fading Multiple LEDs at Once

        We now have everything that we need for each individual LED that will make up our chaser.  The next step is to apply the fader mechanisms to multiple LEDs at once, and then with different starting offsets for each LED to create a chaser.  It is time to break out the breadboard and wire up three LEDs with 2k-ohm resistors between the (shorter) ground leg of the LED and the ground rail.  Connect the other end of the LED to the following pins on the Starter Kit:

         

        • PD1 to LED0
        • PD2 to LED1
        • PD3 to LED2

         5.5_circuit.jpg

         

        The reason why I chose these particular GPIOs for this project is because they are all on location#3 for the TIMER0 Channel Control pin enable, as specified in the Reference Manual in the TIMERn_ROUTE register.   All of the GPIO pins that are to be configured for PWM must be on the same location in the route register.  This is exactly why you need to breadboard your design BEFORE you create custom PCBs of your design.  You must become intimately aware of your MCU’s pinout nuances.

         

        The following code will configure the TIMER0 for PWM with output to the three pins that we have connected.  Some of the prior function and variable definitions from previous code snippets has been removed for brevity, and are unchanged from the previous examples.  The full code listing is available online.

        #define LED_PORT  gpioPortD
        #define LED_PIN0  1
        #define LED_PIN1  2
        #define LED_PIN2  3
         
        #define SPEED_MULTIPLIER            5
        #define RAMP_UP_TIME_MS             100 * SPEED_MULTIPLIER
        #define RAMP_DOWN_TIME_MS           100 * SPEED_MULTIPLIER
        #define HIGH_DURATION_MS            100 * SPEED_MULTIPLIER
        #define LOW_DURATION_MS             0
        #define MAX_BRIGHTNESS              100
        #define MIN_BRIGHTNESS              0
        #define OVERLAP                     125 * SPEED_MULTIPLIER
         
        #define START_OFFSET_MS       RAMP_UP_TIME_MS + RAMP_DOWN_TIME_MS + HIGH_DURATION_MS + LOW_DURATION_MS - OVERLAP
        #define DELTA                 MAX_BRIGHTNESS - MIN_BRIGHTNESS
         
        enum mode_values { NOT_STARTED, RAMPING_UP, HIGH, RAMPING_DOWN, LOW};
         
        // Set the initial conditions for all LEDs
        uint16_t mode[3] = {NOT_STARTED, NOT_STARTED, NOT_STARTED};
        uint64_t next_step[3];
        uint16_t brightness[3] = {MIN_BRIGHTNESS, MIN_BRIGHTNESS, MIN_BRIGHTNESS};
        uint64_t mode_timeout[3];
         
        void start_fade(int led_id)
        {
              if (mode[led_id] != NOT_STARTED)
              {
                    DEBUG_BREAK
              }
         
              uint64_t start_time = get_time_in_ms();
              next_step[led_id] = RAMP_UP_TIME_MS / DELTA + start_time;
              mode_timeout[led_id] = start_time + RAMP_UP_TIME_MS;
              brightness[led_id] = MIN_BRIGHTNESS;
              TIMER_CompareBufSet(TIMER0, led_id, brightness[led_id]);
              mode[led_id] = RAMPING_UP;
        }
         
        void SysTick_Handler(void)
        {
              uint64_t curr_time = get_time_in_ms();
         
              for(int i=0; i<3; i++)
              {
                    switch (mode[i])
                    {
                    case NOT_STARTED:
                          continue;
                          break;
                    case RAMPING_UP:
                          if (next_step[i] <= curr_time)
                          {
                                next_step[i] = RAMP_UP_TIME_MS / DELTA + curr_time;
                                TIMER_CompareBufSet(TIMER0, i, brightness[i]++);
                          }
                          if (mode_timeout[i] <= curr_time)
                          {
                                mode[i] = HIGH;
                                mode_timeout[i] = curr_time + HIGH_DURATION_MS;
                                brightness[i] = MAX_BRIGHTNESS;
                                TIMER_CompareBufSet(TIMER0, i, brightness[i]);
                          }
                          break;
                    case HIGH:
                          if (mode_timeout[i] <= curr_time)
                          {
                                mode[i] = RAMPING_DOWN;
                                TIMER_CompareBufSet(TIMER0, i, brightness[i]--);
                                next_step[i] = RAMP_DOWN_TIME_MS / DELTA + curr_time;
                                mode_timeout[i] = curr_time + RAMP_DOWN_TIME_MS;
                          }
                          break;
                    case RAMPING_DOWN:
                          if (next_step[i] <= curr_time)
                          {
                                next_step[i] = RAMP_DOWN_TIME_MS / DELTA + curr_time;
                                TIMER_CompareBufSet(TIMER0, i, brightness[i]--);
                          }
                          if (mode_timeout[i] <= curr_time)
                          {
                                mode[i] = LOW;
                                brightness[i] = MIN_BRIGHTNESS;
                                TIMER_CompareBufSet(TIMER0, i, brightness[i]);
                                mode_timeout[i] = curr_time + LOW_DURATION_MS;
                          }
                          break;
                    case LOW:
                          if (mode_timeout[i] <= curr_time)
                          {
                                mode[i] = NOT_STARTED;
                          }
                          break;
                    }
              }
        }
         
        int main(void)
        {
              CHIP_Init();
         
              if (SysTick_Config(CMU_ClockFreqGet(cmuClock_CORE) / 1000))
              {
                    DEBUG_BREAK;
              }
         
              CMU_ClockEnable(cmuClock_GPIO, true);
              CMU_ClockEnable(cmuClock_TIMER0, true);
              CMU_ClockEnable(cmuClock_TIMER1, true);
         
              // Set up TIMER0 for timekeeping
              TIMER_Init_TypeDef timerInit = TIMER_INIT_DEFAULT;
              timerInit.prescale = timerPrescale1024;
         
              TIMER_IntEnable(TIMER1, TIMER_IF_OF);
         
              // Enable TIMER0 interrupt vector in NVIC
              NVIC_EnableIRQ(TIMER1_IRQn);
         
              // Set TIMER Top value
              TIMER_TopSet(TIMER1, ONE_SECOND_TIMER_COUNT);
         
              TIMER_Init(TIMER1, &timerInit);
         
              // Wait for the timer to get going
              while (TIMER1->CNT == 0)
         
              // Enable LED output
              GPIO_PinModeSet(LED_PORT, LED_PIN0, gpioModePushPull, 0);
              GPIO_PinModeSet(LED_PORT, LED_PIN1, gpioModePushPull, 0);
              GPIO_PinModeSet(LED_PORT, LED_PIN2, gpioModePushPull, 0);
         
              // Create the object initializer for LED PWM
              TIMER_InitCC_TypeDef timerCCInit = TIMER_INITCC_DEFAULT;
              timerCCInit.mode = timerCCModePWM;
              timerCCInit.cmoa = timerOutputActionToggle;
         
              // Configure TIMER0 CC channels
              TIMER_InitCC(TIMER0, 0, &timerCCInit);
              TIMER_InitCC(TIMER0, 1, &timerCCInit);
              TIMER_InitCC(TIMER0, 2, &timerCCInit);
         
              // Set up routes for PD1, PD2, PD3
              TIMER0->ROUTE |= (TIMER_ROUTE_CC0PEN | TIMER_ROUTE_CC1PEN
                          | TIMER_ROUTE_CC2PEN | TIMER_ROUTE_LOCATION_LOC3);
         
              // Set Top Value
              TIMER_TopSet(TIMER0, TIMER_TOP);
         
              // Set the PWM duty cycle here!
              TIMER_CompareBufSet(TIMER0, 0, 0);
              TIMER_CompareBufSet(TIMER0, 1, 0);
              TIMER_CompareBufSet(TIMER0, 2, 0);
         
              // Create a timerInit object, based on the API default
              TIMER_Init_TypeDef timerInit2 = TIMER_INIT_DEFAULT;
              timerInit2.prescale = timerPrescale256;
         
              TIMER_Init(TIMER0, &timerInit2);
         
              // Check for properly sized constants
              if ( DELTA == 0 || RAMP_UP_TIME_MS % DELTA
        || RAMP_DOWN_TIME_MS % DELTA)
              {
                    DEBUG_BREAK
              }
         
              while (1)
              {
                    // Sweep forward
                    for (int i = 0; i < 3; i++)
                    {
                          start_fade(i);
                          delay_ms(START_OFFSET_MS);
                    }
         
                    // This is the unusual step backward in the sweep
                    start_fade(1);
                    delay_ms(START_OFFSET_MS);
              }
        }

        I wrote this code as a blend of sequential programming and interrupt-driven programming.  The LED events are kicked off during the sequential part of the program and then the SysTick handles moving the LEDs through the mode sequence.  When developing a program that needs to do many things at once, it is a good idea to kick off a process and then let a background interrupt routine handle things from there.

         

        When you run this code, you should see a light that slowly appears on LED0, then “moves” off of LED0 and onto LED1, and then continues “moving” on to LED2 before it changes direction to move back onto LED1 towards LED0.  It should continue this forever.  You can get the LED to chase faster by reducing the SPEED_MULTIPLIER towards 1.

         

        The general theory of operation is as follows:

        • Create arrays to handle the mode, step times, and mode end times for each LED
        • Configure the SysTick interrupt for 1ms ticks
        • Set up TIMER1 for delays and timekeeping functions and TIMER3 for the PWM function
        • Launch each of the LEDs on their fade sequence one-by-one in the main while loop with delay offsets between each one.
        • Let the SysTick handle when it is time to increment the step times and change modes for each LED
        • Limitations
          • There are only three compare outputs on a single timer. To add more LEDs to the chaser, you need to add more timers
          • Ramp times must be even multiples of the LED brightness min/max delta.
          • The offset between LEDs cannot be so large so that when LED1 doesn’t start a new fade while it is still finishing a previous fade. That happens at 150ms and will trigger a debug break.

        This was my first attempt at building an LED chaser.  If this were going to be in my gadget, I would now refactor the whole thing to be easier to maintain and modify, and to add more flexibility so that the offset can be larger such that a previous fade on LED1 can be interrupted by a newer fade sequence.  I would also try to let each LED keep track of its own state, similar to object-oriented programming techniques.  I am not happy with the for loop within the SysTick interrupt.  This requires a single block of code to handle many different cases all at once.  This particular example is OK, but when a single block of code tries to do too much, it can get hopelessly complicated.  It is better to break the problem up into smaller pieces and write clear code to handle each small part.  However, with an embedded design, you have the additional challenge to ensure that the solution is time and power efficient. 

         

        Developing a solution that works is only the first part of the problem.  Now the solution must be profiled and optimized for fast execution time and low energy consumption.  Can this solution be run at a slower clock?  How long does it take to execute the SysTick interrupt under the worst-case conditions?  Can the system be put in a lower power state while waiting for something to happen?  These are the next steps in developing a production solution.

         

        So there you have it.  You have just constructed something similar to Knight Rider’s sweeping hood ornament.  Can you imagine building this circuit in the 80’s with the limited resources available to embedded designers at the time?  It seems that such a simple thing as a sweeping LED chaser shouldn’t be so hard.  But it is complicated and there really are not many other ways to do it.  You either have to write a lot of code or find an external LED driver chip to do it for you.  And when you find such a chip, you have a mountain of documentation to conquer before you can get the LEDs to light up.  Now you know something about all of the engineering that goes into all of these wonderful gadgets and toys that we all own!

         

        PREVIOUS NEXT

      • Accelerating Time to Market for IoT Innovation Using Thread

        lethawicker | 07/202/2015 | 10:26 AM

        Accelerate Time to Market with Thread.png

         

        Everyone talks about how the IoT market is exploding. But just because everyone’s saying it doesn’t mean it’s not true. With so many IoT devices hitting a Kickstarter or store shelf near you, being able to turn your idea from imagination to implementation quickly is vital for success.

         

        The combination of Thread and Silicon Labs gives you the power to take your ideas to market quickly and effectively. Here’s how it breaks down.

         

        Application Development

        Thread does not specify an application layer but instead provides basic messaging services such as unicast and multicast message services using UDP and CoAP. Similar to Wi-Fi, Thread focuses on the secure and reliable transport of information but rather by using a low-power mesh network instead of a high-powered star network. Tools such as Silicon Labs AppBuilder simplify the use of these IP messaging services by abstracting away stack level details through the use of easy-to-use callbacks and plug-ins. Application code development in this framework is highly portable and can be reused across supported 802.15.4 devices. AppBuilder providers a simple GUI to configure devices and networking parameters such as device type, commands, network forming and joining behaviors as well as security modes and operation. Silicon Labs provides a sample application for Thread to get started quickly that can be easily customized and extended.

         

        Networking Debug

        Understanding, adapting and tuning network level behavior is an important development phase in developing applications for mesh networks. Traditional solutions use wireless sniffers to remotely capture over-the-air networking transactions. Silicon Labs networking ICs build this capability in using a unique two-wire interface called Packet Trace that outputs every packet sent and received by the device appended with link quality information. This information can be aggregated across all nodes in the network into a single view using a tool called Desktop Network Analyzer, providing a complete and comprehensive view of all networking activity. Desktop Network Analyzer correlates all traffic into events and can decode Thread messages. Network activity can be logged over extended periods of time to identify issues that may be infrequent or occur intermittently in the network.

         

        Using Silicon Labs’ development tools with our Thread software stack, you can slash time to market for your valuable ideas. Find out more about Thread by reading our whitepaper at www.bit.ly/THREADWP.

         

        To share your thoughts on developing rapidly for the IoT, feel free to comment below!

      • What's Your Energy Score?

        lethawicker | 07/201/2015 | 03:52 PM

        Simpliclity-Studio-3-Profiler-laptop.png

         

        Beat your own Energy Score

        The newest version of Simplicity Studio, released today, contains the completely redesigned Energy Profiler tool. This intuitive, real-time interface tells you how changes to your project effect energy consumption and battery life.

         

        Improvements include:

        • Greater accuracy and reliability
        • A current graph presentation that looks like a real oscilloscope with X&Y zoom
        • An Energy Score to compare sessions so you can compete against yourself
        • Improved usability and flow

        Up and running in minutes

        To speed installation we customized the process to only install the components of Simplicity Studio that you care about as a user. This results in a drastic reduction of the installation package to as little as 120MB for EFM8 to 1.3GB for EZR32.

         

        Get to work faster

        Simplicity Studio launches 43% faster compared to the last version of the software (based on a 2 year old Dell Latitude running Windows). Time to launch key tasks such as softwarwe examples and demos was improved by more than 200%. This means you can sit down at your workbench and get cranking in a fraction of the time.

         

        Download Simplicity Studio here.

      • IoT Hero: Alix James CEO of NK

        deirdrewalsh | 07/201/2015 | 11:43 AM

        NK-FB-Banner.png

         

        As a fan of rowing (thanks to House of Cards) and aspiring female tech leader, I was super excited to sit down with Alix James, CEO of Nielsen-Kellerman, which makes rowing performance measuring tools (and a bunch of other cool stuff). Alix is truly an IoT Hero, having literally grown up in the tech world.  

         

        I understand that Nielsen-Kellerman (NK) runs in your blood.  Tell me about how you got involved in the company.

        NK was founded in 1978 in the basement of my house. My stepfather and his partner were both research scientists who wanted to find a real-world problem they could solve with their knowledge and skills. An introduction to the sport of rowing by a well-known coach led them to develop a rugged system for amplifying the coxswain’s voice, measuring stroke rate, and timing performance. That product, the Cox Box, is still being made by NK today and is found in thousands of racing rowing shells all over the world.

         

        Over the next decade, the founders invented many other products for the sport of rowing. Another introduction led them to realize that their measurement and manufacturing knowledge could be leveraged to create rugged portable instruments for measuring environmental conditions, and the Kestrel line of weather instruments was born.

         

        I have held the leadership reins at Nielsen-Kellerman for 10 years after working my way through many positions at the company. My first job with NK was soldering circuit boards in the Kellerman basement as a senior in high school. Since my soldering rarely met co-founder Paul Nielsen's standards, I headed off to Yale University where I studied English, Economics and rowing, winning national titles on the Varsity Crew and participating in development and selection camps as a sculler. Penn Law School, marriage and a move to the West Coast followed. After practicing law in California for three years, I rejoined NK as General Counsel and Marketing Manager. Twenty years later, I have worked in almost every department at NK and led many facets of the company's growth. Lean Level I and II certified, I have embraced Lean approaches to continuously improving all aspects of NK from the shop floor to customer service. A firm believer in the power of the brand and building a tribe of passionate users, I have also made every effort to ensure that NK always earns its customers’ loyalty by delivering products that can be counted on to provide accurate information in the most challenging environments.

         

        What are some of the cool Internet of Things devices your company makes?  

         

        Most recently, we’ve developed a line of Kestrel DROP Environmental Data Loggers that measure and log temperature, humidity and pressure in practically any environment. These small, rugged, waterproof data loggers connect wirelessly to the Kestrel Connect App on smart devices via Bluetooth Smart and display real-time and logged data. The applications for this data logger are really endless. From measuring environmental data during cargo transport to conditions in the field for military training to feeling secure about the climate conditions in any room in your home or office building, we want to make sure you’re able to measure all of these conditions even when you’re physically not there.

         

        We’ve also recently introduced the SpeedCoach GPS 2 platform to both rowers and stand up paddle boarders. The SpeedCoach GPS 2 greatly expands the performance improving capabilities of the existing SpeedCoach platform and, for the first time, provides users with an upgradable platform that is compatible with LiNK, NK’s connected environment of apps, web analytics and sensors. Currently, LiNK environment includes Bluetooth Smart wireless connectivity to heart rate belts, sensors, phones, tablets, PC’s (dongle required) and Macs as well as cloud connectivity, web analytics and real-time tracking via apps.

         

        Check it out in action! 

         

        Can you share some of your favorite learnings about designing and prototyping your products? 

         

        Wireless data transfer is a complex space with a lot of competing hardware and protocols. No one technology is perfect yet – the main tradeoffs are battery life, range, interoperability and data throughput. We chose Bluetooth Low Energy because we believe that the power to easily move data to phones, tablets and other smart devices will be critical to our product line as it develops, but in doing so we gave up a bit on data throughput and range extension through mesh networking. The Bluetooth SIG is working on these limitations and we expect the protocol to continue to expand in capability as its adoption grows. The good thing about the Bluetooth SIG from a technical standpoint is that, although features may be slow to be added to the protocol, they usually work well once they are.

         

        For my company, it clearly made sense to go with a module rather than designing our own circuit because of the advantages of speed to market, and being able to focus our engineering resources on the features of our products that solve our customers’ problems, not invisible enabling technologies. From that decision, we researched the number of design registrations for some of the leading module makers. We wanted to see that a module had been extensively adopted for different applications – knowing that this would make it more likely it would work for us as well. The BlueGiga line of modules fit this description perfectly. The design support, as well as the accessories such as the USB dongle, have gotten us up and running smoothly and relatively fast.

         

        You and your company have been recognized by everyone from Backpacker Magazine to Ernst &Young, what advice do you have for IoT entrepreneurs? 

         

        Two things – First, be really clear on what problem you’re trying to solve. There are a lot of IoT products hitting the market just “because they can be connected to the internet.” That doesn’t always add value, but it always adds cost and complexity. Then, REALLY understand those tradeoffs I listed above - battery life, range, interoperability and data throughput – in the context of your problem. Customers these days have gotten used to wireless “magic”, but they don’t understand those tradeoffs. Make sure it is technically possible to deliver a real-world solution given the power and connectivity available where your product will be used.

         

        It’s a big question, but in your opinion, what does the future of IoT look like? 

        One of the commonly held beliefs in the marketplace is that soon we’ll be doing absolutely everything with our phones. I think that is true of many data centric applications, but in the world of specialized sensors, dedicated devices are still going to win. Without a doubt, the power of these dedicated devices can often be vastly increased through being able to get their data promptly to “the cloud.” I think we are going to need two new parts of the internet backbone to really make this easy – easy to access, power efficient cellular data services to cut device dependency on wifi, and easy to customize online database platforms. Right now most companies are having to design and build their entire environment themselves, which is limiting the ability of smaller entrepreneurial companies to bring solutions to the market. Effective “middleware” resellers will grow and help this market boom.

      • Chapter 5 Part 4 -- Pulse Width Modulation (PWM) for LED Dimming

        lynchtron | 07/198/2015 | 01:28 AM

        makersguide_ch5_4.png

         

        Pulse Width Modulation (PWM) for LED Dimming

        We have finally arrived at the part of the lesson where we can put all of this clock theory to good use and make pretty lighting displays in the real world!  In the past lessons, our LEDs were either on or off, and they blinked on or off at a programmed rate.  We will now use a very fast rate of blinking with the use of hardware timer PWM functions to actually dim the LEDs, and then change the rate of PWM blinking to fade the LEDs over time.   Finally, we will perform this fading across multiple LEDs in order to create an LED chaser.

         

        If we were to dim an LED by reducing the source voltage for the LED, this could create a change in color and would not be a consistent degree of fading across all LEDs.  The proper way to dim an LED is by turning it on or off very quickly so that the human eye cannot see the blink rate.  The frequency of the PWM waveform is not important as long as it is faster than the human eye can see and not too fast that the LED fails to reach its saturation voltage.  The duty cycle of the PWM waveform is used to set the brightness of the LED.

         

        5.3_pwm_waveform.png

        Various Duty Cycle Waveforms

         

        We could create all of these PWM waveforms through ordinary GPIO sets in firmware as we have used previously to turn on or off the LEDs, but setting GPIOs in firmware takes a lot of time and is vulnerable to the same software-timing issues mentioned previously in this lesson.  For example, take this small snippet of code, which is the quickest possible way to control GPIOs in firmware.  I am using the memory mapped method to set and clear the GPIO, which avoids function calling overhead.

              GPIO_PinModeSet(LED_PORT, LED_PIN, gpioModePushPull, 0);
         
              uint64_t timer = get_time_in_ms();
              for (int i= 0; i < 10000; i++)
              {
                    GPIO->P[LED_PORT].DOUTSET = 1 << LED_PIN;
                    GPIO->P[LED_PORT].DOUTCLR = 1 << LED_PIN;
              }
              timer = elapsed_ms(timer);

        The value found in the timer variable after the for loop completes is 19ms to run this simple GPIO set and clear loop 10,000 times.  That is equivalent to 10,000 cycles / .019s = 526315Hz or ~ 0.5MHz.  That is orders of magnitude greater frequency than we need for LED dimming, but much slower than the hardware is capable of driving.  Remember, the hardware can run at many times that frequency, so controlling things at the hardware level strictly from firmware will always run slower than dedicated hardware peripherals.

         

        Rather than control the LED dimming strictly from firmware, I will configure hardware timers to control the GPIOs directly.  We must first write firmware to initialize the timer and the PWM GPIO functions, and then the hardware automatically repeats the sequence forever, freeing your firmware to do other things.  We don’t need that faster hardware rate for our LED dimming project, but there are other applications that would benefit from the faster switching rate.

         

        Let’s configure the peripheral timer to PWM a GPIO and set up a programmable duty cycle to be output to the TEST_LED0 on the Starter Kit.  If you recall, TEST_LED0 is on port E, pin 2.  I need to make sure that there is a timer that can be configured to output to PE2.  By looking at the Data Sheet for the Wonder Gecko that is on our kit, I find this GPIO is routed from TIMER3, Channel 2, on Location 1:

         

        5.3_timer_gpio_chart.png 

        Data Sheet Selection of Timer Channel and Location for PE2 Control

         

        Here is the code to set up and run this hardware timer-based dimmer to the TEST_LED0, forever, with no software control beyond the hardware configuration:

        #define LED_PORT  gpioPortE
        #define LED_PIN   2
         
        #define TIMER_TOP                   100
        #define DUTY_CYCLE                  1
        #define TIMER_CHANNEL               2
         
        int main(void)
        {
              CHIP_Init();
         
              CMU_ClockEnable(cmuClock_GPIO, true);
              CMU_ClockEnable(cmuClock_TIMER3, true);
         
              // Enable LED output
              GPIO_PinModeSet(LED_PORT, LED_PIN, gpioModePushPull, 0);
         
              // Create the timer count control object initializer
              TIMER_InitCC_TypeDef timerCCInit = TIMER_INITCC_DEFAULT;
              timerCCInit.mode = timerCCModePWM;
              timerCCInit.cmoa = timerOutputActionToggle;
         
              // Configure CC channel 2
              TIMER_InitCC(TIMER3, TIMER_CHANNEL, &timerCCInit);
         
              // Route CC2 to location 1 (PE3) and enable pin for cc2
              TIMER3->ROUTE |= (TIMER_ROUTE_CC2PEN | TIMER_ROUTE_LOCATION_LOC1);
         
              // Set Top Value
              TIMER_TopSet(TIMER3, TIMER_TOP);
         
              // Set the PWM duty cycle here!
              TIMER_CompareBufSet(TIMER3, TIMER_CHANNEL, DUTY_CYCLE);
         
              // Create a timerInit object, based on the API default
              TIMER_Init_TypeDef timerInit = TIMER_INIT_DEFAULT;
              timerInit.prescale = timerPrescale256;
         
              TIMER_Init(TIMER3, &timerInit);
         
              while (1)
                    ;
        }

        The LED PWM frequency is found by dividing the natural frequency of the timer (which is based on the source clock and the divider of the timer) divided by the timer Top value.  I wanted my PWM switching frequency to be above 200Hz so that there is no noticeable flicker.  I also wanted the duty cycle to be easily set in 1% increments.  In order to do that, I had to play around with a spreadsheet calculation until I came up with the following settings:

         

        • Timer Clock Divider: 256, results in a timer natural frequency of 14 MHz / 256 = 54.7kHz
        • Timer Top Value: 100, by choice
        • LED PWM Frequency = 54.7kHz / 100 Top value = 547Hz

        This gives me the >200Hz LED PWM frequency that I wanted while also giving me 100 for the Top value, which allows for 1% PWM increments.

         

        The duty cycle of our PWM GPIO output is produced by the timer compare registers, listed in the Reference Manual as TIMERn_CCx_CCVB, yikes!  This crazy acronym stands for “Counter Control on Channel X Capture/Compare Value Buffer” register.  I am using the buffered version because the timer will wait until a PWM period is completed before making the change to the compare registers, resulting in glitch-free operation.  Once the CNT value in the timer is greater than this long-named compare register, the PWM mechanism will switch off the configured output.  Therefore, by writing a zero to this register, the output will never be asserted high.  By writing a value of 100 or greater to this register, the output will always be high.  And by programming this value to anything between zero and 100, the register will hold the output high until the CNT value matches the compare value, and then switch off the output for the remainder of the Top period of 100. This is how we can specify the exact PWM duty cycle in 1% increments.

         

        If you execute this code on your kit, you will notice that the test LED does not glow as brightly as before.  You can experiment with 0% all the way to 100% and see how it affects the brightness of the LED. 

         

        Programmatically Fading LEDs

        Now that you can programmatically dim an LED using a hardware timer, the next step in our LED chaser is to create a programmable rate of change to the dimming effect on a single LED to produce a fading effect.  We already have the ability to dim an LED to any value.  In order to fade the LED, we must change the level of dimming on a regular rate.  So it is a rate on top of another rate.  This reminds me of Calculus!

         

        The LED PWM frequency is 547Hz (from the above math), which means that each PWM cycle completes in 1/547 = 1.8ms.  If we were to smoothly ramp from zero (off) to 100 (full on) at 1% step size, it would take about 180ms to reach full brightness.  It would take another 180ms to ramp it back down to zero brightness.  Therefore at the lower limit we can fade the LED through almost three complete cycles per second with 1% resolution.  We could fade the LED through even more cycles if we picked a larger step size.  I am going to assume that we don’t need to cycle more than three times per second and keep the step size at 1%.  This means that all of the durations for this particular solution must be greater than 180ms.

         

        To produce a generic fader, the following figure should describe everything that I must implement in firmware.

        5.3_fader_waveform.png

         

        The following code implements the figure shown.  Tack this onto the end of the existing code.  See the source documentation for a full code listing.

        #define RAMP_UP_TIME_MS             500
        #define RAMP_DOWN_TIME_MS           700
        #define HIGH_DURATION_MS            1000
        #define LOW_DURATION_MS             500
        #define MAX_BRIGHTNESS              100
        #define MIN_BRIGHTNESS              0
              enum mode_values { RAMPING_UP, HIGH, RAMPING_DOWN, LOW};
         
              // Check for properly sized constants
              uint16_t delta = MAX_BRIGHTNESS - MIN_BRIGHTNESS;
              if ( delta == 0 || RAMP_UP_TIME_MS % delta 
        ||RAMP_DOWN_TIME_MS % delta) { DEBUG_BREAK } // Set the initial condition uint16_t mode = RAMPING_UP; uint32_t time_step = RAMP_UP_TIME_MS / delta; uint16_t brightness = MIN_BRIGHTNESS; TIMER_CompareBufSet(TIMER3, TIMER_CHANNEL, brightness); uint64_t mode_timeout = set_ms_timeout(RAMP_UP_TIME_MS); while (1) { switch (mode) { case RAMPING_UP: delay_ms(time_step); brightness++; TIMER_CompareBufSet(TIMER3, TIMER_CHANNEL, brightness); if (expired_ms(mode_timeout)) { mode = HIGH; mode_timeout = set_ms_timeout(HIGH_DURATION_MS); } break; case HIGH: if (expired_ms(mode_timeout)) { mode = RAMPING_DOWN; time_step = RAMP_DOWN_TIME_MS / delta; mode_timeout = set_ms_timeout(RAMP_DOWN_TIME_MS); } break; case RAMPING_DOWN: delay_ms(time_step); brightness--; TIMER_CompareBufSet(TIMER3, TIMER_CHANNEL, brightness); if (expired_ms(mode_timeout)) { mode = LOW; mode_timeout = set_ms_timeout(LOW_DURATION_MS); } break; case LOW: if (expired_ms(mode_timeout)) { mode = RAMPING_UP; time_step = RAMP_UP_TIME_MS / delta; mode_timeout = set_ms_timeout(RAMP_UP_TIME_MS); } break; } } }

        This code gives you the ability to set constants to specify how long the LED should take to go from off to full LED brightness or vice versa, as well as set the maximum and minimum brightness.   Note that because I am using a millisecond-based timer and I am dividing the fader parameters by 100 using integer arithmetic, the fader will work best if the fader parameters are in even multiples of the delta = MAX_BRIGHTNESS – MIN_BRIGHTNESS range.  If I were to program a value of 950 for the ramp up duration with MIN_BRIGHTNESS at zero and MAX_BRIGHTNESS at 100, for example, the step size would be set to 950 / 100 = 9ms, which would not fully complete the brightness sweep and things would go off course. 

          

        I wrote this code as a sequential program rather than as fully interrupt-driven program to keep things simpler.  Keep in mind that the smooth performance of this dimmer will be impacted by anything else that takes time away from adjusting the timer compare values.  It also cannot take advantage of sleep states, so it will waste power.  I will sometimes write code with while loops as a sequential program to get things working and then later rewrite it as an interrupt-driven program.

         

        Try it out on your Starter Kit and play around with the values to see how you can change how it glows.

         

        PREVIOUS NEXT

      • Why Thread, Why Now: Part 2

        lethawicker | 07/196/2015 | 05:28 PM

        In part 1 of our series on Thread’s place in the IoT, we looked at our first three criteria: how Thread is a standards-based protocol, its simplified configuration, and IP-based messaging. Let’s continue with the final four criteria.

         

        4. Low-Power Operation

        Thread provides extensive support for low-power operation using sleepy end nodes. As the name would suggest, these sleepy devices are meant to spend the majority of their time in a low-power sleep state. With Thread, sleepy devices are not required to check in with the network, enabling prolonged battery life. Messages for sleepy devices are buffered by their parents. Message transmission is triggered only after a sleepy device wakes up and polls its parent for any inbound messages.

         

        5. Scalable and Resilient

        Thread was architected with the specific goal of supporting networks of 250+ nodes. With this Scalableconstraint, features and capabilities were adapted to maximize throughput and minimize resource requirements. In a Thread network, the maximum number of active routers is 32. A direct and important consequence of this is that routing information can be efficiently distributed across the network and all routers are able to maintain visibility of all routes within the network. As nodes are added to the network and the topology changes, the network adapts by exchanging Mesh Link Establishment (MLE) messages. Additional routers can be autonomously added if there are Router Eligible devices operating as end devices. Such Router Eligible end devices or REEDs, listen to routing messages and will petition the Leader of the network to become a router if determined necessary to improve the overall performance of the network.

         

        Thread is a robust, self-healing mesh network that offers no single point of failure. If a router fails, the network will dynamically re-route traffic around the failed node. If a Leader fails, another router on the network will be autonomously elected the new Leader. Multiple border routers can be used to provide fail-safe redundancy for off-network communication.

         

        6. Interoperable

        InteroperableThe Thread Group has contracted a standard test harness to be used for certification of all Thread stacks as well as final Thread products. This test harness will be provided to all Thread member companies to allow high quality development and testing of software prior to Thread certification testing.

         

        All Thread components (ICs, software stacks or modules) must be certified as Thread compliant before being used in an end product by a customer. All end product devices that want to carry the Thread logo must submit their devices for laboratory certification at an approved test lab.

         

         

        7. Secure and User-Friendly

        Thread networks are built to be simple to use yet extremely secure. Thread uses AES-128 to protect all networking transactions at the MAC level and utilizes a combination of ECC and J-PAKE algorithms to securely add devices to a network (i.e. commissioning). Applications have the option to utilize standards-based IP security protocols (e.g., DTLS) to additionally secure application payloads.

        The Thread network assumes that there is a commissioning device available for a user to designate to add new devices to the Thread network. Thread makes it possible to designate both off-network devices such as smart phones and computers and on-network Thread devices to become commissioners.

         

        Off-network devices must first petition with a Thread Border Router to become a registered commissioner using a secure DTLS authentication handshake specified by Thread. Once registered, the Border Router then performs arbitration with the Leader on behalf of the commissioner candidate to become an authorized commissioner. On-network devices do not require registration, but may need to perform arbitration with the Leader to be authorized. (The Leader ensures that only one commissioner is active on the network at a time.) Once authorized, the active commissioner will be made known throughout the Thread network.

         

        To join, a user instructs the commissioning device that a new devices is to be added and inputs a unique passphrase associated with the joining device. This passphrase is used to establishing a secure DTLS session to authenticate and authorize the joining device. Only then is the device provided access to the Thread network. Once the device is added to the network, the commissioning device is no longer active.

         

        Thread makes its place in the IoT by providing a wide array of benefits that make the connected home, in particular, easier to design for, manage, secure and expand. Find out more at www.bitly.com/THREADWP

         

        Any thoughts? We’d love to hear from you in the comments!