Rectangular LEDS

You may well be right. I'll certainly do some experimentation before settling down to build a constant current sources.

Yes, but they tend to be far beyond my soldering capabilities or equipment.

As I said, maybe its an artifact of putting a set of LEDs in parallel in a single PSU, particularly if there's a common resistor in the current path. Again, it needs to be checked out before making anything.

Not breadboards, but I'd be happy to use Veroboard. I've done it in the past and some of the circuits I've made that way have been running continuously since at least 1990.

Gotcha. You mean a PICAXE or similar. Not used them, but I still have a Parallax BS-2 STAMP or two about the place. PICAXE=cheap, BS-2=expensive

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
Loading thread data ...

I see, he wants to use the row/column multiplexing method, but that has issues with the daisy chained LEDs in the LED blocks. You could drive each of those as separate LEDs more easily. I think that means the three rows of four blocks become 48 LEDs plus the 11 single LEDs for 59 total. BTW, they are not all independent. The four in a block are all lit together and the last LED in any row is only on when the others are also lit, etc.

One advantage of multiplexing is that you can use fewer constant current drivers. 16 outputs can control up to 64 LEDs, 8 high side drivers and

8 low side constant current drivers. The blocks should all work with the same current so you can use 6 constant current drivers for those. The 11 singles can use two constant current drivers for those. If you want to get really fancy you can use 8 DACs (one chip) to drive the constant current transistors and have software defined brightness which can provide very even control of the brightness and other features like night time dimming.

BUT.... this will require real time control by the rPi, not once per minute updates. I looked at using the rPi for reading ADCs over the SPI bus and it is not well suited for real time work, especially if it will be doing other stuff. Given the limited benefit of multiplexing for your design I would suggest that you stick with direct drive.

If you want to use the multiplexing scheme which does have the advantage of requiring fewer drivers, I would recommend using an MCU to do the multiplexing and let it talk to the rPi by I2C or RS-232. Using RS-232 makes it easily adaptable to any PC as well. That becomes one "smart" chip and 16 transistors. Not too bad.

--

Rick
Reply to
rickman

Current control can be done with one transistor in an emitter follower configuration. A current setting resistor is used in the emitter leg and the LED is used in the collector leg. You need to set the voltage on the base and therefore the current control resistor with a pair of resistors from the control output.

What is the two transistor circuit like?

--

Rick
Reply to
rickman

As someone else mentioned, you don't need fancy equipment to use surface mount parts.

The problem with paralleling LEDs is that the I vs. V curve varies, so each one will have a different current. But if you use a current limiting resistor that gets them close. Driving from 5 volts puts more voltage drop on the resistor which gets you closer. You can only perceive a limited amount of variation. Almost no one uses true constant current sources for driving LEDs.

Consider a PCB. Once you have one you can make the design available for others to order through Oshpark

formatting link

I don't know what a PICAXE is, but I assume it is either a Microchip MCU or a board using a Microchip MCU. PICs are not the only MCU on the market. In fact, the lower end PICs have a very odd and uneven instruction set. But whatever, the processor is not so important. The I/O is what this is about. Consider my other post about using an MCU to do multiplexing with DAC control of the LED brightness.

--

Rick
Reply to
rickman

Similar, but the lower resistor of the PD is replaced by the second transistor, who's base goes to the emitter of the first. Current control is *much* better, and you potentially only lose 0.6V + VCEsat of the first transistor. As the second transistor is dissipating only a tiny amount of energy there is no drift due to heating, which there would be with a single transistor.

--
W J G
Reply to
Folderol

Sounds pretty pointless to me. The one transistor circuit is already an improvement over just a simple current limiting resistor. I doubt anyone will notice the difference in any of the three options to be honest.

BTW, take a look at the original clock. It uses a few lightbulbs behind a piece of plastic. In at least one picture some of the bulbs are burnt out which is clearly discernible. Lol, maybe the OP wants realism.

--

Rick
Reply to
rickman

And while we're on the subject, 23 LEDs can be multiplexed (simply) by using just 10 outputs--for a 5x5 matrix with two voids.

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon

Or with only 10 outputs in a 5x5 matrix...

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon

Yes I eventually worked out that was what he was trying to do, but I don't see any advantage over treating the LEDs as a linear array and, for instance, simply using I2C to zap a row of bits into a set of 74HC594s.

Yep, and if I was to use, PCF8574 or its 16 bit bigger brother I think I'd have to do that: if I read it correctly, these specialist LED driver chips can only drive one LED per output pin.

