Page 1 of 6 123 ... LastLast
Results 1 to 10 of 53

Thread: DIYC official DMX Manufacturer ID

  1. #1
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default DIYC official DMX Manufacturer ID

    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.
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  2. #2
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    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.
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  3. #3
    Join Date
    Oct 2008
    Location
    San Jose, CA
    Posts
    10,283
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    neato!
    [COLOR=#000080][B][I]Brian[/I][/B][/COLOR]

    [COLOR=#ff0000]Christmas in San Jose! - [URL="http://www.christmasinsj.com"]WEB[/URL] - [URL="https://www.facebook.com/ChristmasInSanJose"]FB[/URL] - [URL="https://www.youtube.com/playlist?list=PL1W78s7liEQEE0ed7WSyLF7B6j3lBX43w"]VIDEOS[/URL]
    [/COLOR][COLOR=#800080]Halloween in San Jose! - [URL="https://www.facebook.com/pages/Halloween-in-San-Jose/356280784428581?ref=tn_tnmn"]FB[/URL]
    [SIZE=1]2015 Halloween Show - Planning now - hopefully some house projection...
    2015 Christmas Show - 5x E681-12, 1x 6804, Ren48LSD, 3x RenSS16, 1x Falcon16v2 (w/expander), 24x90 WS2811 pixel MT (James MT Strips), 12x DIYC Floods, SuperPixelStar, 3x Pixel Arches, PixaBulb House outline
    [/SIZE]
    [/COLOR][SIZE=3][COLOR=#008000][I]Ignorance is Temporary [/I][/COLOR][COLOR=#800080][I]- [/I][/COLOR][COLOR=#ff0000][I]Stupidity is Forever[/I][/COLOR][COLOR=#800080][I]...[/I][/COLOR][/SIZE][I][COLOR=#ff0000]
    [/COLOR][/I]

  4. #4
    Join Date
    Jun 2007
    Location
    WI
    Posts
    2,611
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Sweet now I can use real codes for RDM and ACM stuff, thanks!
    DMX, RDM, ArtNet, sACN, and RDMnet...the future of DIY Christmas.
    Designer of the PropController an open source single-board hardware platform designed for lighting and prop control.

  5. #5
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    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)
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  6. #6
    Join Date
    Jun 2007
    Location
    WI
    Posts
    2,611
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by LabRat View Post
    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.
    DMX, RDM, ArtNet, sACN, and RDMnet...the future of DIY Christmas.
    Designer of the PropController an open source single-board hardware platform designed for lighting and prop control.

  7. #7
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: DIYC official DMX 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.

    Or is it *just* the use of the MFID inside existing RDM protocol??
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  8. #8
    Join Date
    Jun 2007
    Location
    Ft. Walton Beach, FL
    Posts
    1,502
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    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
    Not just a username but a state of mind

  9. #9
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    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.



    Quote Originally Posted by RavingLunatic View Post
    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
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  10. #10
    Join Date
    Jun 2007
    Location
    Ft. Walton Beach, FL
    Posts
    1,502
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by LabRat View Post
    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)
    Last edited by RavingLunatic; 04-24-2012 at 09:17 PM.
    RavingLunatic
    Not just a username but a state of mind

Page 1 of 6 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •