Re: translation question

[nobody@xxxxxxxxxxxx (Dave Houston)]

"JS" <onlinejds@xxxxxxx> wrote:

>
>Dave Houston wrote:
>> It will simplify things for the translators if the X-10 codes which are to
>> be translated to/from Insteon or UPB are segregated by housecode with any
>> specific housecode limited to 100% X-10 devices or to Insteon and/or UPB
>> devices.
>>
>> Does anybody see a major problem with this?
>>
>> Also, I'm not very familiar with the capabilities of the various high end
>> controllers like JDS, HomeVision, HAI, etc. Can they be programmed to send
>> X-10 addresses and functions independently or must they always send both the
>> address and function codes?
>
>JDS controllers (Stargate, TimeCommander) support sending and receiving
>address only, function only, as well as complete address and function
>codes and preset dim commands (standard and extended code types).
>Limiting the translation to complete housecodes as suggested could
>impact existing users.  As one migrates from X-10 to Insteon (or UPB),
>there will be a mix of both technologies.  The problem locations would
>most likely get changed out first.  In many cases, users will opt to
>keep the working X-10 devices in operation (until they fail).  If only
>one or two locations are problematic on a given housecode, the user
>would be forced to replace all X-10 devices on that housecode with
>Insteon or UPB.  It would be best if roZetta could be programmed on an
>individual address basis, allowing a mix of X-10 and other technologies
>within a housecode.

I understand that it might be inconvenient but it may be necessary. I think
we may have a glass half empty, glass half full thing (or one of us is
looking up through the bottom of the glass while the other is looking down
from above ;). In the case you cite, the user can just assign the new
Insteon or UPB devices to an unused housecode and change the JDS program to
reflect that.

Ironically, the problem occurs with codes that do not need translation. If
all housecodes are in play, the translator has to do a lookup (of a much
larger table) merely to find no translation is needed before sending the
code to the powerline. Of necessity, commands to be sent via the TW523 will
be delayed (assuming standard codes) for 22 half cycles. Given the lethargic
speed of X-10, I'd prefer to not increase that delay significantly. The PIC
based (roZetta) translator will have a 64K EEPROM and will have about 35000
instruction cycles between the last bit of the first code copy and first bit
of the second copy. The ZX-24 based (Transmogrifier) will have a much
smaller EEPROM (exact size is yet to be determined) and fewer than 600
instruction cycles to do the lookup.

If the transmit/translate decision can be made as soon as the housecode is
received and the lookup table is limited, it makes things much, much easier.

Also, while I anticipate that most multiple commands (i.e. macros) will be
moved to the translator, the original controller will need to delay sending
further commands until the translator has had time to process the macro. In
the case of X-10 PLC commands, the delays may be lengthy. Is this going to
be manageable from the original controllers?