Jump to content

Recommended Posts

This project is an offshoot of an earlier investigation of wireless wearables using the MSP430G2553: http://forum.43oh.com/topic/10060-msp430-wearable-with-radio/. The concept has been successfully tested and is described below. I plan regular updates as the project progresses.


The objective is to develop a wearable powered by a coin cell that can be controlled remotely. It could be used, as an example, in the tiara below or on a costume worn by dancers in a performance and controlled from offstage. In the photo an earlier MSP430G2553 coin cell powered wearable is attached to the tiara and driving 3 WS2812 LEDs.



The constraints are:

  • cost - unit cost for the receiver of $10 or less
  • technology - common off the shelf components, MSP430G2553
  • construction - standard double sided PCB spec, keep SMD parts large enough to be hand soldered
  • power - CR2032 (rated 3V and 225 mAH)
  • life - needs to run at least half an hour on fresh batteries
  • reception - 10m with clear line of sight, update at least every 100 ms
  • transmission - desirable but not required
  • size - 40mm/1.6" diameter for receiver
  • programming - Energia desirable
  • schedule - 6 month completion
The transmitter will probably be placed on a "Booster Pack" for a LaunchPad running Energia. Multiple LEDs will be driven to gain extra distance, and if required multiple transmitters could be set up from different angles to assure good reception. A display would be helpful as on the FR6989 shown below with an IR LED.


The initial Energia transmission sketch to test the concept is located here: https://github.com/fmilburn3/Infrared/blob/master/IR_sendByte.ino. The sketch was developed in Energia V17 using a MSP430G2553 LaunchPad and a 940 nm infrared LED. It loops from 0 to 255 and sends a single byte with the count via infrared to the receiver when a button is pushed. The packets for sending bytes do not follow an existing protocol. It is specific to this application and developed with the goal of getting a byte transmitted at least every 100 ms.


The receiver will be a custom MSP430G2553 board powered by a coin cell with a TSOP38238 IR receiver. There will LEDs on the PCB and it will also have the capability to drive LEDs off board.


The preliminary receiver code was written in C using CCS and direct register access: https://github.com/fmilburn3/Infrared/blob/master/IR_Receiver/main.c . The framework for the code is based on a post by RobG here on 43oh. The receiver takes transmissions from the Energia sketch linked above and outputs the current byte on eight LEDs in binary form. When the last byte is received it clears the LEDs and outputs the number of bytes received in error out of the expected 255. This allows analysis of reception at different distances and conditions.


Shown below is the preliminary testing setup. In the foreground is the G2553 receiver with a TSOP38238 and output LEDs on a breadboard. Middle ground is a G2553 with the infrared LED sending bytes. Background is output from the receiver being monitored on an oscilloscope. The output of the TSOP38238 is quite clean and no errors were seen with the transmitter and receiver this close together. Transmission is at approximately 1000 bytes per minute or 16+ bytes/sec which is within the desired range.


I subsequently modified the test setup to run off batteries so I could do some preliminary distance testing. With clear line of sight reception I saw no errors up to 5 meters with one transmission LED aimed directly at the receiver. Errors crept in after that, especially if the transmission is off to one side, not pointed directly at the receiver, or at a greater distance.


Near term activities:

  • increase the number of transmission LEDs
  • evaluate the impact of off-center transmission further
  • test in an environment that doesn't have reflective surfaces
  • add WS2812 driver capability and investigating the impact of TSOP38238 interrupts on the WS2812 driver
  • evaluate 2032 battery life further
Link to post
Share on other sites

@Fmilburn   Not sure if you are aware of this bundle.  Thought it may be of interest on two fronts, first being a good price on the two board combo which might save some time in prototyping. The other is that the MCU has IR hardware on board which also may be helpful.





Link to post
Share on other sites

Hi @@dubnet,


I was aware of the IR booster pack, but not of that bundle at that price.  I also wasn't really aware that the MSP430FR4133 was so well matched to IR.  It beats the clunky pad with a ribbon connection that I have on hand and was going to prototype with.  I think I will order one.  The other way I am considering is to use a phone and connect to the IR transmitter microcontroller via bluetooth.  I have a CC2650 BoosterPack and could attach that to a microcontroller located with and driving a big bank of IR transmission LEDs for a pretty slick solution.


