I am about to start a new project where I would like to record the values passed over DMX.
For that I need to record up to 512 channels, and also the time between each command so I later can get it to play it back again.
My problem is now, how to do this smartest?
I don't know how many commands there can be, or over how long time they will last, so I am considering storing it all on an SD card, instead of in the microcontroller.
The reason I started thinking about SD card, is because my 3D printer is based on an atmega chip running Arduino, and it can both read quite a lot of lines while also moving the stepper motors around, so maybe it would be fine for something like this too.
But then how to format it the best way?
Maybe something like
001000
002000
003128
004255
D200
so channel 1 will be set to 0, channel 2 to 0, channel 3 to 128 and channel 4 to 255
D then defines a 200 micro- or milliseconds delay. This would avoid having to search for a character where to seperate channel from value, but instead there will be a lot of extra zeroes...
DISCLAIMER - I know what it is, but I've never used DMX...
You'd need an SDcard and a microcontroller.
I know there is software to program a whole show (or scene) in advance, but I don't know if there is a standardized DMX file format. If such a standard exists, it would make sense to use it.
so channel 1 will be set to 0, channel 2 to 0, channel 3 to 128 and channel 4 to 255
D then defines a 200 micro- or milliseconds delay. This would avoid having to search for a character where to seperate channel from value, but instead there will be a lot of extra zeroes...
Obviously the DMX light knows when to ignore the data and when it's being addressed and needs to respond to a command. So, your capture device should be able read all of the addresses and capture all of the messages (along with the associated address).
Then, I assume you want to time-stamp them (with relative time) so you can play-back the sequence? Those automated sequences would have to be time-stamped, but again, I don't know if there's a standard or if every application uses it's own proprietary file-format.
I am far from new to working with arduino and different microcontrollers running it, so I am aware of needing both the microcontroller and sd card, instead of inventing the wheel again I am also just going to use a purpose made chip for the DMX signal, which will make the +2.5/-2.5v signal for me. and in the end I will probably end up with a custom made pcb with everything from 230v supply to the dmx connectors.
The DMX signal itself is a standard, all the different programs seems to use different and encoded files.
Instead of timing each line, I was just thinking about adding a delay between them, so if a bunch of values arrived so fast it could not determine the time between them, it would just play them back as fast as it could again. But timestamping would probably also work.
My idea is to use channel 512 as recording trigger. So I program the DMX sequence to set channel 512 to 255, and the microcontroller will wait for channel 512 to to to 255, and record time, channels and values until channel 512 has returned to 0 again.
Hmmmm... Maybe I should just try and see what happens, instead of thinking too much about how...
I'm not too sure on the protocol, but what you could do is read the data stream, store values and a time stamp, then keep reading and compare to stored value until change is detected.
Then its just read new data and timestamp, and simple calc to get the duration or delay.
This should cut down read/writes to the SD card.
maybe start with reading some serial data to work out the protocol.
Looking at the protocol spec on wikipedia,
At the datalink layer, a DMX512 controller transmits asynchronous serial data at 250 kbit/s. The data format is fixed at one start bit, eight data bits (least significant first[7]), two stop bits and no parity.
have a read, I don't imagine its gonna be too hard to do.
and in the end I will probably end up with a custom made pcb with everything from 230v supply to the dmx connectors.