DIYC official DMX Manufacturer ID

[Zeph]

A few thoughts.

Thanks for reserving a manufacturer ID and thinking about how to allocate this limited resource with future expansion in mind.

1) I agree with the concept of a "set serial" command distinct from "set starting address" rather than combined. Different functions.

2) Small. I think Command 1 should be set serial - because having that serial will likely be the base on which the other commands are built.
Command 2 could be set starting address. There may be a command 3 later, and it will probably use the serial...

3) For consistency, I suggest that all our commands begin with a serial address - even Set Serial. However, 0 should be reserved and not used as a real serial number. If you want to change a known serial, you could give the old serial and the new. More often tho you would send it to serial number 0. Addressing the Set Serial command to device 0 means "I'm talking to a device which has been identified out of band". There have been suggestions of having a button or switch or grounding some pin on the device, which means "for a while, you can respond to the Set Serial command addressed to serial 0". The exact method can vary with the device, but there needs to be some way of telling one device "I mean you, even tho I don't know your name".

4) I also agree with the checksum for a one way protocol. Apparently 8 bits. The method of creating the checksum, and which bytes are included within it, need to be specified. A carry-wrapping sum (add the next byte, then add one if it overflows) is easy and fairly effective. A simple sum (low 8 bits) can also work.

5) Renards should probably pass the commands down the daisy chain unmodified by default. (Alternative: pass only commands not addressed to and consumed by itself). This is probably not part of the standard per se (true DMX uses a bus rather than a modify-and-repeat daisy chain), but should be documented in the wiki anyway.

6) Today we have one way protocols in this hobby, but we should be preparing for future of having RDM, and be thinking ahead to how these commands will gracefully interact with it, before committing them in stone.

7) For true DMX, that annoyingly long break separates packets and thus determines packet length. Since sometimes there is value in encapsulating DMX style date in other formats, I wonder if it would be useful to include a length in these new packets, to make them more easily used by alternate streaming contexts?

8) Command 3 might be: (to the device with the given serial): accept the following data bytes as beginning with your start address. So suppose you set serial 1534 to starting address 420. You can verify that it was addressed by sending a regular DMX data packet including channels 420 and up, and see if it lights up. But what if there are two devices responding to address 420? You might be looking at the wrong one. So instead, to test you send 91 Mhigh Mlow 03 SerHi SerLo Data Data Data.... The device displays those data bytes. (1) No other device on address 420 will respond, (2) you don't have to send 419 dummy bytes to get to it, (3) besides testing, this command could potentially be used for displaying sequences with selective update.

 

[LabRat]

Some excellent thoughts here Zeph. Good stuff!

A few thoughts.

Thanks for reserving a manufacturer ID and thinking about how to allocate this limited resource with future expansion in mind.

1) I agree with the concept of a "set serial" command distinct from "set starting address" rather than combined. Different functions.

2) Small. I think Command 1 should be set serial - because having that serial will likely be the base on which the other commands are built.
Command 2 could be set starting address. There may be a command 3 later, and it will probably use the serial...

3) For consistency, I suggest that all our commands begin with a serial address - even Set Serial. However, 0 should be reserved and not used as a real serial number. If you want to change a known serial, you could give the old serial and the new. More often tho you would send it to serial number 0. Addressing the Set Serial command to device 0 means "I'm talking to a device which has been identified out of band". There have been suggestions of having a button or switch or grounding some pin on the device, which means "for a while, you can respond to the Set Serial command addressed to serial 0". The exact method can vary with the device, but there needs to be some way of telling one device "I mean you, even tho I don't know your name".

I think you described the challenge exactly. "I mean you, even though I don't know your name".

Unfortunately many of our boards (as they exist now) don't have any such option (Switches, or Jumpers). As such we either modify the boards by somehow taking an existing I/O pin and polling it at boot, then re purposing it an output, or we accept the fact that we may require the potentially more troublesome "I don't care who you are, program with this number anyways".

Looking at this solely from the protocol side, however, I have come to the conclusion that you are right to suggest that a source serial number of "0" denotes the unknown target. This then leaves it up to the device to determine how it will respond. Some may ignore it, as they have a jumper that says to do so, others may opt to not ignore it, as they don't. Ultimately it's up to the FW in the device.

