Bug 1442

Summary: Decoder has trouble decoding valid DMX-512A data
Product: libsigrokdecode Reporter: gabse
Component: PD: dmx512Assignee: Nobody <nobody>
Severity: major CC: Gerhard.Sittig, graham.g0uus, uwe
Priority: Normal    
Version: unreleased development snapshot   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: Screenshot of the decoder with with my annotations

Description gabse 2019-11-21 22:33:49 CET
Created attachment 560 [details]
Screenshot of the decoder with with my annotations

Hello, I was trying to decode DMX Data from a USB interface, but the decoder does not deliver any valid output. Because my DMX gear was working with the interface I started to deal with the DMX standard.
The decoder does recognize the Break, the MAB and the Start code, but it has trouble with the interframe. According to the standard, the interframe is a high state between 0 and 1 second after each stop bit pair. The decoder however marks the time between the next flank changes as interframe, and therefor all flowing data packages are detected wrong. The decoder also does not start over from channel 1 after a break signal, which is defined by the standard in order to not always have to transmit all 512 channels if only the first few are required.
In order to explain the bug i have added a screenshot of the decoder along with some annotations, on how it should look like according to the standard.

The exact timing is is documented here:



and also here:

I can also upload output dumps from different DMX transmitters if that helps to fix the bug.
Comment 1 Uwe Hermann 2019-11-21 23:12:10 CET
Yes, sample *.sr files which demonstrate the issue would be great. Ideally, as pull-request for the sigrok-dumps repo on GitHub, if possible:


The more *.sr files the better, we like to collect many of those in sigrok-dumps in order to be able to properly (regression-)test protocol decoders, among other things.
Comment 2 Gerhard Sittig 2019-11-24 07:49:13 CET
Had a look at the available literature and at the decoder implementation. 
There are some conditions where the support in the current version can get 
improved. It would be helpful to have captures available, to trigger these 
conditions and verify changes in the decoder's implementation.

@gabse: Can you share the recording that you made and which fails to decode 
properly, as you illustrated? From the image I can only guess that it's a 
very short inter frame mark but having data available helps gain certainty. 
There are also error annotations in start/stop bit positions where the 
ability to zoom in and out helps to better understand the issue.

There have also been (informal) reports about incorrect automatic detection 
of the signal's polarity. It would be great to have captures of these setups, 
too. (I understand it's the differential RS-485 transmission which results 
in users' desire to intercept either line.)

As Uwe pointed out, having captures available increases test coverage and 
allows to extend decoders to support currently unsupported conditions.
Comment 3 gabse 2019-11-24 15:47:22 CET
Hello, I have created a Pull request on the sigrok-dumps repo with the DMX dump i had trouble to decode. I will also add a few dumps of other DMX Interfaces if time allows. Maybe also with inverted Signal lines if that helps to further improve the decoder.

Pull request:
Comment 4 gabse 2019-12-26 16:20:16 CET

I finally had the time to take some dumps of different DMX Signals. I have created a Pull request in the sigrok-dumps Git repository.

I think it would be better to let the user decide if the input channel is inverted or not, or maybe also a differential pair, instead of the automated detection, which seems to be a partial cause for the bug.
Comment 5 Uwe Hermann 2020-01-05 00:30:05 CET
Fixed in dca19fbfdf0650dba693c0ac6213f6cdb748a8c3, thanks!

This is a new decoder which now stacks on top of UART (needs 250000 as baudrate).

If you could grab a few more .sr files that would be great. Ideally with "special" cases (not all-0 or 0-255), e.g. certain lighting setups or whatnot, and cases where certain protocol requirements are violated (the new PD now has features/options to warn about those).
Comment 6 Gerhard Sittig 2020-01-10 18:36:24 CET
*** Bug 1483 has been marked as a duplicate of this bug. ***
Comment 7 Gerhard Sittig 2020-01-10 18:37:30 CET
*** Bug 1484 has been marked as a duplicate of this bug. ***