Jump to content

Possible fault with LED PAR 56 from Thomann


richardc1983

Recommended Posts

Sorry for the delay, but heres a tidied up circuit diagram/board layout for my lights. I run them off 12 volt switch-mode laptop power supplies, though the 5 volt regulator used in the circuit will happily handle up to 30 volts. However my circuit provides no current limiting for the LEDs. To limit the current I have the LEDs wired so that for each colour there are 16 sets of 3 LEDs in series with a resistor. Each set of three is wired like this : +12v -> Resistor -> LED ->LED -> LED -> Red, green, or blue input.

 

To work out the minimum resistor value I us the following formula : (Supply voltage - (number of LEDs in series * LED forward voltage)) / max. LED current in amps. For my green and blue LEDs the forward voltage is 3.1 volts and the max. current is 20mA, or 0.02A, so for 3 LEDs we get :

 

Minimum resistor value = (12-(3*3.1))/0.02 = (12-9.3)/0.02 = 2.7/0.02 = 135 ohms.

 

Anyway, heres the circuit diagram/stripboard layout first. The empty socket at the top right is for the programmer cable to be plugged into.

 

http://i157.photobucket.com/albums/t41/gyro_gearloose/componentsblackandwhite.jpg

 

and heres a pic showing the track side of the board to make it easier to work out which tracks to cut :

 

http://i157.photobucket.com/albums/t41/gyro_gearloose/Trackside.jpg

 

Finally, heres a component list :

 

D1 LED 5mm

D2 LED 5mm

- Solder pin, 1 mm

- Solder pin, 1 mm

- Solder pin, 1 mm

- Solder pin, 1 mm

- Solder pin, 1 mm

 

U1 Voltage regulator, 7805

 

D3 SI-diode 1A, 1N4004

 

T1 TO-220, STP36NF06L

T2 TO-220, STP36NF06L

T3 TO-220, STP36NF06L

 

Cr1 Crystal, 16 MHz

 

C1 Ceramic capacitor, 2,5mm, 100nf

C2 Ceramic capacitor, 22pF

C3 Ceramic capacitor, 22pF

C4 Electrolytic capacitor , 2200 µF

C5 Ceramic capacitor, 100nf

C6 Electrolytic capacitor 4,5mm, 10 µF

 

SC1 Socket DIL6

 

S1 Miniature push button

S2 DIL - multiple switch, tenfold

 

SIP1 Resistor array SIP 8+1, 10k

 

IC1 DIL8, MAX487

IC2 DIL16, 4021

IC3 DIL28, ATMega8-16PU

 

Note : I always put chips in sockets just in case I damage them when soldering them.

 

R1 Resistor 10k ohm

R2 Resistor 1k ohm

R3 Resistor 10k ohm

R4 Resistor 1k ohm

R5 Resistor 10 ohm

R6 Resistor 10 ohm

R7 Resistor 10 ohm

R8 Resistor 100k ohm

R9 Resistor 100k ohm

R10 Resistor 100k ohm

 

 

Note for the mods : In the interests of clarity, can everything from post 12 onwards be split into a new topic???

Link to comment
Share on other sites

  • 2 weeks later...

Not knowing that particular processor particularly well, am I correct in thinking that you're detecting the Break by seeing a framing error?

That's one of the more common 'shortcuts' in DMX reception, and causes much grief.

 

By using framing error, it means that simple 'noise' is very likely to be detected as another Break, and if the next byte happens to be zero it'll appear to 'shift' the address along.

So it's likely to flicker. On top of that, the nature of the flicekr will be different depending on the start address of the fixture...

 

Break must always be detected by measuring the 'low' time - it's why that time is specified.

 

Timers and 'edge' interrupts are generally the simplest way to do this.

Link to comment
Share on other sites

Break must always be detected by measuring the 'low' time - it's why that time is specified.

 

Timers and 'edge' interrupts are generally the simplest way to do this.

 

It's hard to do this on a mega without using up a lot of resources in the chip.

 

A reliable way to do it is to set the UART to 9-bit and detect if the 9th bit is zero (=break time, if all the other bits are zero too) or 1 (=data).

This does not actually check the break time for compliance with the standard. But it does always work.

Link to comment
Share on other sites

By using framing error, it means that simple 'noise' is very likely to be detected as another Break, and if the next byte happens to be zero it'll appear to 'shift' the address along. So it's likely to flicker.

 

If noise were appearing then the LEDs would flicker even when they were set to a static colour. Since this does not happen to my LEDs, then I assume that they are reasonably immune to noise. Given the balanced nature of RS485 communication as long as one uses the right type of cable, and terminates the line properly, then I can't see noise being that much of an issue. I do agree though that using the framing error to detect the break is not the best way to do it.

 

The OPs issue of flickering only occured when fading their LEDs up and down, and then only to the blue LEDs. This is most likely caused by the cpu not being able to handle DMX, PWM, etc all at the same time.

Link to comment
Share on other sites

  • 7 months later...
If noise were appearing then the LEDs would flicker even when they were set to a static colour.
Not necessarily. I've encountered this particular issue several times, and it's almost always very intermittent and thus highly irritating.

The flicker requires two things to happen in the same packet - noise dropping the stop bit causing a framing error immediately followed by a zero level, and early enough in the DMX stream for the fixture address to 'come around again' in the same packet.

 

You are fairly likely to see a flicker occur on a line with RDM-enabled devices on it and an RDM controller, if the address is below 24 or so. To be fair, very few RDM controllers exist at the moment!

The OPs issue of flickering only occured when fading their LEDs up and down, and then only to the blue LEDs. This is most likely caused by the cpu not being able to handle DMX, PWM, etc all at the same time.
That does sound pretty likely.

- I saw a cheap 1-channel LED fixture a couple of years ago that was almost reasonable on Address 1, but got more and more flickery as you increased the start address presumably because it simply couldn't process the received bytes fast enough.

(A Microchip PIC running on the internal oscillator is neither fast nor stable enough for either DMX reception or smooth PWM LED dimming.)

 

So your system is indeed a great improvement over the original, and the hardware looks pretty nice as well assuming a SELV supply.

 

I had another quick look at the code, and have a couple of suggestions for general improvement:

It would be great to keep rechecking the DMX address DIPs so that the user doesn't have to turn it off and then back on to change address.

 

There is enough time during BREAK to do this, so you could kill two birds with one stone this way:

- Frame Error or byte 513 received (probably BREAK start)

- Start checking the DMX Address DIPs (make this plus a byte time take slightly less than BREAK time)

- When DMX Address check completes, begin looking for START CODE.

 

- If any bytes are received while checking DMX address, discard the remainder of the packet as it was rubbish, and wait for another Frame Error.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.