The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[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

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.