chicken

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.

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.

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.

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:

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:

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:

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:

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.

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.

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.

Now here's a set of fancy booster packs! It's a fully integrated automotive radar.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/awr/awr-tools-software.page#tools

Those rectangles on the right with wiggly traces to the IC are the radar antenna. RF magic!

The "CAUTION HOT SURFACE" warning label also promises excitement. Too bad they will cost $299 according to the press release.
Posting in the ARM sub-forum as the radar IC features an R4F ARM core. Though the booster packs probably work with beefier MSP430 LaunchPads too.
Edit: Here's the mmWave landing page. The AWR also has the non-automotive sibling IWR, including similar booster packs.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/mmwave-overview.page
 
 

Unless you care about portability to Atmel Arduinos, there's no need to use progmem with Energia. The compiler will put anything that's declared as const into flash memory.

For a bit of background:
Atmel AVR (the chip in the original Arduino) has a Harvard Architecture, which separates program memory (i.e. Flash) from data (i.e. RAM). It uses special assembly commands to read program memory. That's why you need to tell the compiler if you want to store a variable in Flash or access data that's stored in Flash.
Most other MCUs have a Von Neumann architecture with a unified address space for all types of memory. All access to memory can use the same commands and the compiler decides on where to put things, depending on whether a variable is read-only (Flash) or read-write (RAM).
To maintain compatibility with code written for AVR, Energia and other non-AVR Arduino implementations replace progmem related commands to basically do nothing without having the compiler complain too much. For the MSP430 see:
https://github.com/energia/Energia/blob/master/hardware/msp430/cores/msp430/avr/pgmspace.h
The warning you see is because the replacement for pgm_read_word casts your int to a short.
#define pgm_read_word(addr) (*(const unsigned short *)(addr)) If you want to get rid of the warning while keeping pgm_read, you could declare your array as an unsigned short instead of int.
 

Now here's a set of fancy booster packs! It's a fully integrated automotive radar.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/awr/awr-tools-software.page#tools

Those rectangles on the right with wiggly traces to the IC are the radar antenna. RF magic!

The "CAUTION HOT SURFACE" warning label also promises excitement. Too bad they will cost $299 according to the press release.
Posting in the ARM sub-forum as the radar IC features an R4F ARM core. Though the booster packs probably work with beefier MSP430 LaunchPads too.
Edit: Here's the mmWave landing page. The AWR also has the non-automotive sibling IWR, including similar booster packs.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/mmwave-overview.page
 
 

Now here's a set of fancy booster packs! It's a fully integrated automotive radar.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/awr/awr-tools-software.page#tools

Those rectangles on the right with wiggly traces to the IC are the radar antenna. RF magic!

The "CAUTION HOT SURFACE" warning label also promises excitement. Too bad they will cost $299 according to the press release.
Posting in the ARM sub-forum as the radar IC features an R4F ARM core. Though the booster packs probably work with beefier MSP430 LaunchPads too.
Edit: Here's the mmWave landing page. The AWR also has the non-automotive sibling IWR, including similar booster packs.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/mmwave-overview.page
 
 

Now here's a set of fancy booster packs! It's a fully integrated automotive radar.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/awr/awr-tools-software.page#tools

Those rectangles on the right with wiggly traces to the IC are the radar antenna. RF magic!

The "CAUTION HOT SURFACE" warning label also promises excitement. Too bad they will cost $299 according to the press release.
Posting in the ARM sub-forum as the radar IC features an R4F ARM core. Though the booster packs probably work with beefier MSP430 LaunchPads too.
Edit: Here's the mmWave landing page. The AWR also has the non-automotive sibling IWR, including similar booster packs.
http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/mmwave-overview.page
 
 

For a bit of background:
Atmel AVR (the chip in the original Arduino) has a Harvard Architecture, which separates program memory (i.e. Flash) from data (i.e. RAM). It uses special assembly commands to read program memory. That's why you need to tell the compiler if you want to store a variable in Flash or access data that's stored in Flash.
Most other MCUs have a Von Neumann architecture with a unified address space for all types of memory. All access to memory can use the same commands and the compiler decides on where to put things, depending on whether a variable is read-only (Flash) or read-write (RAM).
To maintain compatibility with code written for AVR, Energia and other non-AVR Arduino implementations replace progmem related commands to basically do nothing without having the compiler complain too much. For the MSP430 see:
https://github.com/energia/Energia/blob/master/hardware/msp430/cores/msp430/avr/pgmspace.h
The warning you see is because the replacement for pgm_read_word casts your int to a short.
#define pgm_read_word(addr) (*(const unsigned short *)(addr)) If you want to get rid of the warning while keeping pgm_read, you could declare your array as an unsigned short instead of int.
 

