In past few years, the IoT industry has aggressively expanded its scope towards 2.4GHz-based protocols such as Bluetooth, Wi-Fi, and Zigbee. These protocols have their pros and cons but there is one common denominator; they are not controlled by teleoperators and their interests. Companies could implement the IoT systems quite flexibly the way they wanted, and the interoperability was mostly managed by the protocol alliances such as the Bluetooth SiG, guaranteeing the interoperability between different vendors. But protocol compliance testing is just a minor part of the total cost of ownership for an IoT device. How do you manage CE, FCC, and other country regulations? It is quite straightforward to manage global regulatory certifications for a single device, but what if your product portfolio includes tens of devices you are selling around the world?

When considerable products in a company’s product mix starts to have IoT functions, they begin to realize that discrete design regulatory certification management becomes a burden, and the need for affordable, small, high-quality and pre-certified modules rapidly increases.

Number of Standards-Based IoT Devices is Exploding 
There are thousands and thousands of applications currently enabled by the standards-based IoT protocols, which are expanding rapidly. It will soon be nearly impossible to find electronic devices that are not somehow IoT enabled – nearly everything is about to become connected, as the integration costs are reasonable. The result is a large number of companies are not used to hiring and maintaining electronic/RF engineers or protocol experts. These companies are also joining the IoT revolution en masse, where in the past they were developing products that are not generally considered technology products.

Construction equipment suppliers, agricultures devices, and home automation companies are a few examples. These kinds of companies have been mainly focusing on mechanics or quite simple electronic functions. Advanced RF engineering for IoT functionality is not in their core know-how. The relevant question is, how can these companies efficiently - and with reasonable investments - transform their products in the IoT era and meet the compatibility requirements?  These companies need something easy to implement and manage. The very good solution for these companies is to consider new system-in-package (SiP) modules to meet the perfect balance of time to market, pre-certification, size, and cost.

Growing Number of IoT Ecosystems
Companies are forming up ecosystems around their IoT enabled devices, and they are inviting partners and subcontractors to join. These ecosystem builders are in front of the interoperability challenge – do the devices work seamlessly together with best possible performance? How do you make sure the devices in the ecosystem fulfills the end-user expectations? A good example of these ecosystems is building automation systems – connected lighting, whitegoods, etc. How do these companies ensure the journey to IoT Ecosystem and success?

A very good candidate to solve this issue is a pre-certified SiP module quarantining the flexible designs, interoperability, performance, right cost, easy product management and fast time-to-market.

Why the System in Package (SiP) Modules are Beneficial for Ecosystem Development?

SiP is a term for advanced semiconductor packaging where an IC is assembled together with passives into the substrate. The look and feel of the SiP IoT module are just like an IC/SoC, but unlike the IC the SiP module integrates all functionality needed for IoT operation in the same size and scale as an SoC. In other words, the SiP modules are completely integrated, certified systems ready for IoT functionality.

What makes the Silicon Labs SiP modules so feasible for IoT ecosystem creation? A proper high-performance RF design is not trivial, nor easy to implement and manage in a way that ensures radio good performance, which is the key into robust functionality. The RF design burden is taken away when designers use a completely integrated SiP module. The SiP allows flexible placement of the module into any electronics device with small footprint. The compact size has benefit as it allows the rest of the device to be flexibly engineered.

Why Are SiP Modules So Convenient?
The patent pending antenna of our SiP modules is in the substrate, and it is engineered the in a way that makes it possible to gain 70% antenna efficiency. Another great benefit of our SiP modules is that they do not easily detune off from the band. And if it does, it is easy to fix it by simple means without time-consuming RF engineering methods. This impressive 70% antenna efficiency is hard to beat, even by seasoned RF engineer designing the system from discrete components with significant amount of time and testing budget. The SiP modules have achieved high performance and small size on a scale no longer easily achievable by discrete designs.

The ecosystems utilizing such precisely engineered SiP modules will have significant advantages in compatibility, RF range, robustness, time-to-market and pre-certification.

