Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JeffVolp]

This is another problem I had been chasing in my signal meter development.  While it has been displaying commands sent by Maxi Controllers correctly, the up and down arrows on a PalmPad have been displaying Bright (or Dim) followed by a "M Hail Request".

I had been chasing this in firmware, thinking there was a bug somewhere.  However, my storage scope captured exactly that data pattern.  To confirm, I monitored the powerline with HomeVision connected to a TW523.  (The smart dim feature in the XTB-IIR automatically changes that trailing M Hail Request to a final bright/dim command.)

I remember reading some time ago that when X10 dimmer modules see concatenated bright/dim commands, they continue doing what the first command in the sequence was.  If that was a DIM command, they will continue to dim, regardless of what the present command actually is.  So, this may be nothing more than an interesting "feature".

Two different Leviton branded TW751 transceivers both ended with the "M Hail Request".  Two different PalmPads worked exactly the same.  It is interesting that the new X10 Icon remote displayed double DIM comands about half of the time, so this may be related to the RF data format.  Substituting a Leviton branded RR501 transceiver for their TM751, the PalmPad bright or dim was displayed correctly all the time.  A new X10 TM751 that I received as part of a recent package deal also worked correctly.

So, this problem is either unique to the Leviton branded TW751, or it has been fixed in the newer version.

(In case anybody wonders, there was no XTB or XTB-IIR connected during this testing.)

Jeff

[Brian H]

Interesting.

My new TM751 also had the same RF receiver daughter card in it as the CM15A.
Does much better than both the CM15A with the short antenna and an old TM751 with a discrete RF board parts.

[Boiler]

Hi Jeff,

You got my curiosity up with that tidbit.  I dug around and found my old Leviton HCPRF transceiver.  No sign of a tag on command reported by my Testerlinc, the CM15a, or my ISY.  It's probably a far newer unit than your TW751.

You have to love it when you make these "discoveries" while trying to debug firmware.  Apparently Murphy has decided to do some vacationing in St. George.

I had been chasing this in firmware, thinking there was a bug somewhere.  However, my storage scope captured exactly that data pattern.  To confirm, I monitored the powerline with HomeVision connected to a TW523.  (The smart dim feature in the XTB-IIR automatically changes that trailing M Hail Request to a final bright/dim command.)

You know you've put in your share of sweat equity when you can "read" X10 bit patterns on a storage scope.

[JeffVolp]

I dug around and found my old Leviton HCPRF transceiver.  No sign of a tag on command reported by my Testerlinc, the CM15a, or my ISY.  It's probably a far newer unit than your TW751.

My Leviton "TM751" is the older boxy style identical to the X10 TM751.  The Leviton part number is 6314.  They were bought about a decade ago.  The Leviton "RR501" (also called a 6314, but obviously a different unit) is that same vintage.  Other than this anomaly, they work fine.

Jeff

[JeffVolp]

Here is a followup to my prior report:

This appears to be an issue when the RF signal drops down to a marginal level.  The "M Hail Request" disappeared when I went into the other room with the PalmPad.  It also disappeared when the TM751 was moved into my lab.  The fact that the TM751 returned the entire bright/dim command string correctly about half the time when using the X10 Icon remote may mean it transmits a stronger signal than the PalmPad.  And the RR501 may be slightly more sensitive than the TM751 because it produced the correct command string all the time.

Note that in all cases the TM751 did begin the transmission with the correct bright or dim command.  With a weak RF signal, the command string would end with a "M Hail Request".  However, even though the last command in the series was incorrect, a dimmer module would respond correctly to the bright or dim command.  So, this is probably not something that would have any impact on actual system operation.

Jeff

[JeffVolp]

This "feature" of the TM751 just burnt me again.  I had been tracing a collision report from the forthcoming X10 signal meter whenever I sent a DIM from the PalmPad.  I was testing repeated signal levels, so my XTB-IIR was on line.  Parsing through the traces on the storage scope, the first TM751 command was "O-DIM", which the XTB-IIR dutifully repeated.  Then the TM751 switched to sending the "M-Hail Request", causing a collision with subsequent repeated "O-DIM" commands.

