Show Posts
Pages: 1 ... 29 30 [31] 32 33 ... 42
451  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 29, 2011, 05:25:34 pm

452  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 29, 2011, 01:45:39 pm
I drew a PCB layout for ShiftMatrixPWM.  I'll send it in to Laen's PCB group order, which makes 3 copies.  I'll build 1 board.  If it works, I'll send the other 2 boards to you guys (elcojacobs & ematson5897) for free!  The next group order goes in next week, so they'll probably arrive near the end of January.  I'll post info about the board design later today.

While working on this last night, I had a concern about the overall design.  There no enable/disable signal for the whole display.  What happens when the AVR chip resets?  The rows will stop advancing, and one row of LEDs will be left on at 100% duty cycle.  If the resistors are picked for good brightness, which means current much more than 20 mA per LED, the LEDs in that row will be indefinitely subjected to a high current which they can only handle for a short duration.  Or at least the duration of a new program download, which is slow on older Arduino boards.  Not good.

One easy solution would be to add a 7th signal to disable the display, but it would be nice to only need 6 pins.

Another approach could use the row latch signal.  The code seems to leave it high much of the time.  If that were changed so it is only driven high in a short pulse, so it stays low virtually all of the time, then the row latch could also act as a active-low display enable.  It could go to the output enable pins on '595 chips, or other disable circuitry if different chips are used.  With a single pullup resistor, when the AVR goes into reset or runs the bootloader for a new download, the AVR pin becomes and input and the resistor would bring that signal high to shut all the drivers off so the LEDs won't burn up.

Another nice possibility might be staggering the row latch pulse with the column latch pulse, to help with ghosting problems.  When the row latch pulse goes high, the new row data will latch to the outputs, but the output drivers will also disable until the pulse ends.  The column can then be latched while the drivers are disabled, and then the row latch pulse can end, causing the drivers to enable again after the new column is latched.  That should completely eliminate ghosting problems.

How would you feel about making this code change?  Is there any downside I haven't seen to making the row latch a short pulse and using the low state to enable the drivers?
453  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 28, 2011, 07:31:28 pm
The MIC5891 certainly looks like it can source a lot of current!  It costs more than a '595, but saves soldering 8 transistors and 8 base resistors.   smiley

However, the "Typical Output Circuit" on page 2 worries me.  I see at least one PNP saturation voltage and 2 NPN base-emitter voltages between the positive power rail and the output.  I read the datasheet a couple times, looking for some sort of spec for the output voltage under a load current when running on 5 volts.  They do spec "Output Saturation Voltage" at 1.8 volts with 100 mA, with 50 volt power.  I'm pretty sure that means you actually get 48.2 volts.  I'm pretty sure that 1.8 volts is from those 3 transistors in the output stage, so it'd be similar on only 5 volt power.  For running with only 5 volt power, which I'm going to assume is actually 4.7 under heavy load (eg, real wires, connectors, etc), losing losing 1.8 in the chip will give only 2.9 volts out.  That's not enough for a blue LED, not to mention a current setting resistor, and that's if the sinking transistor doesn't eat up some of the voltage.  I think this would work great if 9 or 12 volt power was used (and higher value LED current setting resistors), but unless I've misunderstood, I suspect the MIC5891 won't be very satisfying on only 5 volts.

Regarding the current, you're right, only 0.48 amps is needed if you drive the LEDs with 20 mA during their on time.  But will you really be happy with the LEDs at only 1/8th of their intended brightness?  They're off 7/8th's of the time.  It's the same as PWM... if you reduce the duty cycle but want the same brightness, you must increase the current during the on time.

I figured 1/3rd of intended capacity would be a good compromise.  That's not nearly as dim as only 1/8th.  Also, if the software fails and a row remains selected indefinitely, the LEDs will "only" be stressed with 3X their intended current.  Not good, but they'll probably survive.  At 8X, they'd certainly burn.  Then again, 8X gives the full LED capacity!

Even 1/8th should still light up and be viewable in a dimly lit room or at night.  But as a design goal, isn't that a bit skimpy for so much trouble to wire up all these chips, resistors and transistors?  Or have I estimated things wrong?
454  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 28, 2011, 06:30:35 pm
I ordered a couple of the Futurelec displays.

Then I started looking at specs to actually drive this beast.  First, the 74HC595 chip is only specified for 6 mA drive per pin.  I'm sure it can put out more, with more voltage loss, but the spec says at 4.5 volts power and 6 mA sourcing, the pin will typically be 4.31 and worst case 4.18 volts.  So even at 6 mA, 0.2 volts typical loss.

Even though the LEDs in the matrix are supposedly capable of handling 20 or maybe even 25 mA, to make this easier, I decided to shoot for a 7.5 mA average current (at least on paper).  So the 24 column drivers need to source 60 mA current (7.5 mA * 8 rows).  That's TEN TIMES the '595 spec.

So 24 column transistors would be needed.  Luckily, they only need to put out 60 mA, so a cheap transistor like a 2N3906 can work.  A datasheet says it has a gain of 60 at 50 mA, so a base current of 1 mA should be fine.  24 1K base resistors should do it.  The red LED will be approx 2 volts, so 8 resistors of 47 ohms will be needed for the red columns.  16 more resistors of approx 33 ohms will be needed on the green and blue columns.

The 8 rows are the tough part.  Each row transistor needs to be able to sink the current from all 24 columns.  That's 1.44 amps!  That's probably a job for a darlington transistor or beefy mosfets.  The trouble with mosfets is the huge gate charge.  A lot of them are 10 to 20 nC.  If the current charging the gate is limited to 6 mA (eg, a 820 resistor), it will take about 3 us to charge a 20 nC gate.  That doesn't sound like very long, but unless the library is designed to shift out an all-off pattern while one N-channel transistor is turning off and another is slowly turning on, there will be ghosting problems.  Perhaps a darlington pair could be built from 2 individual NPN transistors, where the big one has a relatively low value pull-down resistor on its base, so it shuts off quickly?

Still, the library should really have some design to shut off all the columns right before initiating the row change, and keep them off for a few microseconds (eg, about 50 instructions on Arduino) while the big row transistors turn off and on.  It looked at the code briefly, and it appears to instantly switch without any dead time.  Is that right?

Of course, each of those 8 row transistors need wiring to conduct 1.4 amps (each wire to and from each one needs to carry the full 1.4 amps), and a supply line to the 24 column transistors needs to supply 1.4 amps (each wire carries only 60 mA, but the feeder to them all carries 1.4 amps).  Wiring capable of handling these currents is difficult-at-best on a breadboard.  At least 2 wires of #22 solid should be in parallel for every path that handles 1.4 amps.

That's also for only 7.5 mA per element.  Multiply everything by 3 for max brightness!  Well, except make those 33 ohm resistors only 10 or 11 ohms, and the 47's about 15 ohms.

That's for only one single 8x8 display!  Multiply everything by 2 for a 16x8 display.

It is do-able.  Maybe this weekend I'll sketch up a PCB layout and send it off to Laen.....
455  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 28, 2011, 03:56:33 pm
Yes, the modified file should work with either.

Why you're getting problems, I do not know.  Is there a schematic for how you're hooking this stuff up?

Consider that a 16x8 matrix of RGB LEDs is 384 individual LEDs.  If you turns them all on (all white) at 10 mA average per element, that is 3.84 amps of current.  USB directly from a PC is limited to 0.5 amps, and only 0.1 amps if from an unpowered hub.

You will very likely need a separate power supply for the LEDs, capable of at least 4 amps for 10 mA per element, or 8 amps for 20 mA per element.  To conduct so much current, you'll need heavy wire, like #18 or larger (smaller numbers for thicker wire).  The rows appear to be 1:8 multiplexed.  If there are only 8 transistors for the 8 rows, then each transistor could possibly be powering 48 LEDs at once.  Because they're only on 1/8th of the time, you need 8X the current so it averages out.  For 10 mA avg, that's 80 mA per LED.  There's 16 per row, so each transistor needs to conduct the full 3.84 amps (or 7.68 amps if 20 mA avg current).  That's a huge amount of current, so you need a very good transistor.  It's do-able, but when you mux so many LEDs, the current requirements are really extreme.

If only the red ones are turning on, it's quite likely your 5 volt power is dropping to 3 volts or less under the load.  Even if your power supply can put out 10 amps or more, the interconnecting wires and transistors will lose a substantial amount of voltage if they're not able to conduct so much current.  I don't want to discourage you, but rather point out the intense current requirements so you can troubleshoot.
456  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 28, 2011, 03:31:45 pm
It should work in both, but I currently have no way to test.  It would be most helpful in the matrix version, since 4 of the 6 pins depend upon it.
457  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 28, 2011, 02:37:16 pm
I attempted to add the pin info for Teensy and Teensy++ to pins_arduino_compile_time.h.  This is untested, since I don't have '595's hooked up for testing.
458  Using Arduino / LEDs and Multiplexing / Re: ShiftPWM support topic. Latest update: ShiftMatrixPWM needs testing on: December 28, 2011, 01:13:54 pm
I looked at the library code briefly.  It looks like it ought to work on a Teensy++ 2.0 board.

