Skip navigation

Safe and Sound

14 Posts authored by: ipv1 Top Member



A few months ago, Element14 and Texas Instruments Challenged us to create a wearable with the MSP432 with the theme of keeping us safe. I proposed to create a wearable jacket that could relay important information and sensor data from the cloud or station to the wearable and vice-versa. My initial proposal and plan are available at Safe & Sound - Safety Jacket for the Tolling Industry #1: Introduction to Project

My initial design had a Raspberry Pi at the data sink however as I started work with the parts, my understanding of their capabilities evolved and the design with it. This is the best part of a design challenge allowing us to explore possibilities while gaining new skills.



My final design submission consists of a functional jacket that has the MSP432 running multiple tasks which allows for future expansion in functionality and a singular BLE connection for communication which reduces the complexity and power consumed. The wearable display accompanying the design is self sustaining via solar power harvesting while Qi Charging and a removable power source adds a novelty feature to the project.




All the code, STL files for the 3D printed Enclosures along with a few tutorials are available on GitHub and Pinshape free of cost for download. We are thankful to Texas Instruments and Element 14 for this opportunity and their support.

A sequence of blogs is available at Safe and Sound Blogs for the Companion Jacket.


The Design and Build

The final design is shown below which consists of four modules. The fourth module is a CC2640 based LED module which was added last minute to add a visual indication.


The essential part of this build is the MSP432 Launchpad which is the hero of this design. It runs TI-RTOS which manages the tasks for everything including communications and sensors. I initially tested out the TI-RTOS capabilities which are documented at Safe & Sound - Safety Jacket for the Tolling Industry #3: TI RTOS and POSIX with the CC1310 Launchpad

Since the CC1310 cannot be used in my country due to frequency restrictions, I decided to use BLE for all the communication needs. The CC2650 was employed for this purpose and a detailed explanation of the BLE code and modifications is presented at Safe & Sound - The Companion IoT Jacket #10: MSP432, BLE and 3D Printing module one

I elected to go for a Fuel Tank Booster Pack for power and designed an enclousre that would expose the headers in an appropriate manner.


The sensors need to be separated and were enclosed in a badge like case that is mounted to the front of the jacket.


The connection between the two modules is accomplished via an I2C bus with just four wires traversing the inside of the jacket. My better half was responsible for the cutting and sewing and attaching everything to their rightful place. The exposed headers as seen in the image above allow for an external power pack to be connected.


The second part is the flip display which allows the wearer to get a quick glimpse of the status of the electronics. The Sharp96 display coupled with the MSP430G microcontroller on a custom PCB make for a low power component that consumes around 300uAmps at 1.8V . A working explaination of the code is presented at Safe & Sound - Safety Jacket for the Tolling Industry #7: Cloud CCS and Sample Code Issues  and Safe & Sound - The Companion IoT Jacket #11: An Energy Harvesting Display


The power to the display is supplied from a SuperCapacitor managed by the BQ25570EVM enclosed in a custom box and mounted at the back of the jacket. The discharge rate was monitored and was found low enough to power the display for a few minutes even in complete darkness.


The code for the communications is a custom TLV protocol over Serial which is based on the tutorials at Safe & Sound - Safety Jacket for the Tolling Industry #5: Writing your own protocol  and Safe & Sound - Safety Jacket for the Tolling Industry #6: Writing your own protocol - part 2

The construction of the Qi Power Pack is explained at Safe & Sound - The Companion IoT Jacket #12: Qi Charging with Element14, Texas Instruments and Wurth Electronics  which consists of a TI and Element14 Fuel Tank Booster Pack and TI and Wurth Electronics Wireless Power Kit.



The four module is the BLE LED which is enclosed in a 3D printed badge like box.



The Demonstration

The final project is presented at Safe & Sound - The Companion IoT Jacket #13: The Wearable Demonstration and the long demonstration video is presented below. There are so many tit-bits to this project that the video is around 30 minutes long.


I go through each module, its construction and enclosure and finally demonstrate the jacket in action.



This project took up a life of its own when all the bits and pieces started to work. My biggest accomplishment here is that all the parts being used are Texas Instruments from the MSP432 ARM controller to the MSP430 low power controller all the way from the CC2650 and CC2640 BLE controllers and BQ25570 Energy Harvesting Module and even the bq24210 Li-ion charger and bq27510 Fuel Gauge and also the bq50021a from the wireless charger. Sticking to this theme took a little more thought process and the result is an all TI project.

I am slightly disappointed that I was unable to get the GUI to work and that is partly due to the last two week of health related diversions and partly due to my inability to write mobile applications. The code I presented does work though and can be extended to work with protocols such as MQTT, AMPQ and the like.


This is an exhausting project as creating a wearable is not the same as other projects. I have learned a lot from this experience and am working to learn a bit about java for future work. I hope my tutorials and project can help someone out there. Once again our thanks to Texas Instruments and element14 for their support.





All posts in Series


Here is the progress so far

Safe & Sound - Safety Jacket for the Tolling Industry #1: Introduction to ProjectSafe & Sound - Safety Jacket for the Tolling Industry #2: Filling up the space with CC110L Tutorial
Safe & Sound - Safety Jacket for the Tolling Industry #3: TI RTOS and POSIX with the CC1310 LaunchpadSafe & Sound - Safety Jacket for the Tolling Industry #4: Unboxing and a relaunchpad
Safe & Sound - Safety Jacket for the Tolling Industry #5: Writing your own protocolSafe & Sound - Safety Jacket for the Tolling Industry #6: Writing your own protocol - part 2
Safe & Sound - Safety Jacket for the Tolling Industry #7: Cloud CCS and Sample Code IssuesSafe & Sound - Safety Jacket for the Tolling Industry #8: Energy Harvesting
Safe & Sound - Safety Jacket for the Tolling Industry #9: Keeping the Launchpads SafeSafe & Sound - The Companion IoT Jacket #10: MSP432, BLE and 3D Printing module one
Safe & Sound - The Companion IoT Jacket #11: An Energy Harvesting DisplaySafe & Sound - The Companion IoT Jacket #12: Qi Charging with Element14, Texas Instruments and Wurth Electronics


In this post, I present the final wearable and submission. It is important to package the contents into an ergonomic wearable and make it serviceable. The final challenge is to create something presentable and usable.


The Complete Design Review


The four modules were segregated for design reuse and I designed and printed all enclosure using Fusion 360 and a Cel Robox. The idea is to create a wearable meant for safety and one that uses all Texas Instruments parts. The MSP432 is the hero of our design and runs TI-RTOS and a number of tasks for all the functions. BLE communication is handled by the TI CC2650 which reduces the BOM and power consumption. The BQ25570EVM is used in conjunction with a solar panel and a SuperCap to power an MSP430 and Sharp96 Booster Pack from TI. Information is relayed via serial communications to provide a visual indication of status and data display. The Qi Charging Power Pack is designed around the E14 and TI Fuel Tank Booster Pack and WE and TI Wireless Charging Kit to provide power to the main components.