A while back I damaged two pins on this board and dutifully marked it on the back.  Unfortunately it was only visible from the back.  Some time later I picked it up and was trying to use it unsuccessfully. After tearing my hair out for a while I eventually turned it over and noticed the markings.  Now it is marked front and back.

exactly, and the second diode to make it fool-proof

I guess the forward diode is to bypass the 10k resistor when the MCU draws more than 70uA. That's a great trick to remember.

The example msp430fr5994x_lpm4-5_02.c is supposed to show how little current is used in this mode.
In the file it says:
//   MSP430FR5x9x Demo - Entering and waking up from LPM4.5 via P1.3 interrupt
//                       with SVS disabled
//
//   Description: Download and run the program. When entered LPM4.5, no LEDs
//                should be on. Use a multimeter to measure current on JP1 and
//                compare to the datasheet. When a positive voltage is applied
//                to P1.3 the device should wake up from LPM4.5. This will enable
//                the LFXT oscillator and blink the LED (on P1.0).
Even for a high-end multimeter this current is too low to be accurately measured. 
So I helped myself this way: 
- power the processor from the supercap
- a 10k resistor with two antiparallel diodes act as a shunt,  
- connect the volt meter across the supercap, not across the processor
0.43mV over a 10k resistor gives 43 Nanoamps. (!)   Yes, the datasheet (page 32) is right, typical value at 25°C is 45nA.  
A  CR2032 (200mAh) cell would allow the processor to wait for an interrupt  for 530 years. 

Hi @wanliban
Datasheet numbers are hard (impossible?) to hit, especially when the signal comes from a real world target rather than a piece of lab equipment. But you should definitely be able to achieve better than -70 dBm.
First thing: What does -70 dBm mean in your setup? The level at which you are able to receive any valid messages? Level at which you receive 50% of all messages? 80%? Real world targets or controlled signal from an RF generator?
You can find my radio_config file and software on GitHub: https://github.com/astuder/dAISy
Hardware wise, keeping noise out is very important. A bandpass filter in front of the radio helps a lot. Also make sure to minimize the self-inflicted noise by having continuous ground planes in the RF section and keeping the radio away from noisy circuits (like USB). If testing with real-world signals, make sure to use a proper VHF antenna (i.e. not a short rubber duck) and keep the antenna away from other electronics (e.g. monitors or LED and fluorescent light fixtures).
Also follow Silabs' procedures for RX LNA matching (AN643) and layout recommendations (AN414)
I hope this helps.

Late into this thread, and I haven't read it top to bottom, but there seems to be a slight conceptual gap developing regarding what C & C++ really are.
They are languages, not environments. The C language was originally designed for telephone exchange testing & control. Subsequently, it was used to implement the early UNIX kernels. There is a "C Standard Library", which is distinct from the language proper - this is where printf etc. come from.
The story is similar with C++ - the language is distinct from its support libraries, e.g. stdlib, STL, and the various boost libraries.
A huge amount of apocrypha and mis-information surrounds these languages and the pros and cons of their various implementations - most of the arguments are bogus and ill-informed. The truth is, IMHO, far more boring - that they each have pluses and minuses.
The main differences are that C++ is geared to a more object-orientated design methodology, and generally, the mindsets used are different, which is why some feel that teaching people C, then C++ is a bad plan.
When mis-used, C++ can be memory-hungry, which is one some decry its use for embedded work - I feel that this is a fallacy - C++ is absolutely fine for embedded work (I use it all the time), if you understand the consequences of your actions - C++ is a far more powerful & capable language than C, but with great power comes great responsibility (*) - blaming the language for your poor understanding of the consequences of your actions is not an excuse. C++ is easy to abuse, C can be plain dangerous...
An analogy I like to use is the difference between "mathematicians" and "people who do mathematics".
A mathematician has an intuitive grasp of numbers and mathematics - they can visualize the problem they are working on and come up with novel ways of solving it; further, when presented with a left-field/previously unseen problem, they will see ways of dealing with and solving that.
Someone who does maths, OTOH, knows how to follow rules and can solve problems that are related to problems that they have encountered before, but may have real issues dealing with a novel puzzle..
Same with programmers. There's a world of people who can do C or C++ and have used the support libraries - that does not make them good or even half-decent programmers.
In my career, I have found very very few genuinely good programmers - people who understand architectural issues, who can see solutions, who can visualise novel approaches and solutions, who understand and then, very importantly, can implement with excellence - it's the difference between a programmer (rare beast), and journeymen who know how to program (common as anything).. 
 
