DIYC official DMX Manufacturer ID

LabRat

LabRat

Active member
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_groups/CP/DMXAlternateCodes.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.
 
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.
 
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)
 
LabRat said:
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)
Click to expand...

It does but you need a manufacturer ID.
 
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. :blink:

Or is it *just* the use of the MFID inside existing RDM protocol??
 
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/fo...et-dmx-address-from-vixen&p=205604#post205604) so it would be easy to modify it to fit the new "standard" if we can all agree what that is.


RL
 
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.



RavingLunatic said:
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/fo...et-dmx-address-from-vixen&p=205604#post205604) so it would be easy to modify it to fit the new "standard" if we can all agree what that is.


RL
Click to expand...
 
LabRat said:
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)
Click to expand...

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)
 
Last edited:
Some more thoughts on this. My "can't remember" proposal is based on the model that I take down all my equipment, (some of which looks very similar) and store it in a heap for 10 months, and then try to remember which unit is which. From my own experience, and perhaps this is simply OMS speaking (old man syndrome), I quickly lose track of which is which when they are stored in a box together.

*for arguments sake I'm saying PIC and PIC Programmer, but this could apply to other micro's as well*

I can only think of two scenarios when you would change the serial number on a device.
  1. First time the device is being programmed.
  2. You have forgotten the serial number and must program a new one, so that you can program a DMX address.

I think it's safe to argue that in the first case you would already have the device connected to a pickit (or similar), and thus the device is unlikely to be connected to the rest of the DMX chain. It could also be argued that you could use the pickit to write the serial number to begin with as well. But if you have the option to write the number afterwards, I'm sure that it would be used. The point here being that I think it unlikely that the device would still be connected to the DMX universe at this point in time, thus the use of the NEW serial number message, minus the old serial number would be safe.

In the second case, if don't know the existing serial number, the "program NEW serial number" command would be useless if it required the presence of the old (unknown) serial number to do so. So you would be forced to pull out the PIC programmer again. This is my bigger concern.

I can't think of any other scenario where we would re-program the serial number.

As to the old DMX address as part of the new DMX address message. If the serial number is used to uniquely identify the device, I don't see what role/function there is in sending the old address, other than to reduce false positives. The checksum will prevent this. As such, I think it only likely to get in the way for those times when the DMX address is not known. In *those* scenarios, the operator would be stuck, doing a binary search of the Universe to figure out the old address, or forced to pulling out the PIC programmer and mucking with the EEPROM directly.


In general I'm much better with a whiteboard, for this type of discussion. If anything in here reads of sarcasm, snarkyness (is that a word?), or rudeness. Please go back and read it again, but choosing a different "voice in your head". Trying to keep this level and technical. It's a good discussion so far, and precisely the sort of thing I expect while we decide how a new protocol should work.
 
LabRat said:
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.)
Click to expand...


Why on earth are you inventing your own mechanism and not using RDM???
 
nomis52 said:
Why on earth are you inventing your own mechanism and not using RDM???
Click to expand...

I agree with your position but also realize that implementing RDM in a uC is not a trivial task. In addition before the days of RDM a number of vendors would use special start codes to update firmware and change addressing so really this isn't all that odd.
 
DynamoBen said:
I agree with your position but also realize that implementing RDM in a uC is not a trivial task.
Click to expand...

I didn't claim it was trivial :), a decent number of people have done it though.

Also if you actually design this to solve the problems people have, you're going to end up with something that looks like RDM. For instance people will want discovery, no one wants to have to remember all the device ids in their rig.

DynamoBen said:
In addition before the days of RDM a number of vendors would use special start codes to update firmware and change addressing so really this isn't all that odd.
Click to expand...

Yes, and since RDM was standardized more and more of them are dropping their proprietary start codes and using RDM simply because it *is* a standard.

Simon
 
My understanding of RDM is that it is a bi-directional protocol. We don't have that capability in most the hardware that I had thought to fit this into.
 
LabRat said:
My understanding of RDM is that it is a bi-directional protocol. We don't have that capability in most the hardware that I had thought to fit this into.
Click to expand...

Good point. With that said it is worth while to design for this in the future.
 
LabRat said:
My understanding of RDM is that it is a bi-directional protocol. We don't have that capability in most the hardware that I had thought to fit this into.
Click to expand...

Realistically unidirectional communication is next to useless for transactional messages (which is what you're trying to build here). What good is it to set the start address if you can't confirm that the action has taken place? This model will work fine for one device, but at 10 and beyond it's a pain to deal with.
 
Set address to 10

Bring device 10 up to 50% brightness..

I'd say it's pretty easy to check if the functionality has worked. :wink2:

(No sarcasm intended... it truly is how I would go about doing this)
Frankly we could add an automatic "flash when completed" option to the programming dialog, or
the pop-up window could include two fields "SerialNO""DMX Address", and two buttons "PROGRAM" and "TEST".


Yes.. this is not how a commercial system would do it. There's no question about that. But this is DIYC hobbyist land, not commercial solutions with bells/whistles and bi-directional communications. Our task is to push our existing hardware to the limits. Occasionally we have breakthroughs that puts us ahead of the commercial folks, but they tend to catch up quickly. Most of the time we trail behind with "best efforts to achieve near same behaviour".

The problem at hand.. existing devices (REN series) to which some people want to convert to DMX. These devices don't have dip-switches, and don't have the ability talk back to the server, and the thought of using a PICKIT to reprogram the DMX start address sends people screaming back into their tinsel coated workshops. There's a solution on the table that seems to address the need.

Now comes the tricky bit, as I don't want this to sound all "pissy etc", so I'm trying very hard to word this correctly.
If you think this solution won't work, then please point out the flaws. I realize that postings and emails can so often sound combative, and that isn't my intent. I believe that I have given reasons/evidence as to why the "you should just use RDM" counter proposals won't work for this particular use/situation. RDM is a better choice *IF* you have two way communication. We don't. So what's the alternative for these existing products?




nomis52 said:
Realistically unidirectional communication is next to useless for transactional messages (which is what you're trying to build here). What good is it to set the start address if you can't confirm that the action has taken place? This model will work fine for one device, but at 10 and beyond it's a pain to deal with.
Click to expand...
 
LabRat said:
The problem at hand.. existing devices (REN series) to which some people want to convert to DMX. These devices don't have dip-switches, and don't have the ability talk back to the server, and the thought of using a PICKIT to reprogram the DMX start address sends people screaming back into their tinsel coated workshops. There's a solution on the table that seems to address the need.

Now comes the tricky bit, as I don't want this to sound all "pissy etc", so I'm trying very hard to word this correctly.
If you think this solution won't work, then please point out the flaws. I realize that postings and emails can so often sound combative, and that isn't my intent. I believe that I have given reasons/evidence as to why the "you should just use RDM" counter proposals won't work for this particular use/situation. RDM is a better choice *IF* you have two way communication. We don't. So what's the alternative for these existing products?
Click to expand...

This is the answer to my original question. Like you say, if you don't have bidirectional communication this is the best you've got.
 
Anything that can be done to make things a bit easier sounds good to me,,,
just my 2 cents..:biggrin:
 
You must log in or register to reply here.
Back
Top