It is crucial to have a good wireless range from the IoT device to make sure the RF link is robust. Even in short distances an RF design is only as good as the amount of interference it can tolerate and still achieve fast data rates and lower power consumption. Another great benefit of the SiP module for the ecosystem is its full protocol certifications such as FCC and CE. This means the end-user of the module inherits certifications from Silicon Labs and avoids RF or protocol testing completely. It is our responsibility to make sure our products comply, leaving the IoT developer free from compliance worries and regular re-certifications to meet the ever-evolving RF regulations.

What’s New With Silicon Labs SiP Modules?
Silicon Labs just released its most advanced SiP module, the BGM13S. The module is empowered with BG13 DIE, having state of the art Bluetooth 5.0 Low Energy and Bluetooth Mesh including long range Coded phy. The module has 512Kb memory capable of doing over the air updates. Its several power TX variants offer line-of-sight range even up to 700 meters. This is an extremely good figure considering the module’s size of only 6.5 x 6.5mm, including antenna that uses customer PCB as part of the antenna structure. This very advanced design of the SiP makes it possible for and OEM to optimize the RF range without any RF engineering. We also have been improving the manufacturability of this module by using popular 0.5 soldering pitch. The more relaxed soldering pitch makes it possible to manufacture the devices even in lowest cost contract manufacturers.
 

Learn more about Silicon Labs SiP modules
Bluetooth 5.0 and Bluetooth Mesh: BGM13S  (Available now, 2018)
Zigbee: MGM13S (Available now, 2018)
Bluetooth 4.0 BGM11S, BGM121, BGM123 (Available since November 2016)
 

An important aspect of any IoT device is how secure the device is when it communicates with other devices, gateways or the cloud. It is common for developers to secure communications such as TCP/IP connections, Bluetooth or Zigbee. However, if a microcontroller sends sensitive information over a simple interface such as a UART to another microcontroller, it is important to realize that data should also be secured to prevent someone from snooping the UART line.

Silicon Labs offers a hardware CRYPTO module that provides an efficient acceleration of common cryptographic operations and allows these to be used efficiently with low CPU overhead. In addition to the CRYPTO module, Silicon Labs also provides a mbed TLS library to integrate with mbed TLS to allow it to take advantage of the CRYPTO module acceleration.

To use mbed TLS in a Micrium OS based application, first the developer must understand how the mbed TLS library will be used in the application. By default, mbed TLS is intended to be used in a single threaded/bare metal application or used in only a single thread of an RTOS application. For a Micrium OS application, this means if there will only be one task calling mbed TLS functions then no special modifications to the config file are necessary. If mbed TLS will be called from multiple tasks, for example a Bluetooth project that has a UART to communicate to another microcontroller, then a few modifications need to be made to the mbed TLS config header.

The following instructions will show you how to enable thread protection in mbed TLS for a Micrium OS Blink project on the Giant Gecko Series 1 (SLSTK3701A). If you have any difficulty getting the project set up, a .sls file is attached to this post for you to download. If you need further information on the SiLabs’ mbed TLS library, refer to Application Node AN0955.

Open Simplicity Studio and with your GG11 plugged in, select the board under debug adapters and then expand the Software Examples. Select the SLSTK3701A_micriumos_blink project and jump to the Simplicity IDE. 

First, mbed TLS must be added to the project as its not already included. You can either download mbed TLS from https://tls.mbed.org or you can grab a copy from your install of Simplicity Studio from: Simplicity Studio install location -> Eclipse -> developer -> sdks -> gecko_sdk_suite -> v2.4 -> util -> third_party -> mbedtls. Place those files into the workspace folder for the SLSTK3701A_micriumos_blink.

Once you have mbed TLS added to the project, you need to add the SiLabs library for mbed TLS to the workspace for SLSTK3701A_micriumos_blink. Under the Simplicity Studio install you can copy the sl_crypto folder and config folder from here: Eclipse -> developer -> sdks -> gecko_sdk_suite -> v2.4 -> util -> third_party -> mbedtls.

After adding the folders to the workspace similar to the image above, include paths need to be added to the project. Under the project properties, go to C/C++ Build -> Settings -> GNU ARM C Compiler -> Includes. 

Paths need to be added for the config directory, include directory and the sl_crypto directory. After adding those paths, remain in the project settings and go to Symbols under GNU ARM C Compiler.