All the above components are mounted in a jacket as explained in the proceeding sections.


One More TI Part

Since we are using BLE and it's a wearable, I decided to put in one more part. I had a CC2640 LED module from a previous challenge and design an enclosure around it. It is powered from another Fuel Tank adhering to my policy of using all TI parts.


This module adds another layer of visual indications that can work directly with the BLE app.


The Wearable Electronics

Creating an ergonomic wearable was a challenge that was taken up by my better half. Using ribbons, thread, and other accessories, she assembled all the parts into the final wearable.


{gallery} My Gallery Title


Appearance: Adding ribbons to the enclosure to make it blend in with the jacket


Exposing Headers: Exposing the headers to be able to connect with the power pack


Sensors Badge: Adding the sensors booster Pack so as to use the IR Temp sensor.


Concealed Cabled: Hiding the cables is a task on its own.


Cable Cleanup: All the cables run the underside in a concealedmanner.





Display : The display is embedded on the front.


Exposed Headers: The headers are first exposed and then stitched in place to provide a clean place to dock the Power Pack


The Final Product

My better half has done an excellent job in creating the final product.



The solar panel sits comfortably at the back exposed to light sources and the Sensors Booster Badge is mounted on the front along with the LCD. The LED light is converted into the badge with it's power source in the adjacent pocket. All the wiring is hidden inside going towards the Core module which is in the left pocket. The exposed headers under the jacket allow for mouting of the power pack with ease.

The Video Demonstration

A picture is worth a thousand words and in this case, I needed lots to explain the functioning.


The GitHub Repo and PinShapes

I promised a code upload and to download the code please visit

The 3D models can be downloaded from



I managed to stick to my original plan and created a working Wearable with all TI parts. I am happy with the result and though I am not an Android Programmer, I have started the process of working with Java. The project works and can be expanded depending upon requirement. The intent was to be able to have two way communication and the proof of concept is presented thought the software part is still a bit rough. Hopefully this is an incentive for me to work on other skills.

This is in continuation from my previous post at Safe & Sound - The Companion IoT Jacket #11: An Energy Harvesting Display


In this post, I add a Power Pack based on the Element14 and Texas Instruments Fuel Tank Booster Pack and the Wireless Charging Kit from Texas Instruments and Wurth Electronics.




The Third Module: Qi Power Pack

The last piece of my design is the power pack for the Sensors and Communications Core.


The Fuel Tank booster pack has the ability to manage the Li-Ion battery and provide regulated 5.0V, 3.3V along with battery gauging. Let's take a look at the design process.


a. Testing Charging

The first step in making the power pack is to see if the wireless charger works with the Fuel Tank. The jumpers on the Qi receiver were configured to provide 5V and connected to the Fuel Tank. The test setup is as follows.


Success. The systems can work but the next issue is to be able to connect it with the sensors core.


b. Connections

As discussed before, the headers were left exposed in the enclosure for the Sensors and Communications Core and can mate with the booster pack.


This eliminates the need for cables to connect the two.


c. Enclosure

The final enclosure follows suite with the rest of the enclosures and is design to be press fit.


The headers are exposed and designed to mate with the Core module.

d. The software

The code for the Fuel Gauge is similar to what was done at [Firecracker Analyzer] Wireless sensor Node part II & Setting up a solar Fuel Booster Pack A dedicated task talks to the Fuel Tank Booster Pack and gets relevant information. This information is relayed to a battery service notification service via BTLE and the display via UART


The code will be made available on GitHub with the link provided in the final blog post.



The Qi Charging Booster Pack adds a layer of simplicity to the entire design. The pack can be charged wirelessly and connected simply by plugging it into the Core module.

The last challenge is to put humpty dumpty together and present the final wearable.

This is in continuation from my previous post at Safe & Sound - The Companion IoT Jacket #10: MSP432, BLE and 3D Printing module one


In this post, I add an energy harvesting LCD display to my wearable design and add some basic test results and an enclosure.


The Second Module: An Energy Harvesting Display

In order for the wearable to have a user interface, the Sharp96 Booster Pack was selected. The 96px x 96px real-estate is enough to present relevant information in a compact and efficient manner. Since mounting the entire MSP432 launchpad together seemed to defeat ergonomics, I elected to use my DIY MSP430 econopad. To add to the uniqueness of the design, the BS25570EVM was employed with a solar panel and a 0.1F super capacitor to power the display part of the design. The diagram below shows the second module as it plays out in the final design.




Let us take a look at each of the above modules one by one.


a. The Econopad and MSP430 TLV code

I have explained the MSP430 Econopad in TI Econo Launchpad for DIY People  and Safe & Sound - Safety Jacket for the Tolling Industry #4: Unboxing and a relaunchpad


The Sharp 96 Boosterpack mounts atop the DIY PCB which has an MSP430G2553 micro controller. The firmware for the device uses existing Sharp96 drivers combined with a TLV like protocol as explained in the previous post at Safe & Sound - Safety Jacket for the Tolling Industry #6: Writing your own protocol - part 2


The controller only receives information via UART at 9600bps which have 4 characters transmitted simultaneously. Delays in between characters is treated as a timeout and results in a reset of the state machine. The first character indicates the data type and the next three characters are the data. The following characters are used:


T- Temperature






The alerts are predefined messages stored in the controller and invoked to display messages on the screen. The Battery percentage is displayed in the form of a progress bar. The serial communication happens via interrupts and the main routine waits for a complete and valid frame to arrive. The entire screen is refreshed even if a single value is changed and hence it is the task of the MSP432 to send data only when required.


b. Communications

The uart on the MSP432 is used by the CC2650 driver hence the backchannel uart is brought into play. Every task sends data to the display to update the data. e.g. The temperature task send temperature data overtime there is a relevant change. A dedicated task is used to get messages over BLE and send commands for the messages and alerts.


The MSP432 does not receive any data from the display as this would cause unnecessary delays in the routines. Communications are reconfigured to 9600bps instead of the default 115200bps.


c. Energy Harvesting Investigation

I investigated the use of the BQ25570EVM in a previous blog post at Safe & Sound - Safety Jacket for the Tolling Industry #8: Energy Harvesting


Further analysis confirmed that the MSP430 and the Sharp96 Booster pack only draw 330uAmps of current at 1.8V which means that the system can operate on the harvested energy. The internal buck converter comes preconfigured to provide 1.8V and the jumpers were set so that the internal high efficiency buck converter would keep operating until the supercap was discharged to 1.8V. This adds a longer lifetime to the display which is only usable in well lit areas.






