Sign in to follow this  
Followers 0
Fmilburn

MSP430 Infrared Controlled Wearable

20 posts in this topic

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.

post-45284-0-09225200-1483138241_thumb.jpg

 

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.

post-45284-0-64397400-1483139311_thumb.jpg

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.

post-45284-0-58758400-1483139960_thumb.jpg

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.

post-45284-0-76309700-1483140897_thumb.jpg

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
Rei Vilo and dubnet like this

Share this post


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.

 

https://store.ti.com/MSP-BNDL-FR4133IR.aspx

 

http://www.ti.com/lit/an/slaa644b/slaa644b.pdf

Fmilburn likes this

Share this post


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. 

Share this post


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

Share this post


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.

post-45284-0-45604900-1483311770_thumb.jpg

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.

dubnet likes this

Share this post


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);

Functions:

//
// 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) {

	P1DIR &= ~IRDATA;
	P1SEL |= IRDATA;

	TA0CTL = TASSEL_2|MC1|TACLR|TAIE;
}

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

void startRC (void) {

	data = 0;
	count = 14;
	TA0CCTL1 = CM1|SCS|CAP|CCIE;

}

#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
	P1OUT ^= DEBUG_PIN;
#endif
	    	if(TA0CCTL1 & CAP) {
	    		TA0CCTL2 = 0;
	    		TA0CCTL1 = CCIE;
	    		TA0CCR1 += BIT_75;

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

	    		TA0CCTL1 = 0;

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

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

#ifdef DEBUG
	P1OUT ^= DEBUG_PIN;
#endif
	    	break;

	    case 4:	//  Handle overruns by resetting
	    	TA0CCTL2 = 0;
	    	startRC();
	    	break;

	    default: break;

	  }
}

Snippet from my application showing usage:

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

	while(1) {

		LPM0;

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

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

			switch(getCommand()) {

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

...

				case 12:
					if(toggled)
						selectBtn(STDBY);
					break;

				case 13:
					if(toggled)
						selectBtn(MUTE);
					break;

...

			}

		}

		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.

Fmilburn likes this

Share this post


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:

post-45284-0-19222500-1483491125_thumb.jpg

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:

post-45284-0-69716700-1483492546_thumb.jpg

And here are the results:

post-45284-0-02716000-1483492937_thumb.jpg

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

dubnet and NurseBob like this

Share this post


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.

 

Bob

Fmilburn likes this

Share this post


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.

NurseBob likes this

Share this post


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

Fmilburn likes this

Share this post


Link to post
Share on other sites

Receiver Prototype Working

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

Working_Receiver_Prototype.thumb.jpg.59987fc9126468f855b2bb63fa9dacbf.jpg

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:

Mockup_Transmitter.thumb.jpg.4ac15baff3830cd7091c2d63c7372966.jpg

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

chicken, dubnet and Rickta59 like this

Share this post


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. 

Share this post


Link to post
Share on other sites

Tiara Prototype Assembled

I assembled one of the tiaras in more or less final form last week and while everything is working, and it meets the original criteria, I am working on additional modifications to improve ease of fabrication.  Here is what it looks like at the moment:

Tiara_front.JPG.47139cc66731d73cbc4be6d70b9dd5da.JPG

The fabrication problems are mostly around the wiring between the PCB and the LEDs.  Soldering to the WS2812s is fussy and the wiring isn't too attractive as seen in this photo from the back:

Tiara_back.JPG.7c1aaef9e345e8faf935566f5ad98314.JPG

In addition, I've hot glued a pin header to the PCB and wired to that.  All very unprofessional looking.  There was also a potential problem with shorts when inserting and removing the battery.  So, I've modified the PCB as follows and put them on order:

Petal_V3_front.jpg.e70c9148673baea587b755f8779f080e.jpgPetal_V3_back.jpg.cc927f84c5e243cf5df3a4508d616d6e.jpg

This will allow soldering in a pin header or in the case of the TSOP 38 direct soldering.  The three LEDs on the old receiver PCB have been replaced by a four pin 5050 SMD version of the WS2812. In addition, I am switching to the same LED for external lights and designed a small PCB to make attachment easier - they are a bit more than 11 mm in diameter:

SK6812_front.jpg.76b7977640ff10d12cf5c1f0f3737db8.jpgSK6812_back.jpg.1f8523a1c971a4ba1a1e7081897873f1.jpg

There was a recent blog on Hackaday about cables and I am thinking about ordering some custom ones to tidy up the wiring:  http://hackaday.com/2017/06/25/dirty-now-does-cables/.  Of course this will require yet another spin of the PCBs to accommodate the new cables but in the end it is all easier to assemble and neater.

Meanwhile, the prototype I built for the transmitter looks crummy and I am still waiting on some parts.  Plus, it was suggested that I needed to simplify the programming by the user further and perhaps have an automatic mode that would somehow work without programming on behalf of the user.  So, I've ordered some MSGEQ7 Band Graphic Equalizer chips with the idea of using that plus volume to create some kind of automatic light show (feature creep alert).  I will probably switch to a Raspberry Pi for the transmitter.

chicken likes this

Share this post


Link to post
Share on other sites

New IR Transmitter Prototype Assembled

I have not received the new PCBs yet but I did get the IR LEDs so I put together a "boosterpack" transmitter and a separate module to test coverage and range.

IR_Transmitter_3.jpg.bbd4bbb9d71032dbc2c7776e6c32d433.jpg

