DIYC official DMX Manufacturer ID

[LabRat]

Hello DIYC DMX Heads,

Just sending a "heads up" that I was inquiring about getting an official DMX Manufacturer Id assigned, so that we could move beyond DMX hacking,
and opt for properly extending the DMX protocol. (Specifically focussed on infield address programming). I've had some brief correspondence with
PLASA's Technical Standards Manager, and lo and behold we are now officially in the Manufacturer's Database, with an MFID of 0x586D. This id comes
into play if/when we opt to use StartCode 0x91, in place of start code 0x00 (standard Dimming data).


Manufacturers Database:
http://tsp.plasa.org/tsp/working_groups/CP/mfctrIDs.php

List of StartCodes
http://tsp.plasa.org/tsp/working_gro...rnateCodes.php


What does this mean?

• Short term - not much
• Medium term - a nifty way to modify the DMX firmware images, in order to accommodate in field programming of DMX Start Addresses
• Long term - we need to control the development of any protocol using this MFID, in order to make sure we don't inadvertently pollute our own control space.
  For this I'm proposing that for now a single person maintain the protocol structure (I'm volunteering), and keep a wiki page updated with those changes.
  Any proposed changes have to come to this forum for review by the community, and then I will update the WIKI. It's not that I'm trying to stop people developing,
  but that I want to make sure we don't have duplication of effort and/or protocol changes that somehow limit further development. (I've seen it happen before).
  We only get the 1 MFID... so we must use it wisely.

I will post my first proposal for the SerialNumber and Start Address support in the next posting.

[LabRat]

Proposal - Support for infield start address programming.

For this proposal each device in a customer's installation will be assigned a unique 16 bit address. This value
can be programmed during the re-flash of their firmware (it would be required to make use of this protocol),
or after the fact using a special "Program Serial Number command".

During normal operation a DMX packet contains a "Start Code" (aka "Channel zero data"). This code is/must be
0x00 for normal dimming operation. Any other value, and the DMX packet should be ignored. We aren't currently looking
at the value, but *should* be doing so. This is the key to the protocols operation.

Make use of the start code to create "program address", and "re-program serial number" messages. The PC (or hand-held programmer) is set to transmit these alternate StartCode messages. Note to do this "properly" we should be using SC 0x91 plus a 2-byte "manufacturer's ID (MFID)". (see first post in this thread)

The DMX stream then becomes
0x91 <MFID-HIGH> <MFID-LOW> <PAYLOAD>

(note MFID= 0x586D )

For ProgAddress (CMD=<0x01>)
0x91 <MFID-HIGH> <MFID-LOW> <0x01> <SERIAL-HI> <SERIAL-LOW> <DMXADDR-H> <DMXADDR-L> <CHECKSUM>

For ProgSerialNo (CMD=<0x02>)
0x91 <MFID-HIGH> <MFID-LOW> <0x02> <NEW_SERIAL-HI> <NEW_SERIAL-LOW> <CHECKSUM>
(typically used in a point-to-point communication - as it would cause *ALL* devices connected to the stream
to reprogram to the same Serial Number. Suitable warnings to prevent the user doing this inadvertently must be included.)

So use of the ProgAddress would allow for someone at the PC to remotely update the start address on any device in their network.
The firmware implementation, once the manufacturer's ID is known, is almost trivial. I've even included a checksum in their, to
reduce the chances of false detection.(Which would have to be pretty slim to begin with as in the worst case we would have to
transmit a minimum 4 byte pattern by accident (1 in 4 million chance), with the checksum we reduce that even further.

[budude]

neato!

[DynamoBen]

Sweet now I can use real codes for RDM and ACM stuff, thanks!

[LabRat]

I thought RDM has it's own StartCode already (that's what made RDM distinct.)

(Not overly familiar with RDM, so I'm open to being educated (though perhaps indepth discussions should be a second thread)

[DynamoBen]

I thought RDM has it's own StartCode already (that's what made RDM distinct.)