Yes, exactly. It doesn't matter logically whether you drive the set of four in a block via a single pin, possibly via an external current source, or treat the LEDs in it as separate: treating them as separate just meand more bits to send via I2C, but having 23 connection to the display rather than 59 minimises the wiring problem.

Agreed, but if as seems likely, switchable constant current sources are only needed for the blocks, I'd only need 12 of them and one control connection per block.

Yes, I'd thought of cutenesses like using an ambient light sensor to control the brightness. That would be easier to handle by using specialist LED driver chips since many of them have controllable duty cycles.

Not necessarily. If specialist LED driver chips are used, its possible to check the light level every second or so and, if it changes, zap the driver chips with a command to change the duty cycle for all LEDs.

I think I'll start by getting a handful of LEDs and a 74HC594 to experiment with and decide where to go after that. I think I ought to know a little about I2C and/or SPI in any case.

True, and would give me an excuse for finding out about PICAXE MPU chips as well. BTW, how do most people get RS-2332 out of an RPi? Bit-banging or an extender board and a UART?

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

Yep - its a DIP package containing a PIC MPU, RAM, EEPROM, I/O and a BASIC interpreter. The package size and i/o capabilities vary depending on model. They are cheap, small and available. IMO they're worth knowing about:

formatting link

That said, I haven't (yet) used a PICAXE, bit I have used the logically very similar Parallax STAMP BS-2 and like everything about them except the price:

formatting link

I am. This approach could well help with the other job I'd like this particular RPi to do, particularly as PICAXE's can act as master or slave on an I2C bus and some have onboard DAC/ADC capabilities.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

Use the PI's UART and a TTL to RS232 level-shifter like a MAX3232 chip. You can get small boards with the chip and associated capacitors on for around a quid on ebay. I use one of those boards to connect a Pi to an old VT terminal.

Connect "TTL" GND, Tx, Rx and 3.3V to Pi, then "RS232" GND, Tx and Rx to whatever needs it.

Of course, if the device will happily work with 3.3V logic levels you can just connect it directly.

Reply to
Dom

I don't know why you say that. The only limitation is the voltage the driver can tolerate when off.

When you are multiplexing all the LEDs have to be very similar if not the same. They share a set of high and low drivers.

I'm not sure what you mean about the "wiring problem". Why wouldn't this all be on the same PCB?

Not sure what you are saying here.

You aren't grasping the nature of multiplexing. It requires driving each LED for a short time, faster than the eye can see meaning at least

100 Hz, preferably faster, 1 kHz even.

Uh, the rPi has a UART built in. The output is 3.3 volt which means to talk to a PC you need an RS-232 driver/receiver chip. To talk to an MCU needs nothing since that is also 3.3 volt I/O.

--

Rick
Reply to
rickman

The Pi has a UART built-in. Only Tx & Rx though and it's 3.3v - /dev/ttyAMA0.

The somewhat easier way is to use a USB/RS232 adapter and let that handle the voltage differences, etc.

Gordon

Reply to
Gordon Henderson

No - but my wiringPi driver will only support 4 cascaded as one unit. It would not be hard to change the code to support more, or have multiple units of 4 - each block of 4 needs 3 GPIO pins on the Pi though.

The wiringPi driver allows you to regard them as individually bit-addressable devices - it takes care of the shifting, etc. for you, so you can simply digitalWrite (pin, 1); to set one output pin value and the rest remain unchanged.

You can program them from C/C++ or my RTB (BASIC).

(or the command-line via the gpio utility)

Cheers,

Gordon

Reply to
Gordon Henderson

On Sun, 30 Nov 2014 00:48:14 +0000 (UTC), Martin Gregorie declaimed the following:

Does Parallax still make BASIC Stamps, or are they just selling off old stock (granted -- the processor is just a pre-programmed PIC, so that shouldn't be a problem; it's the carrier board and accessory chips that may be running low). I've got a few lying around too, including a serial port (not USB) experimenters boards. Yeah -- expensive compared to ...

Maybe a Propeller? They've been used to make the DefCon badges for a few years

formatting link
the EFCO act as touch switches, there's an IR transmitter/receiver pair, and USB). With 8 "cores" you could assign one core per display row, with one master core to handle updating the shared time data [the Propeller has no interrupts -- the CONOPS is that one assigns a vacant core to do a polling loop for whatever would be generating an interrupt elsewhere). Strangely one can find Propeller QuickStart
formatting link
boards [which may have been the inspiration for the DefCon badge -- touch switches, LEDs...] for less than BASIC Stamps. For a more production item, but not at the level of building the support environment --
formatting link
-- which is probably closest to a BASIC Stamp (ie; 40pin DIP package that can be installed into some socketed product)

