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: https://i.stack.imgur.com/NdvoB.png https://i.stack.imgur.com/JeM10.png and also here: http://www.soundlight.de/techtips/dmx512/dmx2000a.htm I can also upload output dumps from different DMX transmitters if that helps to fix the bug.
Yes, sample *.sr files which demonstrate the issue would be great. Ideally, as pull-request for the sigrok-dumps repo on GitHub, if possible: https://github.com/sigrokproject/sigrok-dumps 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.
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.
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: https://github.com/sigrokproject/sigrok-dumps/pull/11
Hello, 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.
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).
*** Bug 1483 has been marked as a duplicate of this bug. ***
*** Bug 1484 has been marked as a duplicate of this bug. ***