DMX Receiving on the Propeller
Timothy D. Swieter
Posts: 1,613
I have wanted to code a DMX receiver on the Propeller ever since I heard of the Propeller. Last weekend I finally did it! It only took a couple hours. Most of the time was spent tracking down two bugs in the assembly code.
I used the FullDuplexSerial object as an example and I coded an assembly routine for receiving all 512 channels of DMX. Coding in assembly was not too bad, the Core Docs PDF really helped to shed light on what the different commands are and some basic usage. The DMXin Object runs in its own cog and receives the DMX as fast as anything can send it. I setup an “activity" LED to blink indicating that packets were arriving.
The attached picture shows the hardware details. I used a Demo Board and built the simple circuit for level converting from RS485/DMX to TTL levels. I used the TV display for debugging and in the picture you can see that it is displaying the hex value of 156 of the 512 channels. I used an Enttec Open DMX USB device and a handheld DMX device (in the picture) for generating the DMX packets.
There is a routine in the object for retrieving a channels data out of the buffer.
I need to clean up the code before posting. I may also make the object DMX/RDM (Remote Device Management) capable. The spec for RDM was just released and I may be getting it soon.
The Propeller is so powerful - I love it!! Receiving DMX requires minimal resources of the Propeller and it is free to do what ever I want to with the DMX. Using just the DMXin Object leaves 7 available cogs and don’t forget that the DMX object is capturing all 512 channels of data. What this means is that there is a lot of processing power left to keep the function of advanced DMX lights and devices on one piece of silicone, instead of multiple chips dedicated to specific functions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode
I used the FullDuplexSerial object as an example and I coded an assembly routine for receiving all 512 channels of DMX. Coding in assembly was not too bad, the Core Docs PDF really helped to shed light on what the different commands are and some basic usage. The DMXin Object runs in its own cog and receives the DMX as fast as anything can send it. I setup an “activity" LED to blink indicating that packets were arriving.
The attached picture shows the hardware details. I used a Demo Board and built the simple circuit for level converting from RS485/DMX to TTL levels. I used the TV display for debugging and in the picture you can see that it is displaying the hex value of 156 of the 512 channels. I used an Enttec Open DMX USB device and a handheld DMX device (in the picture) for generating the DMX packets.
There is a routine in the object for retrieving a channels data out of the buffer.
I need to clean up the code before posting. I may also make the object DMX/RDM (Remote Device Management) capable. The spec for RDM was just released and I may be getting it soon.
The Propeller is so powerful - I love it!! Receiving DMX requires minimal resources of the Propeller and it is free to do what ever I want to with the DMX. Using just the DMXin Object leaves 7 available cogs and don’t forget that the DMX object is capturing all 512 channels of data. What this means is that there is a lot of processing power left to keep the function of advanced DMX lights and devices on one piece of silicone, instead of multiple chips dedicated to specific functions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode
1280 x 960 - 556K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Post Edited (Chris Savage (Parallax)) : 6/23/2006 7:16:53 PM GMT
Other instruments get more complicated - especially moving head luminaries (see Martin Lighting website). There will be multiple channels assigned to pan/tilt motor control, color scrollers, lamp brightness, etc.
RDM or Remote Device Management was recently added to the DMX protocol by ESTA. Until RDM, DMX has a half-duplex Master-slave sort of deal. The lighting desk or DMX playback unit told all the fixtures what to do. The lighting desk simply sent 20 to 40 packets of data per second to the devices and they listened. (250K baud - variable update because of spacing within the packet) Now with RDM the lighting desk can set parameters or ask for feedback from a fixture. Where would one use this? Take lamp life for instance. As lamps get older their color temperature and effectiveness decreases. A fixture could be designed to track how many hours the lamp is on. A lighting desk with RDM or a hand held RDM device could be used to ask the fixture, "How long has your lamp been on?" With RDM we can now read this parameter of the fixtures memory.
There are many other possibilities for RDM. At LDI (major entertainment technology tradeshow - in oct/nov) I expect to see the first few devices implementing RDM - from there who knows what will evolve.
I have been toying around with Eagle Cad. I will see if I can create a simple schematic. Overall the circuit is really simple. Code is not too bad either.
The above Wikipedia described DMX pretty well (I guess I repeated a lot of what it says). I also used http://www.dmx512-online.com/packt.html because I did not have the DMX spec in front of me over the weekend. I used the waitpne or waitpeq for detection of the start of the packet, from there is was simply receiving bytes. I will review my code this weekend and post.
I have thought about creating a DMX Coprocessor or other similar devices that other could purchase for use in their products. I think this is a neat idea for an EFX product.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode
Chris I.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
A few things that popped into my mind as an advantage of DMX:
For a band's lighting setup, the limitations of MIDI are negligible. But I can imagine a large setup (imagine Paul McCartney, the Oscars, the Olympic opening ceremony, etc.) being hampered.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
·· I remember Passport well...Thanks for the information.· I will have to look at the specification in more detail.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
When talking about MIDI, there are different standards out there.· The first MIDI standard·was published in 1983.· I admit I have not had to use MIIDI much, but·MIDI exists·in various entertainment installations around the world.· I can see that it is good for small clubs and bands, but professional installations require DMX for lighting control.· There is MIDI,·MIDI Time Code (1986), MIDI Show Control (1991), and MIDI Machine Control (1992).· I recoemmend checking out John's book mentioned above - it is the authority on entertainment control systems.
The 512 channels of DMX is known as a universe in DMX·speak and for the examples mentioned by SSteve usually many universes are needed because of the sheer number of fixtures involved and channels required.· DMX also has some other exciting developments including distribution of the network over Ethernet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode
·
In the near future I will add expand the DMX Object to include support for RDM.· I will also include support to send a DMX packet.
·
Let me know your thoughts.· This was my first project with the Propeller and I love it.· I am thinking on making some PCBs for use in experimenting with DMX.· Let me know if you are interested - maybe I will get a handful made.· I was thinking it would have the Propeller, EEPROM, crystal, connection for USB2SER, headers for attaching a pigtail with an XLR connector, Level converter chip, a couple surface mount LEDs and maybe a 5V to 3.3V regulator.· I will probably make it using the QFP package.· Think of the design as a "DMX Stamp".· A little larger though than a stamp because I don't want to mess with the QFN package at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode
Looking over your project to try to understand a little about how it and the Propeller work, I think I may have noticed a minor flaw. It looks like you are assuming that the packet size is always 513 frames, which in not the case. Many DMX sources transmit shorter packets if they are not using all the frames. And I as I recall RDM uses very random packet sizes.
You can detect a short packet if a break comes down the line when you are expecting another frame. It will appear as a a 00 byte, but then no stop bits. Confirm that your stop bit is a 1. If not there is either a framing error or it's a short packet.
The possibilities the propeller chip presents are boggling. Dang, I wish I had more time to get into it!
-Eric
You are correct on many fronts:
-Yes the Propeller is amazing
-Yes the software posted does assume 513 frames
I got distracted with a couple other projects (mainly planning a wedding and work)·and so I have not returned to this project yet.· I will consider your advice when time allows, thank you for posting.· So far the DMX routine has worked with the four devices I have tested it with, but I had not considered making my·code more robust.· I did do some plugging and unplugging of the DMX cable·though and I never seem to lockup the Propeller and would still receive data after I plugged the unit back in.· I doudt that I was plugging/unplugging·at·packet boundaries.·Hmmmm.....
I also understand that RDM can have varying packet lengths, I have not seen a full spec yet (again with the other projects distraction and money to buy the spec).
Bugger - now I am going to have to find time this weekend to look back into my code to prove/disprove your theory. Stay tuned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode
The DMX looks a awful like it uses standard RS485 chips (i.e. SN75176). Couldn't you create a simple DMX slave with one of those, an MCU and a couple of Quadracs?
The SN75176 chip would handle the talking to the network, the MCU would determine what addresses to listen to and the Quadrac could be the "dimmer" (assuming, of course it has a high enough amp rating).
Or am I way off base (as usual).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College
DMX is RS485 phsycially and it has a defined protocol for messages (@ 250K BAUD). There are a couple of other minor differences as well. I have not used the SN75176, but many people use the SN75156B. In the picture above I used the MAX487E. A DMX device is usually the RS485 transceiver chip and a processor and other circuitry to do something (Lights, LEDs, fog machine, etc). The trick in the past though was having enough processing power (time) to do the other things while watching the DMX stream. Usually the processor operated off of interrupts for counting the channel data and only recorded the channels that the device needed (set by dip switch usually - the device address on the DMX network) With the Propeller I had no problems receiving and recording the entire DMX stream as fast as 30 to 40 frames/second. I also had 7 processors left to do anything else that I wanted.
I am excited about the power of the Propeller and my DMX project was just my first jump into doing assembly programming with the Propeller and seeing what I could do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark is all it takes for an idea to explode