Standalone DMX Recorder/Player devices

fasteddy

I have C.L.A.P
Global moderator
Joined
Apr 26, 2010
Messages
6,648
Location
Albion Park NSW
This is looking real good, I'm wanting to set up some floods around my house that are triggered by a motion sensor and this looks like it will fit the bill perfectly, great work there David.
Three questions, (1) do you have an estimated cost for the board complete? (2) are you needing someone to write some firmware for this? (3) When do you think the board will be available?

Again David great work, I love the feature of having DMX input but with no DMX input it reverts back to the stored program, a great feature for adding security for after show hours and I can see this being part of my permanent flood lighting and security lighting both for Christmas and during the year.
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
(A1) No idea yet. Will update when I get a chance.

(A2) I don't need someone to write it for me - just need the time!

(A3) I have 5 prototype boards - only one populated. So.... whenever I get time to write and debug the firmware!
 

riri7707

Full time elf
Joined
May 9, 2010
Messages
222
Location
Paris / France
Looks small and smart...
Impatient to have some as ready.

Exactly what i expected...

Excellent work for the PCB design and integration, David....

Cheers, Henri
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
Well, I have my new board successfully recording and playing back DMX streams. There are still some smaller issues to work out, but it does basically work!

Here's a brief explanation of what it does:

In standby mode (not recording or playing), the incoming DMX stream is passed to the DMX output. This is so you can see what you're about to record, just like the record monitor function of "Ye Old Fashioned" tape deck!

When the record button is pressed, the board starts recording 32 channels of DMX at a rate of 20 samples per second (50ms timing), with the red LED flashing briefly each time a sample is saved to the eeprom. If the end of the eeprom is reached while the record button is still pressed, the red LED reverts to flashing once per 500ms to let you know that the maximum record time was reached. When you release the record button, the red LED goes out and the PIC stores the length of the sequence to its own eeprom.

When the play button is pressed, the board interrupts the incoming DMX stream and starts playback (at 20 samples per second) of the previously recorded stream. The green LED flashes briefly each time a sample is fetched from the eeprom and sent to the DMX output. When the play button is released, the green LED stops flashing and the incoming DMX is once again passed through to the DMX output.

DMX playback simply plays all of the recorded data in a loop. If you only recorded 20 seconds worth, then only that 20 seconds will be played back as a loop. The eeprom holds a little under two and a half minutes of data when recording 32 channels at a rate of 20 samples per second.

I'm not sure what options I'll provide for this board. Maybe a mode where pressing the play button just plays back one loop of the sequence. This may be useful for stand alone displays that are triggered via a button , PIR sensor, etc.

Comments, questions and suggestions for this project are welcomed. :)
 

ron

Apprentice elf
Joined
Jun 8, 2010
Messages
52
Location
Sugar Land, TX
That sounds very cool David.

I want to make sure I'm reading the function description correctly for recording a DMX sequence.

This assumes you have a DMX stream coming to the board:
1. Press and hold the record button to begin recording.
2. Release the record button when you want to stop recording, or wait for EEPROM to fill up
3. Press the play button to play back the recorded DMX information
4. Release play button to go back to incoming DMX stream

Is that correct, to play back the recorded DMX stream you need to hold down the play button? Any way to start the recorded DMX stream and just have it play over and over in a loop? I think that would be a cool feature.

Thanks for your hard work.

Ron
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
I would envisage that the play button would actually be a relay or other contact in most people's systems. In that case, the recorded stream will play (and loop) for as long as the relay is closed.

You could also just short out the play button input (after recording) so that the board starts playing continuously when powered up.
 

KeithTarpley

New elf
Joined
May 9, 2010
Messages
45
Location
Marietta GA USA
Greetings,,,

Brave man to ask for suggestions...lol...

How about a simple summary of which lines you use on the memory in your device, re which, if any, could be normally paralleled with other memories, and which would need to be switched, if some experimenter wanted to try, at his own risk, to have several different memories to switch between, with a self built daughter board, etc.

