Re: Rosetta progress report

[nobody@xxxxxxxxxxxx (Dave Houston)]

There is one issue that I'm still unsure about. I asked Bruce to see if JDS
could enlighten me about how they handle the TW523 but they only referred me
to an explanation of the X-10 powerline protocol. I'm fairly familiar with
how the Ocelot does things so I'll use it to illustrate. I think that
whatever I do for the Ocelot should also work for other controllers using
the TW523. Also, the problems will only occur in systems with a mix of X-10
and other PLC technologies where a TW523 will be used to relay some commands
to the powerline. With no TW523 sending PLC the issue goes away.

When the Ocelot sends a code, roZetta (there's been a spelling change - I'm
too old and frail to take on Steve Jobs) will have to wait for one complete
copy in order to decide what action to take. Since the Ocelot has collision
detection, it listens during the second copy of the code to see if there are
any ONEs where there should be ZEROs. This is due to the fact that the TW523
actually reports the powerline activity on a delayed basis, reporting the
first copy of the code (as seen from the powerline) during the Ocelot's
transmission of the second copy.

Since roZetta will also be operating on a one code delay basis, the TW523
will not report anything during the time the Ocelot is sending the second
copy and listening to detect collisions. roZetta will have to feed the
Ocelot an image of the first copy (or merely echo the second as the Ocelot
sends it). Whether the defined action is to send to the TW523, send to
another interface or to do nothing, roZetta will always need to feed the
Ocelot a clean copy of the code. If not, the Ocelot will think there was a
collision and automatically retransmit.

However, in the event of a collision, the Ocelot, having been told that all
is hunky-dory might be sending another code, especially if the collision
occurs during the address code preceding a function code. It could get ugly
if the Ocelot is sending a series of addresses ahead of a function or is
sending a macro although this could be alleviated by moving the macro from
the Ocelot to roZetta so the Ocelot only sends the first code as a trigger
and roZetta handles sending the macro to the TW523.

I'm not sure there's a solution other than merely eliminating X-10 error
detection by always telling the Ocelot (or other controller) that "all is
well" but am open to suggestions. I'm most concerned about instances where
the X-10 code is from a security panel. Perhaps, roZetta could be instructed
to give priority to a limited set of X-10 codes and to always try
retransmitting them a certain number of times. Of course, it would be better
to just have roZetta respond to those codes by sending with a more reliable
PLC technology.