Note: I was involved in the ANSI C process and have been an editor or cited as a contributor to various C++ related books, including Scott Meyers' "Effective STL" etc Spent 30 years in the City of London and elsewhere as a CTO, designing, developing and implementing some of the world's largest real-time equity, derivative & FX exchange trading systems, mostly in C & C++.
(*) Attributed to Ben Parker, Peter Parker's uncle...

OK, I think I get it now.  I new the rom_map.h header selected the hardware or software version, but I really didn't look into what it was doing.  I was assuming it determined whether or not my rom could support it.  Turns out, one must include the rom header before the rom_map header.  If I do that (or replace MAP_ with ROM_), I don't need any delays to get it to work correctly....So I think Clavier is spot on.
The flip side is that the rom version is significantly slower than the software versions.  So I guess the price one is paying for a reduced code size, is speed?  I guess I get that.
                                                      9/10 bytes              66 bytes
pyCrc                                             13us                         13us
driverlib software Crc                     11us                          27us
rom Crc                                          16us                          74us

Thanks for the ideas.  Energia uses the WDT for other purposes, as such I didn't put it in my code.  However, I just stuck it in and that doesn't help.  I did try getting rid of the MAP_ stuff and that didn't help either.  I also noticed that the example defined the returned crc value as volatile, so I changed that, but it didn't help either.
I missed the 1-clock cycle note.  As such, I changed my 1 microsecond delay to a 1 cycle delay and the code works fine.  I'm guessing that must be the issue. 

I wonder if there's some aggressive compiler optimization going on. The compiler wouldn't know what's happening inside the ROM functions and may put function calls out of order. Maybe worth a try to see if it works with straight calls to the driver lib (i.e. dropping the MAP_ prefix).
PS: The reference manual says, that CRC result is available after 1 clock cycle. Also no mention of CRC issues in the errata.

Sure, I get it. Like you, I guess I am just more used to using C most of the time, but I still like many aspects of C++, as well as other languages.
It's kind of funny, I was watching a youtube video the other day before bed, and I forget the speakers name( He's pretty well known, I should remember his name, but I dont - I'm not a "fanboy" that way ), where he was explaining why C++ was what he considered the better choice for embedded software development. Then he showed a chart from the last 10-15 years. Which showed C graphing upwards, while C++ was trending downwards . . . Ah right, Dan Saks, but his contention is that C++ is better than C, and I completely disagree with that. I think every language has it's place, and for different people, that will skew one direction or another.
But there is a reason why you will never, at least within the near future, see any C++ code in the Linux kernel.
 
 

I don't try to convince anybody. I'm way too busy myself to unlearn bare metal C.
But I thought the video will be relevant for people that venture down the rabbit hole.

Didn't know you posted, heh been super busy with the day job building a monitoring system for the company, in addition to building an update system( for our own software )from scratch . . . pretty interesting stuff, and I learned A  LOT about systemd services + timers, but without actually getting into the architecture of it all. It's a nightmare trying to visualize all this in your head.
Chicken, I've come to realize that that for myself, C is the only real way to go with embedded design. I personally find C++ good for when you need to use a lot of strings, and perhaps other various constructs, it can be ok to work with. But when you need all out performance, C will usually be the best option. Unless you're super proficient with C++, and you write all of, or at least all of the important code from scratch. Same goes for C though really. An example would be my two process application where I needed to share a file between the two halves, and I wrote my own binary file lock. Because the C std API calls were all way too slow.
 
EDIT:
Oh, and you can bet I will eventually get around to watching the video.

Here's some more C++ magic which seems applicable to embedded programming.
I think he optimized for speed instead of space (using tons of mov instead of a loop to initialize sprite bitmaps). But a lot of impressive optimization by the compiler.
On the downside, I didn't understand half the constructs he was using. I guess I need to relearn C++ 
via embedded.fm podcast