/diy/ - Do It Yourself

bmup for interdast. I just started looking at Arduino-play and would like to see more of it on /diy/.

>>137911
>I fail to see where I can apply an external 12v power supply to the options above..

Isn't that sortof the point of the darlington devices?
I'm having a project with a haptic vest with multiple vibration motors that would require a similar layout with individually adressable devices.

How fast would the setup with shift register and darlingtons allow things to be turned on and off?

That led driver seems to be ok with 12V led supply, so you can supply your leds from 12V directly.

The other option is bit more problematic. Use a pnp version of that uln (can't remember the type) to switch 12V and a C version of 74HC595 to drive leds. Or, you could replace the 595s with that m5451 led driver.

>>137925
already checked the datasheets for the darlingtons, theres no +V & 0V pins....
I have only just heard about them, so clearly I'm missing a major piece of the puzzle here.

>I need to control all 500 leds individually
First I laughed, then I serious'd.

By LED, you do mean a single color LED, and not an RGB LED (which multiplies your number of channels by 3)?

Next, by control, do you mean off/on with no brightness control?

>1. M5451 LED drivers
Read the datasheet. Wasn't impressed.

>2. Shift registers + darlington transistors.
Shift registers mean no brightness control, just on/off. That array leads me to presume you will be row/column multiplexing?

Anyway, tell us about the LEDs. Are they the little component LEDs with a typical If of 20mA or less? If so, things become really easy. Also, is it one channel per LED (as opposed to RGB's 3)?

>I fail to see where I can apply an external 12v power supply to the options above
Oh dear. Well, what would happen is that the 12v rail would supply would be connected to the arduino's Vin pin, and the ground rail to it's GND pin (this will go through the on board regulator).

The ICs you use will have a similar arrangement, but you first have to make sure that the voltage is at the appropriate level. The exact setup is highly dependent on what you choose and your circuit layout (mostly whether or not you are multiplexing).

Personally, I've had good luck with the tlc5940s, but I wanted full brightness control. My most recent project was an RGB matrix (4x5) and it worked pretty well, but I did have a problem with horizontal flicker when doing computationally intensive draw functions. Much of the flicker stemmed from my drawing approach (vertical is always on, refresh horizontal), but I do think some stemmed from the rate at which I was signalling the tlc.

>>137925
its sending whole bytes across serial to each shift chip. should be fast so long as you don't daisy chain loads.

>>137925
>How fast would the setup with shift register and darlingtons allow things to be turned on and off?
Much, much faster than they could actually be turned on or off. At 5v, the shift register could be cycled at around 20MHz. The darlington array is closer to 1MHz. The rate the ICs would actually be driven is going to depend on the control device, but the actual max on/off cycle rate that the motors would respond to would depend on the motors themselves.

>>137930
>theres no +V & 0V pins....
They are transistors - it is a transistor array. The GND pin is the emitter for all of them, and the nC pin is the collector for some channel n. It's like how an transistor doesn't have a Vcc or GND, it has the base, collector, and emitter. GND is a common emitter.

>>137932
+1 intranets.

- most definitely not RGB.

- brightness control would be cool, but not essential.

- standard little leds, probs ~20mA, resistor attached. 12v

>what would happen is that the 12v rail would supply would be connected to the arduino's Vin pin, and the ground rail to it's GND pin (this will go through the on board regulator).
- errrrr, really? 10A+ going through the arduino? i break arduinos for breakfast, and this sounds like a good recipe. (seriously tho?)

- I've looked into saving time and money by creating a matrix, but since it needs to be easily fixable and simple for others, lets just say I need 500 I/0 pins.

>tlc5940
- sweet. will check that out, thanks

>>137943
>The GND pin is the emitter for all of them, and the nC pin is the collector for some channel n. It's like how an transistor doesn't have a Vcc or GND, it has the base, collector, and emitter. GND is a common emitter.

>>137932
+1 on the TLC5940
I've had some success using its parallel twin, the TLC5911. Two of them on a 16bit microcontroller and 32 column drivers for a matrix of 1024 low current LEDs. Worked quite fine, but the 17 bit parallel data transmission and the way TI had implemented the daisy chaining of the drivers made things unneccesarily difficult.
OP, you should reconsider using a matrix. A TLC can sink up to 80mA. If you use a simple shift register and some mosfet based column drivers, you can overdrive 64 (or other multiples of 16) LEDs with one driver without loosing perceived brightness. Is cheaper that way and doesn't add too much complexity.

>>137945
>10A+ going through the arduino?
No. 12v going to the arduino's Vin pin. Remember, the arduino mega has an on board regulator. The arduino itself uses very little current, and the regulator will give it what it wants.

For the shift registers, it'd be up to you to regulate the 12v in down to slightly above 5v. The arduino would pulse in the data to the shift registers, and the shift registers would drive the bases of the darlington array.

>lets just say I need 500 I/0 pins
So you aren't multiplexing? Unless all 500 LEDs must be on at the same time, I'd recommend it. It could make things much simpler (at the cost of brightness). If you do not multiplex, you'd have 500 separate connections, and with each shift register you get 8 channels. This means you'd need 63 shift register+darlington array pairs.

If you are multiplexing and you did it as 64 rows and 8 columns (allows for up to 512, you'd need 8 shift registers + darlington array pairs, plus one more shift register and 8 additional transistors that can handle the current of the entire column. Total would be 9 shift registers, 8 darlington arays, and 8 transistors.

Note that this doesn't mean that the physical layout of the LEDs must be 64x8, only the circuit needs to be that way. Also note that the LEDs would only be on 1/8 of the time (since you'd drive one column at a time) and would be dimmer.

>>137959
>the 17 bit parallel data transmission
Yikes! The 5940 is serial (internal shift register).

>and the way TI had implemented the daisy chaining of the drivers made things unneccesarily difficult
The 5940 actually isn't too bad. To daisy chain, you just connect the SOUT pin to the next one's SIN pin. The other pins required for control (SCLK, GSCLK, XLAT, optionally BLANK and DCPRG) would just be placed in parallel with the first. However, I've never done long runs with it so I don't know if signal propagation or clock skew could be a problem if you were doing a long, individually addressable LED strip.

I like them, but I do wish they could deliver full current to all channels at once. I also wish they were source and not sink, because then I'd use some of their channels to drive the base of the column transistor.

>>137993
Daisy chaining the 5911 was similar, every input had a corresponding output to the next chip. Problem is: the DCdata was just buffered (45ns delay), but the GSdata went through the internal shift register first (45ns delay + 16 clock cycles). Fun times. For future projects I will definetly go serial.

>>137911 you can't draw that amount of current from an arduino, however, I fail to see where I can apply an external 12v power supply to the options above.

>>137945 standard little leds, probs ~20mA, resistor attached. 12v


Wait wut? Why are you adding a 12v power supply? The issue is that you don't have enough current, not that you don't have enough voltage. You're going to be using extra switching components to handle the 12v and burning off an enormous amount of power in the resistors to get 2-3v LEDs to run off it; all for no reason.

Get yourself a 5v power supply that can source the current you're looking for. Use a nice inexpensive TTL shift register like the 74HC164. Pic related; its the way I address long serial chains of LEDs.

I'll hijack this thread for a while.

I'm the haptic vest guy, and while the vibration motors can of course be PWMed they could also be "dimmed" by regulating voltage or current flow. Are there any ICs that would fit better for such a purpose? The criteria for individual adressing still remains, although I don't need 500 individual adresses, something like 30 is a good starter for the proof of concept, with ~150 probably being very sufficient for the final version.

As for the actual motors, the 310-101 vibration motors found in the sparkfun catalogue are what i'm currently leaning towards, but this is more because they're handily button shaped whereas other i find is of the standard DC motor formfactor with a irregular mass strapped on.

>>138473
Having a computer control the speed of a motor through regulating current or voltage is always going to be more complex and expensive than PWM.

You don't need a specialized chip to do PWM, just some latch you can write too quickly so software in your controller can generate the pulsing. Specialized PWM ICs let you write in a byte or two of data, then they generate the pulsing themselves based on it.

Here's a list of PWM motor driver ICs: http://search.digikey.com/ca/en/cat/integrated-circuits-ics/pmic-motor-and-fan-controllers-drivers/2
556626?k=IC PWM MOTOR DVR

OP, you need to make a giant LED display for conways game of life

DO IT NOW

>>137911
what ya gonna do with a single row of 500 leds!?

>>138487
>Having a computer control the speed of a motor through regulating current or voltage is always going to be more complex and expensive than PWM.
You know, when I read that question, my first thought was
>Having a computer control the speed of a motor through regulating current or voltage is almost always going to be done by using PWM.
It generally is. There are also DACs (which work slightly differently), but they wouldn't deliver enough power for motors. Of course, the waveform they output is stepped - it has to be, since it comes from a digital source (this shouldn't be viewed as a problem, though, since the addition of other components can allow one to shape the waveform as they wish).

Anyway, what I am getting at here is that, when you want to constrain the power delivered according to digital logic, PWM is a good choice.

>>138519
That's what I was getting at. I just didn't want to go into the detail of explaining that digital current and voltage regulators are always more expensive and complex than basic PWM chips because they're just PWM with a stabilizer on the end or a resistor ladder, which is more expensive because it requires a lot more latches.

multiplex the leds using three shift registers and either drive the leds straight from the shift registers or use a transistor ic package like the uln2003, either way your need a npn transistor ic package to convert the negative side of the multiplex. Then use rapid switching of individual LEDs to give the impression of constant on state.

Also stop being an arduino using retard.

>>139439 multiplex
Cuts down on the brightness a whole lot.

>>137911
Do with them? No fucking idea.
How to *control* them? Connect them in a 20x25 matrix so you only have to have 45 GPIO lines to control the entire matrix. I am not familiar with the details of your microcontroller, but I doubt it's got dedicated hardware to control a matrix this size, so you'll have to write a routine that runs in the background that scans the entire matrix often enough so that it looks like more than one is on at a time. What you do with it from there is up to you.

>>139441

not if you run it fast enough

i just ordered an arduino mega too but my project only involves 40 to 60 lights that all need to somehow be 110v or so. hopefully ill figure out the programming thing if no i might have to make a thread on here

>>139482
Running it faster cuts down on flicker, it doesn't make it brighter. If only one of ten columns is really on at a time no LED can get above 1/10th of the brightness it would have with a dedicated latch.

>>139441
>>139439

alternatively OP could daisy chain 63, 8 bit shift registers together.

>>139485

bullshit, running it faster with a higher duty cycle will increase the brightness significantly. The flicker IS the dimness (on vs off time).

>>139484
No amount of programming is going to get an arduino to switch 110v without extra hardware. You're going to need some big MOSFETs or relays that can handle the voltage, current, and AC if that's the case.

There are MOSFETs with built in latches; or you can combine latches with the switching components yourself.

>>139484

Use a solid state relay

>>139493
SCRs or TRIACs if it's AC.

If you need to switch 110VAC you can use opto isolators and triacs. If you switch at the right time you can have very low loss.

>>139490
You are confusing duty cycle with frequency. Duty cycle is the percentage of the time the LED is turned on. When using a matrix duty cycle becomes brightness because your eye averages out the fast flashing. When you cycle through a matrix of ten columns no column can have its LED turned on more than 1/10th of the time.

>>139499
Can you use capacitors (with improvements to PSU and switcher transistor specs) to help minimize flickering, using a value suitable with respect to time constants.

>>139503
Caps across the LED & dropper resistor that is.

>>139503
The problem with using caps like that is you get ghosting. No LED can change its brightness quickly, so any moving graphics look horrible. If you've ever tried to play a game on a laptop from the 90s you know what I'm talking about.

>>139507
Ah I didn't realize it was for fast moving graphics. Could you use a transistor to short the cap when turn off was required? Yes a waste of massive proportions on many levels, but should work right? kinda defies the point of mpxing as you need extra channels for the transistors :P

>>139493
its dc and might be up to 170v from a 12v source but its very very low amperage. it needs to switch fast could a solid state relay do that? i figure i could get one 170v power source built and use relays to control the individual bulbs as needed being activated by the arduino

>>139509
or a missing pulse detector of some sort to see when the PWM has halted and then SC the cap.

>>139510
Well use a transistor and be sure to tie the emitter low ( load in series with the collector). add protection incase of transistor SC.

>>139512
to keep the high voltage from the controller? would diodes work?

>>139515
Zener and suitable fuse on the "high voltage" rail. I'm using quotes as in my field high voltage is anything over 1000VAC or 1500VDC

>>139509
By doing this you can cut down on the capacity of the capacitor a great deal because it doesn't need to run the LED directly, just drive high the transistor base. The charge and discharge time of a cap is proportional to it's capacity, so transitions can be much faster.

You can't do this with just one transistor though. When you are driving an LED from a capacitor/transistor pair you only have one input to control; so you can't use horizontal vertical addressing.

What you're talking about is called a "transistor capacitor memory cell". It's what a lot of RAM uses to store data. I've provided a picture. The transistor here serves as an AND gate so that you can pick which capacitor to power up through horizontal and vertical addressing. A second transistor fed by the voltage in the cap would be feeding the LED; or you're just back to the problem of ghosting because you need a big capacitor to run the LED directly.

>>139511
>or a missing pulse detector of some sort to see when the PWM has halted
If the cap is used to reduce flicker from the multiplexing, the pulse detector would require a great deal of logic to decide whether or not to sc the cap - it would have to know the next-up duty cycle PWM for that LED, and it would also need to be aware of the PWM clock. This would require additional logic on a per LED basis.

>>139521
>it doesn't need to run the LED directly, just drive high the transistor base
This will not reduce ghosting, only change it. If you are using row/column multiplexing, the transistor drives an entire row (or column). A capacitor at the base of the transistor softens the transition, but this means that the pulse intended for the previous LED will bleed over to the next, since the cap will be charged already.

Anyway, I've done some experimenting with using caps to smooth, and ghosting issues were only relevant when the framerate was high enough for them to be noticeable, which I don't think it would be (500 LEDs @ 256 levels of brightness having their graphics computations being done on an Arduino).

I would suggest you think of it as flicker vs ghosting - you can reduce flicker, but ghosting will increase. It MUST increase, since the ghost/carryover is what makes the flicker less apparent. If the amount of ghosting or flicker isn't acceptable, or it needs to be brighter, then you should consider changing the number of rows or columns so the multiplex cycle is shorter.

>>139521
OK I see the idea but the pic doesn't show the whole picture. I see the only disadvantage to be cost, which is an advantage to us as we don't care about a few cents for capacitors if the increase in quality is worth it, where professional manufacturers need to save every cent. I don't see that pic at all relevant as the cap would charge and when charged extinguish the LED. What we need is kinda the opposite or the LED in parallel wit the cap and a transistor to short the cap when an off state is required.

>>139499

at higher cycle rates the 1/10th of the time is MORE time on meaning the leds will be brighter.

You're confused.

>>139531
Just a question. Incandescent lights have a time period to reach full brightness limited by the time to get the tungsten to the white hot zone. LEDs must have some time period to get to full brightness I guess also the more channels you multiplex would restrict the maximum duty cycle?

>>139531
>at higher cycle rates the 1/10th of the time is MORE time on meaning the leds will be brighter
No, the total amount of time the given row of LEDs will be on is still 1/10 of the time. The only way I can think of to make faster multiplexing brighter is if your cycle speed was so fast that it refreshed the row before the fall time of the LED, which is neither feasible nor desirable.

>>139535
I see most IR remotes use a higher pulse current to overcome this, maybe 100ma for a 20ma max LED. Is this usually implemented to some degree?

>>139533

possibly but the rate is so fast it doesn't matter. Leds aren't tungsten. Tungsten is heated to throw out photons to produce light. Leds throw off photons when current is passed through the doped semiconductor material they're made of, not due to heat but through subatomic properties of the material.

So time to full brightness is so fast it doesn't even need to be consider, only the brightness of the on rate due to persistence of vision.

More on time makes it brighter.

>>139533
>LEDs must have some time period to get to full brightness
This is known as the rise time, and the time to turn off is the fall time. It should be noted that semiconductors generally have a turn on delay (before the rise time) and a turn off delay.

For example, if you applied current to an LED, there will be some delay before it responds (turn on delay), and a period of time before it reaches full brightness (rise time). The turn off delay and fall time behave more or less the same way.

IIRC diodes also have a reverse recovery time, but I don't think that would come into play.

>>139537
>I see most IR remotes use a higher pulse current to overcome this
The use of higher current pulses for multiplexing is pretty common. LEDs have a peak forward current rating which is usually specified at a 10% duty cycle @ 1kHz.

>>139538
>More on time makes it brighter.
Yes, this is not in dispute. What is in dispute is that 1/10 duty cycle at, say 1kHz, would have a greater on time than 1/10 duty cycle at 10kHz. They are both on 10% of the time - the total on time is the same in both cases. If we measured the on time for a given row for 1/60 of a second, each row is on for 1/600 seconds, regardless of multiplex cycle rate (cycle rate greater than 120Hz for 1/60 second measure time).

>>139547


>What is in dispute is that 1/10 duty cycle at, say 1kHz, would have a greater on time than 1/10 duty cycle at 10kHz

I'm tired of arguing this point, all the information on what I'm saying is right here lemonparty.org

>>139530
I could have explained that better. I think this graphic does a much better job.

>>139529
I can't say I've ever experienced problems with a capacitor storage based LED matrix bleeding in my life; although I'm not arguing it couldn't happen in some circuits.

>>139549
Hey thanks for that, bit drunk at the moment (Friday night), but this makes it alot clearer

>>139548
>>139548
This is the way cool LED matrix math colander hat sitting on my desk.

Here's a paper explaining how LED matrix work:
http://www.avagotech.com/docs/5980-3132EN

You're wrong son.

you can try to use the max7219. it's a 7-segment driver ic witch can also be used to drive 64 individual leds.
you can daisychain more chips together do drive more leds.
the best thing is, that there are arduino libraries and tutorials for this chip
http://arduino.cc/playground/Main/LEDMatrix
and you can get 10 pcs for about 5$ at ebay

>>139548
>>139548
This is the way cool LED matrix math colander hat sitting on my desk.

Here's a paper explaining how LED matrix work:
http://www.avagotech.com/docs/5980-3132EN

You're wrong son.

>>139560
I didnt read it all but would the flicker be different between the LED and ambient (say sunlight) OR another LED in the MPX chain? it should because the other LED would be flickering at a division of the initial LED?? And so on for the chain?

>>139566
I design and implement components on the transmission and distribution lines in my country (11000v - 225000v) so it is great to understand ELV works such as this thread.

>>139566
The human eye can't detect flashing any faster than 60hz. CRT monitors for example only point the electron beam at one pixel at a time at a 60hz frequency, but it looks stable to you. Flickering isn't something you really need to worry about making "better" since after passing a low threshold its just gone.

By MPX chain I think you mean a chain of shift registers. During the time when you are pushing in data the LEDs will be showing "static" because data meant for another LED is passing through them. The static doesn't look like flickering, just greyish since its happening too fast for your eyes.

Lets say that 99% of the time a shift register is holding its data stable, and the other 1% of the time data is pushing through. Also for simplicity lets say on average half your LEDs are turned on:

The minimum brightness of an LED will be 0.5%, since even an off LED will have on signals running through it for half of the 1% of the time it is shifting. The maximum brightness will be 95.5%

There are double buffered shift registers which eliminate the entire issue. You shift data into a holding register, then send another signal which copies the holding register to the output register driving your LEDs.

>>139575
By MPX chain I mean the difference between atmospheric light and an LED output vs an LED output vs another on an MPX configuration (which is pulsed with respect to the original LED, and a certain degree out of phase) So the time between LED1 (original LED), to the second ( or N x multiplexed) , would be divided over the total amount multiplexed, right???

>>139580
Sorry, I couldn't follow any of that. What is "atmospheric light", what does MPX stand for?

So if it is LED1, Continuous light such as the sun (l), LED2, (l),LED3,(l), LED4, (l), LED1..... you would see flickering between LED1 to LED 4, as you do.

>>139581
Atmospheric light meaning a continuous light without such duty cycle as the multiplex (MPX) frequency.

>>139582
You have an M*N LED matrix.
Take M or N, whichever is smallest.
Divide the brightness of an LED which is on continuously by this number; that will be its maximum brightness.

>>139585
Yes but due to continuous lighting (such as incandescent) you will see a weird flickering between digits in a MPX system. I see it all the time between MPX a-b-c-d as each seems to be "moving" with respect to static lighting.

>>139560
Why don't you make a thread for that? /diy/ has got far more questions than it does answers right now, and I was really hoping that there would be more walk-throughs and a stickied works in progress thread.

I would definitely be interested in knowing how you dealt with the large amount of info that might be required with respect to the flicker it could cause. I had trouble with my small matrix flickering during intensive draw routines. Some of it can be improved by software optimization, but that means the flicker rate is going to be different with each frame (which makes cap selection tricky). It's not too bad, though. It's only the vertical refresh that can visibly lag (horizontal is shifted in as the computations are made, but only latched at the end of the row).

>>139586
I think you should sober up and come back to this thread later. You're not making a great deal of sense right now.

>>139590
Will do - Disregard my posts so far everyone else.

>>139591
BTW I still believe my posts hold some truth. We will wait for external input for that from at least someone with a related degree or greater.

>>139589
There are hundreds of tutorials for making an LED matrix on the internet. I don't think putting the matrix in a colander or programming it to scroll math is an important enough new feature to warrant lengthy discussion.

>>I would definitely be interested in knowing how you dealt with the large amount of info that might be required with respect to the flicker it could cause.
I had it refresh faster than 60hz. That's all there is too it. Get a light flickering faster than 60hz and humans can't see the flicker, it just looks dim.


>> I had trouble with my small matrix flickering during intensive draw routines.
Oh I get your problem now. What you want to do is add a timer interrupt. Its something that at a constant period makes your microcontroller stop whatever it's doing, go run another function (Interrupt service routine), then go back to what it was doing. In each Interrupt routine switch to lighting up a different column of LEDs. The led matrix will refresh at a constant rate no matter what else is going on in the microcontroller.

>>139597

Agreed, so long as the period is not greater than the realism of human interpretation of change of light then any MPX scheme should not be visible to humans.

OP here. got a test rig wired up. (pic not related)

>>138504
technically wired in a single row, but they dont light up sequentially if thats what your asking.

>>139484
110V? sounds like some serious lighting. have you looked at a DMX setup?

>>139494
NO. GTFO. NO RELAYS.

Incidentally, anyone got code on the M5451 for arduino? Theres nothing but lightuino's 'beginhere' endless script. just a simple on/off, led1-on tutorial would be so fucking appreciated

http://www.wired.com/dangerroom/2009/09/hardware-hackers-build-250-puke-ray-gun/
build it and use it on your enemies