5
\$\begingroup\$

I'm not sure if I'm reading this wrong or something, but this is a trace of the DMX packet that's coming from my USB-RS485 module then being converter to UART logic levels for my microcontroller.

DMX packet

Differential packet

There are a few things I don't think are right...

  • What I assume is the 'break' is only the width of one frame, but by definition in the standard is is more likely to be twice this size or greater.

  • The 'Mark after break' is huuuuge. From the scope you can see it's about 116 us wide, when it should really only be 8

  • Lastly, there doesn't seem to be a 'start frame'. When set channel 1 to any value, it goes into the first frame after what I've assumed is the extra long 'Mark after break'

Am I missing something here or misinterpreting the DMX protocol? Right now I'm using Freestyler to drive the RS485 device as an ENTTEC OpenDMX transmitter. Anyone have any ideas? is it a software or set up thing? I also tested a tool called KMTronic DMX device tester, and it's given me the same sort of output.

I've just noticed after looking at the differential RS485 lines (see above picture): It looks like that low at the beginning actually is a frame (maybe the start frame?). I can see the line go from an unknown state to driving high for 4us(Mark-time-between-packets?), drive low for the frame of 44us, then drive high for 8us (typically a stop bit time). After that the line goes to an unknown state again. Really strange and confusing. If that's the case though, then I have nothing that even resembles a 'break'.

Also for those unfamiliar with DMX packet structure: http://www.dmx512-online.com/gifs/dmxpack.gif

\$\endgroup\$
  • 1
    \$\begingroup\$ What does it look like if you "zoom out" a bit? Could it be you're looking at the inverted data line of the 485 and seeing the data upside-down? \$\endgroup\$ – John U Sep 25 '14 at 13:12
  • 3
    \$\begingroup\$ Your fundamental problem is likely that in USB-serial and DMX you have two very different things, each of which can be "sort of" interoperable with an ordinary asynchronous device that is willing to meet its peculiarities, but probably not with each other. DMX has particular requirements about timing within a packet, while USB-serial conversion assumes that timing between characters is arbitrary and delay may safely be inserted whenever the USB bus has failed to keep the buffer full, or, removed when the USB has buffered data faster than it can be sent. \$\endgroup\$ – Chris Stratton Sep 25 '14 at 15:57
  • 1
    \$\begingroup\$ Likely you will need a custom implementation where you can fill a buffer for an entire 512-byte DMX packet over the USB, then clock it out in strict accordance with the DMX protocol, independent of the USB. \$\endgroup\$ – Chris Stratton Sep 25 '14 at 15:58
  • \$\begingroup\$ John, It is in it's unknown state if I zoom out (defaults TTL high in this state). Chris, I understand what you're saying, I'm aware the timings might be a little off here. I still don't understand however why I'm getting a strange structure to the packets. \$\endgroup\$ – Sensors Sep 25 '14 at 16:13
  • \$\begingroup\$ Here's a look at the differential RS485 packet imgur.com/5ghGluC. (there's some data in channel 2) \$\endgroup\$ – Sensors Sep 25 '14 at 16:13
1
\$\begingroup\$

Do you have the right bus termination? A lot of cheaper RS485 adapters will 'release' the bus when nothing is transmitted for a while; thus, you 'mark after break' may actually be RS485 transmitter shutting off because of lack of transmissions. Make sure you pull the bus to the right values.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.