I'm currently working on a project using a MEGA 2560, a MAXIM rs485 driver and the DmxSimple library. The device outputs 12 channels of DMX with 6 of the levels being set by pots and the others being set with an encoder and a display.
I'm having issues with the stability of the DMX. I;m monitoring the output with an ENTTEC usb-dmx box and a MAX/MSP patch (I have also looked at the output with a professional DMX microscope which I managed to borrow to rule out this setup)
The output is completely stable when the levels are all (or mostly) at 100% or 0%, if all of the levels are set to any other values, the dmx signal jumps to different levels at random intervals.
When I look at the TTL signal output from the arduino pin on an oscilloscope, I can see the dmx pulses are "jumping" appearing to get longer for a moment, then going back to normal, repeating regularly at about 3 times a second. The oscilloscope is pretty old and I thought that it might just not be triggering correctly but looking at the output from a lighting desk, the pulses are solid and dont move at all.
Im pretty certain that this is the cause of the erratic behavior. It would make sense that the signal settles when all of the values are at full or 0 because every bit would be 1 or 0 within each byte causing less "interference" when the timing jumps.
My code if fairly complex and too large to post in its entirety. The call to DmxSimple is just
DmxSimple.write(channel, level)
which only happens when 'level' has changed for that channel.
Am I correct in thinking that DmxSimple uses TIMER2 to keep track of its timings and TIMER2 is also used by delay() and millis()? I dont use delay() at all but I do have quite a few calls to millis(). Could this disrupt the dmx output timings?
Any help with the issue would be much appreciated...
120 ohms, not 100, and in fact since there's a bias network the actual resistor
will be larger than that as its effectively in parallel with the biasing network.
timer2 is undedicated in the Uno/Mega boards, its timer0 that drives millis() etc.
The DMX controller and the last receiver in the chain both need termination, no
other intermediate nodes should have termination. If you don't use RDM then
the controller doesn't need termination since it'll never be receiving monitoring
packet responses. I think a bias network at the TX end is generally recommended
though.
Does the DmxSimple library use the Hardware serial UART? If not I can see there
are various potential issues with that. DMX512 may be particular on its timing - I
suspect a crystal rather than a ceramic resonator is required to set the timing.
The problem exists with or without the 485 chip connected. I've just been looking at the TTL output straight from the arduino pin so it's not an issue with the balanced line or termination etc...
Chrisnet: Are you using the dmxsimple library or the dmxserial? I can't really use the DmxSerial library in my project as you can't use standard Serial. commands at all (even with the mega and more than one hardware UART port), which I need to do in this project.
Does the DmxSimple library use the Hardware serial UART? If not I can see there
are various potential issues with that.
As gm1mfn said, it uses software UART. What specifically do you think could be the cause of the issues? Is there a way to solve them? I don't understand enough of how software serial works to be able to investigate myself. The main workings within the DmxSimple library seems to be a chunk of assembly code which I don't understand at all...
My alternative at the moment seems to be to use another ATMEL chip (ATTINY?) to generate the DMX with hardware UART for stability and just feed it "channel @ level" commands with software serial or another communication method.