However, the file "pins_arduino_compile_time.h" will assume the AVR to Uno pin mappings.  The latch signal should appear on pin 20 (Port B.0).  The clock should be on pin 21 (SCK), and the shift data on pin 22 (MOSI).

The library will probably configure pins 8, 11 and 12 for output, rather than pins 20, 21 and 22.  So I'd suggest you try adding pinMode for those 3 pins in your setup() function, like this:

pinMode(20, OUTPUT);  // connect pin 20 to Latch (all '595 chips)
pinMode(21, OUTPUT);  // connect pin 21 to Clock (all '595 chips)
pinMode(22, OUTPUT);  // connect pin 22 to Shift Data (first '595 chip)

I did a quick PCB layout to connect 16 RGB LEDs to a Teensy, and sent it off the Laen's PCB Group Order.  When it comes back in a few weeks, I'll test this library on Teensy and Teensy++.  Hopefully the author will accept a patch for the pin mappings, and possibly using Timer4 on Teensy (since it lacks Timer2)?

ps: I could only file "ShiftPWM".  Where is "ShiftMatrixPWM" located?
459  Development / Other Software Development / Re: "Correct" method for migrating libs to Arduino 1.0 on: December 21, 2011, 09:09:46 pm

I'm stuck on why using write('\0') won't work in 1.0

I recently fixed this in LiquidCrystalFast, version 1.1.

This same problem was recently fixed in Wire (will become part of Arduino 1.0.1)
460  Development / Suggestions for the Arduino Project / Re: A way to identify Leonardo or Teensy in a program? on: December 21, 2011, 08:41:00 pm
Ideally the IDE should define a symbol that tells you the target/core/variant which is selected from the Tools > Boards menu.  That's not a new idea... but it's never gone anywhere.  I'm pretty sure it's in the issue tracker, but I'm not going to go look up the issue number right now.

For an immediate solution, after you include Arduino.h or WProgram.h, you can check for CORE_TEENSY to determine if a Teensy board is in use.  For example:

#ifdef __AVR_ATmega32U4__
  // it's Teensy 2.0
  // it's probably Leonardo

Hopefully the IDE will someday provide more descriptive info about which board, or target/core/variant, or platform/target/core/variant, or whatever future schema combination, is in use.
461  Using Arduino / Project Guidance / Re: Closing a circuit with Arduino/Teensy. on: December 17, 2011, 12:04:42 pm
The easiest way involves a "solid state relay".  Internally, they have a LED on the side that connects to your digital pin, and a light-sensitive switch on the side that connects to whatever you're turning on or off.  That's nice, so you don't have any electrical connection between the 2 systems.

The input is just a LED, so make sure you connect a resistor between the digital pin and the LED, just like you would do with any other LED.  Usually 220 ohms is about right.

Code wise, you can turn it on and off with digitalWrite().  See the LED blink example for full code.  All you do is turn the LED inside the solid state relay on and off, and the light-sensitive switch on the other side does all the heavy lifting.

Solid state relays come in different sizes, usually depending on the amount of voltage they can safely handle when off, and the amount of current they can conduct while on.

If the "switch" is a pushbutton on a remote control, which probably runs on a small battery and involves a tiny amount of current, you could use a very small solid state relay.  Digikey Z2102-ND might be a good choice:

If you look at the specs, that relay rated for 60 volts max, and 500 mA max.  If you're connecting to a switch that connects 120 volts or 240 volts AC power, that would obviously not be enough.  Luckily, there are plenty of solid state relays designed to switch AC voltage.  Digikey 425-2396-5-ND is one good example:

462  Topics / E-Textiles and Craft / Re: EL Wire on: December 17, 2011, 04:45:45 am
I would advise you NOT to use Sparkfun's board for 50 feet of wire!

Several months ago, I worked on a big project with 114 pieces of el wire, each 8 feet.  Here's my blog about it:

Unfortunately, we used those Sparkfun controllers, and they were nothing but trouble!  Here is a blog post I wrote about all the technical problems.

The Sparkfun board probably isn't so bad for a tiny project, where you have 8 pieces of wire ranging from several inches to maybe a couple feet.  We used 8 feet on each channel, and it was a new higher brightness wire which has more capacitance.  So 8 feet of this wire is like using perhaps 40-some feet of "ordinary" wire (though the trend seems to be newer wires are brighter and heavier loads).

The really terrible problem with those Sparkfun designs is you can't switch at the AC waveform zero crossings.  With el wire (or any purely capacitive load), switching near the zero cross point is critically important.  If you trigger the triac near the crest of the waveform, you're suddenly applying a massive voltage to a capacitor.  The current flow is incredibly high for a very brief moment.  For short, older-style wires, it's not enough to damage the triac.  But 50 feet is quite a substantial load.