The graph above shows the discharge of the superCap over time with a 25 Second per division.


When the solar panel is exposed to ambient light inside a room, the charge rate is greater than or equal to the discharge rate.


This brings us to the conclusion that the small sized solar panel is sufficinent considering the high efficiency BQ25570.


d. The Enclosure

Making this part wearable was a bit of a challenge since hanging a solar panel on a jacket would be non-ergonomic. A thin box was created with exact dimensions to fit the EVM as well as the SuperCap. The result is shown below. The box has space to attach straps and be mounted onthe jacket.








This modules is a reusable segment and is designed separately. This modular approach allows for reusability of the design and can be adopted to other projects. The code will be available on GitHub for download along with the rest of the project.


I am happy that I was able to incorporate the EVM directly into my design and in the next part I take a look at the power supply for the main module.

With the last week upon us, its time to complete this project and hence the home stretch. In this post, I am going to start by explaining the mutation of my design, the change in design and then the first module in detail. This is one of four blog posts that will explain my implementation, demonstrate the project and finally summarise the work done. I initially planned to schedule these posts due to health issues, however, the extension in deadline has caused a change in that plan and I will be checking in for the comments.



The Design Evolution


My initial intention was to create a safety jacket for industrial workers, however as my understanding of the components evolved, so did my design. Firstly, my initial design included a CC1310 which works on a frequency band which is not allowed in my country which puts a bit of a dent in my plan. The alternative is to use the BLE connectivity for the IoT-ivity.    Next the BQ25570 and superCap combination does not have enough juice to run the complete system, hence, an alternative power source needs to be deployed. Lastly, I am not a professional programmer hence I would have to depend on copy-paste and a lot of trial and error to get things to work.


My final design is hence divided into three sub-sections as described below.




I will be explaining these blocks one at a time so as to provide sufficient detail and place for discussion. Lets get started.


The First Module: The Sensors and Communication Core



One of the requirements of this design challenge is the inclusion of the MSP432 Launchpad and in my case, we need to add the CC2650 Booster Pack to the mix. The Sensors Booster Pack provides all necessary parameter for this case and this data is sent wirelessly to the Android/iOS or PC which can then send the data to the cloud and other data sinks.



a. The Challenges