One simple digital on/off, that would be a known time output, compared to a playing start time, in order to start off board sound playing in sync...

Keith
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
I may do an updated version with room for the maximum 4 eeproms.

Yes, an open collector output that goes low when playback is in progress seems like a good idea.

The main thing with this one was to get something basic working and improve upon it from there.
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
The DMX recorder board currently samples at 20Hz (50ms timing), but the DMX frames are usually coming in more frequently than that. Now this means the recorded sequence won't match the original stream perfectly, as there will be some time skew introduced. The reason is that each sample may be taken just before or after a change in the DMX stream's data.

For sequences with few (or slow) changes this would not be noticeable, but really fast flashes may come and go without a sample being taken. The result will be loss of detail. Fast fades could also be a problem, as the playback may not have every (intermediate) step and appear a little jerky as a result.

One way around this would be to increase the sampling rate, but this reduces the recording time proportionally. (eg. 25ms sampling would reduce time to ~ 100 seconds) Of course more memory could be added to compensate, but bear in mind eeprom chips this size are about $10 a piece.

Does anyone have ideas on what recording time they have in mind for their application?
 

fasteddy

I have C.L.A.P
Global moderator
Joined
Apr 26, 2010
Messages
6,648
Location
Albion Park NSW
For me i see this being used more for security and accent lighting with slow fades and colour transitions and thus would not see it as an issue. I would not intend to run a sequence of sorts through this as instead i would do this from the computer in which case the DMX player should allow this to bypass through.
 

ron

Apprentice elf
Joined
Jun 8, 2010
Messages
52
Location
Sugar Land, TX
I agree with Eddy. I see this more as a use for accent lighting and security. I don't think the 50ms timing will be an issue for me.

Ron
 

j1sys

There are no rules, and those are the rules.
Community project designer
Joined
May 19, 2010
Messages
242
Location
Knoxville TN USA
David -

As we discussed this morning/evening a switch to flash should solve memory problems.

I have a couple of other suggestions. Just my opinions and ideas:

1) Don't set a sample rate, capture your universe packet and record it with a time stamp (ms delay since last packet) that you can replay with. That way you should be able to reconstruct the time line within 1% accuracy.

2) CPU speed allowing, keep a copy of last universe and compare to incoming. If duplicate, just store a time stamp and a flag saying duplicate packet. You should still resend the multiple packets on output to recreate the stream accurately.

3) Again, CPU speed allowing you could do simple RLE compression and, perhaps, save more memory.

Now for an open disclosure so you don't think I'm a wolf in sheep's clothing. I am planning on doing a Prosumer handheld DMX tester with a graphical display and statistical sampling of DMX streams for verifying working DMX protocols. One of it's many features will include a record/playback option that will be used in testing DMX fixtures and I will be using the above suggestions in my implementation. I don't see this as a direct competition to your project and just wanted to be open on future plans. This will be used more by a lighting technician or even a DIY'r with a big display to troubleshoot the DMX streams.

-Ed
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
Hi Ed,
Thanks for your comments and advice both here and in chat. The flash parts seem ideal for the job at hand, and as you said, are so much cheaper.

I had considered the time stamp (only storing new frames) method, but wanted to get something up and running ASAP so haven't pursued that path yet.

For now, I might just update the PCB to use flash memory, add in some additional I/O and just increase the sampling rate to improve accuracy.

Then I can work on the time stamp storage method. That's the great thing about firmware!

I think this board will be aimed at a different audience to your unit, but look forward to seeing it as it sounds very useful.
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
I've finally had some time to get back to designing the Mk II version, using 2x 16M flash memory chips. This won't be available for this Christmas obviously.

So far it has:
  • DMX input - RJ45 with activity LED
  • DMX output - RJ45 with activity LED
  • Record switch input (button on PCB as well)
  • Playback switch input (button on PCB as well)
  • Output that pulls low when idle
  • Output that pulls low during playback

What else does it need?
 
Top