View Full Version : DMX Transmission

02-13-2007, 08:27 AM
So I've spent the last week playing with the Propeller and the education kit (waiting for my starter kit to arrive, they where on back order).
I figured out the basics of spin, got a B420 lcd screen fired up and working, hacked a 9V 300mA adapter onto the board. Now it's time to attempt
an interface to DMX, and here is where I am running into a wall. My problem is, I don't have much experience with programming at such a low
level (granted, spin is pretty high level, but the hardware is not). I am working based off of this site: http://www.dmx512-online.com/packt.html
although I will probably buy the full DMX spec sooner or later.

I am trying to communicate with some DMX units I have, some older, some newer. However, I don't understand how to program for communication
at 250Khz, it seems that accurate timing at that speed is not possible. I'm sure I am just not understanding something here, and I have looked at the
DMXIn object from the forums, but I don't understand assembly (yet?) so that hasn't helped.

PS: I am using a SN75176.

Can anyone help with some advice?


02-13-2007, 08:33 AM
Look at this !!

There is a good DMX demo code made by Timothy D. Swieter



02-13-2007, 09:00 AM
Thanks, but that's the DMX object I already looked at, it is for recieving only and in assembly, so it doesn't help me much :(

Timothy D. Swieter
02-14-2007, 12:52 AM
rapscaLLion (http://forums.parallax.com/member.php?u=48523)·-
Glad to see you are jumping into using the Propeller for DMX.· One of the first things I thought of when I first read about the Propeller was its use in DMX because of the processing power!·
You are correct in that the software I wrote and is found in the forums is used to receive DMX.· Do study it though because it will help you understand the method for receiving the signals - sending them out is only slightly different.· To get the proper BAUD rate I believe you have to use assembly, there may be some fancy Spin tricks, but I doubted that when I created my code last year.·
The DMX object I created was based on the Serial Object included with the programming tool - I think maybe Chip wrote that file.· I studied the assembly code of the receive portion of the driver and wrote the other software around it to receive a DMX packet.· You too should study the serial object to understand how it sends and receives data.· Then start modifying the driver to send a DMX packet.·
At the moment I wouldn't spend the money on the DMX Spec.· The information found on the web site you referenced should be enough for now.· There is a couple other website that may help and recently Show Control, a Yahoo Group, had a good discussion on sending DMX compatible for older instruments.· I am sure there are several tricks out there for sending DMX to make it friendlier to those companies that interrupt the standard differently.·
Your application may have something like this
-1 COG for sending the continuous stream of DMX
-1 COG for general overhead
-1 (or more)·COG managing user input, loading shows from various media, etc
Keep trying.· If I get time I may look into doing the code for sending DMX because I have had several people request it.· I would not count on it happening soon, I just got married and in a month or two I am moving China (and taking my Propeller development tools too - I hope).

Timothy D. Swieter
tdswieter.com (http://www.tdswieter.com/)
One little spark is all it takes for an idea to explode

02-14-2007, 02:38 AM
I have been looking over your DMX input code and I think I might be starting to get the drift.
Wish me luck!

Teva McMillan
02-14-2007, 03:25 AM
I have already written and tested code to transmit DMX, it currently has an issue where is takes a couple mins to start working, likely waiting for the clock to roll around.
I send the code to a friend with a scope, and much much better understanding of the propeller, he will likely have it fixed today. I will post the code sometime tonight.

Can I ask what you are using the lighting for? and what input device you plan on using to control your lights?

My next little project will be to make small box with input/output and usb to program the box. My hope to to be able to do much more interesting effects then I can currently with the Elation DMX operator pro (http://www.elationlighting.com/presstitle.asp?RELEASEID=31) controller that I have. The Operator Pro has a side for controlling moving head, scanner type lights and also a completely separate par can side. My aim is to use the propeller to take input from the par can side and change outputs of the other side to do some more interesting lighting affects. Also I am going to add some switches etc to the propeller since the dmx contoller only has on button that has direct affect, (turns all par can on full), I want to have some buttons to mash on http://forums.parallax.com/images/smilies/tongue.gif

Anyhow, I hope that the code I have written will save you time, as it was a wee bit challenging to get the assembly working correctly.

02-14-2007, 04:50 AM

Thank you so much, I would really appreciate that code. I have been fiddling around myself, and made some generic assembly code but it still isn't working. I just don't have enough assembly experience. I am actually driving some LED color changing lights to light up a room, the propeller would generate the colors and output to the dmx via four channels that correspond to R, G, B and W. There really is not input per say, although certain settings can be changed via an lcd display and three buttons, which I have working already. Pretty boring stuff lol!

Anyways, I would greatly appreciate taking a look at that code, even if you can't solve the holding problem.


Eric R
02-14-2007, 05:16 AM
I would also be interested in your code. I will be driving a pair of Chauvet Intimidators and whatever else I can get my hands on·this year. Still looking for a couple DMX fog / haze units,·couple moving head spots and a couple Chauvet Scorpion lasers.

02-14-2007, 07:43 AM
Sorry to sound ignorent but what is DMX?

lets see what this does... KA BOOM (note to self do not cross red and black)

Paul Baker
02-14-2007, 07:45 AM
Its a communication protocol to control professional lighting and other scene devices.

Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Eric R
02-14-2007, 07:46 AM
boeboy said...
Sorry to sound ignorent but what is DMX?

It is a type of communication used to control lighting (like what is used for concerts)

02-14-2007, 07:58 AM

lets see what this does... KA BOOM (note to self do not cross red and black)

02-14-2007, 01:43 PM
Originally, electric stage lights where controlled via large "dimming" stations, and one huge lever would operate one light. This system was bulky, loud and could be very dangerous. A system was developed whereby the electric dimmers could be hidden away in a seperate room, and operated via remote control. Originally this was done via motors that would operate the large levers, until technology advanced far enough to have electronic dimmer control. From there a few protocols where developed to interface the dimmers to the "control desk". Today the most common protocol is DMX. Many consumer level products will use MIDI, but DMX is the professional standard, and is now used to control everything from simple dimmers to strobes, fog machines and intelligent lights. Because it has minimal error checking it is not safe for use in operating any moving machinery, setpieces, etc that could cause damage or injury. It is based on serial RS485 standards, too facilitate long cable runs. As for the standard itself, it is very simple, consisting of a "start" sequence followed by a string of 8-bit values (0 - 255). A dimmer pack would take each value and assign it in order to the appropriate dimmer, an intelligent light might translate that into motion, etc.

Highly useful for all kinds of control, as it is standardized (at least theoretically) and readily available and supported.

Teva McMillan
02-14-2007, 02:06 PM
Well, my friend did not have time today.

I am posting it anyhow. I may have found the issue, but my test board need to be re assembled which I don't have time for.

Try commenting out the section I mention to see if the delay goes away.

I am really sorry about the delay, it takes a very long time due to I think needing to go through the entire 32bit counter. :(

About maybe 2 mins.

Once it starts working it should work with almost anything, the output should look perfect due to how the counter is used.

Currently I have my hands on: 6 martin scx scanners, 2 roboscan 812's 3 american DJ accu rollers, 1 elation 4pack dimmer, and a martin atomic strobe. http://forums.parallax.com/images/smilies/smhair.gif The strobe is insane, it uses more power then everything else.

I have not got into lasers yet, tell me what you think of the Chauvet Scorpions when you get them maybe?


02-15-2007, 02:03 AM

Thanks for the code, for some reason I could not get it working. I have it wired up properly, and get it started succesfully,
however no matter how long I wait it doesn't connect with the lights. I put a led across A and B and it indeed took about 30 seconds
to light up, but no change in the lights.

Any ideas?

02-15-2007, 04:57 AM
Ok scratch that, I got it working with some old scanners I had lying around. I'm not sure how I got it working, but I did set the packetsize to 64, not sure if that has anything to do with it. (I'll varify that later).
There was indeed a pause before it started to work, but only about 20 seconds. I placed an led across the A/B as an indicator, it work's great.
The other lights I am using still don't work tho... I opened them up and looked inside, the use a JPK (http://www.jpk.co.nz/) 8 channel reciever.
I know they work, as they run fine off the various DMX controllers I have, but they simply won't communicate with your code :(
Out of curiosity, what lengths did you use for MAB, MBF, etc?



02-15-2007, 05:42 AM
Ok, just to add another dimension of oddity, I have just realized that the LED light is indeed picking up the DMX signal.
The red DMX-RX indicator light comes on, but ONLY when all the DMX levels are at zero. Any other level and the DMX
reciever light goes out. If I set the levels with a dmx controller, then switch the cable over to the propeller board, the
lights will zero when DMX is at zero, but any other level the light fails to recieve. What could be going wrong here?
The other lights I have recieve no problem!

02-15-2007, 06:11 AM
Alright, to bring this saga to a close, I have finally figured out the problem. I didn't realize that the code took the value from the DMXData[0]
during the start bit. This should not have been a problem, however the LED light (or more specifically the JPK reciever) only accepted input with
a start bit of zero. I'm not sure that this conforms to DMX standards, as I thought the start bit was unspecified, but regardless I have fixed the
problem by ensuring the start bit is always at zero.

Thanks so much for the code Teva, it works beautifully now. The only issue is the pause before output, which for me varies between 10 and 50
seconds for some reason. The code you said to comment had no visible effect, the hold was still there.



Paul Baker
02-15-2007, 06:28 AM
The line which is causing the problem is the waitcnt instruction in the routine tx. CNT is a read only register but waitcnt is trying to add txticks to it, changing this to waitcnt txcnt, txticks (with the initial cnt target code left in) should get you closer to the correct solution (I say closer, because I don't know if thats the only problem with the code). Or just comment it out if you think no waiting is nessesary.

Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

02-15-2007, 06:46 AM
Thanks Paul, you where absolutely right. That one simple line has fixed it, and the whole DMX function works perfectly!

You guys are all awesome!

Eric R
02-15-2007, 07:17 AM
rapscaLLion said...
Thanks Paul, you where absolutely right. That one simple line has fixed it, and the whole DMX function works perfectly!

You guys are all awesome!

Interested in posting the working code?
I have not had a chance to sit down and work with it yet. It sure would be a time saver for all interested.

02-15-2007, 07:53 AM
The working code is attached. Only one line is changed from Teva's original posted code.

Include this as an object, use the start command to initialize and then use the write command to set the channel values.
Easy as pie.

Eric R
02-15-2007, 10:50 AM
Teva McMillan said...
Currently I have my hands on: 6 martin scx scanners, 2 roboscan 812's 3 american DJ accu rollers, 1 elation 4pack dimmer, and a martin atomic strobe. http://forums.parallax.com/images/smilies/smhair.gif The strobe is insane, it uses more power then everything else.

I have not got into lasers yet, tell me what you think of the Chauvet Scorpions when you get them maybe?


It would be nice to have equipment like yours but I am going as low budget as possible. These will sit outside as part of this years Christmas display. I did pickup a Chauvet Aurora a few weeks back but on DMX I was not happy with its capabilities. It is now stripped getting a BS2 and a few HB-25s. I will post pictures on that when it is done. This will give me the control over the fixture that I was looking for. Should have used a Propeller but just haven't had the time to learn. Hope I will soon.

I will let you know how the Scorpion works out. I have·three 532nm lasers and some mirrors here but didn't want the liability in the event of a home-brew failure.

That atomic strobe would be awesome. I am using 16 walmart strobes this year with a modified trigger. I used 8 last year.

Thanks for the code

Link to last years Christmas display http://www.youtube.com/watch?v=z5VT3buv4TQ

Timothy D. Swieter
02-15-2007, 10:02 PM
The DMX start code, the first byte, should be zero.· The DMX standard states that it should be zero.· In the early days of DMX, some manufactures just igonored the start code and listen to everything no matter the start code.· Last year the DMX standard was updated for Remote Device Managament (RDM).· RDM allows the user to use DMX to set instrument parameters such as the DMX address or read parameters like lamp life hours.· In order to use RDM, the start code is different based on the manfucaturer.· So, for transmitting channel data please do ensure the start byte is zero.

I am glad you got your code working!!!!· It is so exciting.

Timothy D. Swieter
tdswieter.com (http://www.tdswieter.com/)
One little spark is all it takes for an idea to explode

Teva McMillan
02-16-2007, 08:53 AM
That is quite the show! How many dimmer packs are you using? I like Chauvet Aurora, pretty cool for how cheap it is, I am interested in how it turns out, might get and modify one myself. It uses DC motors? Most gear seems to all uses steppers..
Well all 16 together might be close to the Atomics power. The great thing about it is the control, you can control intensity very finely.

Can I post your Input code into the Object Exchange?
I already finished cleaning up some of the documentation.
I just want to post them together.

I will eventually do a complete rewrite with code that can do multi channels and input/output in the same cog and have various timing features to line up output so that delays can be minimized. For now though its works pretty well!

Anyone reading this thread,
Please test this code if you are interested and report any non working hardware, I would really like to find any bugs while the code is still fairly simple!
When trying the code, and a certain device does not work, try adjusting the MAB and other timings, I have it set fairly tight some devices could require looser timings, I would love to know what devices I need this.

02-16-2007, 10:45 AM

I would hardcode the startcode as being 0, to avoid people like me making that mistake :)
Otherwise the code works like a charm! I have had no problems with it since I got it working!

Timothy D. Swieter
02-16-2007, 08:16 PM
Feel free to post my code in the Object Exchange, I have not gotten around to it myself. Just give credit where it is due.

If I remember correctly, in my code I had all 512 values of DMX avaliable in an array. That was one of the cool parts of the Propeller, the speed of the code, and the cog.

Keep up the good work!

Timothy D. Swieter
tdswieter.com (http://www.tdswieter.com/)
One little spark is all it takes for an idea to explode

Eric R
02-17-2007, 10:32 AM
Teva McMillan said...
That is quite the show! How many dimmer packs are you using? I like Chauvet Aurora, pretty cool for how cheap it is, I am interested in how it turns out, might get and modify one myself. It uses DC motors? Most gear seems to all uses steppers..
Well all 16 together might be close to the Atomics power. The great thing about it is the control, you can control intensity very finely.


This display isn't a DMX setup. It is·from another manufacturer,·it·was 96 channels for the 2006 season.
I thought the Aurora would be steppers also but it turned out that they are DC gear motors.

Teva McMillan
03-08-2007, 10:23 AM
I have modified the transmit code to allow random packet sizes, I am hoping to have it tested (by transmitting from one cog to another) and posted next week sometime. Just thought I would update on progress.

01-02-2008, 08:41 AM
Any updates on this object. I will be doing some in-depth testing with a DMX tester in the coming weeks and want to have the most recent revision.

Teva McMillan
01-02-2008, 02:56 PM
I have some updated code I can post this week I hope.

btw what project are you using it for?

01-02-2008, 10:37 PM
Making a USB to DMX dongle (multi-universe).

07-02-2009, 11:32 AM
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?

07-02-2009, 12:39 PM
Ooops, got it to work...kinda.

(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...

07-02-2009, 12:43 PM
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

Timothy D. Swieter
07-02-2009, 01:43 PM
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 (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com (http://www.tdswieter.com)

07-03-2009, 04:16 AM
There is some discussion here about Chauvet not following the DMX standard:


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?

07-03-2009, 04:31 AM
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 :-\

07-03-2009, 05:19 AM
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.

07-03-2009, 06:19 AM
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!

post edited - added test idea

Post Edited (Ziggy252) : 7/2/2009 11:25:01 PM GMT

07-03-2009, 09:48 AM
Thank you SO much for the quick reply.

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?

07-03-2009, 11:01 AM
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:

just before the jmp #packet line, add:

mov dmxdelaycnt,cnt
add dmxdelaycnt,dmxdelay
waitcnt dmxdelaycnt,#0

then in the Initialised Data section:

dmxdelay long 600000 'set this for inter-frame gap

and finally in the Uninitialised Data section:

dmxdelaycnt res 1

Alternatively, if you upload the one you're working on I can add the changes. and repost it.

07-03-2009, 12:40 PM
I attempted to do it myself and post it here but the light flashes once and then stops. The DMX packet light also only flashes once.

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

07-04-2009, 01:18 AM
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:

Why do you put:

waitcnt dmxdelaycnt, #0

instead of :

waitcnt dmxdelaycnt, dmxdelay


I was under the impression waitcnt adds #0 to the dmxdelaycnt as per here: http://forums.parallax.com/showthread.php?p=647408 :

Graham Stabler said...
1. load target variable with cnt
2. add delta to target variable
3. waitcnt target, delta

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

07-04-2009, 06:12 AM
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

mov txrep,#1


mov txrep,dmxdelay

and in the initialised constants section, add

dmxdelay long (250000 - (FPS * Packetsize * 11) )/ FPS

and in the CON section of the file, where PacketSize is set, add

FPS = 30

Now, you can adjust the transmission delay by setting FPS.
I've attached the modified copy of the file.
Let me know how it goes.

07-04-2009, 08:37 AM
Makes sense!

Unfortunately the light works but the problem isn't solved http://forums.parallax.com/images/smilies/shakehead.gif

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 = no flickering

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?

Post Edited (flo) : 7/4/2009 1:46:10 AM GMT

07-04-2009, 09:19 AM
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.·

This is what I have.· Again please bare with me.


· 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

07-04-2009, 09:36 AM
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.

07-04-2009, 10:01 AM
Its Alive, something is happening.· Lights.· Wow.· I have been staring at a dark box for a·few days now.

Thank you.· I assumed the clock timing was being handled in the Assembly code somewhere or at least by the object itself.

07-04-2009, 12:34 PM
Doing some research I have another idea for DMXout object (I apologize if I'm just being ignorant):

Could the problem be not holding the break time for 88microsecs?


How DMX512 works said...

-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?

07-04-2009, 03:08 PM
the break doesn't need to be exactly 88us, that's just a minimum. The instructions you posted above are for use with a micro with a built-in UART.

07-05-2009, 03:03 AM
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:

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 #tx

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?

I'm soooooooooo close http://forums.parallax.com/images/smilies/roll.gif

07-06-2009, 09:25 AM
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 [#of loops] * [wait time]):

I'm a packet of size 5:

Channel 1: 214
Channel 2: 255
Channel 3: 255
Channel 4: 255




Post Edited (flo) : 7/6/2009 3:39:01 AM GMT

07-08-2009, 12:50 PM
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.

[Edit] I've attached my DMX receiver code for anyone who has hardware setup and would like to try it. http://forums.parallax.com/images/smilies/smilewinkgrin.gif

Post Edited (JonnyMac) : 7/8/2009 4:20:29 PM GMT