(see.. I can't be persuaded to change my views :wink: )

4) I also agree with the checksum for a one way protocol. Apparently 8 bits. The method of creating the checksum, and which bytes are included within it, need to be specified. A carry-wrapping sum (add the next byte, then add one if it overflows) is easy and fairly effective. A simple sum (low 8 bits) can also work.

I had thought to include a "rotate with carry" on each byte, in order to try and stave off "byte swap" situations. So for each incoming byte, take the existing total, and shift left (with carry) then add in the new byte. I was searching around last night, and a full CRC seems overkill.

5) Renards should probably pass the commands down the daisy chain unmodified by default. (Alternative: pass only commands not addressed to and consumed by itself). This is probably not part of the standard per se (true DMX uses a bus rather than a modify-and-repeat daisy chain), but should be documented in the wiki anyway.

Good point. I was only thinking about the "device" as a whole, not the individual PICs inside.

6) Today we have one way protocols in this hobby, but we should be preparing for future of having RDM, and be thinking ahead to how these commands will gracefully interact with it, before committing them in stone.

I would think that any that already had bi-directional control could use the existing RDM solutions. As I learned earlier in this thread, these do require use of the MFID, but it didn't sound like we would need to extend the actual protocol at all. (But I'm not an RDM expert, nor do I play one on television)

7) For true DMX, that annoyingly long break separates packets and thus determines packet length. Since sometimes there is value in encapsulating DMX style date in other formats, I wonder if it would be useful to include a length in these new packets, to make them more easily used by alternate streaming contexts?

Hmmm... (that's me thinking about the implications) I have no opinion on this yet.

8) Command 3 might be: (to the device with the given serial): accept the following data bytes as beginning with your start address. So suppose you set serial 1534 to starting address 420. You can verify that it was addressed by sending a regular DMX data packet including channels 420 and up, and see if it lights up. But what if there are two devices responding to address 420? You might be looking at the wrong one. So instead, to test you send 91 Mhigh Mlow 03 SerHi SerLo Data Data Data.... The device displays those data bytes. (1) No other device on address 420 will respond, (2) you don't have to send 419 dummy bytes to get to it, (3) besides testing, this command could potentially be used for displaying sequences with selective update.

An interesting extension.

 

[RavingLunatic]

5) Renards should probably pass the commands down the daisy chain unmodified by default. (Alternative: pass only commands not addressed to and consumed by itself). This is probably not part of the standard per se (true DMX uses a bus rather than a modify-and-repeat daisy chain), but should be documented in the wiki anyway.

There is no need for the first PIC on a Renard board to pass the reprogramming commands. Only the first PIC would ever have a need to change its address, all others (PICs on-board and boards in that serial chain) are set to address 1 and that wouldn't change for Renard.

Remember Renard boards are DMX capable not DMX compliant.

 

[LabRat]

But aren't they passing the DMX through/downstream? So in theory it should pass any reprogramming command that it doesn't identify as being to itself.
The boards I've done locally, I've opted to have a jumper the incoming to outgoing in order to maintain the BUS nature of the transmission. Not sure if we
can assume this to be true for all devices.

Aside: This has the implication that it would have to buffer the entire command, and then re-transmit if the target address was invalid.

 

[RavingLunatic]

But aren't they passing the DMX through/downstream? So in theory it should pass any reprogramming command that it doesn't identify as being to itself.

Simple answer is NO. What gets passed from PIC to PIC is a DMX-Like datastream that is now 8 data values less than the DMX address where the PIC started processing data. So each PIC strips out the data it needs and passes the remaining data. Any data before the start address is lost/skipped. Each PIC/Controller after the first PIC is set to DMX start address 1 and takes the first 8 values and passes the rest. That is why you don't want to hook non-Renard devices after a Renard.


As Phil has stated in the past, the DMX capability was added to the Renard boards well after the original Renard design was done. It was added to give users a DMX ability but is in no way fully DMX compliant. It gets the job done for the Renard users and that is what matters most.

The boards I've done locally, I've opted to have a jumper the incoming to outgoing in order to maintain the BUS nature of the transmission. Not sure if we can assume this to be true for all devices.

No, you can't assume anything in DIYC. All existing Renards (SS series, 24, 64, Xmus 16) don't have that capability.

Aside: This has the implication that it would have to buffer the entire command, and then re-transmit if the target address was invalid.

So now that you see how the Renard-DMX firmware works (above) you'll understand that only the first PIC in the "serial" chain needs to worry about the reprogramming command. If the serial number or address are invalid, then the firmware would just ignore that data and start looking for the next data packet.



To use multiple Renards with different addresses in a DMX environment, you need to "split" the DMX data line before getting to the Renard boards. DMX splitters come in handy for Renard users.


Hope this clears up the Renard-DMX scenario for you.

 

[LabRat]

Hmm... if we have a reasonable mechanism to alter start addresses, without pulling the PICs, would it make sense to stop stripping the bytes, and treat each PIC as an 8-channel device on the chain? Each with it's own serial number (and starting address)? Perhaps a little cumbersome to setup initially.

(Just spit-balling here.. perhaps a bit of a tangent from the protocol discussion.)

Simple answer is NO. What gets passed from PIC to PIC is a DMX-Like datastream that is now 8 data values less than the DMX address where the PIC started processing data. So each PIC strips out the data it needs and passes the remaining data. Any data before the start address is lost/skipped. Each PIC/Controller after the first PIC is set to DMX start address 1 and takes the first 8 values and passes the rest. That is why you don't want to hook non-Renard devices after a Renard.


As Phil has stated in the past, the DMX capability was added to the Renard boards well after the original Renard design was done. It was added to give users a DMX ability but is in no way fully DMX compliant. It gets the job done for the Renard users and that is what matters most.





No, you can't assume anything in DIYC. All existing Renards (SS series, 24, 64, Xmus 16) don't have that capability.





So now that you see how the Renard-DMX firmware works (above) you'll understand that only the first PIC in the "serial" chain needs to worry about the reprogramming command. If the serial number or address are invalid, then the firmware would just ignore that data and start looking for the next data packet.



To use multiple Renards with different addresses in a DMX environment, you need to "split" the DMX data line before getting to the Renard boards. DMX splitters come in handy for Renard users.


Hope this clears up the Renard-DMX scenario for you.

 

[RavingLunatic]

Hmm... if we have a reasonable mechanism to alter start addresses, without pulling the PICs, would it make sense to stop stripping the bytes, and treat each PIC as an 8-channel device on the chain? Each with it's own serial number (and starting address)? Perhaps a little cumbersome to setup initially.

(Just spit-balling here.. perhaps a bit of a tangent from the protocol discussion.)

While possible, would it be worth the effort?

Take the Ren64 as the worst case, if you wanted to change its place in the DMX universe you would have to change the addresss for all eight PICs on the board. Now you only change the first PIC.


Yes, this is off topic of your OP. But it does highlight the fact that a one-size fits all "standard" might not be best for DIYC.

 

[RavingLunatic]

I've been mulling over the OP while modifying code to support the DIYC MFID.

Alternate Start Code and a DIYC MFID - still a great idea.


The thing that keeps nagging at me is the long term goal of a DIYC "standard" or if you prefer a "controlled protocol". The more I think about it, the more I think that it seems very non-DIYC to me. Ignoring the fact that there would be no way to enforce a "standard", here in the DIYC community we never tell anyone that they have to do anything relating to software/firmware/hardware in "our way or no way". That is for other sites to do.