Your second link is interesting and has a good discussion of various protocols and how they can be implemented.  I  did some research on protocols earlier but decided to make up my own for the educational value and insight on how modulation and encoding works while testing the limits of the receiver I had on hand.  I should go back now and look at other implementations to see what might be gained.


I think the receiver end is going to be challenging.  It is greatly constrained by the CR2032 battery and WS2812s (which I would like to use) with their somewhat fiddly timing requirements all the while dealing with interrupts from the IR. 

Link to post
Share on other sites

@Fmilburn   Glad you found the info helpful.  I have been tempted on a couple of occasions to order that bundle just to play with IR on the MSP430 platform. However, I had to slap the mouse out of my own hand since I already have too many boards than the time to devote to them.  I have resolved to carve out some time to work on some projects as we go into the new year. We will see how that goes. :unsure:


Happy New Year!  :D

Link to post
Share on other sites

@@Fmilburn, I'm not sure  you went back and looked at the older posts here, might be worth a look. Opossum did some nice posts about IR. He has a fondness for those TV B Gone things :) ...







Link to post
Share on other sites

Rick:  Thanks for the ideas.  I've gone back now and looked at some of the older posts and there is some good stuff there.  There is an interesting link to an Adafruit forum as well.


Terje: I am pretty sure any code you post would be more than equal to mine.  I would be interested in seeing what you did.


I ran a quick test using a CR2032 with my existing wearable and regular LEDs to get some initial battery life data.  The coin cell is powering the G2553, the TSOP38238, and LEDs on the PCB.  The multimeter is measuring battery voltage.


It has been operating for more than two hours now.  I need to instrument it better and get some current measurements as well.  Probably should do it with EnergyTrace.  Here are a couple of observations:

  • No transmission errors were detected (except the ones I purposely caused to test the setup) over a 2 hour trial
  • The LEDs are not at full brightness - the number and brightness of the LEDs will be the controlling factor on battery life
  • There is a lot of internal resistance in the CR2032 with higher currents.  Note that the multimeter is reading about 2.7 Volts  (the photo was at about one hour but it was well under 3V with a fresh battery ).
  • The G2553 is running at 16 MHz and the datasheet recommends at least 3V at this speed - need to slow it down to 12 MHz or so.

But overall, it appears that I can reach the requirements.

Link to post
Share on other sites

Ok, here we go - @@Fmilburn it is not my code, I have just "translated" it from assembly to C - I have to admit I did not understand much when I started coding for MCUs...

In my application the processor is running at 1MHz, timing parametes (BIT_50 and BIT_75) must be adjusted different.


The header file:

// Philips RC-5 IR protocol decoder library for MSP340G2553

#include <msp430.h>
#include <stdint.h>
#include <stdbool.h>

// The following bit timings are for a 1MHz clock

#define BIT_50 890	//  890
#define BIT_75 1348	// 1348

#define IRDATA BIT2	// IR receiver input (P1)

void initRC (void);
void startRC (void);
uint8_t getAddress (void);
uint8_t getCommand (void);
bool getToggle (void);


// Philips RC-5 IR protocol decoder library for MSP340G2553
// Adapted from assembly code published in Texas Instruments Application Report SLAA134
// http://www.ti.com/litv/pdf/slaa134
// by Terje Io

#include "rc5recv.h"

static volatile uint8_t count;
static volatile uint16_t data;

// returns device address (5 bits)

