Weird DMX problem

[soapdodger]

Hello everyone.

 

I'm using an Arduino with a SKPANG DMX shield to transmitt DMX

 

http://www.skpang.co.uk/catalog/product_in...products_id=663

 

I'm receiving the DMX with the following DMX RGB LED

 

 

http://www.colorstars.com/Products/products_Detail.aspx?ProductsID=89 ://http://www.colorstars.com/Products/...?ProductsID=89

 

 

Problem is the LED wont respond to the DMX from the SKpang board.

 

All my other DMX devices receive the DMX from the skpang ok.

 

If I plug the LEDs into my DMX streamer they work fine. This the weird bit: If I then plug them into the DMX from the SKpang they will start receiving DMX and work fine.

 

So basically it seems the LEDS dont like the signal from the SKpang DMX Board, I've tried all the obvious things like cabling, reversing the polarity of the DMX, termination, earthing DMX to ground and alternative power supply's

 

I Also spoke to Skpang who recommended putting a 120ohm resistor over the +/- on the DMX output socket. I tried this to no avail.

 

I also talked to someone involved with the firmware (firmata) that we use on the arduino, I questioned him to see if he thought it was a timing issue. Does anyone know the ins and outs of DMX timing?

 

I think this fault is due to the LEDS being a bit borderline when it comes to adhering to the DMX standard, the use of a 2 wire system is an example of this.

 

What I need to find out is what is wrong with the DMX signal and how do I improve this signal so my LEDs will pick it up.

[dbuckley]

Timimg would be my suspicion, or possibly the update rate being too high.

 

Plugging the sending thing into a DMX tester would give an instant answer.

[back_ache]

I suspect one of both the devices are not completely compliant with the DMX standard.

 

If you don't have a DMX tester, try plugging in some nice boring reliable kit into each of them (a desk for the LED's and dimmer for the Arduino) to see if that points the finger.

 

That shield just seems to have one chip on it, if its a fairly dumb converter chip, you may have the option of using alternative DMX library's

[HMD]

Sound like the fixture may be non standard compliant.

 

I've posted some sort of explanation of what may be occurring here.

Blue LED's staying on???

 

Cheers

 

Hamish

[greenalien]

Adam Bennette's book 'Recommended Practice for DMX512' is the standard reference for the fine details of DMX such as signal timing. Now in its second edition, available from LSI Online. If you're interested in tinkering with DMX, it's money well spent.

[soapdodger]

I received an email from the manufacturer:

 

 

The problem is the "SPACE" for BREAK of the TRISTAR-RGB-DMX, which is 500. The standard DMX "SPACE" for BREAK is 88~144, but some DMX controllers handle a wide range of from 88~1,000.

 

So at this point, unless we can get our engineers to change the "SPACE" for BREAK, you need a DMX controller than can handle 500.

 

 

 

 

now I need to alter the firmware to output the non conforming break.

[HMD]

Hi Alexis

 

I believe the current E1.11 standard specifies the Break minimum for a controller (Non RDM) to be 92us. Not sure where the 144 comes from.

A fixture / receiver should be able to handle from 88us upwards, which is where your fixtures appear to part company with the standard.

 

A controller generating breaks at 500us, as far as I am aware, does not break the standard for non RDM fixtures, although some one may wish to correct me on this point.

Variable DMX transmission characteristics is not that uncommon and something that we've had to take account of in our developments.

 

Hamish

[dbuckley]

The standard DMX "SPACE" for BREAK is 88~144, but some DMX controllers handle a wide range of from 88~1,000.

In the original DMX specification (DMX512/1990), it says:

5.0.1 RESET SIGNAL

The RESET signal ... shall consist of a BREAK lasting 88uS (two frame times) or any longer duration.

To be compliant with the full spec the RESET could not be longer than just under a second.

 

The timing was not changed in the draft of DMX512-A, buit may have been changed in the final spec, but I doubt it.

[pshughes]

now I need to alter the firmware to output the non conforming break.

 

That looks like fun! A quick squint at the code looks like it's all timed using the number of instruction cycles :P

[Woofy]

E1.11.

Break timing is a minimum of 92uS (Rx has to go down to 88uS) and typically 176uS. There's no maximum specified however there is a slot to slot maximum of 1s.

 

500uS is fine.

[Dmills]

I don't have a copy of the standard in front of me but IIRC there is also a minimum break to break time which may be an issue if only transmitting a very small number of channels.

 

Regards, Dan.

[Woofy]

I don't have a copy of the standard in front of me but IIRC there is also a minimum break to break time which may be an issue if only transmitting a very small number of channels.

 

Regards, Dan.

1204uS

[soapdodger]

I don't have a copy of the standard in front of me but IIRC there is also a minimum break to break time which may be an issue if only transmitting a very small number of channels.

 

Regards, Dan.

1204uS

 

thats interesting, as I'm only using 9 channels

[greenalien]

A quick squint at the code looks like it's all timed using the number of instruction cycles

 

Correct - that's exactly how a software-based DMX decoder is written. Timing is everything, and instructions all take an exact length of time.

[soapdodger]

I got an email from the LED manufacturer saying that the break time was 40us not 500us as originally stated, I tried this but still no joy.

 

I've had a look at the signal on a scope, there are large ripples on the start of the pulse wave, these extend almost as high as the waveform itself and remind me of a audio percussion sample.

 

When I look at the waveform from my enttec streamer I can see a nice square waveform.

 

I'm thinking the LEDs have trouble registering the signal as there isnt a clean differential in the signal, is this likely?

 

If so how can I clean up the signal? maybe trying another driver chip instead of the max481cs fitted to the SK Pang board will help?