Group Actions
Engagement
  • Author Author: beacon_dave
  • Date Created: Date Created
  • Views 6341 views
  • Likes 7 likes
  • Comments 6 comments
Related
Recommended

Looking at the DMX 512 protocol with a Keysight EDUX1002A scope

beacon_dave

First outing with an entry-level Keysight Technologies Infiniivision  EDUX1002AEDUX1002A digital storage oscilloscope

Keysight EDUX1002AKeysight EDUX1002A

 

The particular task chosen was to look at the DMX 512 protocol generated from a Chauvet Xpress 512 DMX lighting controller.

https://www.chauvetdj.com/products/xpress-512/

 

For those unfamiliar with the DMX 512 protocol it is a serial protocol developed back in 1986 and commonly used in the entertainments lighting industry. It most commonly runs on top of the industry standard RS485 serial bus running at a data rate of 250kbps.

 

The first step was to take a look at a single DMX 512 packet on the scope. The packet starts with a 'break' of >88μs and I decided to use the 'pulse width' trigger mode of the scope to trigger on this pulse. Using the cursors I could measure the duration of the packet which is shown here as around 50.2ms giving a DMX 'universe' refresh rate of around 20Hz.

image

 

The 'break' is required to be 88μs or more, and on paper is commonly reported as being in the order of 100μs to 200μs. In this case we can see it is significantly greater at around 1ms.

image

In this case I could have increased the pulse width trigger time from 88μs up to around 1ms.

 

After the 'break' is the 'mark after break' which requires to be a minimum of 4μs in the original spec but 8us in the revised 1990 spec. In this case it is around 17.9ms which appears rather excessive. In some cases this time is increased to make up the minimum packet duration if only a few data frames are being transmitted, however not required here as the payload appears to be the max permitted 512 frames.

image

 

After the 'mark after break' comes the data payload. This is comprised of a start code followed by up to 512 channel data frames. In this case around 29.4ms.

image

 

After the channel data comes the 'mark after last channel' at around 1.9ms which then is followed by the 'break' of the next packet.

image

 

First observations by using the scope to look at the signal are that:

  • the start of packet 'break' is significantly longer than expected
  • the 'mark after break' is significantly longer than expected and which has a significant impact on the overall refresh rate
  • the controller is sending out all 512 channel data frames even though my controller software was only sending data for the first channel

 

Next step was to look at some of the signal components in more detail. First up we have the start of packet 'break' preceded by the 'mark after last channel'.

image

 

Then there is the 'mark after break'.

image

 

Then come the data frames. These are 44μs in duration comprising of one low start bit, 8 data bits, and 2 high stop bits. 11bits total each of 4μs duration.

 

The first is the 'start code'. The most common has a value of 0 which denotes that 'dimmer' data follows.

image

 

Then come the channel data frames of which there can be 1 to 512.

 

This is the channel 1 frame showing a data value of 8

image

 

and channel 1 again showing a value of 85.

image

First low pulse is the start bit, followed by bits 0-7 alternating, followed by 2 high stop bits which merge into the 'mark between frame' idle time.

(In this case bits 0, 2, 4 and 6 are set, 1 + 4 + 16 + 64 = 85)

 

Here are the first 4 channels showing data values of 2, 4, 16 and 64. The width of each bit is 4μs as expected.

image

 

In-between each data frame is the 'mark between frame', shown here between the 'start code' and channel 1 as being around 12.7μs.

image

 

Again, the 'mark between frame', this time between channels 1 and 2.

image

This 'mark between frame' is optional however and the data frame stop bit can be followed immediately by the next data frame start bit.

 

After the last channel data frame is the 'mark after last channel' shown here as around 1.98ms. Once again this is optional and the last channel data frame stop bit can be followed immediately by the start of packet 'break'.

image

 

And that concludes the first outing with the  EDUX1002AEDUX1002A scope and a quick overview of the DMX 512 protocol

Parents Comment Children
  • in reply to mcb1

    In the 'old days' I seem to recall a lot more external protocol-specific trigger boxes being available on the market (and in electronics magazine project articles), whereas nowadays you have some of the functionality built into the basic scope and then more specific stuff is a licensed add-on option (for the more popular protocols).