Instead of thinking in terms of a "standard", work towards getting the new method into working systems and document it. If you have a method that works and is well documented, then others will probably follow the exisiting example. (I believe that most developers will not recreate the wheel if they don't have to.)

Maybe I'm just over-thinking it. Maybe seeing too many "movwf" commands has altered my mind.


RL

 

[DynamoBen]

To be honest DIYC is going through the same growing pains that the theatrical industry went through a decade ago. The same problem existed then as it does for use now, how do you address devices remotely (when a light is hanging 30 ft in the air remote addressing is a handy thing). And the industry did the same thing, companies came up with their own codes and methods in hopes that others would follow. The problem was that each new product had its own "better" method and after years of this a standard was created to normalize the process across all products which is RDM (Remote Device Management).

Now I'm not saying that using RDM is the perfect solution but it's worth knowing the history in case you want to repeat it.

 

[chilloutdocdoc]

To be honest DIYC is going through the same growing pains that the theatrical industry went through a decade ago. The same problem existed then as it does for use now, how do you address devices remotely (when a light is hanging 30 ft in the air remote addressing is a handy thing). And the industry did the same thing, companies came up with their own codes and methods in hopes that others would follow. The problem was that each new product had its own "better" method and after years of this a standard was created to normalize the process across all products which is RDM (Remote Device Management).

Now I'm not saying that using RDM is the perfect solution but it's worth knowing the history in case you want to repeat it.

+1. The standards might be overkill sometimes, but they were written by (hopefully) people that were dealing with a lot of the same issues that we are. I also agree with raving lunatic. There won't be a way to enforce a standard or setup. Just look at the popularity of Renard here and not DMX. However, if something is really good, it will permeate throughout the products here. Unfortunately it won't be implemented on a lot of the old hardware, but on the new stuff, maybe it would work.

I agree with raving yet again that we don't want to reinvent the wheel (hence I propose trying to follow what is out there if it works.) Maybe if we get some documentation and code examples on implementing these solutions, or atleast a subset to start it will be much easier for other developers to implement It.

To chime in yet a bit more, it will require a bit of change in hardware thinking instead of pushing our hardware to the limit and making out what we can do, maybe start keeping some headroom for future advancement. I think Ben does this with some of his stuff and so do some of the others. Also another chime for the fact that sometimes an extra feature is more desirable than saving $1 or $2. Example: I would pay an extra few dollars for some remote access to my fixtures. Just imagine removing into your system from a smartphone and configuring your display while outside in the yard.

 

[LabRat]

Agreeing to standards are only required if you plan to "interop" with others. Any DIY person who has no intention to try and make their gear work with anyone any other gear, can create their own protocols. Nobody is mandating that anyone *must* follow a protocol, but it does make it easier to do so.

eg. DMX... or RENard serial.

 

[timon]

To be honest DIYC is going through the same growing pains that the theatrical industry went through a decade ago. The same problem existed then as it does for use now, how do you address devices remotely (when a light is hanging 30 ft in the air remote addressing is a handy thing). And the industry did the same thing, companies came up with their own codes and methods in hopes that others would follow. The problem was that each new product had its own "better" method and after years of this a standard was created to normalize the process across all products which is RDM (Remote Device Management).

Now I'm not saying that using RDM is the perfect solution but it's worth knowing the history in case you want to repeat it.

+1. If there is already a "Standard" then it's only reasonable to follow it. I suspect that LOR, LSP and of course LF will follow the standards. If one chooses to not follow standards then one opens them selves up to having to write their own drivers or show software. If someone wants to do that fine but then they shouldn't expect other to help them when they have problems. Speaking about DMX only, if there is a Offical DMX standard that does what we want then

Agreeing to standards are only required if you plan to "interop" with others. Any DIY person who has no intention to try and make their gear work with anyone any other gear, can create their own protocols. Nobody is mandating that anyone *must* follow a protocol, but it does make it easier to do so.

eg. DMX... or RENard serial.

But we do interact with others. If you make your own DMX controller you expect it to work with LOR, LSP and other show packages thus one needs to follow standards.
Again using DMX, if there is provision in the specification for manufacture specific options and one want to write a new function that's fine. That's how official standards evolve and it's to everyones advantage. If however the Official DMX standard has already specified how a function is to work I think it's foolish for one to "re-invent" it unless there is a compelling need or a flaw in the existing function.

So since the RDM specification has already defined a way to remotely re-address controllers then I suggest we follow it.

One more point which was brought up by one of the guys making controllers. Even if you don't currently have plans to support RDM functionality it's a really good idea to still design the hardware so you can drive the DMX line. That way you can modify the firmware in the future to add the ability assuming that you have code space.

IMHO
John

 

[LabRat]

Perhaps I was too vague with my response, because this is exactly what I was saying.

RDM exists (if you have bi-directional control), and extending DMX with using the MFID seems an acceptable alternative for EXISTING hardware.
I will be pursuing this latter idea starting in June.

New hardware? Well .. that's up to each hardware designer (but again.. if they expect to interact with others, then adhering to publish protocols/designs seems prudent).

 

[timon]

I'm wondering about only having a 16bit serial number and about running out of numbers. Any thought about that?

 

[RavingLunatic]

I'm wondering about only having a 16bit serial number and about running out of numbers. Any thought about that?

You really think that anybody will have over 65,535 DMX controllers??? Not channels but actual unique DMX controllers?

Even so, the serial number would only be used during reprogramming. So in theory you could have duplicate serial numbers as long as they were on separate DMX universes. And during reprogramming you only had the universe you needed active/powered.



RL

 

[DynamoBen]

You really think that anybody will have over 65,535 DMX controllers???

Careful, at one point they said "Do you really think that anybody will need over 512 channels???"

 

[StandingInAwe85]

Careful, at one point they said "Do you really think that anybody will need over 512 channels???"

I second this statement. And on the same day that Europe officially ran out of public IP addresses (http://www.ripe.net/internet-coordi...o-allocate-ipv4-address-space-from-the-last-8) I can imagine the conversation back in the late 1980's were they said there will never be more than 4 billion devices on this internet thing they're building.

 

[timon]

I've done many specifications in the past so I though I'd take a stab at one for the 0x91 start code. It takes into account error checking, multiple designers and serial numbers. If you think this looks good I'll put it into a specification document that goes into more detail for peer review. So here goes.


As we know the basic DMX stream that would be sent is:
<0x91> <MFID-HIGH> <MFID-LOW> <PAYLOAD>

To that let's add a way to know the payload length and checksum for entire payload. I recommend that the checksum include the entire packet less the start code. I suggest that we use the Unix BCD Checksum. It's easy to code and has been around for a very long time. The total number of bytes will have to be even since it's a 16 bit checksum.

The DMX stream now becomes:
<0x91> <MFID-HIGH> <MFID-LOW> <PAYLOAD COUNT-H> <PAYLOAD COUNT-L> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

Before we continue I think we need to look at how different DIYC designers can work under the single manufacture ID DIYC has been assigned. I think that we need to have our own DIYC Designer ID's so we can track our own.

DIYC Designer ID's, DEID, are easy, they would be 16 bits just like the Manufacture ID, so that becomes <DEID-H> <DEID-L>. DIYC's designer ID would be 0, i.e., <0x00> <0x00>, and would be used for all "Standard" DIYC commands. The DEID's 0xFFF0 through 0xFFFF are for testing until you request a designer ID. I recommend that a designer IDs not be assigned until the designer has their first device built and tested using a test DEID.

Serial number assignments. I think the best way to assign serial numbers is to make them 16 bits,<SERIAL-H> <SERIAL-L>, but have them linked to the DEID. The exception to this would be serial number 0 which is a match all serial numbers.

The DMX stream now becomes:
<0x91> <MFID-HIGH> <MFID-LOW> <PAYLOAD COUNT-H> <PAYLOAD COUNT-L> <DEID-H> <DEID-L> <SERIAL-H> <SERIAL-L> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

So we have now defined the basics preamble for all DIYC Manufacture ID functions. So as to make the rest of the discussion easier well refer to the above up to the payload as the <DIYC PREAMBLE>

So let's look at some of the possible DIYC standard commands. These are commands where the DEID is 0x0000. The command is a single byte plus a command modifier byte. Some commands may only use the modifier and some may not use it as all in which case it should be set to 0.

---------------

CMD=0x01 - Set DMX Address:
<DIYC PREAMBLE> <0x01> <0x00> <CUR_DMXADDR-H> <CUR_DMXADDR-L> <NEW_DMXADDR-H> <NEW_DMXADDR-L> <CHECKSUM-H> <CHECKSUM-L>

This command will program the DMX address for any controller. If the DEID and serial number are set to 0x0000 and the current DMX address is set to 0 then it's up to the device to decide if it should change based on other conditions such as a switch settings. If the DEID and serial number are set to other than 0x0000 only that device will change it's address.

---------------

CMD=0x02 - DMX signal missing time to channels off:
<DIYC PREAMBLE> <0x02> <0x00> <SECONDS-H> <SECONDS-L> <CHECKSUM-H> <CHECKSUM-L>

This is the number of seconds of no DMX signal after which the output will go to their normal "Off" or "Neutral" state This state may not be "0". If the time is set to 0 then never turn off.

---------------

CMD=0x03 - DMX signal missing time to test mode:
<DIYC PREAMBLE> <0x03> <PATTERN> <SECONDS-H> <SECONDS-L> <CHECKSUM-H> <CHECKSUM-L>

This is the number of seconds of no DMX signal after which the output will go into test mode using the specified PATTERN. If seconds set to 0 then never enter test mode if set to 0xFFFF enter test mode immediately.

Note: if a non-zero value is set for both the off and test functions then each will trigger on it's own but will terminate the other. So if test is set to 60 seconds and blank is set to 90 seconds then after 60 seconds the lights will enter test and 30 seconds later they will turn off. This allow one to see that the controller is working but not have the channels stay on all night if the DMX source disappears.

---------------

CMD=0x04 - Program Serial No:
<DIYC PREAMBLE> <0x04> <0x00> <NEW_SERIAL-HI> <NEW_SERIAL-LOW> <CHECKSUM-H> <CHECKSUM-L>

This will program the serial number for the device with a matching DEID and serial number. If the DEID and/or Serial number is 0 then it's up to the device to decide if it should change based on other conditions such as a switch settings.

---------------

DIYC new command testing. (CMD= 0xB0 through 0xBF):
<DIYC PREAMBLE> <0xF_> <0x00> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

Designers wishing to create new commands to be included in the DIYX standard can use these. If accepted they will be given official command IDs.

---------------

Designer private commands. (CMD= 0xE0 through 0xFF):
<DIYC PREAMBLE> <0xF_> <0x00> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

Designers wishing to create private commands can use these. They should only work if the DEID matches.

---------------

Thoughts, flames or anything else.

John

 

[jeffrae]

While possible, would it be worth the effort?

Take the Ren64 as the worst case, if you wanted to change its place in the DMX universe you would have to change the addresss for all eight PICs on the board. Now you only change the first PIC.


Yes, this is off topic of your OP. But it does highlight the fact that a one-size fits all "standard" might not be best for DIYC.

I have a ren64 with dmx software. The problem is that you are looking at the ren64 as 8 separate controllers. I made a small hardware mod cut the tx out of the last pic and added a link so that the dmx input was connected to the DMX output.

now I have a 64 channel controller that operates like any other dmx controller. I then added the Start address code from the modified JEC pixel and now I can set the start address of the First controller we do not care about the method that is used to send the data through the rest of the pics.

It would not take much to change the code in the PIC to look for the start code 91 and when it sees it go into program mode read the program packet and update the First pic's Eeprom. These program packet bytes would not be feed through to the next pic . This would allow all pics to have the same code.

Just my two cents worth.

regards Jeff Rae

Start Address open source code http://code.google.com/p/open-source-lighting-control/source/browse/trunk/DMX_DCSSR/Software/DMX_DCSSR.asm?spec=svn13&r=13

 

[LabRat]

Timon,

This looks like an excellent start. Lets slap it in a WIKI under "DRAFT" and see if we can get some code to support it. Once we have a working solution, we can move it from draft to released status.

How does that sound?

Andrew

I've done many specifications in the past so I though I'd take a stab at one for the 0x91 start code. It takes into account error checking, multiple designers and serial numbers. If you think this looks good I'll put it into a specification document that goes into more detail for peer review. So here goes.


As we know the basic DMX stream that would be sent is:
<0x91> <MFID-HIGH> <MFID-LOW> <PAYLOAD>

To that let's add a way to know the payload length and checksum for entire payload. I recommend that the checksum include the entire packet less the start code. I suggest that we use the Unix BCD Checksum. It's easy to code and has been around for a very long time. The total number of bytes will have to be even since it's a 16 bit checksum.

The DMX stream now becomes:
<0x91> <MFID-HIGH> <MFID-LOW> <PAYLOAD COUNT-H> <PAYLOAD COUNT-L> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

Before we continue I think we need to look at how different DIYC designers can work under the single manufacture ID DIYC has been assigned. I think that we need to have our own DIYC Designer ID's so we can track our own.

DIYC Designer ID's, DEID, are easy, they would be 16 bits just like the Manufacture ID, so that becomes <DEID-H> <DEID-L>. DIYC's designer ID would be 0, i.e., <0x00> <0x00>, and would be used for all "Standard" DIYC commands. The DEID's 0xFFF0 through 0xFFFF are for testing until you request a designer ID. I recommend that a designer IDs not be assigned until the designer has their first device built and tested using a test DEID.

Serial number assignments. I think the best way to assign serial numbers is to make them 16 bits,<SERIAL-H> <SERIAL-L>, but have them linked to the DEID. The exception to this would be serial number 0 which is a match all serial numbers.

The DMX stream now becomes:
<0x91> <MFID-HIGH> <MFID-LOW> <PAYLOAD COUNT-H> <PAYLOAD COUNT-L> <DEID-H> <DEID-L> <SERIAL-H> <SERIAL-L> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

So we have now defined the basics preamble for all DIYC Manufacture ID functions. So as to make the rest of the discussion easier well refer to the above up to the payload as the <DIYC PREAMBLE>

So let's look at some of the possible DIYC standard commands. These are commands where the DEID is 0x0000. The command is a single byte plus a command modifier byte. Some commands may only use the modifier and some may not use it as all in which case it should be set to 0.

---------------

CMD=0x01 - Set DMX Address:
<DIYC PREAMBLE> <0x01> <0x00> <CUR_DMXADDR-H> <CUR_DMXADDR-L> <NEW_DMXADDR-H> <NEW_DMXADDR-L> <CHECKSUM-H> <CHECKSUM-L>

This command will program the DMX address for any controller. If the DEID and serial number are set to 0x0000 and the current DMX address is set to 0 then it's up to the device to decide if it should change based on other conditions such as a switch settings. If the DEID and serial number are set to other than 0x0000 only that device will change it's address.

---------------

CMD=0x02 - DMX signal missing time to channels off:
<DIYC PREAMBLE> <0x02> <0x00> <SECONDS-H> <SECONDS-L> <CHECKSUM-H> <CHECKSUM-L>

This is the number of seconds of no DMX signal after which the output will go to their normal "Off" or "Neutral" state This state may not be "0". If the time is set to 0 then never turn off.

---------------

CMD=0x03 - DMX signal missing time to test mode:
<DIYC PREAMBLE> <0x03> <PATTERN> <SECONDS-H> <SECONDS-L> <CHECKSUM-H> <CHECKSUM-L>

This is the number of seconds of no DMX signal after which the output will go into test mode using the specified PATTERN. If seconds set to 0 then never enter test mode if set to 0xFFFF enter test mode immediately.

Note: if a non-zero value is set for both the off and test functions then each will trigger on it's own but will terminate the other. So if test is set to 60 seconds and blank is set to 90 seconds then after 60 seconds the lights will enter test and 30 seconds later they will turn off. This allow one to see that the controller is working but not have the channels stay on all night if the DMX source disappears.

---------------

CMD=0x04 - Program Serial No:
<DIYC PREAMBLE> <0x04> <0x00> <NEW_SERIAL-HI> <NEW_SERIAL-LOW> <CHECKSUM-H> <CHECKSUM-L>

This will program the serial number for the device with a matching DEID and serial number. If the DEID and/or Serial number is 0 then it's up to the device to decide if it should change based on other conditions such as a switch settings.

---------------

DIYC new command testing. (CMD= 0xB0 through 0xBF):
<DIYC PREAMBLE> <0xF_> <0x00> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

Designers wishing to create new commands to be included in the DIYX standard can use these. If accepted they will be given official command IDs.

---------------

Designer private commands. (CMD= 0xE0 through 0xFF):
<DIYC PREAMBLE> <0xF_> <0x00> <PAYLOAD> <CHECKSUM-H> <CHECKSUM-L>

Designers wishing to create private commands can use these. They should only work if the DEID matches.

---------------

Thoughts, flames or anything else.

John