[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: xPL/xAP an alternative to C-Bu$ ?
- Subject: Re: xPL/xAP an alternative to C-Bu$ ?
- From: "David Buckley" <db@xxxxxxxxxxx>
- Date: Thu, 20 May 2004 21:38:42 -0000
--- In ukha_d@xxxxxxx, "James Mitchelmore" <james@m...>
wrote:
> given that I've acquired some 4 x 5a racks for 30gbp each
Oh yes, very nice.
> The issue I'm currently wrangling with is the best method
> of control.
Yaas...
There are two big problems.
a) DMX512 dimmers need to be driven with data continuously. They
are dumb slaves, and all they do is what you tell them. There is
none of this "fade to 43% over a period of 18 seconds" which (for
example) the CBus dimmers do. If they stop getting data, most just
hold at the current level, some fade to black over a few seconds.
Corollory of this - if you want smooth fades you need a controller
that is constantly outputting DMX512 data, and is doing the fade
logic itself. Therefore, a controller that occasionally pauses to
do something else is going to disturb your fade bigtime. This is my
concern with HV lighting control - it has traditionally be aimed at
X10 devices, of which some types can do timed fades reasonably well.
I dont know if the HV upgrade will "do the business", for DMX512
lighting; I'm (deliberately) only fleetingly in contact with the
thing. It is a very capable whole house controller. I dont know
(though doubt) it will output DMX512, and even if you use the Maplin
board (which I have admired from afar) to translate HV serial to
DMX512 you still need to keep the updates rolling in during fades or
it will look lumpy. I dont know if HV can do that. I seem to
recall that executing certain processes on a HV "stall" the
controller. If that happens in the middle of a scene fade it will
look terrible. Hopefully, a HV owner will be along soon :-)
Using the tightest timing possible, with a full load of 512
channels, a DMX512 system can do about 44 updates per second. To do
fast fades (under a couple of seconds) you need to be somewhere near
that. DDIM16 doess 40 updates per second. I originally thought 20
would do, but that was horrible on short fades. 40 updates a second
on a PIC at 16MHz is no problem at all, even doing other things and
writing in C.
b) User interface. WAF. This is always an issue. When I designed
the DDIM16 unit, I was originally going to grab a lutron keypad
(which looks excellent) and reverse engineer its interface protocol
(its RS485) to control DDIM16. Thats why there was a RS485 port...
Most home built user interfaces are ugly.
UKHA_D Main Index |
UKHA_D Thread Index |
UKHA_D Home |
Archives Home
|