RGB dashboard backlight, PCB's are in!

[ivan141]

@Masterkorp: thanks! I'll put up a new vid of the boards once I get the connectors I need to link up the other boards.
The little row of led's on the left are the last 6 of 16 tach backlight led's. Those are pixel adressable.
I could let them change color with RPM, lower the redline (no reason though), have a colored dot follow the needle.
Wherever you imagination takes you ( with a bunch of leds that is ).

I'm more excited about the needle backlight boards, and having the needle change color. Should have a more refined effect.
Trouble is that I only have 1 reworked needle board that works, but it wont fit due to the very strict constraints of the cluster.
Need to get a new batch of them made with the correct component footprint.


I did find out what was wrong with the power supply. Made myself a high power resistor array with a couple of switches to simulate a load with set increments. At the minimum setting it pulls 225mA, at the maximum setting it pulls about 2.2A, still not the maximum this supply should be able to supply, but enough for my needs.

I found out that with my original setup, the voltage craps out quite fast:
22 ohm: 4.93V
11 ohm: 4.6V
5.5 ohm: 2.9V (!)

Then I put a honking big coil in that should have the correct inductance (hard to believe the little one I was using has the same value, probably doesn't).
22 ohm: 4.91V
11 ohm: 4.91V
5.5 ohm: 4.9V
3.7 ohm: 4.9V
2.2 ohm: 4.89V

That is feckin awesome! Just a shame that this big coil wont fit .
But at least I know what the problem is now, so I should be able to find a suitable replacement so I can get started with linking up the other boards.

[Fred]

Great progress! :-)

[ivan141]

'Persuaded' the big coil to fit my proto anyway, only needed a bit of hacking of the plastic base.
Ordered some new toroids on ebay that look as if they might deliver (in a smaller package).
I noticed the LM2576 simple switcher now runs cooler as well.

Led's are very bright indeed at 40% PWM, they are probably blindingly bright at 100%, but I never
expected to need full power. I did not leave much margin above the worst case scenario. With every led at
full chat I would be pulling 2.7+ Amps from the supply, and my little smd transistors would have to handle
a continuous 320mA each. All is within design limits, but I know from experience that small parts can fail
even when used within their limits, courtesy of a lack of heat dissipation.

Worked on some very 'barnyard' style RPM reading code yesterday. The tach input circuit is now tested and verified
(used one from the MS manual, worked for me before), and I tried out some code that switches the tach led's based
on RPM (actual value relative to max value so far).
I find it difficult to create code that matches good accuracy to good behaviour at very low rpm. I'm now using a combination
of interrupt counting (for 10 ign. event interval timing), and a sharp cutoff when the intervals get too big. Otherwise I often
have trouble getting down to 0 RPM in a smooth fashion.
Really should have a look at how this is done in decent (FreeEMS?) solutions.

[Fred]

What are the current limit resistor values like on your LEDs? That's a lot of draw!

Re RPM code, FreeEMS sucks, don't bother. It's got the opposite problem, and the same problem, so it's likely worse than what you have :-)

Fortunately engines don't run below 100 or so, even when cranking, so if you can hit ~50, you're in good shape.

Fred.

[ivan141]

I only use resistor current limiting where I batch drive multiple led's together. Those are 100R, which roughly
gives me 20mA (given the 2,7V forward voltage on the led's). The rest is constant current regulated by the
WS2803 IC's, and also set at 20mA.

Altogether there are 44 led's, all of them are RGB, so that's 44*3*20mA plus some overhead for the IC's.
It all adds up faster than you'd expect.

I'm sticking to my own RPM code for now then. Was thinking it might be an option to switch over to events-per-fixed-interval
counting once I notice I'm down to 500 RPM, but just cutting out below 500 is good enough for my purposes.
I ditched counting events per interval because it's not exactly stable nor accurate, the count varies whilst the RPM doesn't.

[Fred]

Are the LEDs rated to continuous 60mA combined? I imagine they'll get warm at that! :-)

[ivan141]

Probably not a wise idea, about 100mW max dissipation seems to be a typical value for these led's.
That would mean that I could drive perhaps 2 die's at (near)full power at once. Good observation.
But just to be clear: they are likely staying beneath 40% power in the end application, which should
put them well in the safe range. I just chose to have maximum brightness available whilst designing
the board (easily changed with some different resistors, although the constant current drivers require
some quite exotic resistance values).

[Fred]

Hmmm, I'd personally limit them to max in HW and use SW to go between 0 and max. The reason I noticed is because you said they're too bright. LEDs overdriven are often extremely bright... for a short time before they fade and deteriorate.

In white LEDs life time is not good at high outputs. Best to drive them softly for longevity.

Then again, I have a life/death way of looking at electronics :-)

Fred.

[ivan141]

Well, that's exactly what I've done. Limit max current in HW to 20mA limit as specified by LED manufacturer, then use software to control actual output.
They are high brightness led's, so I'm not surprised that they are very bright, even at 40% PWM drive.
I also have some 5W RGB led's at home that will actually cause retinal damage if you stare at them directly, these plcc ones are not quite THAT bright .

I will take a look at what the highest usable brightness is in the dark (without blinding the driver), and limit the code to that maximum value.

[Fred]

Point being: You're ruining your usable dynamic range by allowing max acceptable PWM to be less than 100% duty. Maybe it doesn't matter much, but it could be smoother if 100% duty was acceptable to look at ;-)