translation question

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?

Reply to
Dave Houston
Loading thread data ...

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.

Reply to
JS

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?

Reply to
Dave Houston

To add a bit of background, the BX24-AHT was designed so users could decide what action to take in response to X-10 RF commands. Anyone interested in this discussion who is not already familiar with the earlier device can read the users manual which Jeff Volp has on his web site at...

formatting link
Most of the X-10 RF commands include both the Address and Function in a single code which, measuring from the start of the first copy of the RF code, takes T2:06 06 'A1 to TW523

02/25/06 09:02:27
Reply to
Dave Houston

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.