Looks nice,
I want something like this for my garden lights.
Now for a firmware guru...
Cheers
Phil
I want something like this for my garden lights.
Now for a firmware guru...
Cheers
Phil
Standalone DMX Recorder/Player devices
- Thread starter riri7707
- Start date
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.
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.
(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!
(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!
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.
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
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
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
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.
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
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
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
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.
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.
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 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.
ron
Apprentice elf
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
Ron
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
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
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.
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.
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:
What else does it need?
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?