Jump to content

Possible fault with LED PAR 56 from Thomann


richardc1983

Recommended Posts

Hello everyone

 

Hope someone can advise me. I bought a LED par for an uplighting project that I am doing.

 

http://www.thomann.de/gb/stairville_led_pa...ished_floor.htm

 

When set to the auto scroll so you set the dip switch to however long you would like the delay to be before it scrolls into the next colour however when it is changing to blue or any colour involving the blue leds it seems to flicker onto the blue meaning its not smooth to blend into the next colour it flashes on.

 

As I have only bought one of these I cannot compare next to another one to see if it does the same.

 

Can anyone else confirm if theres does the same as I have 10 days to return it.

 

Perhaps its how it works? I dont know.

 

Thank you Kindly.

Link to comment
Share on other sites

I've got some quite old Showtec 56's and to be honest that sounds familiar!

 

It hasn't mattered for my purposes so I've not really thought about it. If you have access to a DMX controller it may be worth having a play.

I suspect it's something you have to expect with the budget end of LED PARs :D

Link to comment
Share on other sites

I have a couple of these lights myself, and the same thing happens. However I have had loads of glitch like problems with them, I think you have to expect this with the built in functions (as it is a budget fixture) and so long as it works fine with the essential things like DMX then I don't think its any cause for concern.
Link to comment
Share on other sites

I suspect this effect is related to the fact that Blue LED have a much higher forward voltage than red or green

(4v as opposed to about 2.1v).

 

Ummm, no.... LED dimming is achieved by switching the LEDs on and off really quickly. The ratio of on-time vs. off-time is what gives the illusion of dimming. This is called Pulse Width Modulation (or PWM for short).

 

As to why the blue LEDs flicker in the Thomann, I can only assume it is something to do with the way it handles PWM for the blue LEDs. I've built a pair of LED wash lights using some red, green, and blue 10mm LEDs. The red LEDs had a forward voltage of 2.1, and the blue and green LEDs had a forward voltage of 3.3. They are controlled by an Atmel cpu which recieves DMX and has 3 channels of PWM. These are hooked up to some MOSFETs which in turn control the LEDs. I do occaisionally get some flickering on all colours when fading them up or down, but if I set them to a static colour then there is no flickering. I think I know how to stop this by changing the code so that the LEDs have a minimum fade time, much like a filament lamp does.

Link to comment
Share on other sites

I suspect this effect is related to the fact that Blue LED have a much higher forward voltage than red or green

(4v as opposed to about 2.1v).

 

Ummm, no.... LED dimming is achieved by switching the LEDs on and off really quickly. The ratio of on-time vs. off-time is what gives the illusion of dimming. This is called Pulse Width Modulation (or PWM for short).

 

 

Yes LED dimming is PWM , but the fact that Blue seems to repond differantly to the PWM signal does suggest that some characteristic of Blue LED is coming in to play.

High forward voltage on Blue is one difference , but may not be the cause of the response.

 

 

In Budget cans I suspect an identical PWM signal is sent to all LED colours (cheaper that way).

(ie no account is made of the Blue behaving in a way that is not how red and green behave)

 

 

Perhaps better units adapt the DMX to PWM conversion seperately for each colour and so give smoother fades , either that or there is some other extra circuitry to smooth out the flicker.

 

Either way it will mean the units cost more.

Link to comment
Share on other sites

High forward voltage on Blue is one difference , but may not be the cause of the response.

 

It depends on the LEDs used, but in my experience blue and green LEDs have the same forward voltage, and red typically has a lower forward voltage.

 

In Budget cans I suspect an identical PWM signal is sent to all LED colours (cheaper that way).

 

You wouldn't be able to mix colours if that were the case. If you use the same PWM signal to control the LEDs, then every LED will be at the same brightness!

 

