dubnet

Just wanted to take a moment and wish all the 43oh-ers a Happy New Year!     May the upcoming year be your best yet!

First of all, welcome to the forum.
 
The 5994 is a relatively new device and Energia will likely add support in the next release or so.  I think that I recall @@energia mentioning that a new release was forthcoming. However, he is the one that would be able to confirm support as well as give you a more exact time frame. 

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

@@yyrkoon
 
I am thinking of all kinds of things but the first is this...
 
Congratulations! You did it! You Delivered! Clients love it when you DELIVER! Good Job!!!
 
I am also thinking how you have begun to develop a process for doing various tasks. Things like this:
- How do I capture the client's requirements?
- How do I program a chip?
- How do I invoice the client?
- and so on ...
 
Once you have figured out one of those processes then I recommend writing it down immediately. Then you will remember how to do it next time. Also, you will be able to teach your employee how to do the same thing in the future.
 
I'm also thinking about liability. That is, this hush hush product is now out in the wild being used. Will it fail? When will it fail? How will it fail? Will someone get injured or die if it fails? If any of that happens then who will bear the liability for that unintended and unexpected event? For me, I have an insurance policy that covers me for "Errors and Omissions". That's the policy type.
 
And then I am always hunting for the next job or task. Who could or should I talk to to get more work?
 
I'm sure there are many other things that I could think about but it's important to celebrate the present successes first.
 
<fistbump>
Good Job!
 
This is awesome. Let's do some more of this!

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.

@@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 ...
 
http://forum.43oh.com/topic/2254-pronto-ir-code-transmission/
 
https://forums.adafruit.com/viewtopic.php?p=22714
 
-rick

@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

I spent some time last year setting up an analog meter driver/thermometer for a client, and at the time, I went through my stock of junk^H^H^H^Hreclaimed parts and found a phase angle meter with degree graduations on it. I said to myself "since I alredy wrote the code and did the dev work on someone elses dime, I should throw one together for myself". A year and a half later, the holidays hit and I was looking for something to do instead of paperwork for work.
 
So, I layed out a single sided board (the original was on a launchpad), cut it on the mill, and populated it.
 

 
There was a couple days in the middle between cutting and populating (the holiday, you know), so I had a surprise. The astute amongst you might notice something missing on this layout, given that this is a low power project that will require stable voltage for the analog meter. Yup. No regulator pads.Finished soldering up the board and sitting there in the tray is the regulator. Whoops. I didn't feel like going whole hog (including changing a setup on the mill) for a board just to hold the regulator and a couple caps, so I pulled out a sharpie, a scribe, and an ancient bottle of ferric chloride. 20 minutes later, I had an etched board that would do the job. Ugly, but functional. The layout for the main board will be revised in case I reuse it.


 
It doesn't look so bad populated.


 
The wire is for USB power.

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

What an enjoyable Sunday afternoon.

Seriously, I love debugging!
 

I stumbled across a really cool resource from Ford Motor Company tonight.
 
It's called EMC Online and it's located here: http://www.fordemc.com
 
Here's a copy-paste of their introduction:
 
======================
Forward
The quality and reliability of today's automobiles are dependent in part on its electrical system to operate as designed within the vehicle

personally I use the SPI method exclusively for the smart LEDs  (WS2812B, and sk6812 recently)  one trick for getting the timing to cooperate is to set the SPI divider to get you close then you can change the rate of the MCLK registers to fine tune the timing.  it only has to be changed while the SPI is transmitting so you can change the clock back to normal "speed" after your done with the transmission.

I think it would be a nice gesture on TI's part to refund, perhaps on a prorated basis, recent full price purchases of CCS.

So, does it work wiggling P2.4?
 