At this point, mbed TLS has been added to the project, but it is only set to run in its default configuration. This means it won’t take advantage of the CRYPTO module acceleration and it won’t work from multiple threads. To fix that, add a new symbol that contains the following: MBEDTLS_CONFIG_FILE="config-sl-crypto-all-acceleration.h" then click OK. This will tell all mbed TLS files to look at the new config file, rather than the default config.h file.

Open up the config-sl-crypto-all-acceleration.h under the config directory. This is the default config file for enabling all hardware accelerations supported by SiLabs’ mbed TLS library. Add the following code to the header file to enable threading and remove a requirement for network sockets (unless you plan to use them). This code must be placed directly below the #include “mbedtls/config.h”.

/* Include the default mbed TLS config file */
#include "mbedtls/config.h"

/* Add Micrium OS support */
#define MBEDTLS_THREADING_ALT
#define MBEDTLS_THREADING_C
#define MBEDTLS_MICRIUM
#undef MBEDTLS_NET_C

#undef MBEDTLS_TIMING_C

Finally, the last piece to enable Micrium OS support in mbed TLS is to initialize threading support before starting Micrium OS. In the file ex_main.c, place the following code in main() anytime after the OSInit() call and before OSStart(). This will initialize the necessary mutexes to provide the protection.

// Enable Micrium OS support
#if defined ( MBEDTLS_THREADING_C )
    THREADING_setup();
#endif

At this point, after the OSStart() call completes and multitasking has begun, any mbed TLS call can be made safely from any task in Micrium OS.

The objective of this blog is to show you the steps necessary to use an existing Micrium OS USBD example and add CDC-ACM class and demo using the EFM32GG11.

Baseline Project

Since the Gecko SDK currently ships with a ‘micriumos_usbdhidmouse’ project for the SLSTK3701A_EFM32GG11 board, we can make a copy of it and rename it ‘micriumos_usbdcdcacm’. The convenience of making a copy of the project is to modify it according to our needs without breaking the Gecko SDK default projects.

Start by locating the ‘micriumos_usbdhidmouse’ folder in your Simplicity Studio installation. The project location is at ‘C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\mcu_example\SLSTK3701A_EFM32GG11’

Once you found the folder, make a copy of it and rename it ‘micriumos_usbdcdcacm’. Please make sure to keep the new folder at the same path location of the original.

Locate the ‘SLSTK3701A_micriumos_usbdhidmouse.slsproj’  file inside your New Folder  ‘micriumos_usbdcdcacm\SimplicityStudio’ and rename it ‘SLSTK3701A_micriumos_usbdcdcacm.slsproj’ 

We will be adding our new workspace, so launch Simplicity Studio and connect the SLSTK3701A_EFM32GG11 board to the PC.

Add workspace by right-clicking anywhere inside the Project Explorer box and Select Import > MCU Project

 

Use the Browse button to locate the ‘SLSTK3701A_micriumos_usbdcdcacm.slsproj’ and click Next>

File location: 'C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_usbdcdcacm\SimplicityStudio'

 

Since you already have your board connected, it should all be auto-detected. Leave everything by default making sure that there is an SDK selected, then click Next>

 

You can either change the name of the project or keep the default, then click Finish.

 

Configuration Files

 We will now need to modify the project configuration files in order to include Micrium OS USBD CDC-ACM class as part of our build.

Start by expanding the Includes section in the Project Explorer panel, then expand the configuration folder as shown in the image below. After that, double-click on the rtos_configuration.h to open it in the editor.

 

As soon as you try to edit the rtos_description.h, you will be presented a Warning indicating you are editing an SDK file. Click on Edit in SDK.

Add the following #define in rtos_description.h to indicate Micrium OS that you want to use CDC ACM class.

#define  RTOS_MODULE_USB_DEV_ACM_AVAIL
#define  RTOS_MODULE_USB_DEV_CDC_AVAIL

Remove the following #define in rtos_decription.h

#define  RTOS_MODULE_USB_DEV_HID_AVAIL

 