TI has been hard at work releasing the new version of TI RTOS and I did a video demonstrating the sample code. I had shown how the demo code for the Sensors BP did not work at all ( and I took it as an opportunity to learn about coding drivers.



b. I2C and The Sensors Booster Pack



The first step was to write code to interface the TMP007 and Ambient Light Sensors. Project Zero works and was my starting point and the addition of I2C Setup code was the first step since most of the sensors use the two wire bus for communication.



[I2C Setup Code - [Code to be added from a Gist by the 9th of July]]



The code for the TMP007 was coded with the sample codes as a base and the Ambient sensor code was easy to implement as well. The idea is to have tasks for each sensor so that their frequency can be managed. Additionally some sensors can provided interrupts and would be better implemented separately. 



[TMP007 code - [Code to be added from a Gist by the 9th of July]]



c. Simple Network Processor API and the CC2650 Booster Pack



The BLE code was the hardest part to work with and the most rewarding in terms of the learning experience. The CC2650 module has a processor inside it and can function as a standalone network processor, however in this application, it is required to serve as a slave device to the MSP432 such that it can be replaced or even upgraded to the newer Bluetooth 5.0 devices. The communication happens over a UART and an additional three pins are required to make things work.



The CC2650 in our case has the UART slave firmware loaded, however, SPI can be chosen as an alternative to UART requiring a simple firmware upgrade. Once the firmware is loaded, Project Zero from the MSP432 SDK - Bluetooth Plugin resources can help expedite the process of setting up your first project.



Project Zero has the following important points.


1. It works with the newer versions of the TI-RTOS. There have been some extensive changes in the TI RTOS system hence some projects are not yet fully operational.

2. Three services come preconfigured which include an LED service(Read and Write), a notify service(to subscribe to events) and a data service(I have no idea what that does    )

3. The advertisement data does not include any information on the services which means the client has no idea of the service being provided unless it connects and interrogates the server.

4. All UUIDs are 128-bit which is an inconvenience since they are just too long and painful to remember.



In addition to changing the name of the CC2650 from Project Zero to a more appropriate one, I also added the services for the temperature sensor which is a notify service and an ambient light sensor service which I experimented with more that I should have  



The advertisement data had to go through massive modifications as well and it was a HUGE pain in the B*&&. Here is why.



- The Pain in the B*&&

Bluetooth profiles can be configured using a free tool from . Most manufacturers have provided their own plugin that will parse the code for their SDKs and for TI the plugin can be downloaded from .



Unfortunately, the generated code is no longer compatible with the newer BLE SDK plugin.


Screen Shot 2017-07-05 at 10.16.06 PM.png


I wanted to do something with the newer compiler so the only option is to do a trail and error of the produced code. My requirement is to advertise the services since my NodeJS app likes to get that info off the bat. A better understanding of the BLE Frame and packets is necessary and I found the explanation at very useful. The docs at are very useful.



By editing the project_zero.c and relevant profile.c files, the desired result can be achieved. Long story short, I was able to remove some manufacturer information and replace it with service information. There are only 31-bytes available for the Device Name, Flags, URIs and service data so the choice was a difficult one. All UUIDs were shrunk down to 32-Bits so that everything fits in. Instead of a tutorial, I am sharing the code on github for anyone interested in following along.



The result is the ability to get data from the sensors over BLE and an understanding of how to use the SNP better. For a TI tutorial on the subject that is a bit out of date, please visit Another must visit is



d. Some more tasks



There are two more tasks that the MSP432 must perform and that is the transmission of data over a serial line and monitoring of power. The data will be used in a module explained in the proceeding sections. Needless to say that the MSP432 is being used to do a lot of stuff and still feels under-utilzed.



e. Enclosures



This is a wearables challenge and my target is a jacket which leave a lot of room for imagination. I chose a small box like enclosure which will be placed in the pocket of the jacket. The enclosure was design in Autodesk Fusion 360 and 3D printed on a Cel Robox.







The result is a tight box with the headers exposed which will be used in module 3 of my design. The Sensors booster pack has been trimmed and enclosed in a box that can be fitted to the jacket. I2C lines will run down inside the jacket to where the core module is.




I have started laying out the final submission starting with module one which has the MSP432, the sensors booster packs and the CC2650 with a lot of custom code. With the enclosure complete and handed off to my better half, the final product should be something to look forward to. Getting there...

This post is about enclosures and in particular about a case I designed for the Texas Instruments CC1310 that will fit about anything. Since there are no official enclosures out there for the LPs I though I would give it a shot. The difference between this one and a soap case is the ability to use the Launchpad while in the protective housing.


The objective here is to keep the launchpad safe and sound and hence this case has the necessary features to do exactly that. The design has no way for stray solder or water to get in from the bottom and the buttons on the sides are recessed with ease of access but no way for solids to get through. The USB connector slot is large and allows users to access the port as well as a reset button in some launchpads.


The lid has locks to snap it in place and the pins can be easily accessed via slots on the top.


CC1310LP Enclosure v3.png


I uploaded the first version at and am going to release the second version this week.


Here is a video of the print and modifications to make version 2.0



I intend to research light pipes more and also reduce the thickness of the top lid.



For now, the case is keeping my LP safe while I experiment some more.



Happy hacking,



Log #8


This week I have been up to no good again and the focus of my experiments have been the BQ25504 and BQ25570. The EVM we received from TI and E14 is that of the BQ25570 Energy Harvesting to Battery charger and has all the necessary components and a little too many jumpers. I connected the EVM to a solar panel as well as a superCap in the hopes of making use of power supply. This is what I came up with.




In the above video, it is clear that the LED which usually draws 30 or so milliamps can be run for so long on the SuperCap hence we need a larger one.



In a previous design challenge, I worked on a BQ25504 which is a ultra low power boost converter suitable for energy harvesting circuits as well. In contrast, the BQ25570 also has a programmable buck converter which can be used to switch the voltage of the storage element to a fixed value which in this case was 1.8V . This time around the EVM is with me so a lot more can happen. Today I will take some time to experiment with charging Li-Ion Batteries and hopefully get better results. I would like to see the solar panel, BQ25570 and BTLE module work together to create a beacon of sorts but more details on that next time around.



I have missed the last week’s post due to a number of reasons and this week I am presenting another facet of the TI Platforms. I have been working with the various components of the kit to understand their working and how the code works. In this instalment, I explain Code Composer Studio and the TIREX or TI Resource Explorer. 


CCS Cloud


Going to presents the user with a login form after which Code Composer Studio Cloud is loaded into the web browser. Unlike it’s desktop counter-part, the IDE does not need updating and in my view is perfect for getting started quickly. While working with the Sample Code, I ran into some problems. Instead of writing up a post, I am providing a video with explanation and demo of the code, IDE and the problems faced.



More work

I am still working on some parts and demo code with limited success. My aim is to provide a novel method of creating an IoT Wearable however there are a number of problems to be solved.


  1. Getting all the parts running right.
  2. Write a cordova app for BLE configuration
  3. Get the CC1310 to work with a modified version of MQTT-SN. Yea I’ve tried it but am writing my own gateway in NodeJS and hitting a few snags. Here is where the Protocol Series fits in
  4. Get the BQ25570 to work with a superCap. Issues with my current Lab are not permitting work to happen seamlessly.
  5. Put humpty dumpty together.


Lots of head scratching lies ahead. 



Thanks for reading and happy hacking.



Its been two weeks since my last blog posts and my absence has been due to good reason. I am pursuing my PhD. where lab machine time is hard to come-by. Coupled with some health issues, the last two weeks have been the most hectic ever.


In this post I continue some basics of protocol design and next week, I will move to finally document the implementation of the project itself.


What is TLV?




A quick search on google reveals that TLV stands for Type-length-value. In this protocol, we start by sending the type parameter to indicate communication type and consequently the length of the entire structure and finally the value to be communicated. This is basically what we did the last time around with the difference that we now want to simplify things. There are no address or misc bytes of data.

I have used TLV in another project here where it was piggybacked on MQTT.



Where is it and why do we need it?


In our case, we will be piggybacking it on our Network Layer.

The essence of a protocol stack is that each layer has an individual function and each layer has some specific functionality. In our case, the stack looks like…



|         TLV Layer/Session layer                    |


|        Network Layer/Base protocol            |


|        Physical Layer/Serial/UART               |




This relates to the OSI model and theoretically not all layers are necessary. An Application layer will sit atop this stack and that is where the primary application code resides and takes decisions etc.



We require this middle layer so that if we decided to use the same application with TCP/IP sockets or even MQTT, this layer can be modified without modifying the application code. This facilitates portability and the application can be developed on Windows, tested on Linux and finally implemented on a BeagleBone Black.


The implementation will be similar to what is discussed in the previous post here (


The layer integration


The next problem faced is that of use and integration and how one layer talks to another. There are a number of ways this binding happens and here are the basics. Take the example of our Base protocol that uses Serial functionality of the platform. In order to receive and send a byte, we have a function called get_serial_buf() and put_serial_buf(). Here the functionality is encapsulated in functions and this could be fetch from a buffer, read a register or simply read a file for testing. Hence simply put the code in primitive C language was usually a pointer to a function. In some cases a programmer would use #define macros but using pointers to functions is still a better way.




Hence there will be a header file with pointer definitions and then they would be passed the address of functions that could access lower layer functionality. In the last instalment, the process of writing the payload was not mentioned and it was because of want of this explanation. Hence we can modify the old code to write to a memory location and define a function to read that space. This function can now be called in the upper layer i.e. the TLV layer. Incase the same communication needs to be done over MQTT, simply point to the function that can read the MQTT Payload.


We will go into more details IF I get feedback in the comments. In my last post, no one realised that the state diagram was actually missing and unless details are necessary, I don’t feel like adding them in the first place.


Where is the code?


Unlike the last post, I am not including the code yet. I will upload and link a video demo and explanation on Monday to conclude this series. Suffice to say that this should provide useful for beginners and people trying to understand any kind of protocol stack and the why’s behind it.


I am experimenting with BLE and the TI BLE module next along with a series on Autodesk Eagle- from start to finish.


Let me know what you think in the comments.


Happy hacking,




Please click the safety_jacket tag for all posts in the series.

I have been working with industrial control for more than a decade and have come up with my own 'hacks' to create a working system. This is my input for those who want to understand the process of writing a protocol stack.. at least my process anyways. In this two part series, I take a look at implementing a ModBUS like custom protocol in general and in part two, I will implement it using TI RTOS and the MSP432 board and it's UART. The objective will be to talk to a peripheral successfully and then expand to more slaves.


A protocol is a predefined agreement and sequence of steps that is followed to send data from one point to the other over a medium of transmission. We talk to each other by sound and sight where one looks towards the person or calls out the name and then starts speaking. The same way electronic communication works and is the backbone of many systems today. In this article, I talk about designing, implementing and testing a simple communication protocol for use with microcontrollers and single board computers.

Existing protocols - A survey

Over the years, many big companies have come to create solutions for the communication problem. If you don’t already know the big names are UART, I2C/TWI, SPI, CAN, LIN are the most popular. Dedicated peripheral hardware blocks have been designed for these and are a part of modern microcontrollers like AVR, PIC and the list goes on. It is important to understand these existing standards before we start with our own experiment. In the proceeding section, I will explain the protocols in brief and complete details can be read in their respective specification documentation. I will also try to simplify the explanation to accelerate the process and if something comes out ’not right’ please leave a comment and I shall do the needful.

UART - Universal Serial Asynchronous Receive Transmit

There is a long history behind the UART and RS232 but simply put, its one of most used standard for transmitting digital data over short distances. It works by both the transmitter and receiver having pre-agreed speed of transmission. This speed is the bit rate, bits-per-second or baud rate and values range from 50bits/s to 460,800bits/s. What is important is the duration of each bit since the higher the speed, the smaller the pulse. Most commonly, 9600bps are use with simple/older microcontrollers and 115200bps are used with modern day devices.

alt text

Figure 1: UART Timing Diagram

Figure 1 taken from Wikipedia shows the timing diagram for a serial communications frame or one transaction. The communications line starts in high state and the transmitting device will hold the line low for one bit period. For 115200, this would be 8.68 µs and 9600bps, it would be 104.2 µs. Next the data bits are transmitted starting with the least significant bit and will end with a stop bit which return the line to high voltage. The voltage levels and EIA232 specifications are not important right now but it is sufficient to understand that one byte can be transmitted between two points in one transaction. For transmitting ‘hello world’ this process would repeat 11 times and the receiver will have to put the message in the right place.

The only disadvantage to this scheme is that the speed of communication is predefined. There are workarounds to this as well but that is beyond the scope of this document. Physically there is one wire for transmission and one for reception which means both devices can send and receive at the same time. Most common implementations have one-to-one communication however protocols such as MODBUS can be implemented on top of UART to aid with multi device communication. In this exercise, we will be implementing something similar since its simple and effective.


I²C (Inter-Integrated Circuit), pronounced I-squared-C, is a multi-master, multi-slave, packet switched, single-ended, serial computer bus invented by Philips Semiconductor (now NXP Semiconductors).link Unlike UART, I2C uses the same wire to send and receive however the speed of communication is variable. In a typical use-case, one device takes the role of master and its this device that generates the clock and decides the speed. The master also decides who to talk to and then the corresponding device will send a response.

alt text

Figure 2 taken from spark shows the timing diagram for a typical I2c transaction. In essence, the master ‘asks’ for data and the slave ‘replies’.

Every device connected to these two wires or bus must have an address including the master(though not necessary). The master will first put the address on the wires which means more than one slave may be connected. Next comes a series of commands or command after which the slave will start to produce a reply the speed of which is governed by the master. Once the master has the required information, it creates signals to tell the slave to stop and in the eventuality that something bad occurs, the transaction will reset after a timeout post which a new transaction must start over.

The disadvantage is that since these transactions are more complicated, i.e. clock detection, start condition, stop condition, it’s always better to use a hardware peripheral. Most microcontrollers ship with an I2C controller which is capable of master mode and even have the ability to be configured as slave.

The reason why this article is being written in the first place is that we ran into a situation where I2C would not work. Boards such as the Intel Galileo, Edison etc will not function as I2C slaves and additionally, Texas Instruments, TI RTOS does not support I2C Slave for all devices… yet. I wanted to produce something that will be useful for everyone that uses these devices.


The Serial Peripheral Interface bus (SPI) is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. Its one of the most widely used protocol with sensors given that its similar to UART however an additional clock line is used to control the speed of the data transfer. Additionally, select wires are used to control which device is being talked to which enables multi-device communication. Wiki Link

Simple Memory Transfer Scenario

Figure 3 Shows a simple memory transfer scenario.

alt text

Figure 4 shows the simple nature of the transfer and though CPOL or polarity can complicate things, that discussion is beyond the scope of this document.

The disadvantage of this scheme is the extra number of pins required. Additionally, this method has very few constraints nor any inbuilt error checking etc. Its very useful for shot range sensor interfacing mainly.

CAN Bus and ModBUS

Just worth mentioning, are CAN and MODbus since these are application specific protocols and it would benefit the curious mind to read about these on their own. A detailed discussion would be of no use here and hence is beyond the scope of this document.

The problem statement

All of these protocols are different in some way. If an application demands a change from one of these protocols, it becomes even more obtuse. For example, if one wishes to use say TCP/IP or even MQTT which is a layer on top of TCP/IP, it would be difficult for everyone to be on the same page. In our case, since we have no hardware support for I2C slaves, we wish to use something like UART. This may be upgraded to MQTT in the future and this is our SRS or requirement.

Requirement: A protocol layer that can be used on microcontrollers and SBCs and can work on top of other hardware standards like UART, SPI and even TCP/IP. It should include support for multiple nodes and also have some basic error detection capabilities. It should be light and flexible.

This means, we need to start designing something on paper before we write the code.

The Design

This clearly is a protocol layer that will work on top of a signalling layer hence we need only describe data packaging and handling. We will need timeouts for failed transactions which could be optional and an addressing scheme to allow for multiple nodes. Lets being.

Addressing: 1 Byte should be enough since its not meant to be scalable. 1 byte for sender address as well in case we need it later. Size: 1 bytes should be enough to allow small frames. Payload: Since we are using 1 byte for frame size indication, the total payload should be less than 255 minus our overheads. Error checking: We will keep this lite on processing and use parity words. More details when we implement it.

To pack these lets add a start of frame and end of frame. Two bytes at the start- a character ‘:’ and ‘{‘ and ‘}’ at the end. If these are missing we will discard the frame.

The final frame will look like :{DEST SRC SIZE D0 D1 D2 … PARITY-WORD}

Thats good enough for the most part. Let not over think this and get right to designing the state machine.

Here is my version of the state diagram for the receive.

This diagram shows how the transactions will happen and the steps that the computer must follow. Some states may be merged in the final code however it is necessary to first draw out everything for the sake of understanding. Next comes the code.

Coding things

Depending upon the deployment platform, a user may choose his favourite language. For example, for hardware deployment as an IP Core, VHDL may be preferred or even Verilog. In my case the language will be C. This can be deployed on Microcontrollers, Linux and your favourite RTOS as well.

There are two ways to code a state machine where one method uses a Switch case statement and the other uses pointers to functions. I will be using the former for two reasons. Firstly, its easier for beginners to understand and this document is targeted towards beginners. Secondly, switch case code can be ported to VHDL as well and the same state machine may be synthesised in hardware after a few modifications.

The first step is to create an enumerated data type for the states to keep track of things.

enum state_codes {    wait, get_sof1, check_get_sof2, check_get_dest, check_get_src, get_size, setup_count, get_byte_dec, get_parity, get_eof, check_parity, write_data, discard_data } current_state, next_state; 

We now have two variables called current_state and next_state to hold our values. To implement the functionality of each state, we can write individual functions but for now let code the main machine. The mechanics are simple- in every call or tick, do what the current_state should be doing. Hence we write a switch case statement as follows.

switch(current_state){  case wait:  break;  case get_sof:  break; case check_get_sof2:  break; case check_get_dest:  break; case check_get_src:  break; case get_size:  break; case setup_count:  break; case get_byte_dec:  break; case get_parity:  break; case get_eof:  break; case check_parity:  break; case write_data:  break; case discard_data:  break; case default: break; 

That is just a blank template and we will have to fill up what needs to be done next. The first state is wait which means that it will check for an event. Hence we need a mechanism of asynchronously managing events. Lets make another enumerated data type for that as well.

enum event_code { no_event, byte_received, error, timeout } current_event; 

We need to write a function to inject events into the system and if you are really serious you should add a fifo as well. In this implementation, only one event is saved at a time which is OK for our case.

void event_set(enum event_code new_event){ current_event=new_event; } void event_clear(void){ current_event=no_event; } enum event_code event_get(void){ return current_event; } 

These functions help to set, clear and retrieve events. Now back to our main machine. In the wait state, we check for a byte_received event so the code will be as follows:

case wait: switch(event_get()): case byte_received: next_state=get_sof1; break; case no_event, error, timeout: next_state=wait; break; break; 

This means we have a switch case within a switch case which is confusing at times and you can do if then else if that’s something you like. The standard practice is the one shown and I use this techniques most often. Next we code the get_sof1 state. Now since we are on working with storing data we need a place as well. There are a number of ways to do this with the simplest being arrays. The downside is that the memory will always remain allocated and we don’t want that. So for the few bytes that are know, I usually like to go with dynamic memory allocation but for the sake of simplicity, I will use simple variables.

unsigned char sof1; unsigned char sof2; unsigned char dest_addr; unsigned char src_addr; unsigned char frame_size; unsigned char parity1; unsigned char eof1; unsigned counter=0; 

That takes care of some stuff when added to the start of the file. Global variables no less so lets tread carefully. The act of getting bytes from a buffer are encapsulated in a wrapper so that we may modify it later. For example, in the case of an 8051, serial data is stored in a register called SBUF. Lets write a function as:

unsigned char get_serial_buff(){ return SBUF; // modify according to your hardware. } 

We use this as follows:

case get_sof1: sof1 = get_serial_buff(); next_state = check_get_sof2; break; 

We can check the SOF to be ‘:’ but this will not be possible if it were VHDL code. I preffer checking it either in a separate state or the next state.

case check_get_sof2: sof2=get_serial_buff(); next_state = check_get_dest; if(sof1 != ‘:’){ // in case of error next_state = wait; } break; 

Similarly we code the rest of the check-and-get state. Once we are sure that its the right address and we need to store the data, the fun part begins. We dynamically allocate the space using malloc and save the address in a pointer as:

unsigned char *ptr;  case setup_count: ptr=malloc( frame_size-7 ); counter = 0; next_state = break; 

Here the allocated memory is only for the data. Next we copy the data to the buffer.

case get_byte_dec: *(ptr+counter) = get_serial_buff(); counter++; if ( counter>(frame_size-7) ){ next_state= get_parity; } else { next_state = get_byte_dec; } break; 

Once we have all the bytes, we check the parity and eof and pass on the pointer. There is still the matter of memory deallocation and updating states. Lets take a look at the code once completed.

const unsigned char MY_ADDRESS = 0x08; //Change this for your custom peripheral address unsigned char sof1; unsigned char sof2; unsigned char dest_addr; unsigned char src_addr; unsigned char frame_size; unsigned char parity1; unsigned char eof1; unsigned counter=0; unsigned char *ptr;  enum state_codes {    wait, get_sof1, check_get_sof2, check_get_dest, check_get_src, get_size, setup_count, get_byte_dec, get_parity, get_eof, check_parity, write_data, discard_data } current_state, next_state; enum event_code { no_event, byte_received, error, timeout } current_event;  void event_set(enum event_code new_event){ current_event=new_event; } void event_clear(void){ current_event=no_event; } enum event_code event_get(void){ return current_event; }  unsigned char get_serial_buff(){ // return getch(); // for console testing on a hardware with a display. return SBUF; // modify according to your hardware. }  void my_protocol_machine(){ switch(current_state){ case wait: switch(event_get()){ case byte_received: next_state=get_sof1; break; case no_event, error, timeout: next_state=wait; event_set(no_event); break; } break; case get_sof1: sof1 = get_serial_buff(); next_state = check_get_sof2; break; case check_get_sof2: if(sof1 != ‘:’){ // in case of error next_state = wait; break; } sof2=get_serial_buff(); next_state = check_get_dest; break; case check_get_dest: if( sof2 != ‘{‘ ){ // in case of error next_state = wait; break; } dest_addr = get_serial_buff(); next_state = get_src; break; case check_get_src: if (dest_addr != MY_ADDRESS ){// wrong address? next_state = wait; break; } src_addr = get_serial_buff(); break; case get_size: frame_size = get_serial_buff(); next_state = setup_count; break; case setup_count: if( frame_size<=7 ){ next_state = wait; break; } ptr=malloc( frame_size-7 ); counter = 0; next_state = get_byte_dec; break; case get_byte_dec: *(ptr+counter) = get_serial_buff(); counter++; if ( counter>(frame_size-7) ){ next_state= get_parity; } else { next_state = get_byte_dec; } break; case get_parity: parity1 = get_serial_buff(); next_state = get_eof; break; case get_eof: eof1 = get_serial_buff(); next_state = check_parity; break; case check_parity: if( checkParity() > 0 ){ next_state = write_data; } else { next_state = discard_data; } break; case write_data: // do something here next_state = wait; break; case discard_data, default: // check and deallocate memory here if ( ptr != null){ free(ptr); } ptr = null; next_state = wait; break; } // do everything else here after the switch case including check for events } 

Now there are a few pieces missing. We need to access events to find if a time out has occurred. That is simply done by adding an event checker at the end of the switch case code. We also need to update the current state variable.

current_state = next_state; is added to the end of the code along with if(next_state == wait){ // no need for a timer timer_stop(); } else {        // a valid state is next so restart the timing. reset_timer(); }  if( event_get() == timeout ){ event_set(no_event); next_state = discard_data; } 

That’s it. We have a written a basic machine to get a chunk of data. The only thing missing is some writing data stuff. This I leave for now. You can printf it or send it or in my case I would memcpy it to a predefined pointer.

I think that is enough for this instalment but in the next article, I will test this code out, write another layer on this one so that I can really extract some information out of it in a format for my choice. This will be useful for sending floats and long type data over a stream. In a later article, I will do the same state machine using pointer and enumerated data types and lookup tables in C.

Let me know what you think because its a learning process and I want you to share a comment for my time.

Happy hacking.





Its another friday and this week I am pleased to report the event-free delivery of the kit. The contents have been explained in the past but every box is a new surprise and hence here I present my unboxing video.


The Video


A few words


The MSP432 Launchpad features an ARM cortex M4F and has DSP acceleration capabilities. 

In addition to the Pinout Diagram that comes with the board, here is one more I found on the internet. Lots of ADC pins and a powerful M4F means its begging for some DSP like stuff to happen.

The analog channels are speced as:


Analog: 24Ch 14-bit differential 1MSPS SAR ADC, Two Comparators



Digital: Advanced Encryption Standard (AES256) Accelerator, CRC, DMA, HW MPY32


This CRC block will come in handy if you plan to implement something of a communications protocol.


Additionally, there are Up to 4 I2C, 8 SPI, 4 UART which means it can talk to all of your peripherals though the diagrams indicate less. It will be interesting to implement some examples on this project that talks over multiple comms.


Included in the box was a DLP NFC booster pack which I don’t plan on using BUT the accompanying tag was really nice to see. I might do a smaller sub project with it if time permits. 


Next up is the Sharp LCD booster pack and the Cap Sense Booster


The Capsense Booster will come in handy for doing UIs but taking a look at the wiki links, I realised that the Sharp LCD booster has a Capsense Slider as well. The CapSense came with a micro controller and demo code and if you have a launchpad you can try it out instantaneously.


A few months ago, I made a econopad which can be downloaded here

There was a blog post on the subject at


What Next?

TI just released some awesome stuff at ew17 and I am busy working on some more tutorials before I start writing up the actual project. Its always better to have your ducks in a line and in the next two posts, I am exploring some other issues.


Many thanks to Randall Sir for the quick communication and feedback. Its much appreciated.


As always, for all the blogs for this Project, use the tag safety_jacket or click here…


Thanks for reading.


Getting started with TI RTOS and CC1310


The CC1310 is a sub Ghz single chip solution that run its RF core on a Arm Cortex M0 and the Application processor is an Arm cortex M3 which means it is very flexible in terms of applications. Since things can get very complicated very quickly, TI recommends not developing native applications like for the MSP430 and AVR that is the bread and butter of most firmware. Instead, they recommend using TI RTOS to host your applications and provide a generous load of examples and what not to aid getting of the ground quickly. Unfortunately, there is more than one way to skin a cat and Code Composer Studio can seem downright scary to the new-comer. In this article, I discuss the use of TI RTOS with CCS 7 and touch on pThreads for the POSIX aware readers out there.


What is an RTOS


Here we go again! So from the wikipedia out there...



A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time applications that process data as it comes in, typically without buffering delays. Processing time requirements (including any OS delay) are measured in tenths of seconds or shorter increments of time. They either are event driven or time sharing. Event driven systems switch between tasks based on their priorities while time sharing systems switch the task based on clock interrupts.


Having said that, my version is simply this. An RTOS is a software layer that allows you to write something simple like a function to blink and LED or read a button press and then ask the RTOS to manage things when you want other functions to work in addition to you blinky. These other functions can be listening to the radio or send rf data etc. Why RTOSs are a good ideas is because they allow you to not micromanage everything your processor or peripherals are doing and concentrate on one thing at a time.


The official TI webpage can be found at


The CC1310 sub GHz launchpad




This launchpad is very special since they are designed for low power and long range. When I say long range, I mean, 20KMs on a coin cell. Yea. Thats right!


Check this out


and this


So this means even without the whip antenna I can still get a decent range out of these modules and that's the reason I plan to use them in my ongoing project.


The official TI link is


Getting back to TI RTOS


We need a few tools to get started.


1. Code Composer Studio 7.x or above. [From Here](

2. Smart RF Studio [From Here](


Install em and create a workspace in your favourite location. There are now two ways to create a project. The first is to simple right click in the project explorer and select 'New CCS Project'


Flow the rabbit and select TI-RTOS empty (minimal) Example and give it a name.


2a.png   2b.png


Press that hammer button to check if it compiles. It should. The example comes with a Blinking LED Task that allows you to check if everything is all right and if you connect and program your launchpad, you should be able to see things work. For a demo and instructions on method two, take a look at the video below.




What is POSIX


Again a bit of Wikipedia here.


The Portable Operating System Interface (POSIX)[1] is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines the application programming interface (API), along with command line shells and utility interfaces, for software compatibility with variants of Unix and other operating systems.


And the TI Wiki says...


SYS/BIOS (v6.42.01 and higher) provides a subset of the POSIX thread (pthread) APIs. These include pthread threads, mutexes, read-write locks, barriers, and condition variables. The pthread APIs can simplify porting applications from a POSIX environment to SYS/BIOS, as well as allowing the same code to be compiled to run in a POSIX environment and with SYS/BIOS. As the pthread APIs are built on top of the SYS/BIOS Task and Semaphore modules, some of the APIs can be called from SYS/BIOS Tasks.


[Link to original](


In short, the pThread support is implemented on-top of the tasks modules so unless you want to port some POSIX code from another OS, just stick to the tasks system.


What next?


A UPS notification puts some parts from Element14/Texas Instruments on my table next week. Until then I will be playing with the CC1310 a bit more and hopefully have something with RF Studio Next.


Thanks for reading and happy hacking,



Credits: Special thanks to Jan Cumps Sir for the information.

So with the hardware delayed and my office space being reduced to a small box, I am working with a number of things. I installed the Code Composer Studio Software and it turns out I have some Anaren CC110L Booster packs in my inventory. So I decided to do a simple experiment with it.




This is a simple prject where I use MSP430G2553 Microcontrollers with the Anaren CC110L Booster Packs to make a simple wireless node system. Nothing fancy and a barebones started project is provided for getting off the ground fast.


The basic concept is simple. We transmit with a function and stop otherwise. All-in-all the whole project is quite reusable and I intend to some stuff with it in the future.




How to Import


Only the essential files are checked into the Git repository to reduce the size and hassle of version upgrades etc. As per wiki…


The following project files should be checked into source control:



.ccsproject .cproject .project .settings folder makefile.defs (if using SYS/BIOS) .ccsproject has project information specific to CCS.


.cproject and .project are Eclipse CDT project files.


.settings folder is a standard Eclipse folder that has settings that apply for the project.


makefiles.defs has additional make rules included by the generated project makefile for SYS/BIOS projects.


The following files and folders should not be checked into source control:


\Debug or \Release folder .xdchelp .config folder .launches folder Configuration folders like \Debug or \Release are generated folders that contain build artifacts like object files and do not need to be checked into source control.


.xdchelp is a generated file that is used to help display error messages in the problems view and does not need to be checked into source control.


.config and .launches are generated folders that do not need to be checked into source control.


So here is what you do…




1. clone of download the code or the repository the way you like it. I leave that upto you and we only need the CCS folder in the repo for the next steps.


2. Create a new project in CCS like the way you would normally do. Setup and finish the wizard if thats your thing.


3. Right click the project and click Import > General > File System.


4. Navigate to the CCS folder from the repository. Select the folder and Import. Overwrite Everything!


5. Build and debug.


How to Use


There are three files in the root directory of this project. Import the whole project into Code composer Studio and then right click on either the rx or tx file. Exclude it from build and then rebuild and program the output. Repeat for the other file. Now you should have two controllers programmed with TX and RX firmware. DONE!


Maybe I will use this in my project. Maybe I will use this elsewhere. Maybe...


So as always for a list of posts- past and future, just click the tag safety_jacket and all posts for this project should magically appear.



Yes. I AM running late on this blog post and yes I read the terms and conditions. The delay was due to unforeseen blunders on my part but here we go...


Here is my application for the challenge and where I put my foot in my mouth!. A few points to note:


1. Yes you can make fun of my drawing.

2. No I did not use crayons.

3. Yes I have crayons of my own- my wife bought three sets for my son, me and herself.

4. Yes this is a serious project.

5. And yes I will be using paper drawing from now on. I think it add character to the content.


For all logs on the project, search for the tag "safety_jacket" and it should give you a list of all the posts.



A few years ago when I was responsible for the RnD Department of a Toll Automation Company in India, I was unfortunate enough to witness an accident on one of our sites. A Toll Plaza in Chennai India was the location where a high speed car hit one of our local site engineers and he died as a result shortly thereafter. 

The presence of safety jackets and helmets may not be enough in some cases where either the machines or infrastructure needs regular maintenance and cannot be shutdown all at once. This incident haunts me till date and I have not been able to answer the question, “Could things be done differently to improve personnel safety?”


Reason For Application


I have two reasons for applying for this challenge

  1. The theme for the “Safe & Sound” design challenge is a practical one and asks a question lingering in my mind for some years. I have not had the time or resources to investigate a solution for Road worker and the like and this seems like the perfect opportunity to put Texas Instruments technology in a solution that may save lives.
  1. Secondly, I am a Texas Instruments Fanboy and my experience with the offerings have been fruitful in the past. I would like to expand my hands-on experience to the MSP432 micro controller as well as the BLE and NFC offerings.


Existing solutions

Unfortunately there are no existing solutions that can do what is needed. A walky-talky is usually used to communicate instructions and feedback and is a manual method of transmitting data. In a fast world, the act of picking up a walky and relaying instructions is too slow a process to be useful in high risk environments.


My proposal 

The application is based around the design and development of a complete safety and management solution for industrial workers in the tolling industry and can be extended to be used in other industrial environments as well. It consists of two major components as explained in detail below.


Part 1: The Jacket



In keeping with the theme of the challenge, the first part of the design consists of a wearable smart Safety Jacket. The proposed layout of the jacket with all the components is shown in figure 1. 






Figure 2


The block diagram of the system is given in figure 2 and each component is explained as follows.



  1. The MSP430 Core - This apparel contains the MSP-EXP432P401RMSP-EXP432P401RMSP430FR5969LP as the heart and central processor which talks to the peripherals. This core is responsible for managing the sensors as well as the communications with the remote unit. The controller is expected to run TI RTOS and is expected to sleep and save energy
  2. A CC1310 is used as a long range communications radio between the apparel as well as a remote station. The data packets will be short and intermittent and the radio will power off to save energy.
  3. A TI Fuel Booster Pack or a custom battery management solution will be used to power the wearable and monitor battery life. Monitoring the battery is important for wearables.
  4. The BQ25570EVM will be used to charge the battery as well as a 10Farad super cap from a solar panel. This will allow for longer in-field spans since the super capacitor can charge more quickly from harvested energy.
  5. The CC2650 will be used to provide BTLE connectivity between the apparel and a custom Android App. This will allow for a user interface for configuration and event monitoring.
  6. The Sensors Booster pack will be mounted upfront to monitor environment conditions. These are to be mounted on the front and are in the form of a replaceable format. These can be upgraded later for other applications as well.
  7. A buzzer located at the shoulder will be used to generate audio alerts. The near-the-ear location allows for feedback in addition to the hepatic feedback from the cellphone alerts.

Part 2: The base station


The other supporting and equally important part of this application is the base station. It consists of the following parts.

  1. The CC1310 radio for communication with the Apparel. Being a long range radio, this ensures communication given small obstructions and inside nearby buildings.
  2. An MSP430F5969 Launchpad which acts like a controller for the other booster packs. This MSP430 has enough RAM to store the local data as well as drive the display.
  3. Sharp96 LCD Booster pack which is used to provide a small Display of status. Small and compact, it allows for a friendly and summaries readout.
  4. SENSE1 booster pack which is used for input. Instead of tactile buttons that may get damaged with time, the capacitive sensors will work longer.
  5. A Buzzer for audio and alarm light for visual alerts.
  6. A Raspberry Pi for data storage and event triggers and interfacing with other equipment. I plan to run a small database as well as a NodeJS Service that manages the communications and storage.


Working concept


The idea is to have a field engineer wear this safety jacket out into the field. The sensors will monitor the environment and send feedback to the remote base station. The wearer can also monitor conditions on his smartphone if necessary. In case a local parameter is violated e.g. a sudden rise in temperature is detected or a fall is detected, the values will register and an audio alert will sound. This data is also sent over the sub-GHz radio to the base station where the support staff gets notified of these variations. The data is displayed on the remote station which is a stand alone device that has a user interface using the sharp LCD and Capacitive sense booster packs enclosed in a 3D Printed enclosure.


Additionally, the base station is also connected with a raspberry pi which allows interfacing with other equipment. For example when working on the road, an alert is sent to the jacket every time a vehicle is allowed to enter into the lane. This allows for the engineer to move to a safe zone and can also be used to call the engineer off the track. This data can be sent over the internet to a server for monitoring and can also be used by other systems developers to integrate into their own system. e.g. a toll barrier sensor can be integrated with this system to automatically send alerts about oncoming traffic.

The last part is the Android application which will be used to talk to the smartphone and provide a simple GUI.


Risks and Challenges


I have carefully taken into consideration the time lines and feel the risks in this applications are limited to the availability of the components. In this application, I have proposed a prototype with the provided kit however once I have the basics worked out, I will be attempting to put together a reduced BOM solution which will a PCB with most modules integrated. The testing of these takes time and I shall present a more polished prototype if time permits. Initially, I am aiming at a working prototype to demonstrate the concept which may or may not be production ready.