MatHertel blogging about current activities. I am currently focusing on DMX related hardware and software on the Arduino platform.
Download the file from http://www.mathertel.de/Arduino/DMXSerial.aspx, unzip the file to your Sketches\libraries and try the example in libraries\DMXSerial2\examples\RDMSerialRecv.
The hardware requirements for that sample is a DMX line attached to the serial port, the data direction switch at pin 2 and some led to the ports 5, 6 and 9.
The schema of the DMX shield documented in http://www.mathertel.de/Arduino/DMXShield.aspx can be used as well.
Any feedback is welcome.
The first versions (up to version from 22.01.2013) of DMXSerial2 was not stable during several tests I did and often a response package did not reach the controller as expected.
After some testing with inserted delayMicroseconds() functions and time probes in several places I found that the implementation with the Arduino processor and the DMX Shield was sometimes too fast for the used controllers and the DMX line.
In several publications for example in http://www.soundlight.de/techtips/dmx512/dmx_rdm.htm you can find the timing requirements defined by the RDM standard and it seems that it is very important to follow them strictly.
The one timing condition that is indeed implemented by the RDM client is the time between the end of a RDM command that is sent by the controller and the start of the RDM response that is sent by the client.
Because the answer to a command is created asynchronously in the tick() function this time was varying and was often shorter than the expected minimal 176 µsec .
The version from 01.03.2013 and later now saves the time when the last byte of a command was sent into a global variable and delays the start of the answer when appropriate. After implementing this delay mechanism the RDM communication was much more stable then before.
And there is the RDM-BREAK that is longer than the DMX-BREAK: min. 176 µsec instead of 88 µsec.
I published the updated Arduino project today. It’s still work in progress and a library format will be available soon.
I just published an new Arduino project on my web site that implements an DMX RDM Device using the DMXShield.
From the beginning the DMXSerial library was designed to send and receive DMX data packets. Now it is extended to support RDM packets as well. I had to overcome several pitfalls and stumbling blocks while extending the DMXSerial implementation and I will keep the current version because it needs only a very small amount of program data. The RDM extended version will be DMXSerial2.
What you can find in the attached zip file right now is an ARDUINO project including all the files you need to compile. Because it is still in WIP (work in progress) I did not extract the DMXSerial2 files into a library format yet.
The last weeks I spent some time in extending the DMXSerial library for Arduino to support the DMX - RDM protocol by using the DMX Shield for Arduino.
A prototype version (proof of concept state) is already working. So now I know that the layout of the shield is RDM compatible.
But there is still some work to do for the library. I’ll try to publish a new version of the DMX library in some weeks.
If you are interested in co-working please let me know.
Some new DMXShields arrived, tested and running fine.
I already updated the article www.mathertel.de/Arduino/DMXShield.aspx and updated the eagle files in the zip file too even if the text is still related to an older version.
If you have interest in buying one of the PCBs – just let me know.
The schema and the PCB eagle files are available in the download from the article.
Thank to Jonathan L for this brilliant work on fixing some timing conditions with the sending side of the DMXSerial library.
From his comment:
I'm sure the existing timings (81us break) are pretty much fine with almost all DMX inputs, even though the spec says that the transmitted break time needs to be >= 92 us with MAB >= 12 us. Nonetheless I was motivated to fix it to be as close to 100 us/12us as I could, as this is what is transmitted by most of the commercial DMX units I've seen.
The real issue would be if you ran this on a faster processor, in which case the timings would break when the interrupt service routine became faster than the byte time. I was running this on 16 MHz Atmega 328. Most of the ISR is spent doing the long division inside DMXSerialBaud(): I replaced it with a compile-time calculation of the prescaler value, and this results in trashing the last data byte and the break. You can see the results in attached timing23.png.
Happily all is fixed by the changes, although the code is a bit more complex.
I studied the changes to the routines and I understand h did everything. It's all well commented and I like his programming style too. I loaded it into a project I have done some months ago and it works fine.
I personally haven't used much the sending part of the library. The last projects were lighting systems that are controlled by DMX used the receiving part only and I found it reliable but he fixed a buffer bug in this too.
After 2 weeks of waiting the first shipment of the PCB board finally arrived.
I can not wait to soldering the parts together.
My first impression is that the arrangement of the components fits well. If I find out that the circuit works as intended, I'll publish the Eagle files on my website.
The aim of this project is to build a small PCB board for RGB LED installations and to use the DMX protocol for controlling.
I build this board because I want to have a permanent and robust solution for light installations and I like to release my Arduino board for other projects.
Also, when using a standard Arduino board there are many components built in that are not used at all. For a simple DMX solution the ATMEGA 168 that was used in older Arduino versions is powerful enough and still provides enough memory for complex programs. So all you can find on this board are the minimum components for a 3 channel DMX receiver and the components to drive LEDs with a voltage around 12 volts or higher.
Because I started with an Arduino board many characteristics of the Arduino design remain:
The additional parts compared to the Arduino board are the chips of the communication interface that is able to receive DMX signals including an isolation and 3 Mosfet chips for driving LEDs.
The board uses only standard through-hole soldering components allowing an easy building for hobbyists like me.
Here are some pictures of the Arduino assembly and from my first prototype.
There where several problems with the first version so I had to patch some wires and add some components on the back. Not good enough to be published.