Tell Micrium OS you want to use the USBD CDC-ACM demo by modifying ex_description.h. Expand the Includes section in the Project Explorer panel, then expand the project folder as shown in the image below. After that, double-click on the ex_description.h to open it in the editor.

As soon as you try to edit the ex_description.h, you will be presented a Warning indicating you are editing an SDK file. Click on Edit in SDK.

Remove the following #define in ex_decription.h

#define  RTOS_MODULE_USB_DEV_HID_AVAIL

Add the following #define in ex_description.h to indicate Micrium OS that you want to use CDC-ACM class.

#define  RTOS_MODULE_USB_DEV_ACM_AVAIL

 

Adding USBD Class and Demo

Expand the src section in the Project Explorer panel and remove the ‘ex_usbd_hid_mouse.c’ linked file.

 

Select Import > MCU Project by right-clicking on src section as shown on image below

 

Choose ‘More Import Options…’  and select File System  on the next window that pops-up as shown on the images below

 

Use Browse button and add ‘ex_usbd_cdc_acm_terminal.c’ example as shown on image below, and click Finish.

File location: `C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\micrium_os_example\usb\device\all`

 

Expand the usb>source>device>class section in the Project Explorer  panel and right-click on class. Select Import > MCU Project  and add the USBD CDC ACM class file as shown on images below

 

Use the Browse button to locate the CDC-ACM files to be added as shown below.

File location: `C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\platform\micrium_os\usb\source\device\class`

 

Running the Example

You can now build your application and flash it on the board. Once the application starts running, you should see LED0 on the board blinking which means all the initialization was done correctly; therefore, we can now test the USBD CDC-ACM demo.

Open Windows Device Manager and expand the 'Ports (COM & LPT)' section. 

Use a Micro-USB B cable to connect the PC to the EFM32GG11 board. As soon as you connect it, Windows will enumerate the device and display it in 'Ports (COM & LPT)' as shown in the image below. Keep in mind that Windows is the one assigning the port number (COM7)  to my device.

 

Once you know the serial port number, we can use any serial terminal application and  open a terminal window.  The images below shows the terminal configurations and the CDC-ACM demo output.

 

If you work with Micrium OS, chances are you will eventually encounter some macro prefixed with RTOS_ASSERT which traps your task in an infinite loop.  Micrium OS has two types of ASSERTs, Critical ASSERTs and Debugging ASSERTs. The former type of ASSERT is intended to catch severe errors which may prevent the system from functioning normally such as a module failing to initialize correctly. On the other hand, Debugging ASSERTs are used to catch ordinary errors returned from an API call so that they are found quickly while debugging. However, the question naturally arises: should my system crash because I passed a bad delay value to OSTimeDly?

 

There are a few options to customize how these conditions are handled in your system.

1. You can disable debugging ASSERTs, which will also disable error checking. This is recommended once the project is stable and ready for production.

2. You can force the ASSERTs to return a value, with some caveats.

In order to make these changes, you must modify this section of rtos_cfg.h.

 

Option 1 requires changing the MASK to RTOS_CFG_MODULE_NONE.

Option 2 requires modifying the DBG macro so that it returns the error value.

However, you must be careful not to use any ASSERT_DBG() macros at the top level of your task; you may unintentionally return from the task if you do so.

 

For more details on ASSERTs, please refer to the following pages:

https://doc.micrium.com/display/OSUM50500/Micrium+OS+Asserts+Programming+Guide

https://doc.micrium.com/display/OSUM50500/RTOS+Compile-Time+Configuration

 

Background

The Micrium OS Examples in Simplicity Studio are very easy to access: You connect your Starter Kit and Simplicity Studio will display the list of examples as shown below:

 

For more information on how to access the Micrium OS Examples from Simplicity Studio you can see this document:

https://www.silabs.com/documents/public/training/wireless/micrium-os-examples.pdf

 

 

Revealing the 57 Hidden Gems

In this blog, I’m going to show you how to access the additional Micrium OS Examples that are not available from Simplicity Studio's Launcher Perspective.

There are 57 examples that demonstrate how to initialize the Micrium OS modules to perform the most basic operations:

Micrium OS Module		Example
CANopen		CANopen Module Initialization Example
		CANopen Node Start Example
		CANopen Object Dictionary Read/Write Example
