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: Re: xPL/xAP an alternative to C-Bu$ ?


  • Subject: RE: Re: xPL/xAP an alternative to C-Bu$ ?
  • From: "Kevin Hawkins" <lists@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 20 May 2004 23:25:04 +0100



> -----Original Message-----
> From: James Mitchelmore [mailto:james@xxxxxxx]
> Sent: 20 May 2004 21:58
> To: ukha_d@xxxxxxx
> Subject: RE: [ukha_d] Re: xPL/xAP an alternative to C-Bu$ ?
> Kevin Hawkins mentions 'custom lighting' support from a
> new version of the homevision ROM, would this help to
> produce a nice interface to DMX?

Hmm - not sure. Within the new HV ROM is a lighting table that maintains
state information. Each time that HV changes this data it can call your
routine with various parameters passed that detail the new intended state
of
the device. You can use the existing table data along with this new
information to calculate what to send out to alter the light in question.
Normally this would be via a serially attached 'controller' (or direct
serial attach to the lighting interface) as a sequence of characters,
however it could also be done via i2c, infra red or using the parallel
ports
if you needed. I guess then you could do whatever was necessary to ensure
data was sent repeatedly / periodically if that was needed too but HV does
have some issues with concurrent handling of events that may cause
stuttering or even worse cause it to miss incoming hardware events on its
ports or not receive serial data completely/correctly. This is because the
system is not interrupt driven and X10 transmission for example can cause
the same things.  However you could probably make a little 'intermediate'
processor that took a lighting command and then did 'its thing' in terms of
handling the continual interaction with DMX . The external C-Bus hardware
does exactly this and therefore offloads the C-Bus decoding and state
maintenance from HV.

The reverse needs to be handled too ie the decoding of DMX data back into a
format that can synch HomeVisions state table and generate events for load
changes. Again the C-bus hardware controller does this as it effectively
just directly updates HV's state table to match C-Bus. There are a few
other
things to watch - HomeVision for example does not normally send commands
out
to a device to change its state if it already believes it is in that state.
X10 has some 'force'  commands to achieve this. Also if you do relative
dims
then you need to accurately know the current states in order to calculate
the new ones. C-Bus for example does not support 'relative dim' so you
can't
ask a C-Bus light to raise by 10% or 26 units. Instead I calculate the new
level by adding the relative dim to the current known level and issuing an
absolute dim command.

So yes I believe the new ROM may help you substantially, particularly if
the
Maplin controller handles the 'tickle' require to keep DMX happy. If not I
think a little hardware intermediate DMX processor might be the best option
performance wise.

Kevin




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.