Projects

    Publish
     
      • Simple WGM110 programming fixture

        madsci | 10/289/2017 | 11:29 AM

        This project isn't really an end in itself, just a simple tool for working with the WGM110 Wi-Fi module, but it was suggested that I share it here, so I'm re-posting.

         

        Sometimes it's useful to be able to pre-program modules before they're installed on a board, particularly if your board doesn't have space for a SWD header.  The earliest versions of the WGM110 also had a defective DFU bootloader (stop bits were 1/2 bit time) that wouldn't work with some hosts, which made in-circuit programming difficult without SWD.

         

        To address this I made a quick and dirty programming fixture for about $15.  The components are a Mill-Max 854-22-010-40-001101 0.050" pitch 10-position pogo pin header to connect to the WGM110, a Samtec SFSD-10-28-H-05.00-SR cable with 20-pin 0.050" pitch plug for the JTAG side, some heat shrink tubing, and a 3D printed holder that I whipped up in Alibre.

         

        This is not really the right JTAG connector - its polarity key is in the wrong place and it's latching - but it's the closest thing that Digi-Key happened to have in stock that had discrete wires.  It fits on the dev board as is, and it'll fit on a P&E Cyclone's shrouded header if you snip off the key.

         

        In the orientation shown in the top view photo, the pogo pins are wired to the following JTAG pins:

         

         

        • 3 (ground)
        • (nc) 
        • 1 (VDD) 
        • 10 (Reset) 
        • (nc)
        • 2 (SWDIO)
        • 4 (SWCLK)
        • (nc)
        • (nc)
        • (nc)

         

        If I was going to be using this much I'd have machined mine from Delrin or anti-static ABS, but for only doing a few dozen units at most it didn't seem worth firing up a milling machine.

         

        Without the holder piece, I can use the pogo pin plug to re-flash modules in circuit that have been bricked by DFU failures.  This depends on having the PCB lands extend far enough beyond the periphery of the module to make contact.  If you followed the recommended layout in the datasheet, it ought to work. I wouldn't want to have to do many boards this way without an alignment jig to hold it in place, but it works fine to just hold it in place if you're just fixing an occasional mistake and not doing production quantities.

         

        Top view:

         

        2017-10-14 12.34.07.jpg

        Bottom view, with wiring to pogo pins:

        2017-10-14 12.34.19.jpg

        The STL file and original model in Alibre format are attached.  Keep in mind that I set the dimensions to make it work with my own 3D printer and the fit may require tweaking on yours.

         

        It's no substitute for a proper in-circuit programming setup for production, but it's handy for prototyping and I figured I'd share it here in case anyone else needs such a gadget.

         

        Scott

      • 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. 

         

        Overview:

         

        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.

         

        PD_Az.png

         

        Hardware

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

         

        Software

        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.

         

        Firmware

        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.

         

        image2017-7-7_13-47-56.png

         

        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.

        image2017-7-3_19-46-32.png

        image2017-7-3_19-46-47.png

         

        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.

        image2017-7-3_19-48-15.png

         

        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 GUI_Tool.zip is the stand-alone executables GUI tool which can run in the Windows PC without installing.

        https://webftp.silabs.com/download?domain=silabs.com&id=fa5a12f4f0664883923686bfa20e820f-bb25ad67690248c89887ffd5baf278b6

         

      • Building a Magnetic Alarm System for the Giant Gecko Series 1 STK

        Siliconlabs | 08/242/2017 | 05:17 AM

        This project is created by Silicon Labs’ summer intern Rikin Tanna. 

         

        Project:

         

        A magnetic alarm system uses a Hall Effect magnetic sensor and a supporting magnet attached to the door frame to determine if the door is opened or closed. This project includes a notification service that sends a message to your mobile phone when the alarm is triggered, for added security. By removing any moving parts from the system, the magnetic alarm system proves to be very reliable.

         

        spectrum-1.jpg

         

        Materials Used:

         

        EFM32 Giant Gecko GG11 Starter Kit (SLSTK3701A)

        WGM110 Wi-Fi Expansion Kit (SLEXP4320A)

        Hall Effect Magnetic Sensor (Si7210)

         

        Background:

         

        My goal with this project was to demonstrate an important use case for the Si7210 as a component of an alarm system. Given that Silicon Labs is an IOT company, I figured it would be beneficial to use IFTTT, an IOT workflow service that connects two or more internet-enabled devices, to demonstrate our GG11 STK being used with an established IOT enabler. With this service included, I could also showcase the WGM-110 Wi-Fi Expansion kit working with the GG11 STK. The GG11 STK was chosen due to its onboard Si7210 sensor, its compatibility with the WGM-110 Wi-Fi Expansion kit, and its recent launch (to expand its demo portfolio).

         

        Operation:

         

        The demo is split into 3 phases:

        1. WiFi-Setup – The first phase of the demo configures the WGM110. Here, the WGM110 boots up, sets the operating mode to client, connects to the user’s access point, and enters a low power state (Power Mode 4) to wait for further command. As it configures, status messages will display to the LCD as the GG11 receives responses from the WGM110.
        2. Calibration – The second phase of the demo calibrates the Si7210 digital output pin thresholds based on the user’s “closed door” position (magnetic field reading).
        3. Operation – The third phase is operation. Closing and opening the door (crossing the magnetic field threshold) will cause the Si7210 digital output pin to toggle, which will result in LED0 flashing. Additionally, the output pin will toggle if a second magnet is brought in to try and tamper with the alarm system. When the alarm is triggered, the GG11 will command the WGM110 to contact the IFTTT servers to send a message to the user’s mobile phone.

        Explanation:

         

        GG11 STK:

        The GG11 STK was programmed using Simplicity Studio. Simplicity provides an ample array of examples and demos to help any beginners get started with Silicon Labs MCUs (this was my first experience with SiLabs products).

         

        Below is a representation of data flow for the project. 

         

        spectrum-2.png

         

        WGM110:

         

        The WGM110 is a versatile part, as it can act as Wi-Fi client, a local access point, or a Wi-Fi Direct (Wi-Fi P2P) interface. In this system, the WGM110 acts as a client, and it is a slave to the host GG11 MCU. Communication is based on the BGAPI command-response protocol via SPI on a UART terminal. Debugging this proved to be difficult, as there are two individual MCUs involved, but the Salae Logic analyzer allowed me to view the communication between the devices to help fix any issues I encountered. Below is a capture of a typical boot correspondence.

         

        spectrum-3.png

         

        spectrum-4.png

         

        When the alarm is triggered, the WGM110 establishes a TCP connection with the IFTTT server and sends an HTTP Get request to the extension specified by the IFTTT applet I have created. Unfortunately, IFTTT allows free users to only create private applets, but creating the applet was simple: step by step instructions for creating my applet can be found in the project ReadMe file.

         

        Si7210:  

         

        The GG11 STK comes with an onboard Si7210 Hall Effect Magnetic sensor. It can detect changes in magnetic field to the hundredth of Millitesla (mT), which is more than enough sensitivity for this use case. The part has multiple OTP registers that store various part configurations, and the calibration process specified earlier writes to the register that determines the digital output threshold through I2C. The Si7210 also features a tamper threshold, in case someone tries to fool the alarm by using a second magnet to replace the original magnet as the door opens. This threshold is configured to be slightly greater than the original calibration threshold to detect even the slightest tamper. When either threshold is crossed, the part automatically toggles an OTP digital output pin, allowing any programmer to easily interface the sensor into their designs.

         

        Using this Project:

         

        This project provides a good starting point for anyone who wants to utilize the Si7210 Hall Effect sensor and/or the WGM110 Wi-Fi Expansion kit working in sync with the GG11 STK. The expansion kit can also be used with the PG1 or PG12 boards, but my code may require a few changes in initialization, depending on which specific peripherals are used. 

         

        Below is a slide that details all the various features that I utilized for each part. Feel free to download the project (link below) and use my code to get started on your own projects!

         

        spectrum-5.png.jpg

         

        Source Files: 

         

        • Magnetic alarm zip file (attached) 

         

        Other EFM32GG11 Projects: 

      • Building a Spectrum Analyzer for the Giant Gecko Series 1

        Siliconlabs | 08/241/2017 | 08:35 AM

        This project is created by Silicon Labs’ summer intern David Schwarz. 

         

        spectrum GG11.png

         

        Project:

         

        A real-time embedded spectrum analyzer with a waterfall spectrogram display. The spectrum analyzer displays the most recently captured magnitude response, and the spectrogram provides a running history of the changes in frequency content over time.

         

        Background:

         

        The original intent of this project was to demonstrate real time digital signal processing (DSP) using the Giant Gecko 11 MCU and the CMSIS DSP library. Since many use cases for real time DSP on an embedded platform pertaining to signal characterization and analysis, I decided that a spectrum analyzer would be a good demonstration.

         

        Description:

         

        The spectrum analyzer works by capturing a buffer of data from a user selected input source: either the microphone on the Giant Gecko 11 Starter Kit (STK) or the channel X input of the primary analog-to-digital converter (ADC0) on the Giant Gecko 11 device. It then obtains and displays the frequency response of that data. The display also shows a spectrogram to give the user information about how a signal is changing over time. The format used here is a ‘waterfall’ spectrogram, where the X axis represents frequency, the Y axis represents time, and the color of the pixel at that coordinate corresponds to the magnitude.

         

        Below is a video demonstration of the final project, the legend on the right shows how the spectrogram color scale relates to intensity.

         

         

        There are two parts to the video. One is for the mic input using classical music. The other is sweeping the ADC input using a function generator.

         

        Spectrogram Data flow Block Diagram (1).png

         

        The block diagram above shows the steps required to convert the incoming time domain data to visual content. Certain parts of the process demanded specific implementations in order to function in real time.

         

        I found it necessary to implement dual buffering to allow for simultaneous data capture and processing, which allowed for lower overall latency without losing sections of incoming data.

         

        The microphone data also required further processing to properly format the incoming bytes. This needed to be done post capture, as input data was obtained using direct memory access (DMA).

         

        Finally, I chose to only normalize and display 0 to 8 kHz frequency data since most common audio sources, including recorded music, don’t contain much signal energy above 8 kHz. However, to avoid harmonic aliasing, I decided to oversample at a frequency of 34133 Hz. I used this specific sampling frequency in order to give me 512 samples (one of the few buffer sizes the ARM fft function supports) in 15 milliseconds. This 15 millisecond time constraint is very important for maintaining real-time functionality, as humans are very sensitive to latency when a video source lags audio.

         

        Using This Project:

         

        This project provides a good starting point for anyone wanting to implement real time DSP on the Giant Gecko microcontroller. It can be run on an out of the box Giant Gecko Series 1 STK, or it can be configured with an analog circuit or module that generates a 0 to 5V signal as the input source. The complete source code and Simplicity Studio project files are linked below, along with inline and additional documentation that should be useful in understanding how the application works.

         

        The ADC input mode and DSP functionality of this project is also fully compatible with any Silicon Labs STK using an ARM Cortex-M4 core (eg. Wonder, Pearl, Flex, Blue, and Mighty Geckos). The microphone and color LCD, however, are not present on other STKs.

         

        Source Files:

         

        https://www.dropbox.com/s/wvuk5yk192xywfl/spectrum_analyzer.zip?dl=0

      • EFM32 Voice Recognition Project Using Giant Gecko's Temperature /Humidity Sensor

        Siliconlabs | 08/237/2017 | 08:37 AM

        This project is created by Silicon Labs’ summer intern Cole Morgan.

         

        Background and motivation:

         

        This project is a program that implements voice recognition for the Giant Gecko 11 (GG11) using the starter kit’s temperature and humidity sensor and the Wizard Gecko Module. My motivation to work on this project was mainly that I wrote another project that implemented voice recognition for the GG11 using the starter kit’s LEDs, and I wanted a more advanced application for my voice recognition algorithm.

         

        The program works by first learning your voice through a small training protocol where the user says each keyword a couple times when prompted. After it has learned the user’s voice, the user can set either a temperature or humidity threshold by saying “set” followed by either “temp” for temperature or “humid” for humidity. After this, the user can say a number from 0-99 one digit at a time to set the threshold value; for example, saying “one nine” would be interpreted as 19. For instance, saying “set humid four two” would set a humidity threshold at 42% humidity. Then, if the humidity measured by the onboard sensor crosses this threshold, the user will receive a text.

         

        Description:

         

        Using my previous voice recognition project as a base, I first added the support for multiple word commands using the first command word “set” as a kind of trigger so that the program won’t get stuck in the wrong stage of a command. One side effect of using a lot more keywords than the previous project was that I had to stop storing the reference MFCC values in Flash, as there wasn’t enough space for all of them.

         

        The next stage in my development was to interface the Si7021 temperature/humidity sensor on the GG11 starter kit. This stage was quite simple because there was already a demo for the GG11 that interacted with the Si7021, so all I had to do was integrate the LCD.

         

        Then, I interfaced the Wizard Gecko Module (WGM) to connect to IFTTT via Wi-Fi and send an HTTP GET request. This part was the most difficult of this project because I have never worked with communication over Wi-Fi or sending HTTP requests. I designed two different IFTTT triggers for temperature and humidity so that the SMS alert message could be tailored to the type of threshold trigger.

         

         

         

        Accomplishments:

         

        • I adapted my voice recognition to work accurately and quickly with a larger bank of keywords
        • I successfully created two IFTTT applets to send alerts quickly to a phone number
        • The program is written in a way that is very easily adaptable for many different uses
          • It is well modularized, so if any part of the program is useful to a specific application, it can be easily separated from the rest of the code

         

        Lessons Learned:

        • I learned how to scale an algorithm to work with a larger set of data
        • I learned how to use web requests to interface a microcontroller with applications through the Internet
        • I learned about large program organization and good general coding practice: this was the biggest software project I have written by far

         

        Potential Use Cases:

         

        • Voice-controlled Nest thermostat
        • A shipping container application where temperature or humidity in an area needs to be monitored to make sure it is at a certain level

         

        Materials Used:

         

        • GG11 STK with Si7021 and microphone
        • Pop filter for STK microphone
        • Wizard Gecko Module
        • Simplicity Studio IDE
        • CMSIS DSP Library

         

        Source Code: 

         

        • VRTempHumid (attached) 

      • EFM32 Voice Recognition Project Using Giant Gecko's LEDs

        Siliconlabs | 08/237/2017 | 08:26 AM

        This project is created by Silicon Labs’ summer intern Cole Morgan.

         

        Background and motivation:

         

        This project is a program that implements voice recognition for the GG11 using the starter kit’s onboard LEDs. My motivation to work on this project was mainly that I have never done anything remotely close to voice recognition before, and I thought it would be a good challenge. But another motivation was also that I am very interested in the Amazon Echo and the other emerging home assistant technologies.
        The program works by first learning your voice through a small training protocol where the user says each keyword a couple times when prompted. After the program has learned the user’s voice, the user can turn the LED on, red, blue, green, or off simply by saying “on”, “blue”, “red”, “green”, or “off”.

         

        Description:

         

        My first step was getting audio input from the microphone into the microcontroller and storing it. This proved a little more difficult than I expected because I hadn’t worked with SPI or I2S before. In addition to this, I also had to design a sound detection system that captures as much significant sound as possible. I did this by squaring and summing the elements of the state buffer of the bandpass FIR filter that I apply on each sample and then setting a threshold for the result of that operation. This system turned out to be extremely useful because, in addition to saving processor time, it also time-aligned the data to be processed.

         

        After this step, I began to implement the actual voice recognition. At first, I thought I could just find a library online and implement easily, but this turned out to be far from true. Most voice recognition libraries are much too big for a microcontroller, even one with a very large Flash memory of 2MB like the GG11. There was one library I found that was written for Arduino, but it didn’t work very well. So, I began the process of writing my own voice recognition algorithm.

         

        After a lot of research, I decided I would use Mel’s Frequency Cepstral Coefficients (MFCCs) as the basis for my algorithm. There are a number of other audio feature coefficients, but MFCCs seemed to be the most effective. The calculation of MFCCs is basically several signal processing techniques applied in a specific order, so I used the CMSIS ARM DSP library for those functions.

         

        After beginning work on this, I created a voice training algorithm to allow the program to learn any voice and adapt to any user. The training program has the user say each word a configurable number of times, and then calculates the MFCCs of that person’s pronunciation of the keyword and stores them in flash memory.

         

        Next, because the input data was time-aligned, I could simply put all the MFCCs for the 4 buffers in one array and use that as the basis for comparison. In addition to this, I also calculated and stored the first derivative (delta coefficients) of the MFCC data to increase accuracy.

         

        Coefficient.png

         

         

         

        Accomplishments:

         

        • I wrote my own voice recognition algorithm for microcontrollers with relatively little RAM and flash memory usage
          • Can store up to 10 keywords in Flash and up to 1,150 keywords in RAM (this number would require program modification to not store in Flash and to use less trainings)
        • Successfully created a voice recognition and training technique that works for everyone, no matter their accent or voice, with an excellent success rate
        • The program is written in a way that is very easily adaptable for many different uses
          • It is well modularized, so if any part of the program is useful to a specific application, it can be easily separated from the rest of the code

        Lessons Learned and Next Steps:

         

        • I learned how voice recognition algorithms generally work and how to implement them
        • I learned lots of signal processing, as I didn’t know anything about it before
        • I learned how to read a large library like emlib more efficiently
        • I learned about large program organization and good general coding practice: this was the biggest software project I have written by far

        My next steps are to apply the voice recognition to a temperature / humidity controller application, which should be easier than this LED application as the keywords are very different from each other unlike “on” and “off”.

         

        Materials Used:

        • GG11 STK with microphone and LEDs
        • Pop filter for STK microphone
        • Simplicity Studio IDE
        • CMSIS DSP Library

        Source Files: 

        • VRLEDs (attached) 

      • Wireless Encrypted Voice Communication with the EFM32GG11

        Siliconlabs | 08/237/2017 | 07:55 AM

        This project is created by Silicon Labs’ summer intern Kevin Black.

         

        EFM32GG11-1.jpg

         

        Project Summary:

         

        The goal of this project was to perform one-way, encrypted, real-time, wireless voice communication from an embedded system to an arbitrary client like a laptop or tablet. This was accomplished using the EFM32GG11 starter kit for audio input/processing and the Wizard Gecko Wi-Fi expansion kit for wireless transmission. Audio data is sampled from the starter kit’s onboard microphone and encrypted with AES using the GG11 32-bit MCU; it is then streamed to any clients connected to the Wizard Gecko’s Wi-Fi access point, where it can be decrypted and played back only with the correct password.

         

        Background and Motivation:

         

        My project primary purpose was to demonstrate useful features of both the EFM32GG11 starter kit and the Wizard Gecko Wi-Fi expansion kit, as well as the two working smoothly in conjunction through the EXP header.

         

        The first main feature it demonstrates is the EFM32GG11’s CRYPTO module, which exists on all the EFM32 Series 1 devices and provides fast hardware-accelerated encryption. The project utilizes the mbed TLS library configured to use the CRYPTO module, which speeds it up significantly. It demonstrates the high throughput of the CRYPTO module (up to ~123 Mbps max*) by encrypting uncompressed audio in real time with plenty of overhead. The type of encryption is 256-bit AES in CBC mode, which is currently considered universally secure.

        (*Assuming 256-bit AES on the GG11 driven by HFRCO at 72 MHz)

         

        Another motivation behind the project was to demonstrate two features of the GG11 starter kit itself: the onboard microphone, and the ability of the Wi-Fi expansion kit to easily attach to and be controlled through the EXP header. No examples existed for the microphone, and very few firmware examples existed for the Wizard Gecko in externally hosted mode. My projects demonstrate the quality of the built-in microphone by allowing the user to listen to the audio, as well as shows how to use the BGLib C library to communicate with the Wizard Gecko from an external host. Additionally, it demonstrates the throughput of a transparent/streaming endpoint on the Wizard Gecko.

         

        Project Description:

         

        EFM32GG11-2.png

         

        Block diagram of data flow through transmitter device

         

        Microphone Input:

         

        The GG11 starter kit provides an onboard audio codec that automatically converts the PDM (pulse density modulation) data from the onboard MEMS microphones into PCM (pulse code modulation) data and outputs it on a serial interface in I2S format. The codec’s serial interface is connected to the GG11 USART3 location 0 pins, so reading in the audio data is simply a matter of initializing USART3 to I2S with the correct settings, enabling autoTx, and asserting an additional microphone enable pin.

         

        The audio data arrives in 32-bit words, so the sample rate is controlled by setting the I2S baud rate to 64 times the desired sample rate (2 channels, 32 bits each). Each word contains a single 20-bit sample of audio, but very few systems support 20-bit audio, so for my project, I ignore the least significant 4 bits of each sample and only read 16 bits from each word. I also ignore samples from the right microphone, meaning the final audio data I obtain for processing is in 16-bit mono PCM format. The sample rate is easily configurable, but in the end, I settled on 20 KHz as that seems to be the upper limit of what the Wizard Gecko can handle while being high enough to cover the range of human hearing and provide clear and understandable audio.

         

        The audio input data is transferred into memory using LDMA in order to save CPU cycles. The right channel data is repeatedly written to a single byte in order to discard it, while the left channel data is alternately transferred into two 16-byte buffers; when one buffer is being filled, the other is being processed by the CPU.

         

        Encryption & Transmission:

         

        When a left channel transfer completes, it triggers an interrupt that switches the current process buffer and signals that the next packet is ready to be processed. The GG11 then encrypts the current 16-byte buffer (16 bytes is the AES block size) using the mbed TLS library configured to use the CRYPTO module. In CBC (cipher block chaining) mode, the library automatically XORs the plaintext with the previous ciphertext before encryption.

         

        The 256-bit key used for encryption is derived from a password using SHA-256. Only clients with the same password can obtain the correct key by hashing the password.

         

        In my project, I decided to fix the initialization vector as all zeros. Normally, initialization vector reuse is considered bad practice and weak security; however, it only has the potential to leak data from the first few blocks of data streams with identical prefixes, and that poses an insignificant threat to my project due to the enormous quantity of blocks and the amount of noise in a meaningful segment of audio.

         

        Once a block is encrypted, it is put into a first-in-first-out queue where it is transmitted over UART through the EXP header to the Wizard Gecko. Flow control is implemented using an additional CTS (clear to send) pin connected to the Wizard Gecko; the module can drive CTS high when it cannot keep up with the transmission rate, in which case the transmission halts and the queue fills up. The transmission is driven by interrupts, which allows it to run “in the background” while the next buffer is being encrypted, and does not block the main thread when the Wizard Gecko raises CTS.

         

        The baud rate for UART transmission is configurable as long as the GG11 and the Wizard Gecko are both configured to the same value. Interestingly, however, the Wizard Gecko seemed to perform better (raise CTS for less time) at higher baud rates— perhaps because that increases the gap between packets— so I settled on 3 MHz.

         

        Wi-Fi:

         

        The Wizard Gecko Wi-Fi module, when connected to an external MCU in hosted mode, operates in a command-response format. The GG11 sends commands through the EXP header via SPI, formatted with a binary protocol called BGAPI. When the Wizard Gecko is ready to send a response (or an event) back to the MCU, it raises a notify pin (also connected to the EXP header) that tells the GG11 to read and handle the message. All of the BGAPI commands and responses are defined in a C library called BGLib.

         

        Upon initialization, my project configures the Wizard Gecko to be a hidden wireless access point and a TCP server. When a client connected to the access point opens a connection to the IP address and port of the TCP server, it triggers an event that is forwarded back to the GG11. The GG11 then enables the microphone and begins encrypting and transmitting audio via UART to the Wizard Gecko’s second USART interface (the one not used for BGAPI commands). That interface is configured in transparent/streaming mode, which means it forwards all received data unmodified to a single endpoint. Before the encryption starts, the GG11 configures this endpoint to be that of the connected client.

         

        Accomplishments, Flaws, and Next Steps:

         

        Ultimately, the project was successful and met its end goal of building a one-way encrypted voice communication device. Speech is clear and comprehensible at up to several inches away from the onboard microphone, and the real-time encryption is secure.

         

        The primary flaw in the final implementation is that the Wizard Gecko itself has trouble constantly streaming a large quantity of data without interruptions. The module will occasionally “choke” for 1-2 seconds, during which it will stop transmitting and refuse to accept data by raising CTS. Performance is inconsistent, and the device will go anywhere from 10 to more than 60 seconds in between “chokes”. This causes frustrating gaps in the audio, much like a cell phone connection that is “breaking up”; although on average, the project is still quite usable for talking to someone. I added a blue LED that turns on whenever CTS is raised, so the user can at least tell when the device is not transmitting by observing the LED light up solid blue.

         

        In the future, this behavior could likely be eliminated by changing the protocol that the device uses to transmit. Bluetooth would have much more bandwidth, or if the Wizard Gecko is still used, Wi-Fi Direct or a TCP connection over a third-party local area network (rather than using the Wizard Gecko as the access point). The last two options would make the demo much more difficult to use, so Bluetooth would be the ideal solution; this explains why Bluetooth has become so popular for real-life products with similar functionality.

         

        Using this Project:

         

        Follow the instructions in the readme of the encrypted voice transmitter folder to configure the Wizard Gecko and GG11 to act as the transmitter portion of the project.

         

        To use the receiver, download the executable Java applet below and run the .exe file inside (no JVM installation required). Unless the IP address and port were changed in the firmware, leave those fields blank. Enter the password defined in the firmware (default “gecko123”).

         

        After booting up the transmitter, wait for the LCD output to reach “waiting for client”, and then connect to the hidden access point that the device has created (default SSID is “Encrypted Voice Demo”).

         

        EFM32GG11-3.png

         

        Once the LCD displays “client joined”, click “Connect” on the Java applet’s dialog. When the status message below the connect button displays “Connected” in green, audio from the microphone should begin playing back on the PC.

         

        EFM32GG11-4.jpg.png

         

        Source Files: 

         https://www.dropbox.com/s/1uofaidpdz061ti/encrypted-voice-master.zip?dl=0

         

        [zip file containing encrypted_voice_transmitter (firmware source code)]
        [zip file containing executable Java applet]

        [zip file containing encrypted_voice_receiver (Java source code)]

         

         

      • Project Completed and Working a Treat (TB Sense and Pi)

        neal_tommy | 08/232/2017 | 12:20 PM

        All, 

         

        Whilst I've received much assistance from this community I thought it time I give back and feedback on my working project (thanks all who helped along the way). 

         

        Essentially I have a TB Sense connected up via BLE to a RPi3. I did some changing to the code on the TB Sense to make it continuously advertise and then have a Python script on the Pi to collect data once every 10 minutes. 

         

        This data is fed to Thingspeak (considering alternative options here) and graphed for viewing. I'm still in the phase of looking at some daily / weekly averages and seeing what changes it would make to general lifestyle. I'm collecting data from 6 enviromental sensors (sound, temp., humidity, pressure, TVOC and eCO2). 

         

        Board holder

        Board holder

         

        Overall 3D printed enclosure (enough to let some air in for measurement)

        Enclosure

         

        I've also got a cool 3D printed enclosure made which houses the TB Sense in a nice looking (and acceptable by the wife) designed box whilst on the table top. The Pi is sitting next to my router collecting the data. 

         

        So far I've collected a couple of days of data as shown below. It all seems to be working and is ready for a powercut and suitable reboot / reconnect if that happens (common here in South Africa). 

         

        Capture.JPG

         

        Happy to answer any questions on this, and share details. It is by no means a complex project however did keep me busy for a few weekends. There are still some areas I'd like to improve and then work from there (probably on the efficiency of the Python code). 

         

        Ciao. 

         

        from __future__ import division
        import sys
        from bluepy.btle import *
        import struct
        import thread
        from time import sleep
        import urllib2
        
        PRIVATE_KEY = 'H4HMW1TRAGNYUPBJ'
        
        # Base URL of Thingspeak
        baseURL = 'https://api.thingspeak.com/update?api_key='
        
        
        def vReadSENSE():
            scanner = Scanner(0)
            devices = scanner.scan(2)
            for dev in devices:
                print "Device %s (%s), RSSI=%d dB" % (dev.addr, dev.addrType, dev.rssi)
        
                for (adtype, desc, value) in dev.getScanData():
                    print "  %s = %s" % (desc, value)
            num_ble = len(devices)
            print num_ble
            if num_ble == 0:
                return None
            ble_service = []
            char_sensor = 0
            non_sensor = 0
            TVOC_char = Characteristic
            eCO2_char = Characteristic
            Pressure_char = Characteristic
            Sound_char = Characteristic
            temperature_char = Characteristic
            humidity_char = Characteristic
        
            #bat_char = Characteristic
            
            count = 15
        
            for i in range(num_ble):
                try:
                    devices[i].getScanData()
                    ble_service.append(Peripheral())
                    ble_service[char_sensor].connect('00:0b:57:36:63:ff',devices[i].addrType)
                    #ble_service[char_sensor].connect(devices[i].addr, devices[i].addrType)
                    char_sensor = char_sensor + 1
                    print "Connected %s device with addr %s " % (char_sensor, devices[i].addr)
                except:
                    non_sensor = non_sensor + 1
            try:
                for i in range(char_sensor):
        
                    services = ble_service[i].getServices()
                    characteristics = ble_service[i].getCharacteristics()
                    for k in characteristics:
                        print k
                        if k.uuid == "efd658ae-c401-ef33-76e7-91b00019103b":
                            print "eCO2 Level"
                            TVOC_char = k
                        if k.uuid == "efd658ae-c402-ef33-76e7-91b00019103b":
                            print "TVOC Level"
                            TVOC_char = k
                        if k.uuid == "00002a6d-0000-1000-8000-00805f9b34fb":
                            print "Pressure Level"
                            Pressure_char = k
                        if k.uuid == "c8546913-bf02-45eb-8dde-9f8754f4a32e":
                            print "Sound Level"
                            Sound_char = k
                        if k.uuid == "00002a6e-0000-1000-8000-00805f9b34fb":
                            print "Temperature"
                            temperature_char = k
                        if k.uuid == "00002a6f-0000-1000-8000-00805f9b34fb":
                            print "Humidity"
                            humidity_char = k
        
                        #if k.uuid == "2a19":
                            #print "Battery Level"
                            #bat_char = k
        
            except:
                return None
            while True:
                # units of ppb
                TVOC_data = TVOC_char.read()
                TVOC_data_value = ord(TVOC_data/100)
        
                #units of ppm
                eCO2_data = eCO2_char.read()
                eCO2_data_value = ord(eCO2_data[0])
        
                # pressure is in units of 0.1Pa
                Pressure_data = Pressure_char.read()
                Pressure_data_value = (Pressure_data * 10)
        
                # units of 0.01dB
                Sound_data = Sound_char.read()
                Sound_data_value = (Sound_data * 100)
        
                #bat_data = bat_char.read()
                #bat_data_value = ord(bat_data[0])
        
                #convert from farenheit
                temperature_data = temperature_char.read()
                temperature_data_value = (ord(temperature_data[1]) << 8) + ord(temperature_data[0])
                float_temperature_data_value = (temperature_data_value / 100)
        
                humidity_data = humidity_char.read()
        	humidity_data_value =(ord(humidity_data[1])<<8)+ord(humidity_data[0])
        
        	print "TVOC: ", TVOC_data_value
        	print “eCO2: ", eCO2_data_value
        	print “Pressure: ", Pressure_data_value
        	print “Sound: ", Sound_data_value
        	print “Temperature: “, float_temperature_data_value
        	print “Humidity: “, humidity_data_value
        
        	if count > 14:
        
                	f = urllib.urlopen(baseURL + PRIVATE_KEY + "&field1=%s&field2=%s&field3=%s&field4=%s&field5=%s&field6=%s" % (TVOC_data_value, eCO2_data_value, Pressure_data_value, Sound_data_value, float_temperature_data_value, humidity_data_value))
                	print f.read()
                	f.close()
                	count = 0
                	count = count + 1
                	sleep(1)
        
        while True:
            vReadSENSE()

      • Setting BLE characteristic values – a Thunderboard Sense practical approach

        m_dobrea | 07/191/2017 | 02:45 AM

             Few months ago, I received a Thunderboard Sense kit from Silicon Labs Company. Analyzing the market for applications capable of working with this device, I noticed the existence of many applications capable of running on operating systems such as iOS, Android or Linux. But, I have not found a professional application, developed in Windows, able to work with this device. As a result, I decide to develop one - BLE SensorTags application.

             Right now, the BLE (Bluetooth Low Energy) SensorTag application – BlessTags (BLE SensorTags) can work with 2 different sensor tags from Silicon Labs Company: Thunderboard React and Thunderboard Sense.

             The BlessTags (BLE SensorTags) application has the following functionalities:

        1. To set, communicate, use and display (in graphic and numerical form) the information from all the sensors included on the SensorTags presented above. The supported sensor’s characteristics are:
          • For ThunderBoard React: accelerometer, orientation, temperature, humidity, light (ambient & UV), keys and output LEDs. 
          • For ThunderBoard Sense: accelerometer, orientation, barometer, temperature, humidity, air quality (CO2 & TVOC), light (ambient & UV), sound level, keys and output LEDs (2 x low power LEDs & 4 x power LEDs).
        2. In the developer mode the software provides the user with lots of messages obtained from the communication process with a specific SensorTag - these messages enable the user to identify the communication/configuration setbacks and some other problems.
        3. The software also gives the possibility to interrogate different types of unknown BLE devices - to be able to obtain the complete GATT attribute table for the unknown BLE device. At this link is presented the entire procedure used by me to obtain the complete GATT table for Thunderboard Sense and in the end a pdf file containing all the obtained results.
        4. To obtain and tune the optimal Kalman filter parameters;
        5. ... and the most exciting features: the gadgets. The gadgets are several practical applications that use one or more sensors from the SensorTag to achieve a concrete, fully functional and useful application. For instance, using the two buttons placed on Thunderboard React or Thunderboard Sense, these SensorTags are turning into wireless presenters for PowerPoint.

             For the development of the application I used: (a) intensively the documentation provided by Microsoft and (b) the source code (BluetoothLowEnergy.cpp) developed by Donald Ness and publicly offered at this address: https://gist.github.com/programmarchy/c9d02e22d58bfab3f8bb.

             The following code sequence, developed entirely by me, will complete the program provided by Mr. Donald Ness. With this code addition, we will not only be able to read data from the descriptors of a characteristic, but we will be able also to write characteristic values - in this way we can influence the state of the SensorTag.

             To exemplify the concepts of writing to a characteristic of a sensor, I will customize the code to be presented for the Profile User Interface service; service with the UUID: FCB89C40-C600-59F3-7DC3-5ECE444A401B. All the characteristics of this service (Profile User Interface service) are presented in the figure below. We, in this presentation, will focus only on the 0xC603 characteristic – UUID: FCB89C40-C603-59F3-7DC3-5ECE444A401B. This characteristic allow us to control the intensity and the color of the high brightness RGB LEDs placed on the SensorTag.

         

        Serviciu_C600.jpg

         

             In order to work correctly, the code below must be inserted after the code sequence from the Step 3, presented in ConnectBLEDevice() function, from the BluetoothLowEnergy.cpp file.  At this point and for the 0xC600 service pCharBuffer is a buffer with 4 elements. Each element stores a data structure related with one of the each of the 4 characteristics presented in the table above (UUID1: FCB89C40-C601-59F3-7DC3-5ECE444A401B, UUID2: FCB89C40-C602-59F3-7DC3-5ECE444A401B, UUID3: FCB89C40-C603-59F3-7DC3-5ECE444A401B and UUID4: FCB89C40-C604-59F3-7DC3-5ECE444A401B).

         

        PBTH_LE_GATT_CHARACTERISTIC pCharBuffer   = NULL;
        PBTH_LE_GATT_CHARACTERISTIC currGattCharTB;
        
        ……..
        
        if (pCharBuffer == NULL)	//step A				
        	{
        	free(pServiceBuffer);	pServiceBuffer = NULL; 		//free the service buffer
        	CloseHandle (hLEDevice); 				//close the BLE device handle
        	return -4;
        	}
        
        if (numChars > 4)		//step B				
        	{				//error we have more than 4 characteristics
        	free (pCharBuffer);	pCharBuffer = NULL; 		//free the characteristics buffer
        	free (pServiceBuffer); 	pServiceBuffer = NULL;		//free the service buffer
        	CloseHandle (hLEDevice); 				//close the BLE device handle
        	return -5;
        	}	
        
        //Get the specific characteristic from where the high brightness RGB LEDs can be controlled.
        //Here only the first 48 bits were checked - FCB89C40-C603-59F3-7DC3-5ECE444A401B – in
        //   order to identify this specific characteristic.
        currGattCharTB = NULL;		//step C
        for (i = 0; i< numChars; i++)
        	if (pCharBuffer[i].CharacteristicUuid.IsShortUuid == 0)
        		if (pCharBuffer[i].CharacteristicUuid.Value.LongUuid.Data1 == 0xFCB89C40 &&
        		     pCharBuffer[i].CharacteristicUuid.Value.LongUuid.Data2 == 0xC603)
        		    {
        currGattCharTB = &pCharBuffer[i]; break; } if (currGattCharTB == NULL) //step D { // if no such characteristic can be found: free all the data structures and return free (pCharBuffer); pCharBuffer = NULL; free(pServiceBuffer); pServiceBuffer = NULL; CloseHandle (hLEDevice); return -6; } typedef union //step E { BTH_LE_GATT_CHARACTERISTIC_VALUE newValue; struct { ULONG DataSize; UCHAR Data[4]; } myValue; } rezolvare; //step F rezolvare newValue_base; RtlZeroMemory(&newValue_base.newValue, ( sizeof(rezolvare) )); //step G //fill the structure with the required data newValue_base.newValue.DataSize = sizeof (UCHAR)*4; newValue_base.myValue.Data[0] = comLED; //which LEDs will be on newValue_base.myValue.Data[1] = valR; //red level [0, 255] newValue_base.myValue.Data[2] = valG; //green level [0, 255] newValue_base.myValue.Data[3] = valB; //blue level [0, 255] //step H hr = BluetoothGATTSetCharacteristicValue( hLEDevice, currGattCharTB, &newValue_base.newValue, 0, BLUETOOTH_GATT_FLAG_NONE); //step I if (S_OK != hr) { if (dbgMode) { InsertTextBoxLine (panelHandleDbg, PANEL_Dbg_TEXTBOX, -1, "Error at: BluetoothGATTSetDescriptorValue - impossible to set the I/O lines (LEDs) !"); HRESULTtoErrTxt (hr, buffErr); sprintf (buffDeAfisat, " - %s", buffErr); InsertTextBoxLine (panelHandleDbg, PANEL_Dbg_TEXTBOX, -1, buffDeAfisat); } free (pCharBuffer); pCharBuffer = NULL; free (pServiceBuffer); pServiceBuffer = NULL; CloseHandle (hLEDevice); return -4; } //step J //all is OK now and release all resources previously used free (pCharBuffer); pCharBuffer = NULL; free (pServiceBuffer); pServiceBuffer = NULL; CloseHandle (hLEDevice);

             The first 2 “if” instances (steps A and B) check the correctness of the service data in accordance with our previous knowledge related to this service. If everything is correct, we go to identifying the specific characteristic capable to influences the state of the LEDs – step C, this is done in the “for” loop.

             In D step, the software check if this specific characteristic (0xC603) was found. If this last test is passed, now we can dispatch data to the SensorTag via BluetoothGATTSetCharacteristicValue function - step H. But to do this a new data structure is defined, step E, a new variable (of this data specific type) is declared and initialized with 0, on the step F, and, in the end, the variable is initialized with the required data – step G.

             Analyzing steps E, F, G and H, one could say that a simpler approach can be easily found.  Yes, it is true, but this approach is perfectly functional for a compiler that would support a development in C++ (like Visual Studio). The BlessTags application has been fully developed in LabVindows/CVI, which has a compiler that only supports ANSI C. And for this compiler this was the only functional solution found up to now.

             Going further, if errors occur in the SensorTag communication process, they are treated in step I. At the end, all data structures used are released, step J.

             For the correct operation of the previous code, make sure the device is powered from the USB port, otherwise the RGB LEDS will be disabled by the Thunderboard Sense to conserve the power from the coin cell battery.

             And now a video to show BlessTags main functions:

         

         

             This application, BlessTags (BLE SensorTags) application, can be downloaded from the Windows Store Apps: https://www.microsoft.com/store/apps/9p054xsjjr1n. For more information, demo, practical applications, examples etc. please visit the following blog: https://ble-sensortag.blogspot.ro.

         

      • Sensor node network with Thunderboard Sense and MicroPython

        ThomasFK | 04/92/2017 | 04:04 PM

        I am a member of NUTS, the NTNU Student Test Satellite. The main goal is to create a CubeSat, a tiny satellite that piggybacks on the launch of a larger satellite.

         

        Another goal of NUTS is trying to promote aerospace/STEM topics among other students. Last fall we participated in "Researchers Night" at NTNU, which is used to promote STEM education among high school students. A lot of institutes and organizations show up at Researchers Night with really flashy displays, such as flamethrowers or slightly violent chemical reactions.

         

        At our disposal we had a vacuum chamber, a DC-motor, space-grade and regular solar panels, and several Thunderboard Senses. Showing off how marshmallows behave in vacuum, and how the DC motor behaves when connected to the different solar panels might be interesting enough in and of itself. However we decided to add some Thunderboards to spice it up a bit.

        Using a budding implementation of MicroPython for Thunderboard Sense (which will be released soon), we brainstormed and programmed a small sensor network for our stand, simulating logging telemetry data from our satellite. The Thunderboards were utilized as follows:

        • Glued to the DC motor, transmitting gyroscope data from the IMU.
        • Inside the vacuum chamber transmitting pressure.
        • Transmitting the light-level with the light-sensor.
        • Sampling the sound-level with the microphone.
        • A master that could tune into transmissions from either of the other Thunderboards, logging the output to screen and also showing how much the slave deviated from "normal" status by using the  RGB LEDs.

        I have embedded two video. The first one gives a short overview over the entire project, while the second shows the setup in action, logging data from the vacuum chamber.

         

        Our stand was a great success! Robot Very Happy We got several people standing around for up to half an hour discussing intricacies of satellite development as well as giving us an opportunity to talk more about the satellite radio link.

         

        At last I want to brag a bit about how neat this code turned out with MicroPython, and how MicroPython really was ideal for bringing up a project like this in such a short time.  The code for reading data from the IMU and transmitting it ended under 40 LOC.

        from tbsense import *
        from radio import *
        from math import sqrt
        
        rdio = Rail()
        i = IMU(gyro_scale = IMU.GYRO_SCALE_2000DPS, gyro_bw = IMU.GYRO_BW_12100HZ)
        
        def float_to_pkt(flt):
            integer = int(flt)
            decimal = round(flt, 3) - integer
            decimal = int(decimal*1000)
            ret = bytearray(6)
            ret[0] = (integer >> 24) & 0xFF
            ret[1] = (integer >> 16) & 0xFF
            ret[2] = (integer >> 8)  & 0xFF
            ret[3] = integer & 0xFF
            ret[4] = (decimal >> 8) & 0xFF
            ret[5] = decimal & 0xFF
            return ret
        
        def loop():
            meas = i.gyro_measurement()
            meas = sqrt((meas[0]**2)+(meas[1]**2)+(meas[2]**2))
            pkt = float_to_pkt(meas)
            rdio.tx(pkt)
            delay(200)
            
        def init():
            rdio.init()
            rdio.channel(MODE_IMU)
            i.init()
        
        delay(2000)
        init()
        while True:
            loop()