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 (https://www.element14.com/community/community/design-challenges/texas-instruments-safe-sound-wearables-design-challenge/blog/2017/04/10/safe-sound-safety-jacket-for-the-tolling-industry-7-cloud-ccs-and-sample-code-issues) 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 https://www.bluetooth.com/~/media/developer-studio/index . Most manufacturers have provided their own plugin that will parse the code for their SDKs and for TI the plugin can be downloaded from http://software-dl.ti.com/lprf/bds/ti-bds-plugin.html .

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

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 http://www.argenox.com/a-ble-advertising-primer/ very useful. The docs at https://docs.mbed.com/docs/ble-intros/en/latest/Advanced/CustomGAP/ 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 http://software-dl.ti.com/lprf/simplelink_academy/modules/ble_01_bds/ble_01_bds.html Another must visit is http://software-dl.ti.com/lprf/simplelink_academy/overview.html

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.

Conclusion

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