You can read and react to inputs within the interrupt, so there's not an absolute need to communicate with the main thread. E.g, within the ISR:
if(++timerCount > 1000) { timerCount = 0; if(pin indicates mode 1) { do 1 } else if (pin indicates mode 2) { do 2 } } An alternative approach is to use the ISR just to keep track of time, and move everything else into the main loop. You may add another flag to indicate that a second passed. e.g. in the ISR:
if (++timerCount > 1000) {   timerCount = 0;   secondFlag = 1; } Then in the main loop:
forever {   if(secondFlag == 1) { // wait for flag to be set   secondFlag = 0; // do whatever you need to do once a second } } You could maintain other flags if you need to support more time periods. Make sure to use the volatile keyword when declaring variables that you want to pass between the ISR and main loop.
 
An even more refined program structure would set a mode variable depending on inputs, then have a switch statement covering the different modes.
forever { if(secondFlag == 1) { secondFlag = 0;   mode = depending on input pins;   switch(mode) {      case 1:        do what we need to do for mode 1;       break;      case 2:       do what we need to do for mode 2;      break;     default:      do nothing;    } } } And just like that, you wrote your first state machine. You may move the secondFlag check into the case statements if the modes don't share the timing requirements.
 
PS: You clear the pin 2 interrupt flag (P2IFG) in your ISR. This register is not related to timer interrupts. So no need to clear it.
 
PS2: Busy-waiting in the main loop is not very efficient in regards to power consumption, but we will leave optimizing that to the very end when everything else works.

For transmitter / master, I was thinking more of something at this scale

The relevant keyword for Ebay is IR illuminator

Today I soldered the little nRF24L01 module onto an adapter and tried it out for the first time.  I cut a 28 pin 1.27 mm SOIC adapter in half and then soldered the castellated module onto it so that I could access the pins on 0.1" pitch. That way the antenna was cantilevered out and waving in the breeze.  It will be easy to adapt this to the wearable if selected.

I did have to go back and touch up one pad with the iron that didn't make a good connection.  After that, it was quick to get it going using the Energia library that @@spirilis wrote.  I put a G2553 LaunchPad on a BOOSTXL battery pack and then my homemade prototype on top of that with the radio and voila - something working in less than an hour.

The good news is that to my surprise I couldn't tell any difference in performance with this tiny breakout and the larger more commonly seen ones that I had used in the past - at least in this quick test.  Provided I set the radio speed to 250000 I was getting 10m pretty easily.  However, I had never really noticed how a human body can interrupt the signal and now that I was looking for it, sure enough it was there.  Still, it might be acceptable and I can try using a transmitter with a better antenna and see how much that helps.  If anyone has experience with those I would be interested.  I still need to do some tests on battery life with the CR2032.
 
Meanwhile, I looked a bit more into the ESP8266.  The form factor is OK, I can fit it all in.  0805 jellybeans will fit OK and the ESP8266 module is castellated so I can solder it by hand if desired.  All parts are readily available and inexpensive.  I need to look at setting up a wireless LAN and also battery life.

Although it may be something else, one thing you may want to try is lowering the SCL and SDA resistors down to 2-5K.  Depending on your bus capacitance, 10K resistors may not be strong enough pull ups.

Available from the main CCS download page. Final version due in December.
http://processors.wiki.ti.com/index.php/Download_CCS
 
Downloading now. It'll let you know how it goes...

@@yyrkoon
 
Joe and his brother built the company from the ground up. Their software was written in house. Their product is top notch. They are good people.
 
EEVBlog has done a teardown.
 
And another one here.
 
If the Saleae isn't your cup of tea then maybe you might like the Open bench Logic Sniffer instead?

Energia and Arduino users eventually get to the point where they need more direct access to the hardware if they take on more complicated projects.  In addition to the direct access of registers using the provided header files, TI offers DriverLib which contains abstractions for accessing the peripherals.
 
To better understand the peripherals, and to check out DriverLib, I recently created 20+ short examples for my own edification.  All of them were written for the MSP430F5529 LaunchPad and most of the peripherals are covered.  In some cases pushbuttons, LEDs, resistors, potentiometer, etc. are required that you probably have on hand.  A multimeter is required, and in some cases an oscilloscope and logic analyzer are instructive but not necessary.
 

DriverLib SPI Example 13A_USCI_B_SPI_MCP41010_digiPot
 
All of the examples are located here:  https://github.com/fmilburn3/MSP430F5529_driverlib_examples
 
It is necessary to have some understanding of the registers before using DriverLib because the DriverLib documentation doesn't describe how the peripherals and their registers work.  The documentation for registers is located in the User

Weighing in.... I purchased the 8 channel Saleae a while back when they offered the 43oh community a $25 discount. Didn't have a use for it at the time but since then it has saved me significant time and a lot of aggravation. The hardware is excellent but I feel the major strength is in their software. Overall, it is a superb product that I would highly recommend to anyone.

However, the clones that leverage the Saleae software concern me. If everyone were to buy these clones then Saleae would likely go under or have to invest money in their hardware/software to block the hardware clone vendors. They would probably have to add crypto to the hardware which, in turn, would increase the cost of their product to all their customers.

Perhaps I am in the minority anymore, but I don't buy knockoff hardware even though in the short term the lower pricing can be very attractive. In the long term I would be supporting companies that can take a product that has already been engineered by someone else, offer little to no support, typically use substandard components, and then sell it at a much lower cost. Adding to that I would be supporting the economies of countries that are potentially hostile to us.
 
EDIT:  Should have read @@zeke 's post first as what I was surmising is real time reality:
 
 
 

Weighing in.... I purchased the 8 channel Saleae a while back when they offered the 43oh community a $25 discount. Didn't have a use for it at the time but since then it has saved me significant time and a lot of aggravation. The hardware is excellent but I feel the major strength is in their software. Overall, it is a superb product that I would highly recommend to anyone.

However, the clones that leverage the Saleae software concern me. If everyone were to buy these clones then Saleae would likely go under or have to invest money in their hardware/software to block the hardware clone vendors. They would probably have to add crypto to the hardware which, in turn, would increase the cost of their product to all their customers.

Perhaps I am in the minority anymore, but I don't buy knockoff hardware even though in the short term the lower pricing can be very attractive. In the long term I would be supporting companies that can take a product that has already been engineered by someone else, offer little to no support, typically use substandard components, and then sell it at a much lower cost. Adding to that I would be supporting the economies of countries that are potentially hostile to us.
 
EDIT:  Should have read @@zeke 's post first as what I was surmising is real time reality:
 
 
 

Nick Gammon published an interesting post on using SPI on 16 MHz Arduinos to run WS2812 LEDs (aka neopixels) at: http://gammon.com.au/forum/?id=13357. He also provides a link with a lot of information about the NRZ protocol used by the WS2812 and tolerances:  https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/.  The tolerances are actually quite a bit looser than what I previously believed.  So, I set out to do something similar with Energia and LaunchPads running at different speeds.  Spoiler alert:  It works.
 
The previously linked articles provide all the background so minimal information is repeated here.  NRZ is a one wire protocol that transfers information to the LEDs by varying the length of the signal when high.  A longer pulse is used for a 1, and a shorter one for a 0.  The timing, with tolerances, is shown in the figure below.
 

The length between pulses cannot exceed about 5 us and most everything else is pretty loose.
 
The protocol is implemented using SPI which I find pretty clever.  A byte is sent out with the SPI module with the proper length to represent the desired bit for the protocol.  The following must be determined and set to do this:
Set proper SPI clock speed using SPI.setClockDivider() in Energia Determine the proper byte to send by SPI.transfer() in Energia to represent a 0 or 1 bit For example, using the MSP430F5529:
Clock speed is 25.6 MHz Setting the SPI clock divider to 4 gives a SPI clock of 6.4 MHz and since the SPI block executes in one cycle (Arduino executes in 2), each bit in the byte is equivalent to 156.25 ns. Therefore, to send a pulse indicating a "1", a byte equal to 0b1111000 could be used which gives 4x156.25 = 625 ns.  This is in the acceptable range of 550 to 850 ns. Similarly, for a 0 an acceptable byte would be 0b11000000 or 312.5 ns. A similar process can be used to determine acceptable values for the MSP430G2553.
 
The sketch below is a simplification of the library presented by Nick which and includes the modifications described above to run on both the G2553 and F5529.  The preprocessor is used to set appropriate values for the clock divider and long and short bytes.   The functions are very nearly the same as posted by Nick.  Note that interrupts must be disabled before sending data and then reenabled manually after.
/* * WS2812 display using SPI on various TI LaunchPads with Energia * * Connections: * LaunchPad LED Strip * --------- --------- * 3V3 5VDC * Pin 15 (MOSI) DIN * GND GND * * How to use: * ledsetup (); - Get ready to send. * Call once at the beginning of the program. * sendPixel (r, g, ; - Send a single pixel to the string. * Call this once for each pixel in a frame. * Each colour is in the range 0 to 255. Turn off * interrupts before use and turn on after all pixels * have been programmed. * show (); - Latch the recently sent pixels onto the LEDs . * Call once per frame. * showColor (count, r, g, ; - Set the entire string of count Neopixels * to this one colour. Turn off interrupts before use * and remember to turn on afterwards. * * Derived from NeoPixel display library by Nick Gammon * https://github.com/nickgammon/NeoPixels_SPI * With ideas from: * http://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/ * Released for public use under the Creative Commons Attribution 3.0 Australia License * http://creativecommons.org/licenses/by/3.0/au/ * * F Milburn November 2016 * Tested with Energia V17 and WS2812 8 pixel strip on launchpads shown below. */ #include <SPI.h> #if defined(__MSP430G2553) #define SPIDIV SPI_CLOCK_DIV2 // 16 MHz/2 gives 125 ns for each on bit in byte #define SPILONG 0b11111100 // 750 ns (acceptable "on" range 550 to 850 ns) #define SPISHORT 0b11100000 // 375 ns (acceptable "on" range 200 to 500 ns) #elif defined(__MSP430F5529) #define SPIDIV SPI_CLOCK_DIV4 // 25.6 MHz/4 gives 156.25 ns for each on bit in byte #define SPILONG 0b11110000 // 625 ns (acceptable "on" range 550 to 850 ns) #define SPISHORT 0b11000000 // 312.5 ns (acceptable "on" range 200 to 500 ns) #else #error This microcontroller is not supported #endif const unsigned int PIXELS = 8; // Pixels in the strip void setup (){ ledsetup(); } void loop (){ // Show a solid color across the strip noInterrupts(); // no interrupts while sending data showColor (PIXELS, 0xBB, 0x22, 0x22); // single color on entire strip interrupts(); // interrupts are OK now delay(1000); // hold it for a second // Show a different color on every pixel noInterrupts(); // no interrupts while sending data sendPixel(0xBB, 0x00, 0x00); // red sendPixel(0x00, 0xBB, 0x00); // green sendPixel(0x00, 0x00, 0xBB); // blue sendPixel(0xBB, 0xBB, 0xBB); // white sendPixel(0xBB, 0x22, 0x22); // pinkish sendPixel(0x22, 0xBB, 0x22); // light green sendPixel(0x22, 0x22, 0xBB); // purplish blue sendPixel(0x00, 0x00, 0x00); // pixel off interrupts(); // interrupts are OK now delay(1000); // hold it for a second } // Sends one byte to the LED strip by SPI. void sendByte (unsigned char { for (unsigned char bit = 0; bit < 8; bit++){ if (b & 0x80) // is high-order bit set? SPI.transfer (SPILONG); // long on bit (~700 ns) defined for each clock speed else SPI.transfer (SPISHORT); // short on bit (~350 ns) defined for each clock speed b <<= 1; // shift next bit into high-order position } // end of for each bit } // end of sendByte // Set up SPI void ledsetup(){ SPI.begin (); SPI.setClockDivider (SPIDIV); // defined for each clock speed SPI.setBitOrder (MSBFIRST); SPI.setDataMode (SPI_MODE1); // MOSI normally low. show (); // in case MOSI went high, latch in whatever-we-sent sendPixel (0, 0, 0); // now change back to black show (); // and latch that } // end of ledsetup // Send a single pixel worth of information. Turn interrupts off while using. void sendPixel (unsigned char r, unsigned char g, unsigned char { sendByte (g); // NeoPixel wants colors in green-then-red-then-blue order sendByte (r); sendByte (; } // end of sendPixel // Wait long enough without sending any bits to allow the pixels to latch and // display the last sent frame void show(){ delayMicroseconds (9); } // end of show // Display a single color on the whole string. Turn interrupts off while using. void showColor (unsigned int count, unsigned char r , unsigned char g , unsigned char { noInterrupts (); for (unsigned int pixel = 0; pixel < count; pixel++) sendPixel (r, g, ; interrupts (); show (); // latch the colours } // end of showColor The timing, when checked on a logic analyzer, checks out with the calculations above (hooray for math).  The "gaps" between pulses are within tolerance and largely set by code overhead as well as the byte being sent.
 


And here it is showing the strip lit up in one color.
 

I tried this on several other LaunchPads I had handy and here is a summary:
FR6989 - I had never noticed, but Energia defaults to 8 MHz.  Doing the math, there isn't a good match to the WS2812 requirements without changing processor speed (which I did not try). MSP432 - there was behavior I couldn't explain, probably due to RTOS and I didn't pursue this for long. In summary, the method works although I did limited experimentation.  It would be even easier to implement outside of Energia with full access to clocks.  It was an interesting exercise but alternative methods have been posted here on 43oh with tuned assembler and having used those successfully in the past, I will probably continue to preferentially use them in the future.

Why don't you just set up a timer interrupt and implement the fancy 16/24 bit UART using software running in the interrupt?
 
If you're using 1200baud, that's 1 bit every 833uS. On a MSP430 running at 8MHz, that's one interrupt every 6000 clock cycles (8000000/1200 = 6000). If your interrupt routine takes an average of 100 cycles to complete, you're using 1.5% of the CPU cycles for the UART (((1200 * 100) / 1000) = 0.015).
 
Recall that the original MSP430 LaunchPad shipped with the MSP430G2231 which does not have a hardware UART peripheral, so all the serial port examples for it were using a bit bang driver. It should be very trivial to look through the existing examples for software UARTs for the LaunchPad and find one you like that you should then be able to modify the bit counter to send 16 or 24 bits instead of 8.

Welcome to the forum!
 
Embedded work can be a lot of fun. Enjoy the forum.