They can be used together with crossed beams for coverage from two sides.  The IR LED array on the left is lit, but since it looks to be off, it is apparent that my iPhone has an IR filter on it.  Total current when on is on the order of 400 mA per bank and is controlled by a TIP120 Darlington Transistor which is all I had on hand that could carry the current.  The TIP120 on the left has a heat sink on it but I found that wasn't necessary and the one on the right is bare. The LEDs are capable of 100 mA continuous each but are seeing less than 50 mA at peak here.  If you look closely at the bottom row on the booster pack you can see the 0805 SMD resistors that are in series with each LED.  Power is coming from a 1200 mAh lipo beneath the LaunchPad which seems sufficient for the task.

This thing puts out a lot of photons compared to what I was using before.  Indoors with white walls it even bounces around corners.

I learned the following which will need to be incorporated into the next iteration:

  • The beam is too narrow.  I discovered this by testing outdoors with no walls to bounce off of.  The LEDs I bought were from China and did not have a complete datasheet.  Possible solutions are wider beam LED(s), angling them in such a way as to spread the beam, possibly reflect them with an umbrella as is sometimes done with a photographic flash.
  • Use more SMD components.  I would like to reduce the hand soldering.  Looking for a SMD enhancement MOSFET that can handle 1A at 3.3V and not overheat in a small enclosure plus IR LEDs that fit the spec.
  • Find an off the shelf enclosure and design around it.

The receiver PCBs and WS2812 PCBs should come in next week.

chicken likes this

Share this post


Link to post
Share on other sites

Good progress and tidy prototyping.

Interesting observation about the beam being too narrow. I wouldn't have expected that problem with bare LEDs. Angling will be tricky without visual verification.

Fmilburn likes this

Share this post


Link to post
Share on other sites

Once you start down the rabbit hole there is no end of unexpected things :smile:

I believe the ones I have are for TV remotes or something like that where the user aims the controller at the device and tight focus is desirable.  For example, here is the Everlight IR333A - my crude measurements show something similar:

Everlight_IR333-A.JPG.d66a2f3dc2d77c90eb1b6c9b8d99c7fb.JPG

My idea for angling would be to make the PCB something like this for the desired angles and bend the legs of the LED 90 degrees to point them in the right direction:

IR_LEDs.jpg.1ddd269f98b40e43498e6710064fdf76.jpg

This would not be a good solution if the goal is SMD and simplified manufacture of course.  Plus, it wouldn't fit neatly into a off the shelf enclosure.

Other LEDs can be purchased that have a wider beam.  For example there is a Kingbright  SMD 0605 LED that is good for 50 mA and has 50% relative radiant intensity out to 120 degrees.  Note that the example about had 50% relative radiant intensity only out to 20 degrees.  I would need a lot more of them but they should be easier to assemble than bending leads and through hole soldering.  It is also possible to get single LEDs rated at 1 Watt which might do the trick.

Another idea to reduce parts is to use resistor arrays instead of individual resistors.

Share this post


Link to post
Share on other sites

Project Closure

Here are the original objectives along with closure notes that may be of interest to some...

  • cost - unit cost for the receiver of $10 or less - The project came in at less than $10 for each receiver, even in small quantities.
  • technology - common off the shelf components, MSP430G2553 - The G2553 was more than adequate for the project.  Also used the TSOP38238 for infrared and the SK2812 for LEDs which are readily available and inexpensive.
  • construction - standard double sided PCB spec, keep SMD parts large enough to be hand soldered - I used OSH Park for the PCBs and 0805 components for the jelly bean parts.  Everything was hand soldered.  I did find it a bit difficult to hand solder the SK2812 and had to go back and retouch a number of them up.  Not sure why, the part is relatively large.
  • power - CR2032 (rated 3V and 225 mAH) - Worked well, even with the SK2812 which have a higher voltage on the datasheet and despite drawing 10 mA or more.
  • life - needs to run at least half an hour on fresh batteries - Battery life is easily an hour or more the way I am using it.  Current is on the order of 10 mA as noted above.
  • reception - 10m with clear line of sight, update at least every 100 ms - This is easily done provide there is line of sight and IR LEDs with sufficient beam width are chosen.  As noted in the thread above, multiple transmitters can be used which can help meet this requirement.
  • transmission - desirable but not required - I chose not to make the receivers capable of transmission.
  • size - 40mm/1.6" diameter for receiver - Easily done, see photos below.
  • programming - Energia desirable - The receivers were programmed in Energia as noted in the thread above.  The transmitter was programmed with CCS but I ended up using UART to communicate with it.  Accordingly, any computer or microcontroller with UART can be used to direct the transmitter.  This was actually one of the more interesting parts of the project and I may write a tutorial on the method at some point in future.
  • schedule - 6 month completion - It ended up taking 7 1/2 months but could have been done in half the time without my usual side tracks and procrastination.

Here are some shots of the finished parts...

596c325daab71_IMG_25412806.jpg.607e6e53ddcd88873966d617657d1720.jpg

Each receiver has a SK6812 soldered to it - it is lit red in the photo.  The onboard SK6812 is not used in this project, instead a string of SK61812s is soldered on the 0.1 inch pitch header on the right side of the board (Dout, GND, and 3V3).  The IR receiver is soldered to Pin 3, GND, and 3V3.  Other pins, labelled with Energia pin numbers, are also available to the user.  Programming access is at the top and I usually use Pogo pins although a male or female 0.1" pitch header could be soldered in.

596c33ae2deb1_IMG_25442804.jpg.0e3686b52fca199773410a23c379e234.jpg

The 2032 battery is inserted from the bottom.

596c341190771_IMG_25352808.jpg.3909eb878a4a6d5a84b45a134dc929f2.jpg

On earlier versions I used WS2812 LEDs already soldered to PCBs for the string that is hot glued into the tiaras but ended up making my own and soldering SK2812 LEDs to them for the final project.  The pins are "breadboard friendly".  SK2812s are essentially the same as WS2812s and "Neopixels".

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0