• USB Type-c Power Delivery Protocol Analyzer Introduction.

        yucheng | 09/250/2017 | 03:15 AM

        Power Deivery Protocol Introduction:


        USB has evolved from a data interface capable of supplying limited power to a primary provider of power with a data interface. Today many devices charge or get their power from USB ports contained in laptops, cars, aircraft or even wall sockets. Users need USB to fulfill their requirements not only in terms of data but also to provide power to, or charge, their devices simply, often without the need to load a driver, in order to carry out “traditional” USB functions.


        USB Power Delivery is designed to enable the maximum functionality of USB by providing more flexible power delivery along with data over a single cable. Also it enables alternative modes of operation by providing the mechanisms to discover, enter and exit Alternate Modes. The specification also enables discovery of cable capabilities such as supported speeds and current levels.


        The USB Power Delivery specification defines how USB Devices may negotiate for more current and/or higher or lower voltages over the USB cable (using VBUS or CC wire as the communications channel). And defines mechanisms to discover, enter and exit Modes defined either by a standard or by a particular vendor. And also defines the mechanisms to discover the capabilities of cables which can communicate using Power Delivery.


        Silabs has released the reference design for usb Type-c. Since more and more customers adopt our reference design, it's essential to investigate the Power Delivery specification, and implement a universal Type-C PD Analyzer base on our certified PD library. 




        The USB Power Delivery Analyzer (PD analyzer) base on EFM8BB3 can monitor the PD package data on the Control Channel lines CC1 and CC2, and don’t need intrusive the original system. It can aid to analyze the behavior of the whole USB Power Delivery System to promote the development of new USB PD product or troubleshoot the issue of the PD system.


        The system architecture of PD analyzer connectors be illustrated in figure as below. The PD analyzer be connected to analysis computer through a USB-to-Uart Bridge for data transfer. The target device should connect the Analyzer’s type-c receptacle, and the plug of Analyzer should connect to another type-c device, typically, it is a source port.





        The prototype of the PD Analyzer will be implemented with EFM8BB31F64G STK board.



        The GUI tool be implemented with python + QT which be supposed compatible with major system. And packages the python programs into stand-alone executables with Pyinstaller.



        The firmware be implemented base on Silabs' certified PD library


        Main function of the PD protocol analyzer 

        1. PD data import / export / save
        2. PD data capture
          • connect / disconnect the analyzer
          • run / stop / pause the PD capture, the version1 will support captured data analysis, but not online analysis.
          • data buffer size if adjustable, the data will be overwroten if overflow
        3. PD data analysis
          • can show raw data, decoded from BMC
          • show message view data
          • show policy layer data
          • can mark the data for checking
        4. About & Help
          • Will provide some user guide for how to use the tool
          • The tool is releasable under Silabs' control


        Overview of the GUI

        As below is the main perspective of the PD analyzer GUI, it comprises the following elements:


        • Menu bar
        • A message view window which list all of the captured PD package data.
        • A Raw Data view window

        Message View

        The message view window be consist of a list that displaying all USB protocol elements. The analysis software lists PD package on the left side of the display. Each PD package includes the SOP, Message ID, Number of Data Objects and Message Type information, also the payload and absolute time of each PD package be expressed in the view. And the PD package transfer direction is indicated with an arrow.


        RawData View

        The Raw Data View will show more information about the selected power delivery package. In addition to the basic PD package information be provided by Message view, this display view allows the user to check the raw data (5B encoded) of each package, and all of the detailed information will be listed, also a brief description about each control message or data message be added to help the user understand the meaning of the PD package further.




        Prototype of the PD Analyzer

        The USB Power Delivery Analyzer (PD analyzer) device be implemented with EFM8BB3. EFM8BB3 has a Configurable Logic block which be consisted of multiple Configurable Logic Units (CLUs). CLUs are flexible logic functions which may be used for a variety of digital functions, such as replacing system glue logic, aiding in the generation of special waveforms, or synchronizing system event triggers. The USB PD analyzer adopt the CLU as a BMC decoder, the module can decode the BMC code independently of the CPU, has the benefit of reducing the workload of the CPU.

        The PD analyzer device be consisted of three parts, EFM8BB3 STK board, CP210x USB-to-Uart bridge, a Type-C receptacle and plug connector. As below is the top view and bottom view of the PD Analyzer device.




        PIN Connection

        The P0.1 of STK board should connect to GND for a reference GND. And P1.1 P1.2 is the input channel of CC pin, please connect them with the Type-c connector’s A5 and B5 pin. Also we should connect the P1.7 and P2.0 to the Rx and Tx pin of CP210x for data transaction.

        Capture PD package data


        Connection Check

        Ensure that the PD Analyzer device is connected to the analysis computer and the power is on.
        Launch the PD Analyzer application by double clicking “PD Analyzer.exe”
        At the main window, click the Capture -> Connect menu to create the connection between Analyzer device and computer. The Connect menu will become disabled if connection be established, otherwise a warning message window will be popped to info the connection failed. And please reset the analyzer device and try to connect it again.

        Capture Data

        After ensuring the connection, please start to capture the PD package by clicking the Capture -> Run. And then connect the target Type-c device with the receptacle of the connector, and the plug of the connector should be connected to other Type-c source. For a quick demo, plug the USB Type-C power adapter into the receptacle, and plug the connector into the Macbook.

        The overview of the PD Analyzer be illustrated as below.



        Firmware HEX

        Uploaded the PD Analyzer firmware project base on EFM8BB3 as attachement, please just program the the PD_Analyzer.hex to EFM8BB31F64G to make it a PD Analayzer device.

        And then refer to sector "PIN Connection" for how to connect the EFM8BB3 STK and CP210x.  


        GUI Tool

        Attachement is the stand-alone executables GUI tool which can run in the Windows PC without installing.


      • EFM8-Powered Plug And Play Solar Concept

        nikodean1 | 02/33/2017 | 01:46 PM

        Hey everyone,


        I used the EFM8UB1 starter kit to complete construction of my plug and play solar system concept. The goal of the concept is to make solar system installation as easy (and hopefully) as cheap as possible by reducing the amount of on-site assembly required.


        It has a built-in inverter, charge controller, 12 Volt, 12 Ah UPS battery, 12 Volt solar panel input, a 5 VDC power rail for a later centralized USB power project, and 120 Volt AC outlets. You just connect a solar panel, flip a switch, and you have a 120 VAC solar power source.


        I used the EFM8UB1 to construct an automatic transfer switch for it, so it can automatically switch appliances (or a house, if it is scaled up) to the grid if there is a shortage of solar power. This is convenient for those who want to minimize battery costs without running the risk of a blackout.


        Here is a video of me discussing and demonstrating it. 


        The EFM8 made it very easy by providing the option of a low-energy USB port (which the white USB cable is connected to) and a built-in CR2032 battery slot.


        This is important because it is battery-powered, and I couldn't afford to have it deplete the battery during a cloudy week, or in general: wasting the power generated by the 20 watt solar panel that recharges it. 


        In addition to that, the analog-to-digital converter configuration was very quick and easy.

      • Automatic climate control in a bathroom

        sergeilb | 09/261/2015 | 12:31 AM

        This device is intended for monitoring the ambient temperature and relative air humidity in a bathroom and is used to control the ventilation fan accordingly. The device has two operation modes – manual and auto.


        In the manual mode the device can be power up by a switch located close to the light switch of the bathroom. Right upon powering up it turns the fan on and starts a timer. After expiration of the timer period the fan is turned off. The fan also turns off if the device is powered down. If the fan is off and the device is powered up (which happens after expiration of the timer period), the only way to turn the fan on again in this mode is to flip the device power (turn it off and on again). The timer period can be set by users and is saved in microcontroller’s non-volatile memory. The same period will be applied over and over unless it is modified by the user.


        In the auto mode the device is supposed to be powered up all the time. It measures the relative humidity in the bathroom every second and computes its deviation within a certain time interval T, which can be set via the menu by the user. As soon as the current humidity value exceeds the one measured T seconds earlier on a certain value Thon (say, 3% within 5 seconds), the device turns the fan on and sets the current humidity value Ht as the target value for turning the fan off. After this it waits for humidity to drop down on a certain value Thoff within the time period T (say, 2% within 5 seconds). This happens when the user completes taking the shower and turns the water off. Once this event is detected, the device starts a timer that turns the fan off after its expiration or if the humidity falls below the target value Ht, whatever happens first. If the shower would be used again before the expiration of the timeout, the latter is cancelled and the device starts waiting for a drop of humidity to reset the timeout from the beginning.


        This way in the auto mode the device actually monitors variation of the humidity over certain time interval rather than its absolute value. Therefore, the fan control does not depend on the ambient humidity value and, in particular, is independent on the year season. Current values of temperature and humidity are displayed on a 128×32 graphic LCD. These values are updated every second. The temperature measurements are also used for thermo-compensation of the capacitive humidity sensor.




        The main PCB is assembled in a fan box which is mounted at the ceiling in a bathroom. Bold LCD fonts make it easy to read the LCD from the floor. Besides of current values of temperature and humidity the device also shows some auxiliary information. As soon as the fan is turned on, the number shown in the red circle below is the corresponding humidity value at this moment and is used as the target value for turning the fan off. Also, when the timeout starts (in the auto mode only), the number shown in the green circle is the remaining amount of minutes for the fan to work. As mentioned above, the fan can be turned off earlier once the humidity reaches the target value in the red circle. As soon as this happens both circled numbers are erased from the screen.


        w2.jpg  w3.jpg


        The user interface is provided by 4 buttons. First push of any of them turns the LCD background light on, which automatically turns off in 10 seconds if no other button is pressed. Otherwise, the device enters the menu mode for setting up its function parameters. Two buttons on the left (SB1, SB2) select the menu option while the two right ones (SB3, SB4) are used to increase or decrease the corresponding option value. Upon exiting the menu all settings are saved in a non-volatile memory, the LCD background light is turned off, and the device returns back to monitoring the temperature and humidity. Note that the fan control algorithm keeps running at the background while browsing through the menu settings. Here are screenshots of all menu screens.


        m1.jpg  m2.jpg

        m3.jpg  m4.jpg

        m5.jpg  m6.jpg


        The first screen selects the operating mode (auto/manual). The second one sets the time interval (in seconds) for monitoring changes in the humidity. The third one is for setting the humidity rise speed for turning the fan on. Similarly, the next one is for setting the humidity drop speed for starting the timer, whose timeout is set on the fifth screen (in minutes). The last screen is used to exit the menu. In the manual mode the values set on screens 2 – 4 are not used.




        The device is built around the C8051F996 microcontroller. One of the reasons for using this model is simplicity of interfacing it with the capacitive humidity sensor, whose capacitance is linearly proportional to the humidity level. Measurement of the sensor capacitance is performed by the capacitance to digital converter (CDC) – a unique peripheral module of this MCU. This module is primarily designed for capacitive sense applications; however it is also very well suited for interfacing with capacitive sensors. The CDC allows measuring the capacitance up to about 500pF with a 12-bit resolution which translates to 0.12pf (the resolution can be increased up to 16 bits). This perfectly fits to the capacitance range of the sensor which varies between 300pF to 370pF as the humidity rises from 10% to 100%. It takes about 180µs for CDC to measure the capacitance with the used settings of the module. After numerous experiments I worked out the following formula for computing the humidity:

        H(%) = (((A – A0)·125 + (T – T0)·136 + 256)) >> 9) + H0

        Here A is the CDC value, T is the ambient air temperature (in °C), while А0 is the CDC value at humidity H0 and temperature Т0. Note that all computations involve operations with integers only.


        For temperature measurements I used analog sensor TC1047A along with the microcontroller ADC. Since the MCU is equipped with 1.65V voltage reference, the formula for converting the ADC code K into the temperature is as follows:

        Т(°C) = ((K·165) >> 10) – 50

        This formula also assumes only integer computations which is easy to implement on the MCU.


        The circuit draws about 80 µA with background light being off and 12 mA when it is on. Brightness of the background is controlled by PWM generated within the MCU. The opto-coupler OK1 provides isolation of the circuit from the power grid. It is assembled on a separate board along with the triac Q2 and mounted close to the fan motor. The circuit is powered from a 5V cell phone adapter.




        The firmware is written in assembly language and developed in Silicon Laboratories IDE equipped with Keil development tools. The code size is about 4Kb which includes 2.1Kb of data for the LCD fonts. The PCB is designed with Eagle software. The PCB is mounted on a vertical edge of the fan enclosure which also includes a lamp. The air is sucked in from the left and the right sides of the enclosure.




        The fan provides airflow of 5m3/min. Its propeller is 12cm in diameter and the motor is rated for 120V/1.4А. The device works non-stop for over 3 years now in a small 4.5m2 bathroom with the ambient humidity changing between 30% in winter and 75% in summer. In the auto mode the fan starts to operate about 20s after the (warm) shower is turned on. If one only opens water in a sink tap, the humidity does not rise up that fast as from the shower, so the fan operation is not affected.


      • Low-power temperature/humidity meters

        sergeilb | 08/236/2015 | 11:28 PM

        The designs described here are intended for in-doors usage. They display air temperature (in °C) and relative humidity alternating on the display with a 2-seconds period. The LCD driver is implemented in software. The first design can be powered from a single AAA battery due to the DC/DC converter built into the μC, as well as from a 3V battery. The average current consumption from the batteries is about 3 μA and 1.3 μA, respectively.


        photo3.jpg   photo2.jpg


        If only one AAA battery is used to power the device, its voltage should be be boosted up to at least 2.7V to meet the needs of the temperature sensor and the LCD. Most of the time the μC remains in the deep sleep mode where its current consumption is about 0.7 μA. It exits this mode only when it is time to update the LCD waveform. This happens every 35 msec, which is sufficient for the LCD flickering to be not noticeable. During the sleep time the DC/DC converter is left floating and the circuit is powered from the charge accumulated on C3, which is DC/DC converter output capacitor. The voltage drop on C3 during the LCD updating period does not exceed 0.2V. Upon waking-up the DC/DC converter activates and compensates the charge drop of C3. The converter runs at 2.4 MHz frequency and starts up if the battery voltage is 0.9V or higher. The number of wake-ups is counted and as it reaches 60, a new measurement is performed.




        The temperature is measured by the Microchip TC1046 sensor, whose output voltage depends on the die temperature as follows: V(mV) = 6.25·T(°C) + 424. Since for the ADC code A with reference voltage 1.65V it holds V = A·1650 / 1024, we get the following formula: T = ((264·A / 256) - 271.36) / 4. The formula is implemented in the μC as follows:

        T = (A + (A >> 5) - 269) >> 2

        The temperature sensor is only powered up during the measurement and is off otherwise. This significantly reduces its power consumption.


        Measuring the humidity is done by the Honeywell HIH-1000 sensor. The sensor is a part of a relaxation oscillator based on a comparator which is built into the μC. The feedback resistors are also present in the μC and turned on by software. The oscillator period is measured by using the on-board 20 MHz system oscillator and Timer2 configured for the capture mode. The formula for computing the relative humidity is presented below. It includes thermal compensation of the sensor capacitance according to the datasheet.

        H(%) = (((N - NNOM)·65 + (T - TNOM)·34 + 256) >> 9) + HNOM

        Here N and T(°C) are the measured Timer2 counter value and the ambient air temperature, and NNOM is Timer2 value at humidity HNOM and temperature TNOM obtained at calibration as described below.


        Needless to say that it makes no sense to perform measurements and drive the LCD in darkness. For further energy savings the device is turned off as the ambient light intensity drops below a certain threshold. The ambient light intensity is monitored by the photo-diode VD1, that generates about 0.4V at sun light. This makes the light sensing circuit very sensitive. The photo-diode is connected to the built-in comparator consuming about 0.4 μA when active. The comparator is turned on every 2 sec in darkness for checking the light conditions. Since checking the comparator status takes just a dozen of microseconds, the average current consumption in darkness drops down to 0.35 μA. During the day the lighting conditions are checked after every 256 measurements, i.e. every 8.5 minutes. This option can be disabled by uncommenting line #83 in the supplied source code humi5.asm. In this case the photo-diode VD1 and resistor R1 are not needed, however make sure to short cut the R1 pads on the PCB. The battery holder, humidity sensor and one wire jumper are mounted on its back side. The PCB is placed between the front and back panels which are cut of a 2 mm plexiglass. C2 should be in 0603 package, all the other capacitors and R1 in 0402 ones. Inductor L1 is TDK CPL2512TR68M.


        photo1.jpg    photo4.jpg


        The inductor and capacitor C3 are not needed if the device is powered from from a 3V battery. It could be 2xAAA or even better CR2032. This way the DC/DC converter is not used. The average power consumption in this case is about 1.3 μA.





        One only needs to calibrate the humidity sensor. For this uncomment line #507 of the source code humi5.asm and let the device run for about 10 minutes. In this mode the LCD will show alternating values of the temperature, followed by the high-order byte of the oscillator period counted by Timer2, followed by its lower-order byte. This value should be put in line #5 of the code as N_NOM. Also, update line #4 with a humidity value measured by external reference hydrometer and update line #6 with the temperature value shown on the LCD. Finally, commend out line #507 and load the updated code into the μC.


        The next device is also intended for measuring the air temperature (in °C) and relative humidity (in %) in a living room. The range of displayed values is 0 - 50°C and 5 - 99%, respectively. The measurements alternate on the 2-digit display with a period of 1.5 sec. The temperature values are indicated by the degree symbol at the top right corner of display.


        photo3.jpg     photo4.jpg


        The device is powered by a solar cell D1 manufactured by IXYS that generates 4.3V DC at full sun. The cell is connected to the charge controller of a lithium rechargeable battery which is integrated into IC2. This IC, manufactured by Cymbet, takes care of automatic harvesting of the solar energy and turns the charger on and off depending on the light conditions. The battery capacity is 50 μAh and it can be fully charged in about 40 minutes. The load draws below 1 μA in average, which allows the device to operate from the battery for more than a day till the next recharge. Actually, the real operating time is much longer, because the voltage generated by the solar cell is periodically monitored by the μC and the device shuts down when it is dark. This way the average power consumption falls down in a factor of 3. The device automatically turns on again as the ambient light level becomes sufficient for reading the display.



        The battery's nominal voltage is 3 - 3.8V is stabilized at the level of 2.8V by the voltage regulator IC1 with a quiescent current of 500 nA. This way a constant LCD contract is achieved which does not depend on the battery discharge level. Transistors VT1 and VT2 are used by programming the μC. In this mode the μC draws about 3.8 mA, which the battery cannot deliver. The external 3.3V voltage from the programmer (VDD pin of in-circuit programming connector SV1) closes both transistors and prevents IC1 and IC2 from damaging. After unplugging the programmer the transistors open again and the device automatically switches to powering from the battery. Low channel resistance of VT1 and VT2 provides virtually zero voltage drop on them which increases the overall system efficiency.


        The temperature is sensed by Microchip TC1047A analog sensor IC4 and digitized by built-in to the μC ADC. The sensor is only powered for the duration of the temperature conversion. For measuring the humidity we use Honeywell capacitance sensor C6 similarly to the previous design. The relaxation oscillator also turns on only for the time of counting its frequency by the μC built-in timer. The timer ic clocked by the μC system clock at 20 MHz, so that the entire processing of both measurement takes just a few tens of microseconds. At the remaining time the μC is put into a deep sleep mode with working SmaRTClock 16 KHz timer that provides periodic wake-ups of the system. In the sleep mode the μC draws just about 0.4 μA.


        The Varitronix LCD is driven directly by the μC. Its refreshing period is about 17 msec. Therefore, the μC wakes up from the deep sleep mode every 17 msec and most of the time just inverts the logic level of its outputs connected to the LCD. As experiments show, the LCD is pretty slow and practically no flickering is noticeable even at so low refresh rate. The LCD provides a reasonable contract by being driven at 2.8V.


        The μC code for all designs is written in assembly language and developed in Silicon Labs IDE equipped with Keil tools. Source codes and PCB files for Eagle are attached.



      • Dual Autonomous Motor - Designing a Small Electrical Car

        acracan | 07/183/2015 | 04:21 PM


        Silicon Labs provided our University design team with two free C8051F850 BLDC motor driver kits in exchange for a write-up on our project. Our team won second prize at the Electro-mobility 2015 student competition organized by Continental Iași on 8th-9th May at their location in Iași. We were then invited to showcase our project at the Euroinvent 2015 exhibition.


        The goal of the project was to come up with a design of an autonomous car that satisfied the requirements as stated in the Electro-Mobility Contest design specification document. Mainly, this implied the design of a car driven by brushless motors with the ability to drive unassisted along a specified track.




        Project Members:

        Team of students and a teaching assistant from the Faculty of Electronics, Telecommunications and Information Technology of the "Gh. Asachi" Technical University of Iași, Romania participating in the Electro-Mobility Contest 2015.


        Project description:

        The Dual Autonomous Motor design represents a wireless controlled 4 wheel drive car. The car steers by speed difference between left and right motors. A PiCamera records the car's movement and based on that information using the openCV image processing library the car can enter autonomous mode and drive itself under certain conditions (described in the contest track specification document).


        Dual Autonomous Motor 1.png


        The design can be broken down into three main parts: software, hardware and mechanical.


        Mechanical Implementation: A 4-wheel design was adopted due to stability issues of the 3 wheel design (2 front and 1 back). For better steering results an all-wheel drive solution had to be implemented.



        Fig: Final mechanical implementation


        Hardware Implementation: Industry proven solutions were preferred here, so the BLCD motors are controlled by two SiLabs C8051F850 BLDC motor driver kits. The drivers are connected to a Raspberry Pi 2 model B. Also connected to the Raspberry Pi is the PiCamera for track recognition in autonomous mode. Two Servo motors are used for adjusting the camera view angle. All the components are powered by a LiPo battery through dc-dc converters, except for the motor drivers which are connected directly. 


        original (1).png

        Fig: System model of 3-Phase BLDC Motor drive


        Software Implementation: Consists of three parts:

        • SiLabs MCU software for motor control
        • Raspberry Pi software for camera control and communication with the SiLabs MCU
        • PC software for image processing, communication with Raspberry Pi and motor control for autonomous drive, joystick controller management for manual drive

        This design can also be used for other purposes. With minimal addition to the image processing algorithms, a color object tracker can be easily implemented. Due to the video streaming feature the design can be used for access and vision in unfriendly environments. With the addition of some sensors (temperature, pressure, chemical) it can be used for collecting data from a specific environment. The design easily allows the addition of several I2C sensors.


        Materials used:

        1. Hardware tools:
        • 2 x brushless motor
        • 1V LiPo rechargeable battery
        • 3 dc-dc converters.
        • 4 wheels
        • Mechanical components (shafts, gears, bearings)
        • Raspberry Pi 2
        • USB wireless adapter
        • Raspberry Pi compatible video camera (PiCamera)
        • 2 x servo motors
        • accelerometer sensor
        • 2 x brushless motor driver kits (Silabs C8051F850)
        • generic PC Monitor
        • USB keyboard
        • USB hub
        • generic PC (ThinkPad T440p)
        • joystick controller
        1. Software tools:
        • Silicon Laboratories IDE
        • Qt5.4 & QtCreator
        • Avahi and Apple Bonjour libraries
        • openCV library
        • Raspberry Pi libraries: Gstreamer, WiringPi, pca9685
        • Both Windows and Linux OS
        • AutoCAD

        Source files:

        See attachment for detailed design description.

      • EFM8 Space Invaders Demo - Not Your Standard 8 bit MCU!

        Tabitha | 03/68/2015 | 05:15 AM


        We thought Space Invaders is a great demonstration of all the things the EFM8 microcontrollers (MCUs) can accomplish at once. Just like a real world application, the EFM8 demo device can monitor its environment, do a bunch of calculations and report its findings while retaining the fast and responsive feel of the game.


        Project Members:

        Tabi, Chris, Dewald 


        Project description:



        Space Invaders is one of the new demos for the EFM8 8-bit microcontroller products. It was created as proof of the concept that these devices could handle graphics on the 128 x 128 pixel Memory LCD display along with doing everything else. Not only did the smallest devices (BB1 and SB1 with 8 KB of flash and 512 bytes of RAM) handle it just fine, they perform really well. The game feels really responsive, even at the higher levels where the sprites are moving very quickly across the screen. A screen buffer in RAM can’t be kept and modified, since there isn’t enough memory, so everything has to be recalculated in real time each time before drawing a line on the screen.


        Here’s a quick rundown of everything the device is doing at once in this game:


        • Calculating alien sprite changes and movement across the screen
        • Calculating projectile sprite changes and trajectory
        • Calculating player sprite position
        • Detecting collisions between projectiles and player/alien sprites
        • Transmitting the calculated screen information to the Memory LCD over SPI line by line
        • Generating a PWM signal to change the color of the LED depending on the “threat level,” or how close the sprites are to the player
        • Measuring the joystick using the ADC and calculating joystick direction
        • Detecting push button presses to fire the player projectiles


        If you are a long-time gamer, you will be particularly impressed that even such a small and low cost EFM8 MCU can do all this simultaneously without any problems.


        Materials used:

        Source files:

      • EFM8 8-bit Microcontroller Oscilloscope Demo

        Tabitha | 03/68/2015 | 05:07 AM


        The purpose of this project is to demonstrate cool analog features of the EFM8 microcontrollers (MCUs). The EFM8 oscilloscope demo highlights the ADC speed and performance of the EFM8 MCUs in a clever way that also enables basic oscilloscope debugging.


        Project Members:

        Tabi, Josh and Chris


        Project description:

        A Busy Bee board was used in this demo, but it is available on any of the EFM8 starter kits. This demo uses the ADC running at up to 500 ksps and outputs the measured voltage to the 128 x 128 pixel display on the kits. Most of the kits can measure between 0 to 3.3 V using the 1.65 V internal reference with a 0.5 gain. The other kits use VDD, so they’re not as accurate and are limited to 0 to VDD. It keeps up to two screens worth of buffered data and supports single capture, triggers, and other common oscilloscope features.




        In order to demonstrate the oscilloscope, we’re using a mobile device (phone, iPad, etc.) and any standard function generator App. For example, the video demonstrates Function Generator by keuwlsoft for Android. These applications are meant for audio use and output a small tone to the headphone jack that’s ~500 mV peak to peak centered around zero. Since most of the EFM8 ADCs are single-ended, we put together a little EXP board for the kits that would add offset and bias to the mobile device output to make the signal 0 to 2.4 V.



        Figure 1. Gain and Bias Circuit



        Figure 2. Mobile Device Function Generator Output



        Figure 3. Output after the Gain and Bias Circuit


        The component values can be tuned to work with whatever kind of signal you’re working with. These were picked mostly because they are what were in the lab when the board was being built. It’s really cool to be able to debug 115200 UART traffic on one of the kits!  



        Figure 4. UART Traffic at 115200 Baud


        Materials used:

        Source files:

      • Hack-a-thon: An IoT Rube Goldberg Machine Combining Over 100 Zigbee, MCU and Sensor Devices

        GregH | 01/21/2015 | 10:23 AM



        Project Members:

        Greg, Peter, Clay, Dewitt, Terry, Jason, Preston, Rasmus, Bernt, Raymond, Charlie, Cruz, Mike, Tim



        Our goal was to experience the challenges that Silicon Labs’ customers experience and experiment with rapid prototyping and development techniques. We decided to build a Goldberg Machine that serves a beer as we can set up many different scenes to test various features of IoT devices including our microcontrollers, wireless, and sensor products. Lots of good ideas came out of our first meeting but not all of them were realized due to time constraints. We ended up spending 2.5 days to build, develop, and debug everything with 130 IoT devices.


        Project Description:

        “Ok, Google, Beer me.”

        We kicked off the first scene of the Rube Goldberg Machine by ordering a beer through Google Voice and EM357 ZigBee board. You can see the full sequence on the video but I can introduce some of the most notable projects here.


        • Poison Dart Launcher



        The RF4CE baseboard transmits audio over the air to an RF4CE receiver connected to a PC. An application on the PC listens for that audio and when it gets a full packet it should perform speech recognition to check if the audio contains “beer me”. If it does it will trigger the rocket launcher to position itself and shoot at a balloon. The balloon is setup next to a sensor so that when it is popped it triggers the sensor to set the pin on a ZigBee on/off module which then notifies that gateway it’s ready for the next scene.


        Hardware Materials:


        Software Materials:


        • Good Vibrations



        The gateway sends an MQTT message to the IBM BlueMix service, which is hosting a deployed Node-RED application. This app will route the incoming message, parse out the message string and send that string over SMS to a phone. The phone is sitting in a raised box such that when the SMS comes across it will vibrate and slide down to trigger the sensor to start the next scene.


        Hardware Materials:

        • Cell phone
        • Box
        • Spring-loaded sensor attached to a popsicle stick
        • Zigbee On/Off Module


        Software Materials:

        • Roomba Robot Water World




        The scene is activated over the ZigBee network by the ZigBee Gateway sending an HA On command to the first ZigBee node. This node is preprogrammed to set a GPIO high when it receives this command. This pin is connected to the EFM32 Starter Kit in which it triggers an interrupt. The EFM32 Starter Kit was programmed to generate a 38 kHz modulated signal that matches the Roomba IR Protocol. This signal was generated using a timer to generate the 38 kHz carrier and turning this on and off functions that were timed by another timer. With the Roomba IR interface, you could drive the robot forward, turn it sideways as well as start automated cleaning processes. In this scene we only used the FORWARD command. The IR control signal was then fed through a MOSFET to an IR diode which transmitted the signal to the Roomba.


        Right in front of the Roomba there was a plastic tub with a glass of water in it. When the Roomba moved forward and hit the tub, the glass tipped over and the water flowed into the bottom of the tub, where the resistive water sensor was placed. The voltage output of the water sensor was read using another EFM32 Giant Gecko Starter kit. If the read value was above a threshold the EFM32 would set a GPIO high that signals to the connected ZigBee node that it should send an ON command to the ZigBee Gateway.


        Hardware Materials:

        Roomba control:

        Water sensor:

        • Resistive water sensor board
        • EFM32 Giant Gecko Starter Kit
        • EM35x ZigBee node board
        • Cup with water
        • Plastic tub


        Software Materials:

        • Simplicity Studio
        • IAR Embedded Workbench for ARM


        • Space Rails and Light Pipes



        The scene is activated over the ZigBee network by the ZigBee Gateway sending an HA On command to the first ZigBee node. The first node is a ZigBee output module in series with the battery that activates the elevator carrying a steel marble up to the top of the track.  As the marble travels down the track, four ZigBee input sensors are placed around various areas of the track connected to contact sense points that are tripped by the marble.  The contact sensors trigger events within the gateway’s rule engine.


        For the start, a ZigBee output module’s PA7 is connected to a 1k ohm resistor in series to the base of a 2N2222 transistor. The transistor straddles two sides of a piece of cardboard with separate pieces of copper tape on each side.  The collector is wired to the plus side of the AA battery and the emitter is wired to the negative side of the battery.  This allows the ZigBee output module to wirelessly control the elevator.


        For the four input sensors, each ZigBee module was taped with mylar tape to the Space Rails nearby spots along the trail length.  30 gauge wire connects PA7 and GND from the module to each track rail where the wires were then secured with conductive tape.  The steel marble as it hits the two pieces of tape, effectively shorts the two contact points triggering the input sensor.  No input hysteresis / de-bounce electrical circuitry was employed so the input sensors were innovatively written to only accept one message per second to avoid flooding the gateway with redundant messages.


        Hardware Materials:

        • Space Rails, Level 2 with included ½” steel marble:

        • AA battery
        • Five ZigBee wireless modules
          • Four configured as ZigBee input sensors
          • One configured as a ZigBee output
        • Conductive copper tape
        • 30 gauge wire
        • 2N2222 NPN transistor
        • 1k ohm resistor
        • Milar non-conductive tape
        • Small piece of cardboard


        Software Materials:

        • Ember Desktop


        • Fully Automated Bartender

        In this hack, the ZigBee Node ended up serving as a simple wireless IO controller, sending On/Off signals to the EFM32GG, and relaying when the beer was dispensed.

        Due to familiarity, the EFM32 + Simplicity Studio was used for a majority of this hack. At its highest level, the code on the EFM32GG would wait for either a button press or the ZigBee HA ON signal to start a pour routine. Once this is detected, a pre-programmed state machine starts running, moving the arm to locations in 3D space that were pre-determined to successfully actuate the lever for beer pouring. Since complexity was not desired, a simple time-based state machine was used. Once the movement sequence was complete, a GPIO was toggled to signal to the ZigBee Node that the actuation had been completed.

        To make future development easier and allow for more code reuse, a PCA9685 driver and Servo wrapper library were also developed for this hack.

        Hardware Materials:


        Software Materials:




        Learn More



        There are some further improvements to be made in the future but we’re satisfied that we learned a lot about pros and cons of developing different applications with existing IoT solutions in a short time. Besides, this was a ton of fun for the team!

      • Touch Transfer: Capacitive Transfer of Digital Signals

        khsoh | 07/192/2014 | 02:09 PM

        Team Member: Kok Hong Soh


        At best, it’s a minor frustration; at worst, a multi-hour black hole draining you of time and energy. Wireless or not, transferring data from one device to another is never easy, and inefficient authentication/pairing mechanisms only add to the problem. 


        Project Mission

        : Simplify the process of exchanging information between devices.



        Through capacitive transfer of digital signals using human touch.  

        (Because nothing is easier than being able to touch a device to transfer information!)





        How it works


        The operating principle is based on the fact that voltage across a capacitor cannot change instantaneously. This principle is also used in capacitive-based digital isolator technologies (see For example, in the “Implementation Demo” image, the two copper pads form a capacitor when the people touch each end of the pad. The voltage between the two pads is initially at 0V.


        1. The voltage at UART TX copper pad jumps from 0V to 3V.
        2. The voltage at the other pad (P1.6) will also jump from 0V to 3V because of the principle mentioned above (0V – 0V = 0V to 3V – 3V = 0V). However, the voltage at this pad will not be held forever because charges can leak through the high impedance path to the ground. So the key to maintaining this voltage is in finding a way to hold this charge.
        3. When P1.6 is at 3V, it will be at a higher voltage than the negative input of the comparator. So the comparator will drive its output, P0.4, to logic high (3V).
        4. As mentioned earlier, given sufficient time, the voltage at P1.6 will begin to drop due to charge leakage. This will cause current to flow from P0.4 (3V) towards P1.6 (dropping below 3V), replenishing the charge in the capacitor and maintaining P1.6 at 3V – leading the comparator to maintain its output at the 3V level. 
        5. This means that the comparator output will follow the UART TX pad in a transition from 0V to 3V.
        6. Similarly, when the voltage at UART TX copper pad drops from 3V to 0V, P1.6 will also drop from 3V to 0V because the voltage across the capacitor cannot change instantaneously.
        7. As P1.6 voltage (0V) is below the negative input voltage of the comparator, the output, P0.4 will drive logic 0 (0V).
        8. P1.6 will stay at 0V because any rise in voltage will cause current to flow through the 2.7 MΩ resistor (P1.6 towards P0.4 (= 0V))
        9. Hence, P0.4 will follow the remote UART TX pin in a transition from 3V to 0V.
        10.  Points 5 and 9 explain how a digital signal is transferred capacitively using this circuit.
        11. The purpose of the positive feedback path (via 2.7 MΩ resistor) of the comparator is to maintain the initial transition induced by the principle of “non-instantaneous voltage change across a capacitor.”
        12. The circuit can work without the resistor as long as the digital signal at UART TX is always transitioning. However, if the UART TX pin stops transitioning, it is possible that P0.4 may eventually transition to the opposite logic level due to charge leakage at P1.6. But with the resistor, the positive feedback path allows the level at P0.4 to be held indefinitely.




        Materials Needed:


        o   2 x C8051F800DK (called DK-UART and DK-CMP)

        o   1 x 2.7 MΩ resistor

        o   1 USB cable

        o   1 PC terminal program running at 115,200 bps

        o   1  copper pad

        o   3-4 wires (3 wires needed for Demo1, and an additional wire required for Demo2)


        During these demos, Comparator 0 in DK-CMP is configured for:


        o   CP0+ input: P1.6

        o   CP0- input: VREG (1.8 V) input

        o   CP0 output to crossbar on P0.4

        o   P0.4 – push-pull output

        o   P1.6  – analog input


        Demo1: Message to Terminal


        This demo will print “Hello Silicon Labs {16-bit running hex counter}” to the terminal once per second.



        1. Solder one end of the 2.7 MΩ resistor to the P0.4 on DK-CMP.
        2. Connect a wire between P1.6 on DK-CMP to the other end of the 2.7 MΩ resistor.
        3. Connect a wire between P0.4 of DK-UART to the copper pad.
        4. Connect the GND between the two boards.
        5. Run a terminal program with USB cable connected to DK-CMP (not DK-UART) at 115,200 bps.

        The program can be downloaded in the attachment. 

        Touch one hand to the P1.6 pad of DK-CMP, and with the other hand touch the copper pad attached to DK-UART. Observe the message printing in the terminal program.


        Demo2: Blinking LED


        Demo2 will cause an LED to blink once per second. This demo uses the same firmware, but with some modifications in set-up:

           Instructions (assuming user is already set up for Demo1):

        1. In the DK-UART, move the wire connected between the P0.4 and the copper pad to connect between the P1.0 and the copper pad.
        2. In DK-CMP, add a wire to connect P0.4 to P1.0.
        3. Ensure jumper will short P1.0 to P1.0_LED on J3.

        Touch one hand to the P1.6 pad of DK-CMP, and with the other hand touch the copper pad attached to DK-UART. Observe the P1.0_LED on DK-CMP blinking in sync with the P1.0_LED on DK-UART.



        This video shows an example of Demo1 when successfully completed: 


        Future challenges/ideas:

        -        Figure out how to transfer data without sharing common ground.

        -        Experiment with battery-based operation (such as using F9xx boards instead).


        This Hack a Gecko project is a result of a “fun hacking session” and are provided as is, free of charge with no guarantees or support from Silicon Labs, to partially or fully show and demonstrate EFM32 Gecko microcontroller capabilities. Get inspired, use at own risk, and build some awesome and cool applications.” 

      • Open-source motion logger using C8051F381

        fenrir | 05/133/2014 | 11:26 PM

        Hi, all.


        I would like to introduce my project using C8051F381 USB MCU.

        This project is to make an ultra small motion logger, which records acceleration, angular speed, magnetic force, pressure, temperature, GPS position and velocity.

        Finally I have successfully built two types of loggers; NinjaScan-Light and NinjaScan-Slim, whose size are 1.0 x 1.4 inch, and 0.6 x 1.6 inch, respectively.

        If you have any interest, please visit, in which schematics and firmware of the project are published.