The flickering the OP is experiencing may be down to the cpu not being able to handle DMX, PWM, and sound-to-light all at the same time. The cpu I am using has built-in serial communication and 3 channels of PWM. It only costs me a few pounds for the bits to make a circuit capable of receiving DMX and controlling 3 channels of LEDs, plus I can easily change the code to accomodate different effects such as strobing, colour chases, different dimmer curves, etc.

 

If anyone is interested, I've made a circuit diagram and code to enable you to build a 3-channel LED controller. It uses through-hole components and stripboard, so no nasty home PCB etching to worry about. The board is considerably larger than it would be if one were to use surface-mount components, but at least its fairly straightforward to build. At the moment the diagrams are hand-written on pre-printed stripboard templates, but I can always re-draw them if anyone is interested.

Link to comment
Share on other sites

Hi there Mark,

 

I wouldn't mind having a go at building and having a play with that circuit you've designed. I'm thinking that I could make some pretty nice specials with it. I'm presuming that all the components would be available from Maplins or CPC?

 

Do you want to post it or PM it?

 

Cheers.

Link to comment
Share on other sites

If anyone is interested, I've made a circuit diagram and code to enable you to build a 3-channel LED controller. It uses through-hole components and stripboard, so no nasty home PCB etching to worry about. The board is considerably larger than it would be if one were to use surface-mount components, but at least its fairly straightforward to build. At the moment the diagrams are hand-written on pre-printed stripboard templates, but I can always re-draw them if anyone is interested.

 

I'd also be interested - perhaps you could render the circuit diagram as an image and upload it to Photobucket or similar? Might make it easier to share.

Link to comment
Share on other sites

Wow! I didn't think that many people would be interested in my little lighting project! At the moment my circuit diagram is a little bit of a mess. I'll redraw it in Stripboard Magic or something similar and post a picture here. While I do that though heres a bit of information about my circuit.

 

Its basically an Arduino clone based on a simplified version of this schematic. It doesn't use the serial comms. portion of the circuit, but has a Maxim 487 RS-485 transceiver chip for receiving DMX. I use a 10-way DIP switch to set the DMX address, and a 4021 chip to read the switch settings. This means I can read 9-bits of data with only four pins on the cpu. To drive the LEDs I use three logic level MOSFETs connected to the PWM pins of the cpu. To program the cpu I use the free Arduino programming environment and a Parallel Programmer.

 

The LEDs I'm using are just some waterclear 10mm ones I found on ebay. I bought mine from Goodwill LED sales. Be warned though. I bought my LEDs in two batches and they aren't quite the same. The light spread from one batch seems to be slightly narrower than the other batch, and with the red LEDs the polarity was back to front. Usually you can determine the polarity of an LED by the flat side but the 10mm LEDs don't have this. Another method is looking at the length of the pins. The longer pin should be the anode (+), but with one batch of red LEDs this was not the case so check your LEDs before you solder them!

 

 

Mods : It might be worth splitting this into a new thread.

 

A concurrent post has been automatically merged from this point on.

 

Heres the code :

// ********************* local definitions *********************
#define DMX_CHANNELS	(3)		//Define the number of DMX values to store

enum {IDLE, BREAK, STARTB, STARTADR};	//DMX states

int  gDmxState;
int  DmxIndex;
int  DmxCount;
int  PacketComplete;

byte DmxField[DMX_CHANNELS];		   //array of DMX vals (raw)
int DmxAddress;					   //start address

int ledPin=13;

int RedPin=9;						  // LED PWM pins
int GreenPin=10;
int BluePin=11;

int clockPin = 5;					  // Define the 4041 shift register pins
int latchPin = 6;				  
int dataPin = 7;
int highBit = 8;