uint8_t getAddress (void) {
	return count == 0 ? (data >> 6) & 0x1F : 0;

// returns device command (6 bits)

uint8_t getCommand (void) {
	return data & 0x3F;

// returns toggle status - changes when a new remote key is pressed or a key is pressed, released and pressed again

bool getToggle (void) {
	return (data & 0x800) != 0;

// Init input pin and Timer 0

void initRC (void) {



// Start receiving data - call must be followed by LPM0 in main code (to wait for command)

void startRC (void) {

	data = 0;
	count = 14;


#pragma vector = TIMER0_A1_VECTOR;
void __interrupt TimerA0 (void)

	switch(__even_in_range(TAIV, 14)) {

	    case  0: break;		// No interrupt

	    case  2:			// CCR1 not used

#ifdef DEBUG
	    	if(TA0CCTL1 & CAP) {
	    		TA0CCTL2 = 0;
	    		TA0CCTL1 = CCIE;
	    		TA0CCR1 += BIT_75;

	    	} else if(--count == 0) {

	    		TA0CCTL1 = 0;

	    		if(data & 0x1000) { // second startbit ok?
	    			data &= 0xFFF;
	    		} else

	    	} else {
	    		data = data << 1;
	    		data |= (TA0CCTL1 & SCCI) >> 10;
	    		TA0CCR2 = TA0CCR1 + BIT_50;
	    		TA0CCTL2 = CCIE;

#ifdef DEBUG

	    case 4:	//  Handle overruns by resetting
	    	TA0CCTL2 = 0;

	    default: break;


Snippet from my application showing usage:

	startRC();									// set up IR receiver for next message

	while(1) {


		toggled = toggle != getToggle();
		toggle = getToggle();

		if((address = getAddress()) == 16) {

			switch(getCommand()) {

				case 0:
					if(isMuted())						// If muted then
						selectBtn(MUTE);				// demute


				case 12:

				case 13:




		if(address != 0)		// if IR receiver command processed
			startRC();		// set it up for next message



I have code (and schematics) for a RC5 transmitter based on MSP430G2312 as well, again based on someone elses work but cannot remember where I found it. I run it off a CR2025 cell so it has limited range (4-5m), still battery life is 1 year+ with my (daily) use.

Link to post
Share on other sites

CR2032 Battery Performance


Most of what I am doing in this project is well plowed ground, but the elevated current requirements differ from what is normally done with a CR2032 battery.  For example, here is data from an Energizer data sheet:


The battery maintains a fairly constant voltage after an initial drop but there is a marked increase in the internal resistance of the battery at 105 mAh and the voltage supplied drops off.  The background drain in the upper green curve is 0.2 mA.  The red pulsed curve is 23 mA on for 1 mSec and then off for 14 mSec.


My application requires high currents (10 mA +) continuously without interruption.  The tests that follow have a constant resistive load and were recorded continuously at one minute intervals. Temperature was 20^C (68^F) and the test batteries were fresh Sony Lithium 3V CR2032 with a 2025 expiration date.  Voltages were measured with a MSP-EXP430FR6989 and checked with a multimeter.  Fixed resistances of 150 ohms and 219 ohms were tested.  Before the test the open voltage across both batteries was measured at 3.18 V (it makes me feel like a real engineer just to write this kind of stuff again).  Data was written to the serial terminal and copied into an Excel spreadsheet.  Here is the test setup:


And here are the results:


I've drawn a line at 2.2 V across the graph as this is about the minimum voltage I think I can get away with - at least with regular LEDs, I need to find the minimum voltage where WS2812s will work reliably.  Here are some observations:

  • There is a knee to the curves but they aren't particularly sharp or steep.  Neither curve is particularly flat.
  • With a 150 ohm load the battery lasted about 30 minutes before the voltage dropped below 2.2 V.  At that point the current was around 14.5 mA.  At peak it was 19 mA, and it averaged about 16 mA.
  • With a 219 ohm load the battery lasted about 2 1/2 hours.  Current dropped from about 13 mA to 10 mA and the average was around 11 mA or so.

The results are good news and available power appears to meet project requirements.  The next step is to test a more realistic setup with some WS2812s and the TSOP38238. 


Code for the battery test (Energia) is here:  https://github.com/fmilburn3/battery_voltage

Link to post
Share on other sites

@@Fmilburn, after looking at your posts I tried to remember what I used to know about cr2032s, but ultimately went to Google. I ran across this post from Jack Ganssle regarding CR and BR coin cell capacity and life.  Curious if your data tracks with his.

BTW there is a comment at the bottom of his post suggesting that a 10mA continuos load is not within the design specs for the batteries which links to a data sheet.  However, the comment seems to assume that test conditions are also design specs, which may not be true.



Link to post
Share on other sites

@@NurseBob,  That is a great link - much appreciated.  I discovered Jack Ganssle a while back but still haven't worked through all his articles and had not seen that one. As usual, he hits it out of the park.  The quick answer to the comparison question is that the two sets are a bit apples to oranges but if anything my tests left me expecting shorter battery life than what his do.  The internal resistance of the batteries from my tests seems higher.


They are apples to oranges because he tested with a constant current whereas for simplification I used constant external resistance and as a result the current varies over time.  I also have a much sparser dataset consisting of one manufacturer (which I am now skeptical of) and only two samples.


The measured current in my setup with the 219 ohm load (nominal 220 ohm resistor) varies from about 13 mA at the 1 minute mark to about 9 mA when it crosses 2V.  It took it 190 min to get there.  So the battery life is roughly 11 * 190 / 60 = 35 mAh.  Jack reports 180 mAh 3 sigma for a constant 10 mA load.  I believe my data is good so I may have some knockoff or bad batteries - entirely possible since I acquired them super cheap over the internet - like 11 cents a piece in a quantity of 20 and free shipping.  The difference in life is enough that I am tempted to go buy some batteries I know are name brand and repeat the test.


I agree with your observation on whether 10 mA is within specification.  In any event, I don't think what I am attempting here meets any normal engineering criteria or approach to product development.  I spent almost 40 years as an engineer in an industry where safety considerations and cost meant we applied very rigorous testing and safety factors to designs.  Product failure was not acceptable.


I am a hobbyist tinkerer now and outside my area of expertise and it is kind of fun to be ignorant and just experiment (making sure I don't do anything that could hurt myself or others).   I may end up with only a modest number of dim LEDs and very short battery life but that is acceptable.  In addition I have provided for an external battery and could easily hook up a AA pack if it were necessary.

Link to post
Share on other sites

Batteries, batteries, batteries... :)

For my current project I'm using LIPOs, and am experimenting with 1200 - 5000 mAh batteries to find an acceptable (to me) recharge interval.  It's been both challenging and interesting to explore not only the power source(s), but also the F5529 using the USB capability.  Designing (plagiarising) circuits for the PCB so that the USB works, along with the charging circuit, and the 5 I2C and 1 SPI devices has led to seemingly endless hours (not too sure about "fun" as a modifier there...).

Prior to my transition into Nursing, I had 15+ years as a Systems Engineer writing enterprise apps for Del Monte Foods (before they became just a brand name), Electonic Data Sytems, etc. On top of that, I've been a bit of a gypsy regarding work, having been in 3 other unrelated industries, as well as self employed.  Life's been "interesting" - which translates to a poorly planned retirement when it comes to finances. So it goes... :)

Link to post
Share on other sites
  • 5 months later...

Receiver Prototype Working

After some stop and start I am back on this project and making progress.  Here is the latest iteration:


The wearable IR receiver and WS2812 controller at bottom runs off of a single 2032 battery.  With only one LED lit at a time it is capable of easily running for an hour since current is  down in the 10-15 mA range.  It also transmits and receives with high reliability at 10 meters with two IR LEDs as shown. The transmitter is battery driven at the moment. I have a large number of IR LEDs on order so as to build a transmitter with a larger array of LEDs.

It uses 2400 Baud UART for transmission.  The transmitter code was written with CCS and is done in software with two timers.  One timer maintains 2400 baud. To transmit a 1 bit the second timer is turned on and outputs a 38 KHz square wave over the IR LEDs until time for the next bit.  For a 0 bit nothing is transmitted.  The LEDs are rated for 100 mA each continuous but are being driven here at about 70 mA each with a NPN transistor hidden behind the jumper wires on the breadboard. 

On the receiver side the IR receiver turns the transmission into input that can be directly input into the UART peripheral on the MSP430G2553.  A single byte is used to select the color and display mode of the WS2812 LEDs.  The driver for the WS2812s uses the SPI method which I have posted elsewhere.  There are some areas for improvement in the receiver PCB which I will incorporate in the next board spin but everything is working.

A feature of this approach is that the receiver uses Energia with no tricks and even works on an Arduino Uno without modification other than pin changes.

For the transmitter, I am still thinking about how best to implement.  One approach would be to continue using a microcontroller such as the MSP430F5529 I am currently using with a keypad and display.  Something like this mock-up:


Alternatively, I could use something like a Raspberry Pi 3 and use Python to give Bluetooth LE access control over a phone.

Link to post
Share on other sites
3 hours ago, chicken said:

That's a nice mock-up. Took me a while to realize that the keypad and display just sit on top of a tin box.

I plan on going ahead and fitting it all together - it is the quickest way for me to put something together that won't fall apart and demonstrate the concept. 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...