Check me here guys...(Jands Vista/Chauvet ColorStrip)

[theatre4jc]

Okay here's my situation. I purchased a few cheap Chauvet Color Strip LEDs to light a few panels. Higher end gear was beyond my budget for this project and even if I could afford it quality units were overkill. I am using a Jands Vista S3 and when I load the profile for the light I get this random flashing. Not the typical flicker associated with dimming. The unit actually flashes other colors randomly. I have full dimming control, DMX is good and clean. This is happening with all 12 of my fixtures. I'm thinking the issue is in the fixture profile so this is what I'm thinking of trying.

The fixture uses 4 channels of DMX, Channel 1 for "Fixture Mode" (with a range that sets it in RGB mode), Channels 2-4 for RGB respectively. The vista profile adds a master control for intensity. I want to bypass this so here is my thought. I'll use a generic RGB LED profile that does not include intensity. But since that is only a 3 channel profile I'll use a generic dimmer for the fixture mode (channel 1). On the patch I'll make the generic dimmer channel 1 and then the generic LED for channels 2-4. This would by pass the intensity control that I think is my problem. Do you guys think this might work. Am I correct in assuming the LED will read the DMX like normal even though the profile is for a dimmer? I asked for help on the Jands Vista forum but so far have not gotten a reply.

 

[derekleffew]

Sounds like a reasonable workaround, but I don't think it's going to solve your problem. See this post http://www.controlbooth.com/forums/lighting/9943-chauvet-led-colorbank.html#post119221 and the entire thread.

 

[tyler.martin]

Hmmm, I was on a corporate gig this past week, and had a similar problem. We were using a GrandMA Ultralight, and some Microh LED P64's. The Ma did not have a profile for them so our programmer did the exact same thing you did, and it did work. Just a Generic RGB LED Profile, and one Channel of Dimming... Give it a shot and let us know!

 

[MillburyAuditorium]

Well, As I know for DJ lighting, there are strobe features that will cycle through every possible color the light can make. Its so DJs can be lazy. Make sure the dip switches are set right, you are using DMX not XLR cables, and be sure the sub master slider for Strobe on the fixture is down. Get all the submasters that contol the unit, I think there are 5 or 6, (My par can, has one for blue, one for red, one for green, one for strobe, one for itnensity, and one that cycles through colors.), And just take each slider and move it to full and back down to 0. And do it for each slider, dj quality lights being cheaper tend to do this, so it would be worht a try to do th 0-100 100-0 thing I explained : )

 

[Brownlight]

I have had some problems with Jans/ Vista and Chauvet. What I found was that If I put a DMX spiltter and boasted the DMX output of the board all my problem went away. weird but it work ?

 

[JChenault]

You might want to try using the standard profile, but setting the faux intensity channel to full. I would expect (based on logic, not experience ) that if the 'Master intensity' control is set to full, that the RGB should just be output at full values.

John

 

[jmabray]

The random flashing you are describing is due to the low quality DMX transciever chip with the Colorstrip not being able to take 44 times a second refresh rate on the DMX. As I understand it the buffer fills up and just kinda freaks out.

However, there is hope - If there is a way to slow your DMX speed down coming out of the console, I would try that.

I had this same issue with these exact fixtures a year or so ago with an ION console. I was able to slow the DMX speed down and there was no further issues. I was not able to slow it down enough on the Expression console to get it to work though - Just the ION.

You might also try calling Chauvet directly. Their tech support knew about this issue and said a fix was being worked on - but I don't know if they were able to come up with something yet.

Good Luck!

 

[theatre4jc]

Okay was checking other sites and forums for any possible ways around this issue. My console will not change the dmx refresh rate and I read another suggestion but sadly there was no reply to see if it actually worked. It seems the lower the light is addressed the less there is a flicker because it has less time to receive packets, I guess? Anyway the suggestion was put the LEDs as an address of 1 and have some other fixture set at the highest output for the board, which for me would be an address of 510 for my hazer. The thought behind this is that it would give the most time possible from when the light first receives the DMX packet to when it next receives the next refresh rate.

I'm skeptical if this would work. Worth a try. Think I'm wasting my time by trying it?

 

[Kelite]

It's worth a try David, though the actual time delay won't be very much. Even if he is a sales guy, Jamey Brock has been hawking DMX related good at Martin Professional for quite a few years and may have an opinion regarding the Chauvet's care and feeding.

jbrock @ iluminarc . com


(And please tell him Keith from Apollo says YO!)

 

[derekleffew]

theatre4jc, have you resolved your issue yet? If so, what was the solution?

 

[theatre4jc]

I have not. When I put the LED strips addressed at 1 and my hazer at 511 the flashing dropped considerably but didn't go away. When I addressed the unit at 5 the flashes were noticeably bad.

I had to stop working on the issue because I left the country for a short tour in South Africa. Once I got back I haven't had time to get back to the issue due to more pressing issues.

Can't change the data rate on my console, but am hoping to find an inline device that can alter refresh rates. Sadly I haven't yet but have not given up hope.

 

[traviswill]

Were you ever able to work the porblem out? I'm having the same issue and Jands has been of no help. I would surely appreciate any new suggestions you have.

 

[theatre4jc]

I've not got it fixed. I did finally talk to someone at Chauvet that would actually admit that the light is a POS and had known issues. He then told me that Doug Fleener does make an inline device that will slow the DMX rate, which has been known to fix the issue. If your system uses programable nodes you might be able to try that route. I've not attempted this yet because I do not have any nodes in the room these units are in, but I do have some ETC NET2 nodes in another room and I've been thinking of slowing the output rate down from them and see if that fixes it. Might put a couple into the mix and try it.

But the official Jands view is there is nothing they can do. Because of this light they tried to add in a feature to slow the DMX rate from the console, but it was far to unstable to release to the public. Maybe Byron will be able to solve this, but I'm not holding my breath. Till then I just run them as a static light with a quick snap change of colors.

 

[SHARYNF]

I am not a Jands user but here is what ETC did to fix the problem. I would guess that with a bit of encouraging and perhaps sending a color strip to Jands they could fix this for you

AdamBennette replied on 11-05-2009 3:19 AM
rated by 0 users

Hello,

yes, this has been solved in the current version 2.1.1 We adjusted some of the slower DMX settings to be more suitable to the Chavet products which are unable to receive DMX at full speed.

Please update your console and SmartSoft to the latest version. SmartSoft 2.0.1 (which includes SmartFadeML 2.1.1 inside) is available here: Lighting solutions for Theatre, Film & Television Studios and Architectural spaces : ETC Enter SmartSoft as the keyword and Software as the download type.

If you do not use SmartSoft you can download the console software independently. Enter SmartFade as the keyword and Software as the download type. You need version SmartFadeML 2.1.1

here is the forum overall link

Yes is is a Chauvet fault but Jands should be able to fix it

Chauvet Colorstrip Flickers no matter what DMX Speed is used - happened after 2.0 upgrade - Electronic Theatre Controls


Sharyn

 

[jmabray]

Yes is is a Chauvet fault but Jands should be able to fix it

I disagree with you - This is entirely Chauvet's fault. They have made a fixture that does not respond to industry standard DMX. When I talked to the guys at Chauvet about it at their booth at LDI, they blew me off completely telling me that they only had 8 or so complaints about this issue and as this was one of their highest selling fixtures, they weren't going to go back and fix the issue. (Talk about your flawed logic... but I digress)

These fixtures are made as cheaply as possible and sold for the highest margin that they can get away with. Well that's what a company is supposed to do, right? Yes, they are, but they are also supposed to do what is right and fix issues that their customers bring to their attention. When they don't do that, that's what chaps my a**. Chauvet is relying upon other companies to devote time and resources to fix their issue and not taking responsibility for it themselves.

I brought the issue to ETC's and Chauvet's attention a good year and a half ago now. They have known about it at least that long. ETC took the time to go out and have Chauvet ship them a fixture and re-write some of their software to fix the issue. Chauvet basically told me to F'off.

Nice.....

 

[SHARYNF]

While I agree with you that it is Chauvet's fault, I disagree with what is the LIKELY solution. Jands like ETC realize that excellent customer service is important no matter who's fault it is, and will resolve the issues. It would be interesting to see what ETC actually did but I get the impression that the Chauvet unit technically fits the spec but has a problem at the margins of timing, there have been a few tweeks to the DMX spec over time on the between times that mark the beginning and end.

I followed up with Milton Davis and Doug Fleenor Design has a product called DMX2DMX-5 (or DMX Decelerator ) with Chauvet Output Software, the output is specifically set up to drive the Chauvet fixtures. It looks like a 123 splitter wut with one DMX in and one DMX out list price is 772.20 so it is not an inexpensive solution.

Milton does say that Chauvet's comment was we are aware of the issue but we have decided we are not going to do anything about it...

So maybe a campaign from members to complain to Chauvet and maybe we can get Bill who is a dealer to put more pressure on Chauvet

Chauvet's email is [email protected]

Sharyn

Sharyn

 

[jmabray]

Just curious... What makes you think that Chauvet's equipment meets the spec. Transmitting DMX is easy. Receiving it is more difficult. (There are slight differences in what is allowable to be transmitted and this is why it is more difficult.)

If everybody else's fixtures can transmit and receive just fine but these can't it would seem that they are the ones that don't meet spec. (never mind the fact that it has been tested and proven to be the case.) It's close... but not close enough.

I understand that Jands and ETC and others can and, most likely, will pick up the slack for a negligent and unresponsive manufacturer, but why should they have to. Chauvet should grow a pair, admit that this is an issue, and fix it. If they did that - they would gain more in respect garnered than it cost them to do so.