void setup()						   // run once, when the sketch starts
{
 pinMode(ledPin,OUTPUT);
 digitalWrite(ledPin,LOW);

 // sets the PWM pins as output
 pinMode(RedPin, OUTPUT);	  
 pinMode(GreenPin, OUTPUT);	  
 pinMode(BluePin, OUTPUT);	  
 
 // setp the shift register pins
 pinMode(clockPin, OUTPUT); 
 pinMode(latchPin, OUTPUT);
 pinMode(dataPin, INPUT);
 pinMode(highBit, INPUT);

 
 // Set up the serial port for DMX reception - 250kbps
 // Disable interrupts
 cli();	 
 
 // 250kbps baud - only works for 16MHz clock frequency. See the ATMega8 datasheet if you are using a different clock speed
 UBRRH = 0;
 UBRRL = 3;

 // enable rx and interrupt on complete reception of a byte
 UCSRB = (1<<RXEN)|(1<<RXCIE);
 UCSRC = (1<<URSEL)|(3<<UCSZ0)|(1<<USBS);

 // Enable interrupts
 sei();

 gDmxState= IDLE;
 PacketComplete= 0;

 // Clear the DMX input array
 int I;
 for (I=0; I<DMX_CHANNELS; I++)
 {
DmxField[I]= 0;
 }

 // Grab the DMX base address from the shift register
 DmxAddress= 0;  
 
 //Pulse the latch pin:
 //set it to 1 to collect parallel data
 digitalWrite(latchPin,1);
 //set it to 1 to collect parallel data, wait
 delayMicroseconds(20);
 //set it to 0 to transmit data serially  
 digitalWrite(latchPin,0);

 //we will be holding the clock pin high 8 times (0,..,7) at the
 //end of each time through the for loop

 //at the begining of each loop when we set the clock low, it will
 //be doing the necessary low to high drop to cause the shift
 //register's DataPin to change state based on the value
 //of the next bit in its serial information flow.
 //The register transmits the information about the pins from pin 7 to pin 0
 //so that is why our function counts down

 int temp= 0;
 byte dataIn= 0;

 for (I=7; I>=0; I--)
 {
digitalWrite(clockPin, 0);
delayMicroseconds(2);
temp = digitalRead(dataPin);
if (temp) 
{
  DmxAddress= DmxAddress | (1 << I);
}
digitalWrite(clockPin, 1);
 }

 //Now we grab the highest bit (bit 9) of the address
 temp = digitalRead(highBit);
 if (temp==1) 
 {
DmxAddress= DmxAddress+256;
 }
 
}

void loop()					 // run over and over again
{
 if(PacketComplete== 1)
 {
PacketComplete= 0;

analogWrite(RedPin,DmxField[0]);
analogWrite(GreenPin,DmxField[1]);
analogWrite(BluePin,DmxField[2]);
 }
}

// *************** DMX Reception ISR ****************
SIGNAL(SIG_UART_RECV)
{
int USARTstate= UCSRA;					//get state
byte DmxByte= UDR;						//get data
int DmxState= gDmxState;					//just get once from SRAM!!!

if (USARTstate &(1<<FE))					//check for break
{
UCSRA &= ~(1<<FE);					//reset flag
DmxCount= DmxAddress;					//reset frame counter
gDmxState= BREAK;
}

else if (DmxState == BREAK)
{
if (DmxByte == 0) 
	{
	gDmxState= STARTB;				//normal start code detected
			digitalWrite(ledPin,HIGH);
	}
else gDmxState= IDLE;
}

else if (DmxState == STARTB)
{
	DmxCount= DmxCount - 1;
if (DmxCount == 0)					//start address reached?
			{
		gDmxState= STARTADR;
	DmxField[0]= DmxByte;
	DmxIndex=1;
		}
}

else if (DmxState == STARTADR)
{
	DmxField[DmxIndex]=DmxByte;
	
	DmxIndex=DmxIndex+1;

if (DmxIndex==DMX_CHANNELS) 		  //all ch received?
	{
			digitalWrite(ledPin,LOW);
	gDmxState= IDLE;
			PacketComplete= 1;
	}
}							
}

Edit : I've noticed something odd. The code is indented when I edit this post, but the tabs disappear when it is posted. Odd.

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.