Small Arduino...

Or -- possibly overkill... A Texas Instruments TIVA C 123 Launchpad

formatting link
board (TI calls them evaluation kits, but given that they look so much like an Arduino [not pin compatible] in layout and function I'd consider them hobbiest kits)... These are ARM Cortex M-4 processors with lots of add-ons (the 123 has up to

24 timers -- 6 32-bit/12 16-bit, and 6 64-bit/12 32-bit). Cost varies: In the US, direct from TI, with shipping -- $13 (and the big brother with built-in Ethernet is $20); via third party on Amazon -- $40-50. Getting the programming environment is the pain... Most of the free ones are limited to 32K or so; the 123 comes with 256K, and the ethernet 1294 has 1MB (TI's Code Composer Studio supposedly has no memory limit -- but is locked to the Launchpad boards; can't be used with generic programmers). I'm guessing Energia isn't memory limited, but it's based off of the Arduino IDE modified to be Launchpad specific.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

All overkill just to drive a bunch of LEDs off a Pi. Really - if you already have the Pi in the first place for other tasks, then driving LEDs is fairly trivial - multiplexed, charlieplexed, via IO expander chips or even just directly. Pi model A/B has 17 usable IO pins, the A+ and B+ have 26 usable ones and via IO expanders - virtually unlimited. (if you can manage the wiring!)

Gordon

Reply to
Gordon Henderson

Or if multiplexing change the PWM (mark/space ratio) lot easier and lot less circuitry to use as the Pi has a clk output and various libraries have PWM capability. For 5 or more multiplex points on 1 to

2 kHz update frequency you have a lot of scope for brightness control. Just turn the 'column' control on for shorter or longer time.

If really fancy you could use different PWM widths for different 'columns'.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
 Click to see the full signature
Reply to
Paul

Bith the 594 and 595 have the same number of outputs, so for 23 outputs you need 3 oof either one. The difference between them is whether the output latch has a common clear or common output enable. I would suggest using 595 with the OE (Output Enable) then drive the output enable from a clock output to give you a form of global brightness control from a PWM signal.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
 Click to see the full signature
Reply to
Paul

In comp.sys.raspberry-pi message , Sat, 29 Nov 2014 21:20:02, Martin Gregorie posted:

For each independent LED output (i.e. after grouping) use half a 7474, all in a line. Connect each D to the previous Q, but the first D goes to one output pin of the Pi. Connect all of the Clocks in parallel, perhaps through a simple buffer, to another Pi output pin. Connect the Q or Qbar of each D-type to a driver for a LED group.

Once a minute, and at startup, write a data bit to the first output pin and pulse the second one, repeat as fast as possible until every lamp group has its new data bit. I guess you can easily do that in a millisecond, which you will not see on the display. You can use a pair of switches to do that much more slowly for initial test.

To use fewest output pins, i.e. one, encode the data as long and short pulses, trigger a monostable giving a middling delay from the rising edge, and use the falling output of that to clock your D-type chain.

It may be that a well-chosen type of 7474 can switch enough current to drive a modern LED adequately. If they cannot switch a group of LEDs, just use extra half-7474s for those stages.

Actually, IIRC, you can probably get multi-stage shift register chips with all outputs exposed. But I liked the 7474, when I built circuits.

--
 (c) John Stockton, near London.                Mail ?.?.Stockton@physics.org 
  Web   - FAQish topics, acronyms, and links.
Reply to
Dr J R Stockton

Actually, the rPi is very poor at I/O. Trying to multiplex a device with some dozens of LEDs to control will take a *lot* of the I/O capability and likely much of the processor... if it can even be done!

I looked into using the SPI for something high speed once and found it was only good for about 6 kSPS operation. The I2C driver may run a bit faster, but I believe the OP wants this to run in the background with minimal impact on the rest of the OS.

Maybe others are not so sensitive to it, but I find LEDs flashing to slowly to be very bothersome. When I drive at night I can spot the Cadillacs from a certain age very easily. Their tail lights are strobed too slowly so that when I move my view they create a trail of dots. Very disconcerting. It fools my peripheral vision into believing there are a lot more cars on the road than there really are. I certainly wouldn't want that in a clock.

--

Rick
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.