LED1642GW - Intermittent Illumination

[GKerwood]

Context

I'm working on building an LED Cube for no other reason but my own self learning. My intention is to use 12 LED1642W to support a 8x8 grid of 3 channel RGB LEDs, with a 13th LED1642W to multiplex the cube's layers. As a minimum viable model, I've built the following:

The working principle is that the LED is of a common Anode type, with the three channels sourcing to the driving LED1642GW. The "MUX" LED1642GW, powers the anode via a PNP transistor. All communications and configuration of the chips seem to be working as expected.

The Problem

I can configure and illuminate the LED to a colour and brightness of my choosing, however it only stays lit for 4 to 5 seconds before going out. Some time will pass, and it will reillumination. After initial configuration, no communication is made to chip and nothing physically is changed.

What I've checked

• Illuminated or otherwise the MUX chip seems to be functioning. The common anode has voltage.
• With or without the LED is place the channels "close" and cease to sink current.
• All connections are solid.
• The Driver is configured correctly to regulate to 20mA, as per the LED specification.

I'd be really grateful if anyone had some advise as to what might be happening?

Many Thanks

[GKerwood]

@Peter BENSCH​ Sorry to "@" you, Sir, but I'd be very grateful if you might have some insight on this one? Thank you.

[Peter BENSCH]

I would have answered your question if I had been sure about the cause - but I am not.

However, it is also rather unusual to use such an LED driver as a driver for the multiplex transistors. In addition, you drive the pnp transistor directly, i.e. without a base resistor. Actually, this should be feasible, but depending on the configuration of low/high range and CFG-x, a base current of up to 20mA can flow.

What strikes me, however, is that you only buffer the LED1642GW with 10nF each, which seems a little low to me, 100nF would be more appropriate here, even better with an additional 10µF in parallel.

Regards

/Peter

[GKerwood]

Thank you. Personally I'm at a complete lost so the slightest hint could be helpful.

Yes, the application is a little strange 😅 However, I'd wanted to avoid having a more conventional chip on a different protocol opposed to having a single cascade. I have configured my multiplexing driver to a 3mA channel so I hadn't though an additional resistor would be required. That side of things seems to be working okay.

We noted for the bypass cap. The supply is driven from an Arduino Nano 33 IoT's MP2322 which I'd assumed to be well conditioned. I'll never the less increases the value since I've no way to confirm as such.

Many Thanks for your time,

George

[GKerwood]

Hi @Peter BENSCH​,

You should have more confidence! I’m mostly convinced you’re correct regarding the bypass caps. I added a 1uF and a 4.7uF (it’s all I had to hand) and it extended my on time considerably. I’ll try sourcing the caps you recommended; would of been a nice detail for the data sheet 😉

As a further detail, power cycling the chip clears the issue, so it’s unlikely to be damaged or a thermal shutdown.

Many Thanks!

[Peter BENSCH]

Please use ceramic cap for the smaller one, i.e. MLCC, due to their low ESR and better high frequency response. The bigger one can be of any chemistry.
In the beginning you didn't mention the switching regulator - maybe an additional choke inductor between it and the supply of your LED system can improve the behavior even further.
Good luck!
Regards
/Peter

[GKerwood]

Hi Peter, I hope you're well.

The mystery continues... I revised the capacitor values as you suggested and it's brought me to a suspiciously consistence 16 seconds of up time before the LED goes out.

Oddly, clutching at proverbial straws, or jumper cables in this case, I've noticed that if I remove the PWCLK line then the issue is resolved in so much as the LED stays on. In doing so I've also noted that brightness values has no bearing.

Whilst I don't have a scope, I do have a logic analyser. In reducing the Vth threshold down as low as 0.5V, I've noted that my CLK line suffers some cross talk with the PWCLK, momentarily peaking on the leading edge. My understanding is that the induced voltage isn't high enough to be logically high, nor on long enough to "register". The same is also not happening on the LE line so I don't see that this should really be causing the issue.

Any chance there's a glimmer of explanation in there for you? I'm running our of ideas and greatly apricate the input.

Kind Regards

[Peter BENSCH]

Well, you've only shown the circuit with the LED1642GW so far, but not how you drive them. Unfortunately, you don't have a scope to judge the signal quality.

What frequencies are you working with on CLK and PWCLK?

How long are the connections from the controlling mcu?

Regards

/Peter

[GKerwood · Accepted solution]

Hi Peter, apologies for spamming this post, BUT, I've found the issue!

The PWCLK frequency was not sufficient. I had been using the Arduino's PWM output which is 700kHz. Replacing this with that of a signal generator, or even a crude astable 555 I hashed together, complete resolved the issue. The datasheet doesn't specify a minimum frequency but after having experimented with limits, I'm fairly convinced this is in fact around 1MHz.

I apricate you sticking with me through this, I know that I've not been able to provide great information to support so it was kind of you. I'm also convinced that the bypass concern was certainly contributing.

Kind Regards o/

[Peter BENSCH]

You found the problem, great!

Thanks for the feedback, which may help other users as well.

Regards

/Peter