There is no white for LED color?
- Thread starter Wolfie
- Start date
In another thread you had commented that while the controller shows white LED's during programming, white is absent from the timeline editor.
Put some dead or nearly-dead batteries in your controller. The LED's will be pink instead of white during programming mode. Due to the low forward-voltage and high lumens characteristic of red LED's, the red LED tends to overpower the other LED's as the battery drains. Were we to offer white as an option to customers, we would soon receive thousands of support ticket complaints from customers telling us that their controller LED's are pink when they picked white from the color picked in the macro software.
It was not economical to install an additional voltage-booster circuit. For that matter, most voltage-booster circuits require a different chemical composition of battery cell than what Microsoft supplies. I can't remember the specifics (it's all in the datasheets if you want to spend that much time researching it), but the gist here is that the Microsoft packs are ****ty quality, and thus not capable of providing the higher amps required for a booster circuit to boost the voltage well above the forward-voltage of the green and blue LED's. Most voltage-booster IC's provided on the market are compatible with cell phone quality batteries.
A couple months back I tried desperately to boost the 2.3V-2.6V provided by the Microsoft battery pack, but could not, and after heavy research it basically ends up the Microsoft pack cannot be used with the low cost voltage boosters. That's the problem here, while AA's put out a nice 3.0 volts fully charged, and around 2.6-2.7V dead, the Microsoft battery pack only puts out 2.6V fully charged and as low as 2.0 Volts when dead. Hit up the datasheets for most blue LED's and you are not going to find a forward-voltage that low for blue. Hit up the datasheets for 1206-sized RGB LED's (the size required to fit underneath the "light tube" inside the Microsoft controller) and you won't find any LED's that have a forward-voltage that is truly compatible with Microsoft packs.
Therefore we made the decision not to allow white as a color in the GUI software. Since our hardware is not really capable of maintaining a nice true white throughout the entire range of voltages that are coming from customer batteries. 2.0v-3.0v is too wide of a variable range to deal with. There are simply too many variables and curves to reliably produce white over the whole battery range.
Perhaps if I had a whole lab full of technicians in a dark lab who could create highly accurate luminescence vs voltage curves for all of the LED's, we could create some translation curves to dim our LED's to compensate for the variation in voltage as the voltage changes. Ahh, but then you get into another set of issues with analog-to-digital conversion. It is difficult for this particular MCU to accurately determine the voltage of the power source. The MCU does have a 'steady' internal voltage reference that can be used to compare to the power supply, but dig into the electrical specifications of the MCU and that internal voltage reference actually tends to be pretty variable, in terms of the accuracy required to compensate for LED dimming due to variable voltage source!
Again sorry I do not have time to make a proper case for this with charts and graphs and formulas. We need some sort of drawing tool in the forums.
Put some dead or nearly-dead batteries in your controller. The LED's will be pink instead of white during programming mode. Due to the low forward-voltage and high lumens characteristic of red LED's, the red LED tends to overpower the other LED's as the battery drains. Were we to offer white as an option to customers, we would soon receive thousands of support ticket complaints from customers telling us that their controller LED's are pink when they picked white from the color picked in the macro software.
It was not economical to install an additional voltage-booster circuit. For that matter, most voltage-booster circuits require a different chemical composition of battery cell than what Microsoft supplies. I can't remember the specifics (it's all in the datasheets if you want to spend that much time researching it), but the gist here is that the Microsoft packs are ****ty quality, and thus not capable of providing the higher amps required for a booster circuit to boost the voltage well above the forward-voltage of the green and blue LED's. Most voltage-booster IC's provided on the market are compatible with cell phone quality batteries.
A couple months back I tried desperately to boost the 2.3V-2.6V provided by the Microsoft battery pack, but could not, and after heavy research it basically ends up the Microsoft pack cannot be used with the low cost voltage boosters. That's the problem here, while AA's put out a nice 3.0 volts fully charged, and around 2.6-2.7V dead, the Microsoft battery pack only puts out 2.6V fully charged and as low as 2.0 Volts when dead. Hit up the datasheets for most blue LED's and you are not going to find a forward-voltage that low for blue. Hit up the datasheets for 1206-sized RGB LED's (the size required to fit underneath the "light tube" inside the Microsoft controller) and you won't find any LED's that have a forward-voltage that is truly compatible with Microsoft packs.
Therefore we made the decision not to allow white as a color in the GUI software. Since our hardware is not really capable of maintaining a nice true white throughout the entire range of voltages that are coming from customer batteries. 2.0v-3.0v is too wide of a variable range to deal with. There are simply too many variables and curves to reliably produce white over the whole battery range.
Perhaps if I had a whole lab full of technicians in a dark lab who could create highly accurate luminescence vs voltage curves for all of the LED's, we could create some translation curves to dim our LED's to compensate for the variation in voltage as the voltage changes. Ahh, but then you get into another set of issues with analog-to-digital conversion. It is difficult for this particular MCU to accurately determine the voltage of the power source. The MCU does have a 'steady' internal voltage reference that can be used to compare to the power supply, but dig into the electrical specifications of the MCU and that internal voltage reference actually tends to be pretty variable, in terms of the accuracy required to compensate for LED dimming due to variable voltage source!
Again sorry I do not have time to make a proper case for this with charts and graphs and formulas. We need some sort of drawing tool in the forums.
Wolfie
Member
Have you tried looking at the TPS61200 voltage converter? It can do 600mA at 5v out from a single source cell. Plenty for an LED. Anyway, you are not using tri-color RGB LEDs? I haven't seen the guts of the unit but you are using 3 discreet LEDS instead of a single tri-color LED? If so, I believe you can compensate for the different drive and efficiencies by using different current limiting resistors for the 3 colors. And yea, I know the green and blue LEDs are less effecient since the wavelengths are significantly shorter for the higher color bands than the IR and red LEDs.
Actually, over the weekend I did notice that the color of the LEDs changed as the battery drained and was distinctly different from when the CnP connector was attached as a power source. I had set my page for yellow and noticed it was distinctly orange in reality. I also noticed that the 4th player LED was different in color than all the others with anything but a full battery.
I will have to see about running the controller using my Maha Imedon 2400mAh low self discharge NiMH AAs I use with my camera equipment and see if the run time and LED color characteristics are better. If so, I can see about availability of them with solder tabs to replace my older Microsoft packs. Or just order more AA holders for my controllers
I still need to get a really small SPST NC pushbutton switch to mod the AA holder pack for easy resetting of the controller.
Actually, over the weekend I did notice that the color of the LEDs changed as the battery drained and was distinctly different from when the CnP connector was attached as a power source. I had set my page for yellow and noticed it was distinctly orange in reality. I also noticed that the 4th player LED was different in color than all the others with anything but a full battery.
I will have to see about running the controller using my Maha Imedon 2400mAh low self discharge NiMH AAs I use with my camera equipment and see if the run time and LED color characteristics are better. If so, I can see about availability of them with solder tabs to replace my older Microsoft packs. Or just order more AA holders for my controllers
I still need to get a really small SPST NC pushbutton switch to mod the AA holder pack for easy resetting of the controller.
I'll post in two posts as I sort of have two topics. Topic#1 : the booster you proposed looks great on paper, not so great in this application.
I didn't look for single inverters nor any units high in the price range. Single-channel voltage converter is simply not an option due to cost and board space limitations, need a multi-channel in a package that is capable of working with Alkalines, NiMh and LiIon.
Component: TPS61200
Quantity pricing: $1.24/ea
Quantity needed per LED: 1
Number of LED's per macro controller: 12 (4 player LED's x 3 separate colors in each RGB package)
Total additional cost (excluding assembly and passive components): 12 x $1.34 = $16.08
Component : 2.2uH inductor for boost circuit (needs a high amp rating, refer to datasheet) such as LQH3NP
Quantity pricing: $0.143/ea
Quantity needed per macro controller: 12
Simple Cost added to macro controller, excluding additional assembly costs, shipping, inventory, design/prototyping/production re-tooling, etc. etc.: $16.60
Now, if you can find me a space inside of the XBOX360 controller where I can fit a bank of twelve 3mm x 3mm inductors, as well as twelve 3mm x 3mm SON-10 TI booster chips, as well as enough board space for passives/resistors, then you sir are a savant.
By the time it's over we would have invented a giant $30 flexible circuit board that has to be carefully crammed into the controller so that all the large 3mm x 3mm components fit when the controller shell is closed.
I didn't look for single inverters nor any units high in the price range. Single-channel voltage converter is simply not an option due to cost and board space limitations, need a multi-channel in a package that is capable of working with Alkalines, NiMh and LiIon.
Component: TPS61200
Quantity pricing: $1.24/ea
Quantity needed per LED: 1
Number of LED's per macro controller: 12 (4 player LED's x 3 separate colors in each RGB package)
Total additional cost (excluding assembly and passive components): 12 x $1.34 = $16.08
Component : 2.2uH inductor for boost circuit (needs a high amp rating, refer to datasheet) such as LQH3NP
Quantity pricing: $0.143/ea
Quantity needed per macro controller: 12
Simple Cost added to macro controller, excluding additional assembly costs, shipping, inventory, design/prototyping/production re-tooling, etc. etc.: $16.60
Now, if you can find me a space inside of the XBOX360 controller where I can fit a bank of twelve 3mm x 3mm inductors, as well as twelve 3mm x 3mm SON-10 TI booster chips, as well as enough board space for passives/resistors, then you sir are a savant.
By the time it's over we would have invented a giant $30 flexible circuit board that has to be carefully crammed into the controller so that all the large 3mm x 3mm components fit when the controller shell is closed.
The LED's are a "1210" package, RGB LED's. Inside each package is a separate red, green, and blue LED. The issue is not LED efficiency, but the high forward voltage of the blue and the green LED's. As the battery gets low, the LED is basically shutting off.
There are 4 player LED's on the XBOX360 controller, and each LED consists of red-green-blue. So really our circuit board we installed has 12 LED's on it.
We are using an NXP PCA9635 to drive the LED's. Each LED is individually dimmable, with a resolution of 8-bits. In other words we are sorely underutilizing the capability of these LED's by limiting the customer to 16 color choices -- with the advantage that we are reducing "false alarm" tech support requests by the thousands. We've been meaning to unlock a secret, advanced color-mixing control panel with a disclaimer to more advanced users to play with.
The NXP PCA9635 is a 16-channel, 8-bit LED driver with individual brightness control on each channel http://www.nxp.com/documents/data_sheet/PCA9635.pdf
Also I just realized in my previous example we could probably get by with only 8 boosters and not 12, since we don't need to boost red. However some real serious bench testing would need to be done to ensure that the NXP PCA9635 feeding into the TI booster works without some sort of performance issue or somehow exceeding electrical specifications. Those booster chips are a lot more finicky than their datasheet leads you to believe.
There are 4 player LED's on the XBOX360 controller, and each LED consists of red-green-blue. So really our circuit board we installed has 12 LED's on it.
We are using an NXP PCA9635 to drive the LED's. Each LED is individually dimmable, with a resolution of 8-bits. In other words we are sorely underutilizing the capability of these LED's by limiting the customer to 16 color choices -- with the advantage that we are reducing "false alarm" tech support requests by the thousands. We've been meaning to unlock a secret, advanced color-mixing control panel with a disclaimer to more advanced users to play with.
The NXP PCA9635 is a 16-channel, 8-bit LED driver with individual brightness control on each channel http://www.nxp.com/documents/data_sheet/PCA9635.pdf
Also I just realized in my previous example we could probably get by with only 8 boosters and not 12, since we don't need to boost red. However some real serious bench testing would need to be done to ensure that the NXP PCA9635 feeding into the TI booster works without some sort of performance issue or somehow exceeding electrical specifications. Those booster chips are a lot more finicky than their datasheet leads you to believe.
The "1210" package RGB LED's are bigger than the single 0603 LED's that they replaced. The "light tube" (the round clear plastic surrounding the Big "X" guide button) is designed with 0603 in mind. If the 1210's are not centered just perfectly under the light tube, the color mixing can vary. This is the main reason we do not offer a user color-mixing module in our software. As you start to mix away from bold colors, the mixing and reproduction varies greatly from one quadrant to the other no thanks to the light tube being same size or slightly smaller than the LED's.
Wolfie
Member
Why in tarnation would you need one per color per LED? The 1210 packages are common anode, you only need one supply per LED package. Don't you modulate the cathode of the LED from your PIO pin(s)? And you wouldn't need one per LED package either. The typ forward bias is 20mA per LED, thats a max of 60mA per package and even if you over biased it for higher luminance you are only takling in the 100mA range for each of 4 packages, no?
The TPS61201 is the 3.3v version of the chip and puts out 300ma @ 3.3v. If you are biasing the LEDs at the rated forward current, thats a max of 240mA for all 12 LEDs at full brightness. That leaves you with 60mA of overhead. Or am I looking at this wrong?
I haven't seen your board so I am flying in the blind here.
My CameraAxe (a Arduino based device for triggering flashes/cameras for high speed photography) uses the TPS61200. Its enough to power an LCD panel, the cpu, all circuitry, optoisolators for 2 outputs, supply 5v for two sensors, both of which can be lasers or motor controls. It is powered by a single LIPO battery and a single TPS61200. I can't imagine that your 4x3 LEDs consume more power than my CameraAxe does with 2 laser pointer diodes consuming 30mA each plus powering +5v to the entire Arduino board.
Here is the CameraAxe schematic in case it helps.
And I don't expect you to change your current design. Just offering thoughts for the next version.
The TPS61201 is the 3.3v version of the chip and puts out 300ma @ 3.3v. If you are biasing the LEDs at the rated forward current, thats a max of 240mA for all 12 LEDs at full brightness. That leaves you with 60mA of overhead. Or am I looking at this wrong?
I haven't seen your board so I am flying in the blind here.
My CameraAxe (a Arduino based device for triggering flashes/cameras for high speed photography) uses the TPS61200. Its enough to power an LCD panel, the cpu, all circuitry, optoisolators for 2 outputs, supply 5v for two sensors, both of which can be lasers or motor controls. It is powered by a single LIPO battery and a single TPS61200. I can't imagine that your 4x3 LEDs consume more power than my CameraAxe does with 2 laser pointer diodes consuming 30mA each plus powering +5v to the entire Arduino board.
Here is the CameraAxe schematic in case it helps.
And I don't expect you to change your current design. Just offering thoughts for the next version.
Wolfie. Thank you. Having a brain fart here (running on about 4-5 hours a sleep per night between two jobs, a newborn baby, and my whole Viking staff on vacation). Our LED's are hooked up with common anode and the LED driver IC acting as a current sink for all twelve cathodes. The LED's total at full brightness are consuming less than 250 mA (the limitation is the MCU anyway, digital I/O pins on this MCU can only sink 25mA max and there is a rating for all I/O pins combined). So a single booster should work perfectly. This looks more promising. I don't have the part # of the booster I was trying to get to work a couple weeks ago, but I never could get it to work and it turns out that it wasn't compatible with most battery types.
I will have to order up on of these TI units for bench testing and give it another go. Not something we would implement in the current macro controller (I just finished a new revision to the LED board about 2 months ago, that's when I was playing with a booster circuit) but definitely something I'd like to use in any future products. Of courseassuming Microsoft continues with change-able battery packs. The PS3 controllers for example use an internal 3.7v LiIon cell and there's no need for boosting the voltage for the LED's).
Wolfie keep giving me good ideas, I don't want you to go into business and become our competition.
Wish I had found this TI part the first time I was looking around for components!
I will have to order up on of these TI units for bench testing and give it another go. Not something we would implement in the current macro controller (I just finished a new revision to the LED board about 2 months ago, that's when I was playing with a booster circuit) but definitely something I'd like to use in any future products. Of courseassuming Microsoft continues with change-able battery packs. The PS3 controllers for example use an internal 3.7v LiIon cell and there's no need for boosting the voltage for the LED's).
Wolfie keep giving me good ideas, I don't want you to go into business and become our competition.
Wish I had found this TI part the first time I was looking around for components!
Wolfie
Member
Whew. I thought I was missing something really obvious.
Trust me, not happening. Promise. I have too much happening right now anyway. Got a 9-5. Not interested in starting a modding company. I do want to get a photography studio off the ground in the next couple years and that is what I have invested my time and money in for equipment (20k and counting). Want to get into product photography and sports team shots for local schools. With that and 4 granddaughters living next door (literally) and all their associated sports and activities, I am not touching the modding scene as a business. Got a full slate already.