![]()
|
How short can ramps be? |
Post Reply ![]() |
Page <1234> |
Author | |
ChrisL1976 ![]() Beta Testers ![]() Joined: 01 Sep 2008 Location: Kankakee, Ill Online Status: Offline Posts: 1341 |
![]() ![]() ![]() |
Is the 0.15 seconds Minimum for ramps with version 1.15 or 1.13? I wonder if this is going to be resolved in the new update that supposed to be coming out here shortly.
|
|
Chris
www.lightsonsixth.com |
|
![]() |
|
LightsOnLogan ![]() Admin Group ![]() Joined: 11 Oct 2007 Online Status: Offline Posts: 3187 |
![]() ![]() ![]() |
I just did some testing here. It appears that the hardware treats a ramp down less than 0.15 as "off" and a ramp up less that 0.15 as "on". Given the intended design it makes sense (I don't think D-Light ever thought of using the ramp as a blink). I've always sequenced those by placing two timing marks down and putting an intensity in there, but I can see the advantage (less grid clutter) to having a tool that will take care of sending both commands (protocol wise, this is in fact two commands).
Actually, for the circumstance you describe, I actually prefer to put in a short (0.05 to 0.1) full on command and then follow it up using a 50% to 0% ramp for about 0.35 seconds to 0.5 seconds (depending on the tempo). It gives it the "pop" desired with a very subtle/non-distracting sustain (kinda like audio reverb but with lights). Give it a try... if you like the effect I can probably automate this into a "pop tool" for 2009. There are already plans for other "hybrid tools" like a "LED ramp" tool that will break ramps into 3 ramp commands in an attempt to linearize ramps on LEDs.
|
|
![]() |
|
Pony_God ![]() Senior Member ![]() ![]() Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
![]() ![]() ![]() |
Well, it's not that I want real fade to happen, per-say.
What I want is 'blink', so I have the Eve's following the beat, and so if the beet is BummmBummmBummm, I can just to FadeeFadeeFadee, rather than OnOffOnOffOnOff
4 timing marks vs 7 tming marks.
In places like mini-trees or arches, I can change the fades to intencities since the next 'beat'/'note' whatever is on the next section.
I'll see what 1.0.32 does tonight.
If I had something like a 'blink' tool that let me set intensity and percent of selected area to divide to the on/off, then that would do the same idea as well.
|
|
![]() |
|
BigDPS ![]() Beta Testers ![]() ![]() Joined: 13 Dec 2007 Online Status: Offline Posts: 471 |
![]() ![]() ![]() |
I have had the same problem. If I have a small ramp going from 100 to 0 intensity, it won't light up. However, if it's from 0 to 100 with the same length, it will light up no problem.
|
|
![]() |
|
LightsOnLogan ![]() Admin Group ![]() Joined: 11 Oct 2007 Online Status: Offline Posts: 3187 |
![]() ![]() ![]() |
The data stream for short ramps (all the way down to 0.0154) looks good coming out of Aurora 1.0.25+. The protocol supports the command and it is getting out the serial port. This may just be a hardware limitation.
Honestly, I find it difficult to find a perceptible difference between a 0.02 ramp and an "off" command in the first place. If you are using incandescents then it is going to take the bulb filaments more than 0.02 to cool down. LEDs can respond this fast, but can the eye really tell the difference between "off" and "ramp" at these speeds (we're talking 50 FPS here)?
I have never used a ramp less than 0.15 before, but I wouldn't find support on down to 0.07-ish unreasonable for ramps (I suspect such a ramp would make an LED mimic the cool down behavior of an incandescent but I have never tried it). Every other command should respond on down to 0.0154.
|
|
![]() |
|
Pony_God ![]() Senior Member ![]() ![]() Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
![]() ![]() ![]() |
Anyone know if the ramps should work better with Aurora 1.0.29? |
|
![]() |
|
Pony_God ![]() Senior Member ![]() ![]() Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
![]() ![]() ![]() |
Alright, so I'm back at 1.14 so that I can get short ramps on the controllers, but they still do not display.
Now, I'm still running Aurora 1.02.
I did some testing, and a ramp that is shorter than .15 seconds does not show up at all, anything longer seems to be fine.
So I tested 100% intencity commands, they work down to .03, then it seems as though the TRIACs can't keep up and the lights start to go really funny. By funny, I mean that they might not all turn on, and will most likely not be at 100%.
So, if I _should_ be able to do a ramp .05, what an I doing wrong?
I have all of the controllers set to auto rate, standard 1280 frame, Aurora 1.0.2, fw/ 1.14, and lets call it 100' of cat5. Edited by Pony_God - 20 Nov 2008 at 10:17pm |
|
![]() |
|
Pony_God ![]() Senior Member ![]() ![]() Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
![]() ![]() ![]() |
Do we really need to work with the speed of light to put christmas light up... Do we get time on Nasa's super computer too?
Hum... short shimmer, I'll see how that looks.
|
|
![]() |
|
LightsOnLogan ![]() Admin Group ![]() Joined: 11 Oct 2007 Online Status: Offline Posts: 3187 |
![]() ![]() ![]() |
Send a 100% shimmer for a really short time (the command compresses really well for fast send and if you keep it short you should only get one firing pulse)?
BTW, 0.0154s is a limitation of ramps in the protocol, not of Aurora. The Aurora editor can go down to 0.001 resolution. Playback itself is limited to the frame size settings in playback properties (1280 is the default, which works out to 0.01451s). You can use a smaller frame size (e.g. 512) to gain better resolution, but you risk dropping frames if the COM can't keep up with the amount of commands you are sending in a single frame (I don't recommend messing with it!).
Since we are ducumenting these settings, I might as well touch on "frame offset" as well. The "frame offset" setting compensates for "protocol lag" (the amount of time it takes to send all of the bytes out the COM port). To compensate, the data being sent out is this number of frames ahead of where we actually are at. The default of "2" should be fine for most users. If the lights in the yard seem to come on sooner than in your visualiation, then a lower value can be used. If they seem to come on later then a higher value can be used.
If you are using speakers instead of an FM transmitter, you can compensate for the speed of sound being slower than the speed of light with the frame offset setting as well. Just use one of the negative number settings to make the lights go on later than in the visualizer. Trial and error at the street is best to fine tune this, but if you want the math:
Frame Size / 88200 * Frame Offset * -1 = Delay (in seconds)
The speed of sound is about 1125 feet per second (it varies with atmospheric conditions). If your speakers are 100 feet from the listener, this results in a propagation delay of 100/1125 = 0.09 seconds (very noticable). With a frame size of 1280, this works out to about -6. Add a couple in for protrocol lag and a setting of about -4 will time align the speakers with the lights. Edited by LightsOnLogan - 12 Nov 2008 at 12:48pm |
|
![]() |
|
Pony_God ![]() Senior Member ![]() ![]() Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551 |
![]() ![]() ![]() |
That's about what I want... Kind of a sudo "blink" command.
|
|
![]() |
Post Reply ![]() |
Page <1234> |
Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |