Add per-address priority support (E1.31 START code 0xDD)#3
Open
taylorcjensen wants to merge 5 commits intodnadoba:masterfrom
Open
Add per-address priority support (E1.31 START code 0xDD)#3taylorcjensen wants to merge 5 commits intodnadoba:masterfrom
taylorcjensen wants to merge 5 commits intodnadoba:masterfrom
Conversation
- Add startCode property to DMPLayer (defaults to 0x00 for backwards compat) - Write startCode at byte 125 instead of relying on template's hardcoded 0x00 - Add sendPerAddressPriority() to Connection with independent sequence counter - Per E1.31 spec: each START code gets its own sequence number tracking Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- DMPLayer startCode defaults to 0x00 and can be set to 0xDD - write() places startCode at correct byte position (125) - DMX data bytes follow start code correctly - Priority sequence number is independent from DMX sequence Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
sACNView (Tom Steer) confuses DATA and PAP packets when they share the same sequence number. Starting the priority counter at 128 ensures they never collide during normal operation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add usage examples for sendPerAddressPriority and list the feature in the features section. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
sACNView (and likely other receivers) tracks one sequence counter per source, not per start code. Sending DATA at seq=0 then PAP at seq=128 caused every packet to be flagged as a sequence jump. ETC Eos uses a single monotonic sequence across both DATA (0x00) and per-address priority (0xDD) packets. Match that behavior by removing the separate priority sequence counter. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
startCodeproperty toDMPLayer(defaults to0x00for full backwards compatibility)startCodeat byte 125 instead of relying on the template's hardcoded0x00sendPerAddressPriority(_:priority:)toConnectionwith an independent sequence number counter, per E1.31 spec requirement that each START code maintains its own sequenceContext
E1.31 per-address priority (START code
0xDD) allows a source to specify priority per DMX address rather than per universe. This is useful when a source only cares about a subset of addresses -- addresses with priority 0 are ignored by receivers, preventing the source from unnecessarily overriding other sources on the same universe.The implementation is minimal and non-breaking: existing callers of
sendDMXDataare unaffected sinceDMPLayer.startCodedefaults to0x00.Test plan
DMPLayerdefaultsstartCodeto0x00DMPLayeracceptsstartCode: 0xDDfor priority packetswrite()places the start code at the correct byte position (125)sendPerAddressPriorityuses an independent sequence counter fromsendDMXData