Chronome LED brightness issue - suggestions please!

  • Hi Chronomers,

    I have a little hardware issue which I'd love your input on. To set the scene, I'll start with a couple of posts which I've split out from [[http://post.monome.org/comments.php?DiscussionID=13835&page=1#Item_16|this thread]] (which was mainly about software):

    On Mar 16th 2012 I posted this:
    > Thanks for that Owen, I'll look into the software stuff when I get a chance.
    >
    > Regarding point 2) - sorry, I didn't explain that clearly enough - I don't think it's a dot correction issue.
    >
    > The LEDs get dimmer and less uniformly coloured the more of them that are on, which makes me suspect that not enough current is getting to them. When a single row or column is on they are bright and very consistent in colour; when all 64 are on they are noticeably dimmer (not much, but enough to notice) and the colours more variable.
    >
    > Should the Chronome be able to get enough current to light all 64 LEDs white from USB power alone?

    > Thanks,
    > Jo

  • To which owen_Vallis kindly responded thus:

    > Ahh, I see now. I didn't realize you were using modified sparkfun button boards. Your USB port can supply ~500ma, which should be good of rthe 64 RGB leds, but I did end up using a large Electrolytic on the board (between +V and GND) itself to help smooth out the USB power. Also, it was recommended to me to provide FATTY +V traces and fatter GND traces. I guess the board can pull quite a bit of current :)
    >
    > Hope that helps,
    > Owen

  • I'm now revisiting the project after a busy few weeks of new things (house/city/job/baby!). To describe the problem (hopefully) a little better...

    //My setup consists of://
    - Arduino Mega 2560 R2.
    - Custom Chronome stripboard shield, incorporating all connections to the Arduino, all components except for the LEDs, and several ribbon cable connections to the buttonpads.
    - Sparkfun button pads with modified by some judicious vandalism with a stanley knife to separate the GND connections of the LEDs (which are obviously RGBs) into 64 individual channels.

    After a fair bit of mucking around and some much appreciated help from folks in other threads, it's communicating fine with my mac, and I'm able to use lots of the monome apps in single colour mode.

    As mentioned in the posts above, the problem I'm experiencing is that I get some dimming of the LEDs when lots of them are on, which leads to unevenness of colour due to the R, G and B components being at not-quite-the-same brightness. I've been doing a few little experiments as detailed below, but **I'd be very interested to hear if anyone else has experienced the same thing with their setups** (which I appreciate will be different from my build).

    //Observations/experiments/tentative conclusions://
    - I can light up to 2 rows (16 LEDs) with no appreciable dimming. Each extra row after that makes the original 2 rows dim visibly. The dimming is roughly even across the board (there's a little variation, but none remain at full brightness). Turning the extra rows off again lets the original 2 rows come back up to full power.
    - Adding an external (2A capable) power supply made no difference at all, so it seems that the USB's supply should be adequate.
    - The R, G and B channels are completely independent. Adjusting the firmware so that different rows light up different colours, I can light 2 rows up full brightness red (for example), then switch the other 6 rows on green or blue without affecting the brightness of the reds.
    - This behaviour appears to be the same, independent of which 16 LEDs I light initially, so I'm confident the LED drivers are working fine.

    //A few things I'm going to try next://
    - I've tried beefing up the +V and GND connections, but to no avail so far. I've still some work to do on this though - I'll focus on improving a) the main GND connections from the LED drivers, and b) the +V connections to the transistors.
    - One of the few differences I can think of between my build and the FlipMu build is that I was unable to source the same transistors that Owen used in his build. I'm using 2n5401s at the moment. I'll try switching a different type in for one of the colour channels to see if that helps.
    - I might also try using my external power supply (run through a 5V voltage regulator) to provide a separate +V supply to the transistors.

    **Anyone else got any input or suggestions?**
    Cheers,
    Jo

  • A little progress update (or possibly lack-of-progress update):

    - Beefed up the +V and GND connections. Made no difference that I can tell. From the info I've been able to find, a single stripboard track should easily carry enough current anyway.

    - Subbed in some bc327 transistors for the 2n5401s - no difference (wasn't particularly expecting there to be, as we're essentially just using them for switching).

    - Now powering the transistors/LEDs through an external supply - no difference.

    My main thought now, after reading a few threads over on the Arduino forums, is that it's probably a decoupling problem (since my circuitry is different from the "standard" chronome setup, one might reasonably assume that the optimum decoupling cap values might not necessarily be the same). So my next line of attack will be to head to maplin for a lucky(-if-you-get-any-useful-ones) bag of capacitors and try out some new combinations.

    All ye other chronomers, have any of you experienced the same dimming issue or anything like it?

    Owen, how did you arrive at the cap values in your build - was it mainly trial and error?

    Cheers,
    Jo

  • Hi Jo,

    To sum up where your at, so I make sure I'm on the same page, are you trying to convert the Sparkfun button pads to work with the Chronome firmware, and the Arduino Mega?

    If so, is there any way you can trow up some pictures to see where your at. It would be cool to see what you've done to the Spakfun boards.

    The dimming issue is interesting, and I can't say I ran into that problem myself.

    The cap values I chose were decided in the following way.

    1) decoupling/bypass caps are just the standard Ceramic 0.1uF. These are used to decouple the +V and the GND at the IC chips. Apparently noise can be introduced into the circuit from the IC transistors switching.
    2) the CAP ALUM 470UF 25V 20% RADIAL is a similar idea. It goes over the main +V and GND lines for the LEDs. I actually have a bigger value on my prototype, but it turned out that 470uf was fine. This is used to help smooth out the power when a lot of LEDs ask for current all at once.
    3) the CAP CER 470PF 50V 10% RADIAL are used to filter any high freq noise out of the A2D lines. They just pull to GND and help to fight against false positive readings. I arrived at these by trial and error. Just kept slowly increasing the value until the buttons stabilized.

    Okay, so back to the LEDs... if you are using the Sparkfun boards, then you should have 4 boards, and one TLC5940 per board. You might want to look at the OCTINCT as it was set up that way as well. It sounds like you have everything in a slightly different configuration, but the OCTINCT board is closer to the sparkfun ones if I remember correctly.

    Let me know how it goes.

  • Hi Owen, cheers for the reply.

    1) __Decoupling__ - The questions about the caps come from a few threads over on the Arduino forums where some people had discovered that the 0.1uF decoupling caps on the tlc5940s were insufficient, and had got much better results by adding larger values (even up to 100uF) in parallel with the 0.1uFs.

    This weekend I've tried adding various different values in parallel (1, 10 and 100uF), but as far as I can judge, none of these has made any difference whatsoever. So now I'm kinda back to square one on the ideas front :o(

    3) __A2D caps__ - Thankfully I haven't experienced any problems with the buttons part of the circuit. I did notice that sometimes analog inputs A8-A15 produced a bit of noise, but grounding these (at least until any point in the future where I might utilise them) seems to have solved this one.

    I'll get some photos and diagrams up shortly...

  • Description and pics now up in [[http://post.monome.org/comments.php?DiscussionID=14847|this thread]].
    J

  • From Owen on [[http://post.monome.org/comments.php?DiscussionID=14847|this thread]] - just thought I'd keep all the "dimming issue" content in one thread.

    > Nice project! After seeing the pictures, I might suggest one possible area that
    > could lead to the LED dimming issue. The TLC5940s are on your shield, and as
    > such, the GND leads to each LED is very very long. This will create extra
    > resistance along the lines, and might be contributing to the dimming effect. I
    > know on both the Chronome, and the Octinct, the TLC5940s GND traces are
    > kept as short as possible. Might be worth a look.

    Cheers Owen,

    A worthy suggestion, but after a bit of thought I'm not sure it fits this particular problem:

    1. Any one LED //can// be at full brightness, if not too many others are on.

    2. The leads are not much longer than the length of a PCB trace from one side of the board to the other (and the shorter ones are definitely shorter than your longest traces), and the leads will have a larger cross-section than a PCB trace, so I'm not convinced they will have a significantly higher resistance. It's tricky to measure with my multimeter as it's right at the bottom of its range, but both a trace across the length of the board, and my longest leads are both coming out at roughly 1 ohm.

    3. If this were the problem, then I guessing I should expect to see more dimming at the side of the board with the longer leads, which is not the case here.

    It is some sort of current supply problem, but I haven't managed to track down exactly what kind yet. When I get the chance I'll try to recreate part of the circuit on a breadboard and see if I can get anywhere. Either that or track down someone with a scope I can borrow...

    All that said, I'm only improvising really when it comes to electronics and circuitry, so all suggestions very welcome!

    Cheers,
    Jo