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.
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.
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.
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.
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.
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.
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'.
Then there is the 'mark after break'.
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.
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
and channel 1 again showing a value of 85.
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.
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.
Again, the 'mark between frame', this time between channels 1 and 2.
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'.
And that concludes the first outing with the EDUX1002AEDUX1002A scope and a quick overview of the DMX 512 protocol