Bug 1483 - Decoder doesn't recognise short frames containing less that 512 slots
Summary: Decoder doesn't recognise short frames containing less that 512 slots
Status: RESOLVED DUPLICATE of bug 1442
Alias: None
Product: libsigrokdecode
Classification: Unclassified
Component: PD: dmx512 (show other bugs)
Version: 0.5.2
Hardware: x86 Windows
: Normal major
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-05 15:30 CET by Graham
Modified: 2020-01-10 18:36 CET (History)
1 user (show)



Attachments
Screenshot showing missed fram start detection. (12.80 KB, image/png)
2020-01-05 15:30 CET, Graham
Details
Correct detection of start of Packet (21.05 KB, image/png)
2020-01-05 15:33 CET, Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Graham 2020-01-05 15:30:15 CET
Created attachment 577 [details]
Screenshot showing missed fram start detection.

I have a device that sends "short" DMX frames, i.e., with less than 513 slots, when there is less tnan a full frame of data.

In this instance frames consiting of 60 slots, 1 start code slot and 59 channel data slots.

However, the decode fails to recognise the break followed by the MAB.

Data was captured using a fx2la (Hobby components) sampling at 16MHz

As you can see from the screenshot, The raw Data line clearly shows a sequence consisting of -

2 stop bits with a continuing high state - total 18.0625us (i.e. 2 stop periods + 10.0625us of marking)
A break - length 119.623us
A Mark-After-Break of length 15.25us

A quick look at the decoder source shows that it does not in fact look for a MAB until it has processed more than 512 channels (code counter name)

Note also that the docoder is not correctly aligning the decode slots - I wil lraise another bug for that
Comment 1 Graham 2020-01-05 15:33:00 CET
Created attachment 578 [details]
Correct detection of start of Packet

This screenshot shows the DMX detector correctly finding the start of Packet.
This is earlier in the capture than the other screenshot.

Note this shows other issues relating to skipping entire slots! - I will raise a separate bug for those.
Comment 2 Gerhard Sittig 2020-01-05 16:10:34 CET
Is this a duplicate of bug 1442 perhaps? Can you please re-check with a more 
recent version? The DMX512 decoder received an update just yesterday.
Comment 3 Gerhard Sittig 2020-01-05 18:50:52 CET
Almost forgot: Can you please provide example captures (.sr files) which 
contain less than 512 slots in their DMX packets? The decoder is supposed 
to handle this condition, but got implemented when no test data was available. 
Let's keep such a test case in the project to avoid regressions during 
future maintenance. Thank you!
Comment 4 Gerhard Sittig 2020-01-10 18:36:24 CET
Closing the report, assuming the new version fixes the issue (it did in 
a local test on other data before submission to mainline).  Feel free to 
re-open if the problem reproduces with the most recent decoder version, 
and make sure to provide capture data which demonstrates the issue.

*** This bug has been marked as a duplicate of bug 1442 ***