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.
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.
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.
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...
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?
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.
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.