File System		File System Module Initialization Example
		File Read/Write Example
		File Read/Write with Posix API Example
		File Multi-Descriptors Example
		Entry Path Example
		Block Device Read/Write Example
		Media Polling Example
Network	FTP Client	Send Data from a buffer to a file on an FTP Server
		Upload a file to an FTP Server
		Receive a file into a buffer
		Download a file from an FTP server
	HTTP Client	HTTP Client Initialization Example
		HTTP Client GET Request Examples
		HTTP Client POST Request Examples
		HTTP Client PUT Request Examples
		HTTP Client Persistent Connection Examples
		HTTP Client Multi-connection Examples
	HTTP Server	HTTP Server Initialization Example
		Simple Server That Uses No File System
		Basic Server That Uses the HTTP Static File System
		Basic Server That Uses Micrium OS File System
		Server That Handles REST Requests
		Server That Handles Webpages, REST Requests and Authentication Support
		Basic Secure Server That Uses SSL-TLS and the HTTP Static File System
	IPerf	IPerf Initialization Example
	MQTT Client	MQTT Client Initialization Example
		MQTT Client Connect Example
		MQTT Client Publish Example
		MQTT Client Subscribe Example
		MQTT Client Echo Example
	Network Core	Network Module(s) Initialization Example
		Network Core Initialization Example
		Start Network Interface(s) Example
	SMTP Client	SMTP Client Initialization Example
		SMTP Client Send Email Example
	SNTP Client	SNTP Client Initialization Example
		Basic SNTP Current Time Retrieve
	Telnet Server	Telnet Server Initialization Example
		Telnet Server Instance Example
	TFTP Client	Download and Upload a File to a TFTP Server
USB Device	Audio Class	USB Device Audio Class Loopback Example
	CDC ACM Class	USB Device CDC ACM Class Terminal Example
	CDC EEM Class	USB Device CDC EEM Class Example
	USB Device Core	USB Device Core Initialization Example
	HID Class	USB Device HID Class Mouse Example
	MSC Class	USB Device MSC Class Ramdisk LUN Example
		USB Device MSC Class Ramdisk Shared Example
	Vendor Class	USB Device Vendor Class Loopback Example
USB Host	Android Accessory Class	USB Host Android Accessory Class Example
	CDC ACM Class	USB Host CDC ACM Class Example
	USB Host Core	USB Host Module Simple Initialization Example
		Simple Device Port Operation Example
	MSC Class	USB Host MSC Class Example
	USB-to-Serial Class	USB Host USB-to-Serial Class Example
Table 1. The Hidden Micrium OS Examples

 

 

How to run the hidden Micrium OS Examples

The process of including, configuring and initializing the examples is the same for all the examples and can be summarized as follows:

Start off with one of the examples available through Simplicity Studio by connecting your Kit and selecting an Example from the list as illustrated in Figure 1.

If the example project does not have the Micrium OS module files, then you need to include them by inserting in your project the folder located at ${StudioSdkPath}/platform/micrium_os/[module]/include and ${StudioSdkPath}/platform/micrium_os/[module]/source/[module] and configuring your compiler's include paths with the new paths.

Locate the header file rtos_description.h and insert the macro necessary to enable the module. For the full list of macros see this document.

Make sure you have in your project all the configuration files located in STUDIO_SDK_LOC\platform\micrium_os\cfg

Explore the examples listed in Table 1, select the one that you want and follow the corresponding hyperlink.

       The hyperlink will take you to the example's documentation which provides four things:

• Description: Brief description of the example
• Configuration: The name of the #define that needs to be defined in ex_description.h
• Location: The location of the files that need to be included
• API: The API that needs to be called from your application to start the example

Locate the header file ex_description.h and define the corresponding macro if necessary as described in the example's documentation section: Configuration.

Include in your Simplicity Studio project the required files as listed in the example's documentation section: Location. In this step you can either create a link to the original folder or make a copy of the files and place them in your own workspace directory.

Configure your compiler's include paths with the new paths where the header files are located.

Insert a #include in your application, of the header file where the API to start the example is declared and call the API from your application to get the example started as described in the example's documentation section: API.

 

 