If you search the web for info about triacs, everything is regarding resistive and inductive loads, at 50 or 60 Hz.  The rules are entirely different for a capacitive load.  With an inductive or resistive load, you can switch at any point in the waveform, and dimmers do exactly that to control effective brightness.  The problems with inductance come in regarding excessive rates of voltage change due to the inductance.  But with capacitance, the issues are completely opposite.  Switching capacitors causes huge surges in current rather than incredibly fast changes in voltage.  Small triacs simply can't handle those huge peak currents reliably, so you must switch at the zero crossings.

The simplest solution, and what I believe Sparkfun is eventually planning, involves using an optocoupler which has a zero cross switching detector built in.  If you're going to control 50 feet of wire, do yourself a big favor and look for a solution with zero cross switching built in.  You could also build a zero cross detector circuit and interface it to an interrupt pin.  But that solution is a bit risky, because a bug in your code could stress or destroy the triacs.  With the Sparkfun design, you don't even have any way to know when the zero cross is near, so your only option is to just trigger the triac at some random moment (relative to the AC waveform) and hope you don't stress the triac too much.  It's a very poor design.

If you go with Sparkfun's board, you'll have nothing but trouble using such long wires.

463  Development / Suggestions for the Arduino Project / Re: Arduino Due with SAM3U4E on: December 16, 2011, 01:18:00 pm
On the developers mail list, Massimo Banzi of the Arduino Team recently wrote:

the Due is in private alpha at the moment.
There will be a public beta in january

Unless you can somehow get into their private alpha program, looks like Santa will be bringing your Due a few weeks later.

There doesn't seem to be any mention of Due at all in Arduino's github.  But then, when Leonardo was announced, suddenly lots of files became visible, complete with edit history in github stretching back at least several weeks.  So it's possible a lot is actually going on, but none of us can see it?

There was mention, a few months ago, about an experimental IDE based on Qt... but nothing mentioned since.  It's entirely possible Due might have a completely different IDE?

Regarding "a reference implementation for how an on-chip USB perihperal would be used within the Arduino environment", indeed Teensyduino (I am the author) has provided such code for nearly 3 years, with open source MIT licensing.  Indeed, the PCB layout and bootloader are not open source... so if you want a development board which you can clone with zero effort and resell in competition with the original project (as many unscrupulous Asian companies do), then Teensyduino not a good fit for you.  But if you want an open source "reference implementation for how an on-chip USB peripheral would be used within the Arduino environment", all that code used within the Arduino environment freely available under the extremely permissive MIT license, and has been for almost 3 years!

Of course, the Leonardo code is now part of Arduino 1.0.  It uses a much prettier C++ syntax, which you may prefer?  Or maybe you'll like my messy but "everything right there" C-only style?  Leonardo's code shares (perhaps borrows?) a lot of Teensyduino's design, as opposed to the way things are done in Atmel's reference and Dean Camera's LUFA library.

If you want open source code to see how this works, there's plenty of it out there for you.
464  Development / Suggestions for the Arduino Project / Re: Compile Speed - testing & feedback needed! on: December 12, 2011, 09:18:05 am
Glad to hear it's working and helping you.  :-)
465  Development / Suggestions for the Arduino Project / Re: Arduino 1.0 IDE Compatibility with previous versions on: December 11, 2011, 02:58:46 pm
Will it work for everything? of course not but there is a level of pre 1.0 backward compatibility
that can easily be provided that does work for a great number of existing pre 1.0 libraries and sketches.

I have personally worked with a large number of the commonly used libraries and their example sketches.  WProgram.h, print(n, BYTE), and Wire.send represent the lion's share of all compatibility issues.  All the others are relatively rare.

The Arduino team intentionally decided not do those things and push all work for dealing
with these incompatibilities out to the end users with no period of overlap.

"No period of overlap" doesn't take into account the many months where 4 beta tests and 2 release candidates were published.  Unfortunately, they were published on an obscure wiki page, not the main download page, so relatively few users saw them.  The first release candidate was announced on the Arduino blog on Oct 4th, and the upcoming candidates at Maker Faire on Sept 17.  Some news sites carried those stories, though the 1.0 software issues were drowned out by hype about the upcoming new hardware, especially Due.

Certainly 1.0's release candidates could have been promoted much better.  But to say the Arduino Team didn't give any period for libraries to adapt just isn't true.  I personally updated several libraries during that time, and in the process developed and tested Teenyduino's backwards compatibility on 1.0, and forwards compatibility on 0022 and 0023.

Pages: 1 ... 29 30 [31] 32 33 ... 42