The X10 dimmer module doesn't seem to care, as it ramps up and down just fine, regardless of what the subsequent commands are (even if they are invalid due to a collision).  Apparently, they don't even have to be on the same housecode.  So this might be causing some of the strangeness occasionally reported here.

I thought about modifying the meter to ignore bright and dim commands when checking for collisions.  However, these are indeed collisions due to a flaw in the TM751, and I think they should be reported as such.

I repeated this test with a RR501, and it works just fine (no collisions reported).

Jeff

[Dan Lawrence]

Jeff,

Reading this, I wonder if the collisions were due with the known "impoliteness" of the TM751?  That could be why the collisions don't appear with the RR501.  I junked my two TM751s several years ago in favor of RR501s for that reason.

[JeffVolp]

Reading this, I wonder if the collisions were due with the known "impoliteness" of the TM751?

No, what I recorded on the storage scope was the TM751 sending the first bright/dim command correctly, but changing that to "M Hail Request" at the first concatenated bright/dim command.  This is true whether or not the TM751 was running barefoot (no repeater in service).  This issue seems to be related to how close the transmitter is to the TM751.  In a prior test, either moving the PalmPad close to the TM751 or moving the TM751 into my lab eliminated the problem.  Interestingly, today the TM751 WAS in my lab, and it still exhibited the problem most of the time.  So, it may also be influenced by something outside my control, such as external RF interference.

As you probably know, bright/dim commands deviate from the standard X10 protocol in that there is no 3-cycle gap to separate those commands when sent in a sequence.  Back some time ago, I read that X10 modules only check for the next start pattern after a bright/dim command to determine whether it should respond with another step.  This testing confirms that after the first bright/dim command, the module does not care about the content of subsequent concatenated commands.

Jeff

[Boiler]

No, what I recorded on the storage scope was the TM751 sending the first bright/dim command correctly, but changing that to "M Hail Request" at the first concatenated bright/dim command.  This is true whether or not the TM751 was running barefoot (no repeater in service).  This issue seems to be related to how close the transmitter is to the TM751.  In a prior test, either moving the PalmPad close to the TM751 or moving the TM751 into my lab eliminated the problem. 

Hi Jeff,

I had intended to post a picture of my suggested solution.  Unfortunately my camera battery is dead.  The solution involved close coupling the palmpad and TM751 with some duct tape (yes that's a joke).

Seriously, I understand the value of "robustness" testing but this little item seems to be costing you valuable time.  I have several TM751's that I do not use any longer and would be happy to ship one to you.  That is, of course, as long as you don't mind sticky duct tape residue.

Boiler

[JeffVolp]

I have several TM751 and RR501 transceivers available in both the X10 and Leviton flavors.  I use the Palmpad/transceiver loop with the XTB-IIR off line to get a weak signal back to my workbench for testing.

Using a variety of modules is an essential part of testing.  I had identified this issue a couple of weeks ago, but forgot that it could also manifest itself by producing collisions.  Actually, that was a handy way to verify the meter collision detector is doing the job.

FYI, many "little items" cost a lot of time.  One major time sink has been trying to come up with a robust way to identify noisy devices.  I found that some devices that generate bad start codes actually produce relatively little "detectable" noise.  For example, the Cellet charger looks awful when viewed on an analog scope with persistence, but on a single trace digital scope, the random nature of its regulator hits only occasional X10 sample windows.  It is enough to reek havoc on X10 traffic, but difficult to measure.

Jeff

[dave w]

Hi Jeff,

I had intended to post a picture of my suggested solution.  Unfortunately my camera battery is dead.  The solution involved close coupling the palmpad and TM751 with some duct tape (yes that's a joke).

 That is, of course, as long as you don't mind sticky duct tape residue.

Boiler

"Close coupling"...oh gosh!      gasp!    chortle!     someone defib me!