DIYC official DMX Manufacturer ID
- Thread starter LabRat
- Start date
kingofkya
New member
Not sure if it is still relevant but a while back you guys mentioned the difficulty for giving each device a unique id.
Maybe something like below. as a requirement for future boards. Then everyone can read the sn off the chip directly, and later use that to program a dmx address.
"DS2502 consists of a factory-lasered registration number"
http://www.maximintegrated.com/datasheet/index.mvp/id/2924
Maybe something like below. as a requirement for future boards. Then everyone can read the sn off the chip directly, and later use that to program a dmx address.
"DS2502 consists of a factory-lasered registration number"
http://www.maximintegrated.com/datasheet/index.mvp/id/2924
Actually, this is the preferred method.
A valid DMX packet with dimming data will have a start code of <0>. So a PIC with Renard DMX code should only treat a packet with 0 as the start code as dimming data, strip off the 8 bits it needs and pass it on the rest. If the packet doesn't have a start code of <0>, then it should pass on the packet unchanged, or simply ignore it. Ignoring the packet does have a side effect of any downstream controllers not getting the packet, but may be the simplest to implement.
I am currently doing some research on building new fixtures and a usb->dmx device for use in amateur theatre. I love the idea of not having to have dips & displays on each device to reduce cost, complexity, and I hate displays glowing on stage. For this reason, this "standard" is very attractive. RDM would be nice but most of the consoles I use don't have RDM so it would be kind of pointless.
I think the "standard draft" written by timon looks brilliant and I would like to add my suggestion to this to address my needs and some issues raised in earlier posts.
1 - I think each device design should have a DEID as apposed to designers. The reason will become apparent in my next suggestion.
2 - I would like to see functionality to incrementally address devices. Below is my idea (building on timon's preamble) for implementing this:
<DIYC PREAMBLE> <0x__> <0x00> <DMX_ADDR-H> <DMX_ADDR-L> <DMX_OFFSET-H> <DMX_OFFSET-L> <CHECKSUM-H> <CHECKSUM-L>
SERIAL would be set to 0. Then by setting the DEID (device id), we can address all of one type of fixture starting at address DMX_ADDR and offset by DMX_OFFSET. This would require the receiving device to increment the DMX_ADDR and calculate a new checksum before passing it along. As a device's firmware knows if it supports this, it can ignore the command if it doesn't. Using a device ID allows us to have multiple fixture types on the same DMX universe and address each according to channel requirements and where we want them patched. Obviously this would mean devices need to be physically plugged in order - great for LEDs along a wall.
3 - I disagree with using the CUR_DMXADDR when re-addressing fixtures. We're already using the DEID and/or SERIAL and so this is pointless, as already stated somewhere above (cant find it now...). Below is my suggestion for addressing. This also allows for addressing all of a fixture type to a single address if required.
<DIYC PREAMBLE> <0x__> <0x00> <DMX_ADDR-H> <DMX_ADDR-L> <CHECKSUM-H> <CHECKSUM-L>
As you can see above, both the addressing commands I have suggested look almost identical and I would personally combine them, using the first command. Setting an offset of 0 allows for addressing to the specified address (wouldn't be ignored by devices that don't support incremental addressing). The following codes would allow for a specific device, set of devices, or everything to be addressed easily.
<DEID> <SERIAL>
All devices: <0x00> <0x00>
All of one type: <0x__> <0x00>
Specific device: <0x__> <0x__>
And on the argument for this vs RDM, I want both! A protocol like this doesn't affect RDM due to a different start code, is much simpler to implement, and as far as I can tell RDM doesn't allow for incrementally addressing fixtures in an easy manner. I think RDM is a great idea but I see no reason not to have both.
Those are my thoughts. I'd love to get some input on my ideas.
I think the "standard draft" written by timon looks brilliant and I would like to add my suggestion to this to address my needs and some issues raised in earlier posts.
1 - I think each device design should have a DEID as apposed to designers. The reason will become apparent in my next suggestion.
2 - I would like to see functionality to incrementally address devices. Below is my idea (building on timon's preamble) for implementing this:
<DIYC PREAMBLE> <0x__> <0x00> <DMX_ADDR-H> <DMX_ADDR-L> <DMX_OFFSET-H> <DMX_OFFSET-L> <CHECKSUM-H> <CHECKSUM-L>
SERIAL would be set to 0. Then by setting the DEID (device id), we can address all of one type of fixture starting at address DMX_ADDR and offset by DMX_OFFSET. This would require the receiving device to increment the DMX_ADDR and calculate a new checksum before passing it along. As a device's firmware knows if it supports this, it can ignore the command if it doesn't. Using a device ID allows us to have multiple fixture types on the same DMX universe and address each according to channel requirements and where we want them patched. Obviously this would mean devices need to be physically plugged in order - great for LEDs along a wall.
3 - I disagree with using the CUR_DMXADDR when re-addressing fixtures. We're already using the DEID and/or SERIAL and so this is pointless, as already stated somewhere above (cant find it now...). Below is my suggestion for addressing. This also allows for addressing all of a fixture type to a single address if required.
<DIYC PREAMBLE> <0x__> <0x00> <DMX_ADDR-H> <DMX_ADDR-L> <CHECKSUM-H> <CHECKSUM-L>
As you can see above, both the addressing commands I have suggested look almost identical and I would personally combine them, using the first command. Setting an offset of 0 allows for addressing to the specified address (wouldn't be ignored by devices that don't support incremental addressing). The following codes would allow for a specific device, set of devices, or everything to be addressed easily.
<DEID> <SERIAL>
All devices: <0x00> <0x00>
All of one type: <0x__> <0x00>
Specific device: <0x__> <0x__>
And on the argument for this vs RDM, I want both! A protocol like this doesn't affect RDM due to a different start code, is much simpler to implement, and as far as I can tell RDM doesn't allow for incrementally addressing fixtures in an easy manner. I think RDM is a great idea but I see no reason not to have both.
Those are my thoughts. I'd love to get some input on my ideas.
timon
New member
I was going over some RDM information and as far as I can tell so far the MFID is not used alone but always as part of the 6 byte unique device identifier, UID. That gives each MFID 4,294,967,296 devices.
I suggest that we divide that in half and have 2 bytes for a DIYC Member ID and 2 bytes for a Device ID which allows each member/developer 65,536 devices. The format would look like this, 0x586DMMMMDDDD. If a member ever needed more then they would get a second member ID.
If 4 hex digits for member is to many it could be 3 for 4096, i.e., 0x586DMMMDDDDD but I think it's highly unlikely that a member would need that many IDs.
Comments or suggestions?
I suggest that we divide that in half and have 2 bytes for a DIYC Member ID and 2 bytes for a Device ID which allows each member/developer 65,536 devices. The format would look like this, 0x586DMMMMDDDD. If a member ever needed more then they would get a second member ID.
If 4 hex digits for member is to many it could be 3 for 4096, i.e., 0x586DMMMDDDDD but I think it's highly unlikely that a member would need that many IDs.
Comments or suggestions?
dmcole
New member
Your DIYC member ID is displayed in the URL when you view your profile ... Rob's is 13435 ... mine is 710 ... jeez, I've been around here a long time ...
\dmc
Great, thanks.
What kind of checksum are we using here? If there's no decision yet, how about 8 bit Maxim-Dallas? You know, the one from GwtS
Also, I will throw in my suggestion.
<0x91> <MFID-HIGH> <MFID-LOW> <MEMID-H> <MEMID-L> <DEID-H> <DEID-L> <MSG-TYPE> <LENGTH[0-255]> <PAYLOAD> <CHECKSUM-8>
I don't think we should be dictating what the content of the payload is.
However, we could agree on few message types, like changing the address to make this more universal.
For example:
...<MSG-TYPE=ADDR-CHG> <LENGTH=4> <PASSWD-H> <PASSWD-L> <NEW-ADDR-H> <NEW-ADDR-L> <CHECKSUM-8>
Any configuration commands should require fixed password (we could use MFID,) to prevent accidental changes.
What kind of checksum are we using here? If there's no decision yet, how about 8 bit Maxim-Dallas? You know, the one from GwtS
Also, I will throw in my suggestion.
<0x91> <MFID-HIGH> <MFID-LOW> <MEMID-H> <MEMID-L> <DEID-H> <DEID-L> <MSG-TYPE> <LENGTH[0-255]> <PAYLOAD> <CHECKSUM-8>
I don't think we should be dictating what the content of the payload is.
However, we could agree on few message types, like changing the address to make this more universal.
For example:
...<MSG-TYPE=ADDR-CHG> <LENGTH=4> <PASSWD-H> <PASSWD-L> <NEW-ADDR-H> <NEW-ADDR-L> <CHECKSUM-8>
Any configuration commands should require fixed password (we could use MFID,) to prevent accidental changes.
timon
New member
FYI, I strongly suggest that the member ID be converted to 4 digit hex before it's used because if we don't we'll only get 9,999 IDs instead of 65536 IDs.
My ID is 7640 so in hex that's 0x1DD8.
DM your 710 so in hex that's 0x02C6
Rob you 13435 so in hex that's 0x35A7
All of that said I didn't realize that we had that many members, we're almost a quarter of the way to maxing out, so I'm just a tad worried about running out of numbers because of waste. Any other way is going to require someone to administer the numbers. Another option would be to make the member ID one hex digit longer which would give each member ID 4096 devices and a total of 1,048,576 member IDs, i.e., 0x586DMMMMMDDD.
I'll leave this up to the one who got us the MFID to figure out.
I'd suggest we find out what RDM uses for a checksum and use the same thing rather than reinvent the wheel. Why have multiple checksums.
Also, RDM assumes that both the sender and the receiver have UID and both of those IDs are sent but reversed on the reply. That's very common so I'd recommend that anything we do follow that same rule.
To make things easier to read UID = <MFID-HIGH> <MFID-LOW> <MEMID-H> <MEMID-L> <DEID-H> <DEID-L> and SUID is the senders UID and RUID is the receivers UID so in the above example.
<0x91> <RUID> <SUID> <MSG-TYPE> <LENGTH[0-255]> <PAYLOAD> <CHECKSUM-?>. During a reply sent from the receiver the form would be <0x91> <SUID> <RUID> <MSG-TYPE> <LENGTH[0-255]> <PAYLOAD> <CHECKSUM-?>.
Again following RDM RUID of 0xFFFFFFFFFFFF is a broadcast to all devices.
Not that it's a big deal but RDM starts in the following form. <0xCC> <Modifier> <SUID> <RUID> <Payload> <CHECKSUM-HIGH> <CHECKSUM-LOW>. I don't know that the modifier is used for.
My ID is 7640 so in hex that's 0x1DD8.
DM your 710 so in hex that's 0x02C6
Rob you 13435 so in hex that's 0x35A7
All of that said I didn't realize that we had that many members, we're almost a quarter of the way to maxing out, so I'm just a tad worried about running out of numbers because of waste. Any other way is going to require someone to administer the numbers. Another option would be to make the member ID one hex digit longer which would give each member ID 4096 devices and a total of 1,048,576 member IDs, i.e., 0x586DMMMMMDDD.
I'll leave this up to the one who got us the MFID to figure out.
I'd suggest we find out what RDM uses for a checksum and use the same thing rather than reinvent the wheel. Why have multiple checksums.
Also, RDM assumes that both the sender and the receiver have UID and both of those IDs are sent but reversed on the reply. That's very common so I'd recommend that anything we do follow that same rule.
To make things easier to read UID = <MFID-HIGH> <MFID-LOW> <MEMID-H> <MEMID-L> <DEID-H> <DEID-L> and SUID is the senders UID and RUID is the receivers UID so in the above example.
<0x91> <RUID> <SUID> <MSG-TYPE> <LENGTH[0-255]> <PAYLOAD> <CHECKSUM-?>. During a reply sent from the receiver the form would be <0x91> <SUID> <RUID> <MSG-TYPE> <LENGTH[0-255]> <PAYLOAD> <CHECKSUM-?>.
Again following RDM RUID of 0xFFFFFFFFFFFF is a broadcast to all devices.
Not that it's a big deal but RDM starts in the following form. <0xCC> <Modifier> <SUID> <RUID> <Payload> <CHECKSUM-HIGH> <CHECKSUM-LOW>. I don't know that the modifier is used for.
Last edited:
I am with you on the member ID assignment, I think it should be managed, 99.99% of users will never make anything DMX related.
When it comes to RDM, I don't know. Do we really need broadcast, bi-directional communication, 16 bit checksum?
I believe what we are trying to do here should be as simple as possible, and if anything fancy is required, use RDM instead.
When it comes to RDM, I don't know. Do we really need broadcast, bi-directional communication, 16 bit checksum?
I believe what we are trying to do here should be as simple as possible, and if anything fancy is required, use RDM instead.
michaelc
Active member
I just found this thread. One feature that I'm interested in handling is the ability to have two devices on a universe with the exact same DMX addresses.
Example of use: I have mirror displays on two sides of the house.
They would have unique device id's but can they both have the same start/end addresses using this 'standard' you are creating?
Example of use: I have mirror displays on two sides of the house.
They would have unique device id's but can they both have the same start/end addresses using this 'standard' you are creating?