I'm trying to hook up a Chauvet Colorstrip but I can't get it to work.
The LED on the Colorstrip is blinking, indicating it's receiving the DMX packet, but the light values aren't changing. I've changed the packet size to 64 as mentioned in this thread, but how do I change the MAB timing?
Ziggy252 said...
You may need to check that the end of the DMX line is properly terminated. IIRC you need 1 120 ohm resistor between pins 2 and 3
However if the line is short and between a DMX Transmitter and the light fixture the termination would help but not cause too much noise - unless the transmitter/receiver were really mismatched.
I need to get back to working on a DMX Transmit routine sometime. First I need to do some rework in the DMX receive routine. I will keep watching this thread to learn how your further testing goes flo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT www.tdswieter.com
I tried changing the packet size but can't conclude anything. Sometimes a single color will not flicker and other time it flickers. Moreover, it seems that when two colors are on, it will always flicker more or less violently.
I placed a 110 Ohm resistor between pins 2 and 3 as I don't have a 120 Ohm on hand. How important are those 10 Ohms?
After some googling, it seems that this is a common problem among the cheap LED lights that don't follow the DMX standard. The solution seems to be, "slow down the DMX by increasing the interslot time" from http://srforums.prosoundweb.com/index.php/t/22244/0/
How would I go about doing that in Teva's Propeller object? I don't understand assembly... Mech. Engineer, sorry :-\
If it helps: I increased the packet size up to 4097 and the flickering occurs less frequently but the color changes stay on for longer.
So for example, I put red at 255 and green at 255. It'll flicker by turning off green. The time the light is only red (green is off) depends on the packet size.
It also flickers less frequently if I set the values to 50 rather than 255.
We used to have this problem with the enttec dongles. The standard doesn't really explain what the expected behaviour is for short frames (ie if your frames are short is it ok to send more of them or must you keep the frame rate down), and some gear just can't deal with it. My dimmer racks used to do pretty much what you're describing with the led gear.
See what happens if you set ALL the channels to the same value, and fade them up and down together. if you find that it doesn't flicker the same way, the problem is probably that the receiver has missed locking on to the start of the frame.
I've added code to wait between frames, if you send 512 byte frames it should get around 30 frames/sec out. That's still plenty fast enough to control your gear, and gives you more breathing space at the sending end for other things (I have mostly working code here somewhere that handles DMX out at 25 frames/sec, as well as about 100 8-bit ADC inputs and 100 6-bit PWM outputs, all in one cog)
You might also want to try adjusting the length of the break. The standard allows for 88us up to a 1 second break, it's now about 120us. Probably won't make any difference but give it a go.
I haven't tried this on hardware yet, I'm late for work, so good luck!
Ziggy, I think you hit the nail on the head. I set the packet size to 5 ( the light has 4 channels), and set RGB to 255, 255, 255 then ran a loop that decreased the values to 1 and then back up to 255. No flickering, works perfectly. Set RGB to 255, 255, 0, this time only changing the the red and green channels keeping blue at 0, and there was a lot of flickering.
I can't begin to describe how thankful I am that you guys are here! I finally feel like I'm going somewhere on this project again.
The DMXout2a spin file you posted isn't sending DMX packets though :-\ I tried comparing version 1.03 that I've been using and yours but all the changes are in assembly which I'm completely lost about. Does anyone see a glaring error that is a quick fix?
Can't we put a waitcnt between packet sends in the spin code?
The assembly code sends out frames as fast as it can, the spin code just updates the contents of the array. The wait has to be in the assembly code.
There's a timer overflow problem where it tries to send out the bytes. The DMXout2 file I based it on from earlier in the thread has the same problem.
Since the code you have doesn't have this problem, you can apply my modifications to your file:
So I've spent the morning reading Asm tutorials and the such and ended up writing nearly exactly what Ziggy wrote in the post above. However, I have a few questions:
When you have
Waitcnt target, delta
the cog waits until cnt=target, then adds delta to target for next time. In this case we set the value of dmxdelaycnt each time we use it, so it doesn't matter what the waitcnt sets it to.
OK, just had the AHA! moment.
The reason it fails when we add the delay is because the last time we called waitcnt we set the delay for the next time we use it. This is usually not a problem, but seeing as how we added a huge delay in between, it misses the count for next time.
In looking at what we'd need to change to correct that, I realised that we already have almost what we need. The first part of the packet is idling the line for a while before the break. All we need to do is extend the idle time (and in fact that's what we've kind of done in a round-about way). Amazing what a good night's sleep does for looking at a problem!
Throw out all the changes we made before. Go back to the file you posted yesterday.
Change the line after the 'packet' label from
Unfortunately the light works but the problem isn't solved
What's even weirder is the original DMXout (the one I posted) did not flicker when all the channels were the same value and faded up and down. However, the file you posted with the FPS variable, flickers sporadically. I changed the FPS from 30 to 5 in steps of 5, and it flickered for all of them with no change in "flickerness."
Ok so, back to the drawing board, thinking out loud, here are the summary of our results:
- DMXout is the original file from object exchange
- DMXout2c is the file changed with an FPS variable to adjust the timing by changing the idle time
DMXout; Packet Size 513; all values the same; fading up/down = flickering
DMXout2c; Packet Size 513; all values the same; fading up/down = flickering
DMXout; Packet Size 5 (only active channels); all values the same; fading up/down = [b]no flickering[/b]
DMXout2c; Packet Size 5 (only active channels); all values the same; fading up/down = flickering
DMXout; Packet Size 5 (only active channels); R value = G value, B = 0; fading up/down = flickering
DMXout2c; Packet Size 513; FPS 30 thru 5; all values the same; fading up/down = flickering
DMXout2c; Packet Size 5; FPS 30 thru 5; all values the same; fading up/down = flickering
The conclusion is that only one way works perfectly. As a side note, the flickering for the last two tests was minimal compared to the DMXout tests that flickered.
My hunch is this timing idle wait is half right, something is missing. Thoughts?
I know this is silly, and should be as easy as pie.· But could someone post their test DMX program.· Say, channels 1 – 4 at level 255.· I have downloaded the object needed to run DMX·but I’m not sure if I am writing the channel, and level information correctly.· Also, how do you assign levels to multiple channels.·I do get a quick flash on the DMX indicator lamp but nothing else.·Needless to say I am new, new, new to propeller.· I do have experience in Basic Stamp and thought I could make the jump.·
That looks good but don't forget to set the constants at the top that tell the propeller what speed to run at (I actually don't know what they're really for)
I've included the demo program I've been running and the DMXout I've had the best luck with. The demo program fades channels 2,3, and 4 from 255 to 1 and back up to 255 endlessly.
A thing to take into account: my light requires channel 1 to define what mode to run in (chase, color change, rgb, strobe, etc.) That's why my channel 1 is statically set to 214 (the value for RGB). Check your light documentation to see if it needs it or not.
Oh, and in DMXout.spin, I've set the packet size to 5 (4 channels; it's default value is 513 for 512 channels) because my light is quirky like that. The smaller the packet size, the faster the refresh.
-Transmit a break time, which is a logical "0" lasting for 88 microseconds. On a microcontroller you can usually do this by temporarily setting the baud rate to 96KBaud, then transmit a "0" byte.
-Then transmit a startcode of "0" (returning the baud rate to 250KBaud).
-Then transmit up to 512 8-bit channel level bytes.
In the current code, I don't see anything changing the baudrate. How is the hold happening?
Figured out a little bit more. Studied assembly and the DMX protocol more and from that was able to figure out what's controlling the length of break, MAB (mark after break), and idle time between packets.
For those learning assembly, mov txdata, #1 assigns txdata to the number 1, the next line assigns 100 to txrep, and the third line calls tx (which you can find at the bottom of DMXout.spin). Tx, waits 4 microseconds (250k Baud), sends txdata (number 1 in the first case), and repeats this loop txrep times (100 in the first case). So, by changing txrep, you can control the length of break, MAB, and idle.
Here are my changes that brought the best results:
I say best because the lights works without flickering for up to ~40 seconds, flickers for a while, then does another <40 seconds of perfect operation. It's as if I'm going in and out of phase with the receiver in the Chauvet light.
I can play around with those three values for years before finding the right combination. Any ideas how I could determine these through a set of tests?
To further narrow down the possible problems I used an oscilloscope to look at the data packet being sent.
I'm curious at the huge break after the MAB. Should that be there? How do I remove it? Sorry that's start code.
The red text in the following pictures is the calculated timing based on the tx function in the assembly code (txreps * txticks or [noparse][[/noparse]#of loops] * [noparse][[/noparse]wait time]):
I've done limited DMX work with the SX and one of the things I'm excited to experiment with the Propeller is DMX (and MIDI, specifically to build a MIDI-to-DMX bridge). I've attached code that is, essentially, a translation of SX code that has worked for me (albeit with very short packets due to the SX's RAM limitation). Perhaps it will be helpful and I would, of course, welcome comments from others.
Hardware is on the way so while the code does compile I haven't yet run it on anything.
[noparse][[/noparse]Edit] I've attached my DMX receiver code for anyone who has hardware setup and would like to try it.
Comments
The LED on the Colorstrip is blinking, indicating it's receiving the DMX packet, but the light values aren't changing. I've changed the packet size to 64 as mentioned in this thread, but how do I change the MAB timing?
(If anyone has the same problem: the Colorstrip uses channel 1 as a changing mode value, so check page 14 of the PDF manual at the chauvet website)
However, I'm still having a problem. The light is behaving erratically. The R G and B LEDs flicker at no discernible pattern.
In some of the color modes (like color fade and sequential color chases, the flickering occurs. However, during static color modes they do not).
I'll do some more testing tomorrow. Could it be interference in the cable or the light is faulty? I don't have a light controller to test it...
However if the line is short and between a DMX Transmitter and the light fixture the termination would help but not cause too much noise - unless the transmitter/receiver were really mismatched.
I need to get back to working on a DMX Transmit routine sometime. First I need to do some rework in the DMX receive routine. I will keep watching this thread to learn how your further testing goes flo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
http://www.controlbooth.com/forums/lighting/9943-chauvet-led-colorbank-2.html
I tried changing the packet size but can't conclude anything. Sometimes a single color will not flicker and other time it flickers. Moreover, it seems that when two colors are on, it will always flicker more or less violently.
I placed a 110 Ohm resistor between pins 2 and 3 as I don't have a 120 Ohm on hand. How important are those 10 Ohms?
Anyone have similar experience with their lights?
How would I go about doing that in Teva's Propeller object? I don't understand assembly... Mech. Engineer, sorry :-\
So for example, I put red at 255 and green at 255. It'll flicker by turning off green. The time the light is only red (green is off) depends on the packet size.
It also flickers less frequently if I set the values to 50 rather than 255.
See what happens if you set ALL the channels to the same value, and fade them up and down together. if you find that it doesn't flicker the same way, the problem is probably that the receiver has missed locking on to the start of the frame.
I've added code to wait between frames, if you send 512 byte frames it should get around 30 frames/sec out. That's still plenty fast enough to control your gear, and gives you more breathing space at the sending end for other things (I have mostly working code here somewhere that handles DMX out at 25 frames/sec, as well as about 100 8-bit ADC inputs and 100 6-bit PWM outputs, all in one cog)
You might also want to try adjusting the length of the break. The standard allows for 88us up to a 1 second break, it's now about 120us. Probably won't make any difference but give it a go.
I haven't tried this on hardware yet, I'm late for work, so good luck!
post edited - added test idea
Post Edited (Ziggy252) : 7/2/2009 11:25:01 PM GMT
Ziggy, I think you hit the nail on the head. I set the packet size to 5 ( the light has 4 channels), and set RGB to 255, 255, 255 then ran a loop that decreased the values to 1 and then back up to 255. No flickering, works perfectly. Set RGB to 255, 255, 0, this time only changing the the red and green channels keeping blue at 0, and there was a lot of flickering.
I can't begin to describe how thankful I am that you guys are here! I finally feel like I'm going somewhere on this project again.
The DMXout2a spin file you posted isn't sending DMX packets though :-\ I tried comparing version 1.03 that I've been using and yours but all the changes are in assembly which I'm completely lost about. Does anyone see a glaring error that is a quick fix?
Can't we put a waitcnt between packet sends in the spin code?
There's a timer overflow problem where it tries to send out the bytes. The DMXout2 file I based it on from earlier in the thread has the same problem.
Since the code you have doesn't have this problem, you can apply my modifications to your file:
just before the jmp #packet line, add:
mov dmxdelaycnt,cnt add dmxdelaycnt,dmxdelay waitcnt dmxdelaycnt,#0then in the Initialised Data section:
and finally in the Uninitialised Data section:
Alternatively, if you upload the one you're working on I can add the changes. and repost it.
I'm using the DMXout.spin object from the Object Exchange. I've attached it to this post. It does not have any of your modifications.
Thanks again for all this help.
Post Edited (flo) : 7/3/2009 6:12:00 PM GMT
Why do you put:
instead of :
?
I was under the impression waitcnt adds #0 to the dmxdelaycnt as per here: http://forums.parallax.com/showthread.php?p=647408 :
Also, using either code set, the time between flashes is 53 seconds, which I read somewhere is the time it takes for the clock counter to loop around?
Does this imply that the dmxdelaycnt isn't properly being set to the current cnt each time?
Post Edited (flo) : 7/3/2009 6:59:39 PM GMT
Waitcnt target, delta
the cog waits until cnt=target, then adds delta to target for next time. In this case we set the value of dmxdelaycnt each time we use it, so it doesn't matter what the waitcnt sets it to.
OK, just had the AHA! moment.
The reason it fails when we add the delay is because the last time we called waitcnt we set the delay for the next time we use it. This is usually not a problem, but seeing as how we added a huge delay in between, it misses the count for next time.
In looking at what we'd need to change to correct that, I realised that we already have almost what we need. The first part of the packet is idling the line for a while before the break. All we need to do is extend the idle time (and in fact that's what we've kind of done in a round-about way). Amazing what a good night's sleep does for looking at a problem!
Throw out all the changes we made before. Go back to the file you posted yesterday.
Change the line after the 'packet' label from
mov txrep,#1to
mov txrep,dmxdelayand in the initialised constants section, add
and in the CON section of the file, where PacketSize is set, add
FPS = 30Now, you can adjust the transmission delay by setting FPS.
I've attached the modified copy of the file.
Let me know how it goes.
Unfortunately the light works but the problem isn't solved
What's even weirder is the original DMXout (the one I posted) did not flicker when all the channels were the same value and faded up and down. However, the file you posted with the FPS variable, flickers sporadically. I changed the FPS from 30 to 5 in steps of 5, and it flickered for all of them with no change in "flickerness."
Ok so, back to the drawing board, thinking out loud, here are the summary of our results:
- DMXout is the original file from object exchange
- DMXout2c is the file changed with an FPS variable to adjust the timing by changing the idle time
The conclusion is that only one way works perfectly. As a side note, the flickering for the last two tests was minimal compared to the DMXout tests that flickered.
My hunch is this timing idle wait is half right, something is missing. Thoughts?
Post Edited (flo) : 7/4/2009 1:46:10 AM GMT
This is what I have.· Again please bare with me.
OBJ
· DMX : "DMXout"
·
PUB Main
· DMX.start (1)
· DMX.Write(1, 255 )
· DMX.Write(2, 255 )
· DMX.Write(3, 255 )
· DMX.Write(4, 255 )
Post Edited (Kednerpo) : 7/4/2009 2:28:17 AM GMT
I've included the demo program I've been running and the DMXout I've had the best luck with. The demo program fades channels 2,3, and 4 from 255 to 1 and back up to 255 endlessly.
A thing to take into account: my light requires channel 1 to define what mode to run in (chase, color change, rgb, strobe, etc.) That's why my channel 1 is statically set to 214 (the value for RGB). Check your light documentation to see if it needs it or not.
Oh, and in DMXout.spin, I've set the packet size to 5 (4 channels; it's default value is 513 for 512 channels) because my light is quirky like that. The smaller the packet size, the faster the refresh.
Thank you.· I assumed the clock timing was being handled in the Assembly code somewhere or at least by the object itself.
·
Could the problem be not holding the break time for 88microsecs?
http://www.sabretechnology.co.uk/dmxwork.htm
In the current code, I don't see anything changing the baudrate. How is the hold happening?
For those learning assembly, mov txdata, #1 assigns txdata to the number 1, the next line assigns 100 to txrep, and the third line calls tx (which you can find at the bottom of DMXout.spin). Tx, waits 4 microseconds (250k Baud), sends txdata (number 1 in the first case), and repeats this loop txrep times (100 in the first case). So, by changing txrep, you can control the length of break, MAB, and idle.
Here are my changes that brought the best results:
packet mov txdata,#1 'idle mov txrep,#100 '(default 1) call #tx mov txdata,#0 'break mov txrep,#150 '(default 30) call #tx mov txdata,#1 'mark after break mov txrep,#30 '(default 2) call #txI say best because the lights works without flickering for up to ~40 seconds, flickers for a while, then does another <40 seconds of perfect operation. It's as if I'm going in and out of phase with the receiver in the Chauvet light.
I can play around with those three values for years before finding the right combination. Any ideas how I could determine these through a set of tests?
I'm soooooooooo close
I'm curious at the huge break after the MAB. Should that be there? How do I remove it? Sorry that's start code.
The red text in the following pictures is the calculated timing based on the tx function in the assembly code (txreps * txticks or [noparse][[/noparse]#of loops] * [noparse][[/noparse]wait time]):
I'm a packet of size 5:
Post Edited (flo) : 7/6/2009 3:39:01 AM GMT
Hardware is on the way so while the code does compile I haven't yet run it on anything.
[noparse][[/noparse]Edit] I've attached my DMX receiver code for anyone who has hardware setup and would like to try it.
Post Edited (JonnyMac) : 7/8/2009 4:20:29 PM GMT