Example

To illustrate the process, I'm going to provide an example where one is interested in running an HTTP server:

Connect the SLSTK3701A and select the example SLSTK3701A_micriumos_net from Simplicity Studio.

Inspect which modules are included in the project by looking at the folder net in the Project Explorer. There you will notice that the module HTTP Server is missing.

Include the HTTP Server module by creating a new Linked Folder located at STUDIO_SDK_LOC\platform\micrium_os\net\source\http\server

Open the new folder Properties and either include or exclude the folder from compilation as necessary from the section C/C++ Build.

Open the Project Properties and insert the location to the new header files ${StudioSdkPath}/app/micrium_os_example/net/http/server in the section C/C++ General -> Paths and Symbols

Locate and open the header file rtos_description.h and insert the following line to enable the new HTTP Server Module: #define  RTOS_MODULE_NET_HTTP_SERVER_AVAIL

Copy the configuration files from STUDIO_SDK_LOC\platform\micrium_os\cfg to your own workspace directory and make sure the compiler is aware of this include path.

Look at Table 1, locate the Example Basic Server That Uses the HTTP Static File System and explore the documentation.

Open the header file ex_description.h and insert the following line to enable the example: #define  EX_HTTP_SERVER_INIT_AVAIL

Create a new Folder named Examples and then create a Linked Folder in it that points to STUDIO_SDK_LOC\app\micrium_os_example\net\http\server

Open the Project Properties and insert the path ${StudioSdkPath}/app/micrium_os_example/net in the section C/C++ General -> Paths and Symbols

Open the file ex_main.c and insert the following line at the top: #include  "http/server/ex_http_server.h"

From the same file ex_main.c, locate the calls to the functions Ex_NetworkInit() and Ex_Net_CoreStartIF() and insert right after them, a call the following API to get the example started: Ex_HTTP_Server_InstanceCreateStaticFS();

 

 

 

Date: Tuesday, December 11, 2018
Time: 10:00 AM Central European Time
Duration: 1 hour

 

Applications receiving Power over Ethernet (PoE) often face the dilemma of maintaining power budgets while meeting the demands to develop full-featured solutions.  With higher power classifications becoming more frequent at the end device, Silicon Labs delivers a set of PoE Powered Devices (PD) solutions to optimize BOM solution cost, efficiency, and performance while reducing development time.

In this technical webinar, we discuss how Silicon Labs’ PD controllers meet ever increasing power demands and demonstrate our evaluation kits’ drop-in ready designs.

 

The following blog explains a simple way of detecting task stack overflows while debugging your Micrium OS application.

Micrium OS Kernel Red Zone

The kernel's red zone is a feature that, when enabled through OS_CFG_TASK_STK_REDZONE_EN in os_cfg.h creates a monitored zone at the end of a task's stack. The length of the red zone is user-configurable via the #define OS_CFG_TASK_STK_REDZONE_DEPTH in os_cfg.h. By default, this is set to 8 stack elements (CPU_STK). 

When the red zone is enabled, every time a task is switched out, either at the task level or at the interrupt level, the kernel checks if the red zone has been hit. By default, a software exception is thrown with the use of the CPU_SW_EXCEPTION macro in the ARMv7m port. However, if you want more control over what your application should do in the event that the red zone is hit, you can turn on the application hooks by setting OS_CFG_APP_HOOKS_EN to DEF_ENABLED in os_cfg.h.

Using the Red Zone Application Hook

If you decided that you want your application to determine what to do in the event that a task hits the red zone instead of throwing a software exception, then you will have to define a hook function to do so.

A simple example:

static  void  RedzoneHitHook (OS_TCB  *p_tcb)
{
	BSP_LedSet(0);
	while(1);
}

 

With that, you can tell that if you see LED0 permanently on and with your code trapped at the while loop you have hit the red zone. You can then check p_tcp->NamePtr in your local variables panel and find what was the task that hit the limit.

Don't forget to assign the red zone hit hook pointer to your custom function. Using the example above:

OS_AppRedzoneHitHookPtr = RedzoneHitHook;

 

