Author Topic: RR501 Dim Loop  (Read 1911 times)

Jeff

  • Administrator
  • Hero Member
  • *****
  • Posts: 199
    • Owner, JV Digital Engineering
RR501 Dim Loop
« on: September 10, 2013, 10:23:29 AM »
Some of you probably know I have been working on a new version of the simple plug-in XTBR.  This version will not have the X10 Boost input on the cover, and will instead directly boost the strong signal from an X10 transmitter plugged into a nearby outlet on the same circuit.  I’m in the process of testing that code now.

The old RR501 dim loop came up again.  This time I had the storage scope monitoring the powerline signals so I could see what was going on.

When a dimmer button is kept pressed on a Maxi Controller, it will transmit a continuous series of those commands without any gaps between.  A PalmPad working through the RR501 or TM751 works differently.  When the PalmPad dimmer button is kept pressed, the RR501 sends packets of three half-doublets of that command, with about 260 milliseconds between each packet.  In the “smart dim” mode, the XTBR or XTB-IIR will repeat the second and third half-doublets, which causes a full-step change in brightness.  (A single half-doublet is a micro dim, which changes the brightness only about half a percent.)

When the smart dimmer mode in the XTBR or XTB-IIR is disabled, it responds to those commands like any normal commands by receiving the first half of the doublet, and repeating that in bit-sync with the second half.  Because there is another half-doublet tacked onto the RR501 sequence, that is received and repeated in the gap following that third half-doublet.  My guess is that is the reason for the 260mS gap.

If the repeated signal strength is in a certain range, the RR501 apparently gets stuck in a loop, sending the three half-doublet sequences continuously.  That may be why some folks have reported that a single dim or bright command causes the lights to ramp to either off or full brightness.

It is interesting that moving the RR501 to a different location where it received a stronger repeated signal prevented it from becoming stuck in the loop.

Jeff
X10 automation since the BSR days...

Brian H

  • Hero Member
  • *****
  • Posts: 169
Re: RR501 Dim Loop
« Reply #1 on: September 10, 2013, 12:47:48 PM »
Interesting findings.
I wounder if different version RR501s may act differently.
I have an old DC: 02F23 with a H10137E PCB and P10283E Part Number on the controller IC.
I also have a recent DC:10G28 with a =10432K PCB and a P10308C Part Number on the controller IC.
« Last Edit: September 10, 2013, 01:01:38 PM by Brian H »

Jeff

  • Administrator
  • Hero Member
  • *****
  • Posts: 199
    • Owner, JV Digital Engineering
Re: RR501 Dim Loop
« Reply #2 on: September 10, 2013, 02:19:30 PM »
Jeff
Interesting findings.
I wounder if different version RR501s may act differently.

Good point.  I tested 4 different date codes, and they behave differently.

My "test" RR501 (actually an X10 Pro PAT01) has date code 03I39, and it exhibits the loop described before.

Two different Leviton 6314 (same as the RR501) do not exhibit the repeater loop, but they will often lock up by themselves after receiving a bright or dim command, and must be unplugged to restore operation.  They are date codes 0K10V0 and 0I40V0.

I also have a bunch of newer RR501s that I purchased about a year ago when the supply was running out.  I checked one with date code 11B08, and it does not exhibit either the repeat loop or the lock up.

My test RR501 is at least a decade old, and I think the Leviton units are pretty old too.  It looks like the problem may have been fixed in the newer units.  Or perhaps the newer unit just exhibits the problem at a different signal level.

Jeff
X10 automation since the BSR days...

 

succession-resounding