I'm trying to write a piece of software which sends sACN, but crucially, with per-sACN-address priority - in the same way that the Net3 protocol seems to allow an sACN source (i.e. Paradigm systems) to take control / priority over specific addresses within a universe. (Is this only offered by the Net3 protocol?)
From what I can tell, the E1.31 sACN protocol as it is seems to provide this support, by being able to specify the Property Value Count, First Property Address, and length of the DMP layer.
Although, I fear I could be misreading the E1.31 standard.
Essentially, I'm writing code in Python 3, and am basing it off of this project: https://github.com/Hundemeier/sacn
Would anyone happen to have a breakdown of the Net3 protocol, in a similar format to this:
https://tsp.esta.org/tsp/documents/docs/E1-31-2016.pdf (this document is actually superseded by the 2018 revision)
The application of this code is to control parts of a light's pan/tilt through another system, but still allowing the LD to control colour, zoom etc.
Any thoughts are appreciated!
Net3 is a collection of different protocols, some standards and some proprietary. To do per-address priority you don't need to know Net3. Wireshark will tell you everything there is to know when you look at sACN output of e.g. ETCnomad. The priority message is sent once a second, looks like a regular sACN message but has a start code of DD. It is actually quite easy to find.
Thanks for this Ueli,
So one thing that I missed from the E1.31 standard - to specify priority per channel, this is done in a separate packet, with a start code of 0xDD (221), with the data portion of the addresses being set from packets with a start code of 0?
I'll have to re-read the E1.31, but it didn't seem to touch on this there... is the Start code of 221 0xDD a standard thing?
What role does the PDU layer Priority flag have? If not for specifying whole universe level control priority?
For example, when using a start code of 0xDD, why is the PDU priority equal to 0?
The Priority flag defines the priority for the whole universe, the DD packet can override it. The DD packet is not in the standard, it's an extension by ETC. But it's compatible to the standard as it allows different start codes. Recipients that don't understand a certain start code should ignore the data.
In the pdf you linked above there is actually a link to a list of start codes used and ETC registered DDh for those priorities.
0xDD packet timing is defined as "The source follows the sACN rules for non-changing data for 0xDD packets as well, so a change of priorities for a universe is sent for 3 extra frames and then sent once every 800-1000ms."
It's also worth nothing "A priority value of 0 indicates that the DMX level from the source is to be ignored by the sink."
The source code (and compiled application) to sACNView might be of use to you: https://github.com/docsteer/sacnview / https://sacnview.org/
Thanks for this. I've been using sACNView quite closely to unpick what's going on. Presumably the priority = 0 thing would be effectively releasing control of that address from the source(?) - particularly useful when having multiple sources sharing a universe - an application being houselight control with paradigm and/or lighting desk.
One way to look at priority 0, is that the address is unpatched....