DMX512 SPEC OF data format of WAVEFORM

[longpole001]

Can some one who has knowledge for the DMX512 spec 2008 advise the information specs for this spec , it appears that the spec says that data byte then 512 bytes of address follow is this correct , if not can someone give me a link to the correct information

cheers

[HenrikOlsson]

Hi,
I've never worked with DMX-512 but as far as I understand the first byte is a type byte (called start code) indicating what type of information is being transmitted, this is usually 0 (zero) but there are others. Then there are up to 512 bytes of data, first byte is the data for adress 1, second byte is the data for adress 2 and so on. Each "string" of lights etc are called a universe and each universe can occupy up to 512 adresses. If only adress 1-20 are in use you only need to send 20 bytes (start code + 19 data bytes, one for each adress).

But again, that's just my understanding of it after a short read on Wikipedia and some other places.

/Henrik.

[longpole001]

thanks for that

[longpole001]

it does seem that this protocol is not very good for when RF is used to control lights , there is no checksum byte , high chance that if one or two bytes dont make it , then its likely that any lighting will get the wrong value , am i seeing this incorrectly

[ScaleRobotics]

Sounds like you are reading it right. DMX was made for RS-485, wired communication. But companies do make wireless DMX. Since it is just lighting, the hope would be that if it did get a few bits messed up, they would come in correctly in the next 25 ms transmission. Microchip made this application note a while back. http://ww1.microchip.com/downloads/e...tes/01076A.pdf

[HenrikOlsson]

No, there is no checksum etc in the DMX-512 protocol itself but there are RF-modules which uses a more robust protocol so the DMX-512 frame you feed the transmitter will travel as payload inside a larger datapacket containing checksum etc and only come out of the receiver if the data is concidered valid. So, in short, it depends on what exactly it is you want to do and what type of RF-modules you're planning to use. The modules obviously would have to be able to handle
A) The bitrate and
B) Be able to handle packets of 513 bytes or more

[longpole001]

mmm,

what RF module that encapsulate the DMX512 protocol , i was looking at using a RF protocol that is more robust even though it comes from other designs from a propitiatory use for messaging ,making any packet meet that protocol as there are so many that i looked at are way way better for the application than dmx512 ,

DMX512 appear to be well below par and waist full, even when used in wired app for the data sent , has no checking, no end of packet byte and high over head when less than 512bytes use , cos you have to know you not getting 512 bytes , not that you missed some and would fill the air with less than usefull retries to achieve an effect result.


I am new to some of this but it just seems that way to me

I also hate redoing the wheel even though the RF modulus i have dont have any protocol defined ( NRF 24L01 2.4Mhz )

any input be good as i am at a crossroads on the best way to proceed i need to control small amount of 600 lights with this app over a small area , of less that 1000 meters

l can make it work with any protocol as long as i can get the correct doco spec & it is not so left field that is not use full except for this application

cheers

[longpole001]

oh and the payload is max 10 bytes and need to be sent about every 5sec so low data rates , just need to get there and accurate delivery

[keithdoxey]

DMX512 appear to be well below par and waist full, even when used in wired app for the data sent , has no checking, no end of packet byte and high over head when less than 512bytes use , cos you have to know you not getting 512 bytes , not that you missed some and would fill the air with less than usefull retries to achieve an effect result.

I think you may have misinterpreted what DMX512 was designed to do. Its was specifically designed for control of lighting in a theatrical/club environment where lights are constantly changing. It is only wasteful if not properly configured.

The data packet consists of a header byte followed by a byte for each of the channels in order. As such it doesnt need any addressing info, the receiving device merely detects the header byte then count until the number of bytes received matches its configured address. There doesnt need to be a end of packet byte because there is a break in transmission between packets. The recieving device looks for the break, then header then counts.

Many DMX controllers use less than 512 channels, 54 or 192 channels being quite common. A 54 channel controller only sends 55 bytes per packet and as such can refresh lights about 9 times faster than a controller that addresses an entire universe.

DMX has been around a long time now and Im pretty sure that it would have been superceeded if it was as flakey as you appear to think it is. Good cable and correct termination makes for a robust system in what is often a very electrically noisy environment.

[longpole001]

thanks for the info ,

As i am looking to use RF as the control , not a cable is it best to encapsulate the DMX512 protocol or go with a better protocol more in line with RF

[keithdoxey]

thanks for the info ,

As i am looking to use RF as the control , not a cable is it best to encapsulate the DMX512 protocol or go with a better protocol more in line with RF

Given your intended use ....

the payload is max 10 bytes and need to be sent about every 5sec so low data rates , just need to get there and accurate delivery

.... I would abandon any thoughts of using DMX. The baud rate is 250k and the data frame is intended to be repeated constantly.

Early DMX equipment didnt used to store the recieved values and any loss of the DMX signal would result in the lights going out. Modern equipment will retain the last values recieved.

For your application I would use a much lower rate like 9600 and implement some form of checksum. Even if you opted for 1200 baud you would still be able to send 120 bytes per second so your 10 byte packet could be sent 12 times per second.

[longpole001]

cheers , i agree for this application dmx is not well suited even if this app is for lighting and i am thinking of a header byte , payload bytes , checksum , end of packet byte , max 10 bytes . for each packet , the device allows upto 2000000 bps , but a low rate is all i need to get what i want

[longpole001]

or just go with how the chip encodes using shockburst ,