Make sure that this is added prior to calling OSStart() otherwise the pointer is never assigned to your application hook.

For more details about detecting stack overflows and the red zone, visit the following link: https://www.micrium.com/detecting-stack-overflows-part-2-of-2/

Watch our interview with the team lead, Corey Hulse

The next generation of designers and developers must be forward-thinking to build smart, connected, energy-friendly products. The University of Texas at Austin’s Solar Vehicles Team (UTSVT) is a group of passionate students, applying engineering concepts to bring us closer to practical solar-powered alternatives. We sat down with Corey Hulse, the electrical team leader, to discuss the team’s achievements, the importance of their mission, and their biggest development concerns.

Every year, the team participates in the American Solar Challenge, which includes two races: the Formula Sun Grand Prix and world championship race. The goal of the competition is to prove the viability of sustainable systems by showing sustainable energy sources used in unexpected, new ways. The first race at the Circuit of the Americas hosts teams from all over the country, as well as Canada and Puerto Rico. After three days of racing, eight hours a day, the vehicle with the most laps accumulated wins.

Above all else, Hulse said, “We just want to show the idea that there are new discoveries to be made in renewable energy and it is a viable power source for the future.”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Design Challenges:

Safety is a top concern for the UT team. The team works with extremely high voltage battery packs, so they require reliable protection systems to detect any shorts or temperature issues. If high temperatures were not reported and caused a battery to ignite, the entire battery pack could catch fire, engulfing the entire vehicle. The battery pack uses Silicon Labs’ temperature sensors to carefully monitor temperature levels, and there are also temperature sensors in the array itself. According to Hulse, the team receives “feedback on what areas of the array might not be performing at their best due to temperature problems,” and can then adjust for improvements. 

Using Silicon Labs’ galvanic isolation products, the team isolates their grounds to protect against shorts that may carry over into different systems. Due to the many different voltage levels, if one were to escape into another it would destroy whole parts of the vehicle. The isolators also help to improve signal quality.  Multiple power levels introduce noise that affects every system since they run parallel to each other. The galvanic isolators clean up the signal lines and ensure that important information is being communicated.

The design team also considers the driver interface and diagnostic platform to gain a complete picture of the car’s performance during the race. The ergonomics team works with Silicon Labs’ Gecko 32-bit microcontrollers to build out the team’s dashboard and design the driver interface. Hulse explains this choice, stating “They have a lot of LCD screens that display various information about how well your battery pack is doing, how well your car is performing, and if there are any safety dangers that you need to be aware of.”

Sensors gather information, including: the speed of the car, GPS coordinates, power usage, and temperature of each battery. This information is not stored in the vehicle, it’s sent to the pit crew during the race. The UT Solar Vehicles Team relies on Silicon Labs’ Zigbee technology to attain necessary information to understand the car’s performance and diagnose safety issues. The team selected Zigbee because its range was able to cover the entire track and its bandwidth was large enough to collect all the information onto a remote server for viewing.

Overall, students from many different disciplines from manufacturing to meteorology to business come together to help make the most efficient solar car design possible. Though the process is very involved, the students tackle problems with enthusiasm, excited to gain hands-on engineering experience and to have a positive impact on the world.

 

Development Experience:

There are a lot of factors to consider when designing a solar car, especially for a student-driven team with a limited budget. The UT Solar Vehicle team prioritized excellent performance, power efficiency, and quick support from the company provider. Silicon Labs checked all their boxes. Our applications team responded quickly and answered all their questions, which was very helpful for undergraduates trying to overcome a large learning curve. Hulse described the support, saying “They really seemed like they wanted to answer any questions we had and make sure that our project got completed.”

 

 

Future Endeavors:

The UT students involved are extremely motivated and ready for any challenge, including designing and building a completely new vehicle from scratch. Teams typically build new cars every 2-4 years. The UT team’s previous car, TexSun, cost around $140,000 and the one they’re currently building is budgeted at $180,000. The current car, BeVolt, cleverly named after the university’s mascot, Bevo, should be ready to race this summer. The team is determined to take this opportunity to make significant improvements in speed, battery life, and maintainability.

