Re: X10 TM751 and "runaway" dims???

[Charles Sullivan <cwsulliv@xxxxxxxxxxxx>]

Dave,
Ouch! I knew that, but I guess my thoughts were fixated on the
dim command.  Thanks for snapping me back to reality, and for the
chip reference.

Regards,
Charles Sullivan

On Sun, 04 Dec 2005 11:41:17 +0000, Dave Houston wrote:

> No. The RF code includes address and function in one code. For example...
>
> A1 ON 01100000 00000000
>
> The RF encoding is described (partially) in the CM17A documentation. The
> payload bytes are the same as the 3rd & 4th bytes sent to the CM17A with the
> RF protocol being identical to the NEC IR protocol. The old rectangular
> keychain remote used a µPD6121 NEC chip to generate the codes.
>
>      www.cpcares.com/pdf/UPD6121G-001.PDF
>
> Each of the two payload bytes are followed by their bitwise complements (B1
> 'B1 B2 'B2) and the bits are sent in reverse order. See p5 of the PDF.
>
> Charles Sullivan <cwsulliv@xxxxxxxxxxxx> wrote:
>
>>Many thanks Dave.  Your informative and detailed responses
>>are much appreciated.  Am I correct in assuming that the
>>encoding of the 310 MHz RF pulses is the same as the encoding
>>of the corresponding PLC?  I.e., if the pulse train for the PLC
>>is "1110011010...", do the 310 MHz RF pulses follow the same
>>pattern?
>>
>>Regards,
>>Charles Sullivan
>>
>>On Sat, 03 Dec 2005 12:51:00 +0000, Dave Houston wrote:
>>
>>> 4-5 years ago I conducted extensive tests using a Ming 310MHz RF transmitter
>>> driven from the LPT port of a machine running W95 so I could control exactly
>>> what RF was being transmitted.
>>>
>>> I sent a single RF code and using a CM11A determined that the TM751 and
>>> RR501 sent 3 contiguous dims to the powerline resulting in a 12% step. Three
>>> contiguous dims (12%) take 550ms (66/120) to transmit as PLC. Each
>>> additional dim takes 183.33ms (22/120). (If a PLC signal follows a previous
>>> dim/bright by no more than 5 idle half cycles it will result in an
>>> additional 6% change.)
>>>
>>> Starting at the end of the 105ms RF code I sent a continuous 1kHz modulated
>>> 310MHz RF signal for ~1000ms, varying the duty cycle until I found a burst
>>> width that would cause more dims to be sent to the powerline. For the TM751
>>> this was 60% (~600µs on, 400s off). I then reduced the duration of the 1kHz
>>> signal until I found the point where one extra dim was triggered. This was
>>> at ~535ms after the start of the RF code or about 430ms after the 40ms gap.
>>> Another dim was triggered at ~735ms and ~935ms after the start of the RF
>>> code. These timings were very repeatable.
>>>
>>> With the RR501 a 40% duty cycle (400µs on, 600µs off) present ~200-300ms
>>> after the start of the RF code would trigger an additional dim. The trigger
>>> point was nowhere near as repeatable as with the TM751. What is notable is
>>> that any device sending 5 copies of the RF code (e.g. HR12A) would trigger
>>> an extra dim.
>>>
>>> I did not check to see just when the PLC code started in relation to the
>>> start of the RF code. The CM15A waits until near the end of the 40ms gap
>>> before it starts sending PLC but I do not know about the TM751 or RR501.
>>> Also, I incremented the duty cycle of the 1kHz modulation in 100µs steps.
>>> The TM751 did not respond to a 50% duty cycle but did to 60%. I did not try
>>> to refine it beyond that.
>>>
>>> What this means is that if the data out line of the RF receiver section of
>>> the TM751 or RR501 is high for sufficient time at certain points after an
>>> initial RF dim signal an extra dim will be sent.
>>>
>>> The RF section uses a data slicer circuit. The demodulated RF data envelope
>>> is applied to one input of a comparator with the other input having a
>>> capacitor that charges to 1/2 the average amplitude of the signal. When the
>>> signal is greater than the charge on the capacitor the comparator output is
>>> high, otherwise it is low. In the absence of an RF signal the TM751 RF
>>> receiver section outputs continuous noise pulses. Most are of short duration
>>> with an occasional longer one. It may be that inductive coupling of the PLC
>>> signal can result in longer noise pulses. I did not try putting a scope on
>>> the data out line to see what was present during an endless dim episode.