(Not overly familiar with RDM, so I'm open to being educated (though perhaps indepth discussions should be a second thread)

It does but you need a manufacturer ID.

[LabRat]

Ah I see... so perhaps we need another forum to track proposals for use of the DIYC MFID with respect to RDM.

If *only* we had someone knowledgeable to look after it.

Or is it *just* the use of the MFID inside existing RDM protocol??

[RavingLunatic]

Labrat,

1 - Are you looking at using VIXEN to do the reprogramming via channel info or are you developing a different user interface?

2 - If VIXEN, have you already developed or coordinated for new DMX plug-ins?

3 - If we are going for a "standard" reprogramming method, then I would like to see a check of the old serial number or address before writing a new serial number or address. This should make it almost impossible to accidently reprogram the wrong controller. However, it would still be possible to create duplicate serial number or addresses by accident if not careful. I removed the checksum since it would be pointless with this much double checking.

For ProgAddress (CMD=<0x01>)
0x91 <MFID-HIGH> <MFID-LOW> <0x01> <SERIAL-HI> <SERIAL-LOW> <OLD_DMXADDR-H> <OLD_DMXADDR-L> <NEW_DMXADDR-H> <NEW_DMXADDR-L>

For ProgSerialNo (CMD=<0x02>)
0x91 <MFID-HIGH> <MFID-LOW> <0x02> <OLD_SERIAL-HI> <OLD_SERIAL-LOW> <NEW_SERIAL-HI> <NEW_SERIAL-LOW>

I have already done some work in this direction for the Renard-DMX firmware (http://doityourselfchristmas.com/for...604#post205604) so it would be easy to modify it to fit the new "standard" if we can all agree what that is.


RL

[LabRat]

I have no specific plans (yet) on transmission of the signals. This could be via a plug-in, or via a stand-alone component (probably a plug-in).

As to the suggestion to include the "old serial number" , and the "old DMX address". I had considered these, and discounted them for the
following reasons.

1. For old/new DMX address, I had thought that as we don't display the DMX Address anywhere, it would be too common for people to forget the devices existing address, and thus the protocol to reprogram becomes useless.
2. This is repeated for the reprogramming of the SerialNumber - if I was foolish enough not to write down the serial number, I would have no ability to over-ride and reprogram a new one, short of opening it up and reflashing with the PICKIT. (blech)

I opted instead to use a checksum as a means to rule out false positives. I believe this will give a much better user experience, while still maintaining the stability desired.

Labrat,

1 - Are you looking at using VIXEN to do the reprogramming via channel info or are you developing a different user interface?

2 - If VIXEN, have you already developed or coordinated for new DMX plug-ins?

3 - If we are going for a "standard" reprogramming method, then I would like to see a check of the old serial number or address before writing a new serial number or address. This should make it almost impossible to accidently reprogram the wrong controller. However, it would still be possible to create duplicate serial number or addresses by accident if not careful. I removed the checksum since it would be pointless with this much double checking.

For ProgAddress (CMD=<0x01>)
0x91 <MFID-HIGH> <MFID-LOW> <0x01> <SERIAL-HI> <SERIAL-LOW> <OLD_DMXADDR-H> <OLD_DMXADDR-L> <NEW_DMXADDR-H> <NEW_DMXADDR-L>

For ProgSerialNo (CMD=<0x02>)
0x91 <MFID-HIGH> <MFID-LOW> <0x02> <OLD_SERIAL-HI> <OLD_SERIAL-LOW> <NEW_SERIAL-HI> <NEW_SERIAL-LOW>

I have already done some work in this direction for the Renard-DMX firmware (http://doityourselfchristmas.com/for...604#post205604) so it would be easy to modify it to fit the new "standard" if we can all agree what that is.


RL

[RavingLunatic]

As to the suggestion to include the "old serial number" , and the "old DMX address". I had considered these, and discounted them for the
following reasons.

1. For old/new DMX address, I had thought that as we don't display the DMX Address anywhere, it would be too common for people to forget the devices existing address, and thus the protocol to reprogram becomes useless.
2. This is repeated for the reprogramming of the SerialNumber - if I was foolish enough not to write down the serial number, I would have no ability to over-ride and reprogram a new one, short of opening it up and reflashing with the PICKIT. (blech)

I can't say I'm in agreement with the "people cannot remember things" rationale. Maybe others will chime in and it will become more of a consensus decision.

1- If the controllers are already in the display (reason for the remote reprogramming) then the users most likely know what DMX address a controller has and what they want to change it to.

2 - If you don't specifiy the old serial number then you will have to make sure no other controllers are active. But using the old serial number, this would allow all controllers to be active during the reprogramming. Don't think that it is a "much better user experience" if they have to unplug (or remove power from) all other controllers to change a serial number.


Lets see which direction the community wants to go before getting too fixated on a single method.


EDIT: Random thought:

For ResetDMX (CMD=<0x03>)
0x91 <MFID-HIGH> <MFID-LOW> <0x03> <NEW_SERIAL-HI> <NEW_SERIAL-LOW> <NEW_DMXADDR-H> <NEW_DMXADDR-L>

(Definitely a point-to-point method in-case you need to reset all values)