We’re proud to support UTSVT and look forward to seeing all that they accomplish in the future. To learn more about the UT Solar Vehicles Team and how you can support their work, watch our interview with Corey Hulse, team lead and former stand-out summer intern:

Last week, Armis Security published the discovery of two new vulnerabilities named BLEEDINGBIT. The first (CVE-2018-16986) is a classical buffer-overflow attack that allows an adversary to run arbitrary code on the BLE device. Once this occurs, the BLE device can be used to attack other devices in the system.

The other vulnerability (CVE-2018-7080) is related to an over-the-air upgradability feature, which appears to be specific to the affected TI devices and end products using this feature.

Both vulnerabilities are present in the Bluetooth stack software from TI, and the company already issued BLEEDINGBIT patches for the software vulnerabilities earlier this year. Texas Instruments appears to be following security best practice protocols as effectively as possible to ensure effective remediation of the situation.

Silicon Labs uses the affected TI BLE devices (CC2540 and CC2541) in our BLE112, BLE113, BLE121LR modules, and the BLED112 USB dongle.

Yet the Silicon Labs modules and dongle using the affected TI chips do not utilize the TI software stacks, which is where the vulnerabilities reside. Silicon Labs uses are our own proprietary stack for these devices. Silicon Labs has verified that our proprietary software stacks using the affected TI BLE chips are not vulnerable to the BLEEDINGBIT vulnerabilities.

For completeness, Silicon Labs Blue Gecko Bluetooth devices and modules using our Bluetooth SDK are not vulnerable to these exploits.

In 2017, the Bluetooth SIG added mesh networking capability to Bluetooth. An established, trusted technology, Bluetooth mesh demonstrates global interoperability and is well-suited for consumer lighting and home automation applications—think large-scale systems in which tens to hundreds of devices need to reliably and securely communicate. In addition to industrial applications, mesh shows strong signs of growth in many markets, including smart building, and smart home.

 

Bluetooth Mesh by the Numbers:

 

Meeting the Bluetooth SIG's Mesh Specifications 

The Bluetooth SIG released their mesh networking specifications in 2017 in order to set the fundamental requirements of an interoperable many to many (m:m) mesh networking solution for Bluetooth Low Energy (LE) wireless technology. Any mesh networking solution, model, or device must meet these specifications in order to be fully compliant with the SIG’s standards. 

Not only are Silicon Labs’ Bluetooth mesh solutions fully certified by the Bluetooth SIG, we are the only company that has performed Bluetooth mesh performance testing and published the results. When we compared the performance of mesh networking standards between Thread, Zigbee, and Bluetooth mesh, we found that Bluetooth mesh works best when short messages (<=11B) are used, especially for multicast messages. 

 

Silicon Labs Bluetooth Mesh Solutions: Setting the Example, Right out of the Gate 

Though any Bluetooth low-energy hardware can be used for a Bluetooth mesh implementation, Silicon Labs’ EFR32BG13 Blue Gecko SoCs, as well as BG13MP and BGM13S Blue Gecko Bluetooth® Module feature several advantages: 

• High transmit power, which means good RF performance
• A temperature range of over 125 Celcius, a key consideration for LED bulb design
• At 64 k ram and 512 flash, an ideal memory profile for Bluetooth mesh applications

Silicon Labs is also the leading producer of Bluetooth mesh hardware and software with low power nodes (LPN). Low power is a critical feature for battery-powered energy harvesting devices such as sensors and switches. 

Because Silicon Labs was the first to market with Bluetooth mesh, we have most mature software with the most features for developers. Those dev tools include: 

1. The Simplicity Studio™ Network Analyzer. No other company makes a network debugger tool like this one. Customers tell us it provides the easiest way that they’ve found to see and squash bugs. Learn more in this quick this video tutorial. 
2. With the Blue Gecko Bluetooth Low Energy Wireless SoC Starter Kit, you can quickly build test networks and visualize energy usage and optimization.  
3. Support for Android and iOS in the form of an app dev kit (ADK), with an example app and source code included. 

One of our Bluetooth experts, Mikko Savolainen, explains the benefits and features of Bluetooth mesh in this video:

For more information, visit the Bluetooth Mesh Learning Center.