As it is right now, I will not even come close to reccomending any of their products to any of my customers and will actively tell them to go to another manufacturer - not based upon their initial product - but rather solely based upon their response when the problem arose.

 

[SHARYNF]

So we just were able to get a technical description of exactly what the problem is with the color strips from Milton Davis of Doug Fleenor Design:

The issue is that the Chauvet fixture can not cope with consecutive DMX bytes with no time between the bytes. The DMX specification says that the time between consecutive bytes can be 0 seconds to as much as 1 full second. A large percentage of control consoles produce no time between bytes. The Chauvet fixture doesn't have enough processing "horsepower" to take in the byte and prepare for the next one if they are sent back-to-back with no time between them. The result is flickering or shifting of levels. In order to operate correctly, we add about 40 microseconds (0.000040 seconds) of dead time (also called "marking" time) between DMX bytes. This allows the fixture enough time to receive the data byte and get ready for the next one. Some consoles such as the newer ones from ETC take care of this issue by adding the appropriate dead time when their DMX outputs are set to the "slow" mode. The resulting output update rate for their consoles or our interface is about 25 Hz. Our interface doesn't care what the incoming update rate is. We take in the data, put it in a table and transmit it with timing parameters that the Chauvet fixture can cope with. The incoming data rate and the outgoing packets are completely disconnected in terms of timing; only the DMX data is passed along.

Sharyn

 

[SHARYNF]

where I was coming from was using the Wikie

Timing

DMX512 timing parameters are allowed to vary over a wide range. The original authors specified the standard this way to provide the greatest design flexibility. Because of this, however, it was difficult to design receivers that operated over the entire timing range. As a result of this difficulty, the timing specification of the original 1986 standard was changed in 1990. Specifically, the MAB, which was originally fixed at 4 μs, was changed to 8 μs, minimum. The E1.11 (2004) standard relaxed the transmitter and receiver timing specifications. This relaxed the timing requirements for systems using controllers built to DMX512-A (E1.11); however, a significant number of legacy devices still employ transmit timing near the minimum end of the range.
-- Min Break (μs) Min MAB (μs)
Transmitted 92 12
Receiver recognize 88 8

Maximum times are not specified because as long as a packet is sent at least once per second, the BREAK, MAB, inter-slot time, and the mark between the last slot of the packet and the break (MBB) can be as long as desired.

A maximum-sized packet, which has 512 channels (slots following the start code), takes approximately 23 ms to send, corresponding to a maximum refresh rate of about 44 Hz. For higher refresh rates, packets having fewer than 512 channels can be sent.

The standard does not specify the minimum number of slots that can be sent in a packet. However, it does require that packets be transmitted so that the leading edges of any two sequential BREAKs must be separated by at least 1204 μs, and receivers must be able to handle packets with break-to-break times a short as 1196 μs.[2] The minimum break-to-break transmit time can be achieved by sending packets that contain at least 24 slots (by adding extra padding bytes, if necessary) or by stretching parameters such as the BREAK, MAB, Interslot, or Interpacket times.


Sharyn

 

[starksk]

It's close... but not close enough....

So we just were able to get a technical description of exactly what the problem is with the color strips from Milton Davis of Doug Fleenor Design

The issue is that the Chauvet fixture can not cope with consecutive DMX bytes with no time between the bytes. The DMX specification says that the time between consecutive bytes can be 0 seconds to as much as 1 full second. A large percentage of control consoles produce no time between bytes. The Chauvet fixture doesn't have enough processing "horsepower" to take in the byte and prepare for the next one if they are sent back-to-back with no time between them. The result is flickering or shifting of levels. In order to operate correctly, we add about 40 microseconds (0.000040 seconds) of dead time (also called "marking" time) between DMX bytes. This allows the fixture enough time to receive the data byte and get ready for the next one. Some consoles such as the newer ones from ETC take care of this issue by adding the appropriate dead time when their DMX outputs are set to the "slow" mode. The resulting output update rate for their consoles or our interface is about 25 Hz. Our interface doesn't care what the incoming update rate is. We take in the data, put it in a table and transmit it with timing parameters that the Chauvet fixture can cope with. The incoming data rate and the outgoing packets are completely disconnected in terms of timing; only the DMX data is passed along.

Sharyn

jmabray got it right. SHARYNF's explaination of the problem is also accurate. Because of the interbyte timing needed by the fixture, they do not meet appropriate timing guidelines.

Here is information about DMX Speeds and timing that is implemented on ETC Products from our Wiki Article:

We, ETC, adjusted the timing speed of our "slow" setting to compensate and allow for the extra timing required by the Chauvet fixture. (They required a 46μs interbyte time)

We also discussed with them about how to change their fixture to meet spec, but they declined to take action.

Edit: Sorry for the simulpost