X10 Community Forum
🖥️ActiveHome Pro => ActiveHome Pro General => Topic started by: jclarkw on January 09, 2013, 07:12:43 AM
-
I want to eliminate RF interference between my new CM15A Computer Interface/Controller and my previously installed TM751 Transceiver. (The range of the CM15A receiver is too limited, as others have found, so I need to keep the TM751 in order to use my HR12A Remote.) X10 Tech Support referred me to http://forums.x10.com/index.php?topic=10807.msg61565#msg61565. When I opened the CM15A box, I saw not one but two piggy-back "daughter" boards soldered into the main controller board. The one connected to the external antenna is presumably the receiver. The other, connected to another antenna wire inside the box, is presumably a transmitter that can be used with advanced ActiveHome Pro plugins to control other RF devices. In addition to cutting the +V input wire to the former (receiver) daughter board, is there any downside to cutting the same wire to the latter (transmitter) daughter board? -- jclarkw
-
If you still want to use RF commands to trigger thing in the CM15A but not to have it transceive RF back to the power lines.
In the Tools tab. Hardware configuration. Try checking the Transceived House Codes to NONE.
You may want to do some searching here. As there are a few users that have disabled the RF receiver of the CM15A.
If it still uses the same RF receiver board, as my older date code CM15As. The chip on it has a disable logic input pin. Has to be pulled high but can be done. I did one as an experiment.
There is some information on the CM15A on Dave Houston's web site and the FCC Database has CM15A photos, parts lists and schematics.
http://www.davehouston.net/cm15a.htm
http://transition.fcc.gov/oet/ea/fccid/
Grantee B4S
Product Code CM15A.
-
One more point.
The schematic on Dave Houston's site shows four added bypass caps on the logic chips and power supply filters.
Many find it makes the CM15A much more stable.
-
If you still want to use RF commands to trigger thing in the CM15A but not to have it transceive RF back to the power lines...
You may want to do some searching here. As there are a few users that have disabled the RF receiver of the CM15A.
No, I want to eliminate the RF entirely, since I have no use for it and it appears to cause serious interference, especially with the activity log in ActiveHome Pro.
After studying the thread quoted in my first post, I have performed the surgery indicated there. It has indeed eliminated the interference problem, but I have noticed other changes that logically should not be related: The activity log in ActiveHome Pro no longer distinguishes between direct commands from ActiveHome Pro and macro-initiated commands; it now indicates all non-received events as "Transmit." Also the activity log has become even more unreliable than before the surgery (see also my post at http://forums.x10.com/index.php?topic=27918.0.
-
The schematic on Dave Houston's site shows four added bypass caps on the logic chips and power supply filters.
Many find it makes the CM15A much more stable.
Yes, I saw that, but it's a much taller order than simply cutting wires. Maybe I'll try it in the future...
-
Well I did a few tests with my modified CM15A where I can switch the RF Receiver ICs enable pin high and low to disable or enable the receiver.
With the receiver enabled there is a constant static signal. Like a unsquelched two way radio. To the controller IC RF Received Input Pin.
When the receiver is disable but still has +5 power. The signal to the controller RF Received Pin is High.
Memory here as I didn't unpack the scope. When receiving an RF signal the data pulses low and then when done. Goes back to random static pulses.
My thoughts are. With the +5 volts removed. The controller IC is seeing a constant low and trying to decode data that should be there.
I tried a small test. With the RF disabled and a power line signal was received. The Activity Monitor showed a receive entry not an RF receive entry.
-
...When the receiver is disable but still has +5 power. The signal to the controller RF Received Pin is High...
My thoughts are. With the +5 volts removed. The controller IC is seeing a constant low and trying to decode data that should be there...
OK, so it sounds as though I had better disable the receiver (or tie the "controller RF Received" pin high -- is that easier or harder to do?) rather than removing power. As I recall, you had specified what pin was used to disable the receiver, but I'm not sure if it would be the same in the latest batch of resurrected CM15A's. Do you have any advice here?
Also, have you any thoughts on the effects of removing power from the transmitter? I guess that should be benign, since one would expect no hand-shaking with the controller... -- jclarkw
-
What is the silk screened part number on the receiver board?
Is the IC on the receiver board a RX3310?
The FCC Schematic shows a 20 pin RX3310 IC though my PCB uses a 18 pin IC.
Pin 9 is the Disable Pin with both 20 and 18 pin style ICs.
-
Well I did a few tests with my modified CM15A where I can switch the RF Receiver ICs enable pin high and low to disable or enable the receiver...
Brian H. -- Looking back at your old post, http://forums.x10.com/index.php?topic=10807.msg61640#msg61640, I see that you explain the procedure as follows:
"The receiver boards IC RX3310A has a Disable Pin on it.
There is some confusion between the Schematic on the FCC web site and the one in my CM15A. The schematic shows a 20 pin IC and mine has the 18 pin version.
Anyway pulling the disable Pin High through a 100K resistor; for safety to the chip; to the +5 volts disables it. Pin 9 of both the 18 pin and 20 pin ICs is the disable pin and it has a very small pad with a unused solder hole on it."
I'm confused: Is it the RF receiver (daughter board) or the controller IC (18 or 20 pin DIP) that has the disable pin? The schematic that I found on davehouston.org shows all but pin 10 of the 18-pin DIP connected to something already. The receiver board is shown as having only 4 pins, all of which are connected. The latter pins are labeled Vss, RF Out, Vcc, and RFin (whatever that means), none of which is shown as connected to an external antenna. None of the pins on either the daughter board or IC is labeled "Disable" or anything like that.
I had cut the lead on **each** daughter board in my CM15A that was labeled +V. I haven't re-opened my box yet -- waiting for more guidance... -- jclarkw
-
What is the silk screened part number on the receiver board?...
Sorry. You sent this while I was typing. I will open the box again and try to answer your questions...
-
The RF Receiver Daughter Card is the one I was referring to.
All three schematic are on the FCC Database web site.
Dave has the Main Controller Board schematic on his site. The FCC has all three.
There is no Disable Label on the Receiver Daughter Card just an unlabeled pad and it does not connect to the main board.
Another way would be remove the RF Receiver Daughter card and just solder a 10K resistor from the +5 VCC Pad to the Received Data Out Pad on the main board.
-
Well I did a few tests with my modified CM15A where I can switch the RF Receiver ICs enable pin high and low to disable or enable the receiver.
With the receiver enabled there is a constant static signal. Like a unsquelched two way radio. To the controller IC RF Received Input Pin.
When the receiver is disable but still has +5 power. The signal to the controller RF Received Pin is High.
Memory here as I didn't unpack the scope. When receiving an RF signal the data pulses low and then when done. Goes back to random static pulses.
My thoughts are. With the +5 volts removed. The controller IC is seeing a constant low and trying to decode data that should be there.
I tried a small test. With the RF disabled and a power line signal was received. The Activity Monitor showed a receive entry not an RF receive entry.
The data output pin will always have continuous short noise pulses - that's the nature of the data slicer (i.e. the comparator circuit shown in the receiver data sheet http://www.allparts.co.kr/pdffile/pdffile_001/3274.pdf). On a 'scope the input to the comparator will resemble the 'scope shots shown at http://davehouston.org/rf-noise.htm. It is extremely unlikely that the CM15A microcontroller responds to anything other than valid X10 RF signals at the output.
Adding the decoupling capacitors might improve things but I think the OP is chasing gremlins.
There can be PLC collisions caused by both receiving the RF and sending it as PLC but the CM15A should detect this, then back off and retransmit after the line is clear.
The best course of action would be remove power from the RX3310 receiver and rely on the TM751 or get rid of the TM751 and improve the CM15A reception as detailed here.
- http://davehouston.org/ImproveCM15A.htm
Range measured in hundreds of feet is possible.
A distributor is currently conducting range tests and looking into where to manufacture the antenna hardware for the CM15A. TM751A and RR501. Kits should be available soon. It could have been available earlier but a community organizer who agreed to conduct range tests accepted about $300 worth of my hardware and then stopped responding to my emails - live and learn. I've been totally disabled for the past 20 years and am unable to supply these myself beyond a few prototypes.
-
Any idea what happens if the +5 to the receiver is removed and the output to the controller chip is sitting low and not randomly pulsing low?
When I tie the Disable pin of the RX3310 High the output to the controller is also a constant High.
-
I want to eliminate RF interference between my new CM15A Computer Interface/Controller and my previously installed TM751 Transceiver. (The range of the CM15A receiver is too limited, as others have found, so I need to keep the TM751 in order to use my HR12A Remote.)
I'm guessing that the "interference" to which you are referring is when both the TM751 and the CM15A receive the same RF signal, and both try to act on it.
Have you tried (as was suggested here) settings the "Transceived House Codes" to "NONE"? That *should* prevent the signal from being acted upon twice.
Another thing to try might be the CM15A "Antenna Reflector" mod. Simply put, you secure an 18.5-inch wire alongside the CM15A's antenna, WITHOUT an electrical connection between the two. I used two strips of masking tape the first time, and it worked great. The longer wire (I *think* it is a half-wavelength) helps bring in the signals, and "funnel" them toward the CM15A's antenna. I've used this mod on my own units for a few years, and it have improved RF reception greatly. You might be able to improve it enough to the point where you can eliminate the TM751. It is certainly worth a try.
-
Any idea what happens if the +5 to the receiver is removed and the output to the controller chip is sitting low and not randomly pulsing low?
When I tie the Disable pin of the RX3310 High the output to the controller is also a constant High.
The microcontroller is going to ignore anything that does not begin with the X10 STX signal (9ms pulse/4.5ms space) or the similar but shorter start sequence from the camera remote. Then it will only act on valid codes that follow the STX sequence.
- http://davehouston.org/rf.htm
- http://davehouston.org/cr14a-rf.htm
-
Personally. I think Noam's idea of getting the transceivers out of the picture and enhancing the CM15As reception. Would be a better way to go.
Thanks for your insight on such things Dave.
-
Brian H. -- To answer your questions:
>>What is the silk screened part number on the receiver board?<<
"H1124SA
[symbol]94V0
E340835
JDM-01D
1188"
>>Is the IC on the receiver board a RX3310?<<
"HiMARK
RX3310A-LF
1EJ2403"
It has 18 pins and (if I'm counting correctly -- looking from the TOP and counting CCW from the corner dimple) pin 9 is apparently the only open pin.
The **other** RF daughter board (transmitter? -- connected to a wire running around the inside of the case), from which I **also** removed +V, says "H11157B." It has a round can "HD/R310M" with an indeterminate number of pins mounted on it.
So I think I understand what you want me to try: Reconnect +V to the receiver board, connect a 100K resister between pin 9 of the DIP and +V, and see if the activity log improves. Right? -- jclarkw
-
The microcontroller is going to ignore anything that does not begin with the X10 STX signal (9ms pulse/4.5ms space) or the similar but shorter start sequence from the camera remote. Then it will only act on valid codes that follow the STX sequence.
Dave -- I hear what you are saying, but then you have to explain why the activity log changed when I disconnected +V from **both** daughter boards. -- jclarkw
-
Personally. I think Noam's idea of getting the transceivers out of the picture and enhancing the CM15As reception. Would be a better way to go.
Thanks for your insight on such things Dave.
Brian H. -- Please clarify: Are you now recommending to re-connect +V to the receiver board, **not** disable the receiver, and then set "Transceived House Codes" to "NONE"?
And what about the presumed transmitter board? Leave +V disconnected or re-connect it? -- jclarkw
-
Since you are the first user to report this finding. We are kind of on our own.
I would try reconnecting the +5 volts to both the receiver and transmitter boards. Then try the none choice for the transceived house codes.
Remember if both the TM751 and the CM15A receive the signal from the HR12A Palm Pad. Both may show in the Activity Screen.
If that doesn't do what you need.
You can tie pin 9 of the RX3310 chip on the receiver daughter card to +5 volts. I used a 100K 1/8 watt in my preliminary tests and a 10K 1/8 watt in my modification. Where I used a micro miniature toggle switch and a 10K resistor. Tying it to +5 or Gnd through the switch to select RF On and Off.
-
What I did to sort of unclutter the log was to remove the RX board. Still use the TX function and us V572RF32 for the receive.
Bruce
-
OK, here's what I've learned so far:
>>I would try reconnecting the +5 volts to both the receiver and transmitter boards. Then try the none choice for the transceived house codes.
Remember if both the TM751 and the CM15A receive the signal from the HR12A Palm Pad. Both may show in the Activity Screen.<<
I did this except that I removed the transmitter daughter board completely -- no use for it and conceivable RF interference -- left the single transceived house code on for the moment, and also unplugged the TM751. In this configuration I had essentially the same problems as before except that commands executed directly from the CM15A were now listed as "Macro" in the log instead of "Transmit" -- a small improvement. In particular, although remote RF commands (if the remote was very close to the CM15A, but that's another issue) were executed, they either didn't show up in the log at all or produced bursts of meaningless garbage in the activity log. Similar results were obtained with remote (wired) commands. (Note that this last problem, at least, cannot be avoided by improving RF reception by.CM15A and elimnating the TM751! The CM15A just is not detecting remotely executed commands correctly.) In fact either kind of remote command often seemed to permanently lock up the log.
Setting tranceived house codes to "NONE" was no help at all except, of course, that the RF commands were not executed.
Added back the TM751 solved the latter problem, of course, but also produced bursts of garbage and/or lock-ups in the activity log.
>>If that doesn't do what you need.
You can tie pin 9 of the RX3310 chip on the receiver daughter card to +5 volts. I used a 100K 1/8 watt in my preliminary tests and a 10K 1/8 watt in my modification.<<
Electrically disabling the RF receiver in this way appears to be the best configuration for me, as RF reception by the CM15A is blocked, producing no garbage or lock-ups in the log. But all of the other problems continue, including garbage and lock-ups due to RF commands executed by the TM751. It's as though the internal (macro and ActiveHome-issued) commands work OK until a few external commands are detected, an then problems begin. (As discussed in thread, http://forums.x10.com/index.php?topic=27918.0, I also tried an earlier version of ActiveHome Pro that was advertised to help with this, but his did not solve the most annoying log problems.)
The main problem for me remains that it's difficult to determine what a "program" actually does (especially with dawn/dusk and/or "security" options) without being able to rely on a recorded log during the testing phase... -- jclarkw
-
You have one TM751 in use not multiple TM751s?
Do you have any phase couplers between the two split phase power found in almost all homes?
If you have a coupler/repeater. What brand and model?
There are a few that are known to get into firestorm signal power line flooding with a CM15A.
-
Brain H. -- Thanks very much for your patience and ongoing help with this problem.
>>You have one TM751 in use not multiple TM751s?<<
Just one.
>?Do you have any phase couplers between the two split phase power found in almost all homes?
If you have a coupler/repeater. What brand and model?<<
Yes. It's a Leviton model HCA02, with which I replaced the original Advanced Control Technologies CR 230 after two of them had failed. I haven't noticed any signal collisions -- at least everything is working on command.
>>There are a few that are known to get into firestorm signal power line flooding with a CM15A.<<
I also have a "Power Line Signal Analyzer" with which I could verify the existence of the "garbage" command fragments that ActiveHome Pro is reporting (to make sure that they are real and not figments of ActiveHome's buggy imagination). But this does not give me a convenient way to identify the source of the fragments. And it doesn't explain why the combination of the CM15A and ActiveHome's log ignore commands that I know are on the power line -- all remote commands, both RF and wired, are being executed even when they are not reported in the log.
-
X10 wiki may have more details.
http://kbase.x10.com/wiki/ActiveHome_Pro
http://kbase.x10.com/wiki/Known_Issues_with_ActiveHome_Pro
-
Brian H. -- The attached is an annotated ActiveHome Activity Log fragment that illustrates the weird behavior I have been describing. -- jclarkw
-
X10 wiki may have more details...
http://kbase.x10.com/wiki/Known_Issues_with_ActiveHome_Pro
Brian -- I'm reading there, "Users have claimed that ACT's coupler/repeaters don't have this problem (though I haven't tried them myself)."
1) Can anyone elaborate on specific models of phase couplers that known to be OK with the CM15A? I would be happy to try one...
2) I'm not using dim or bright commands at all, the non-logged commands and the logged bogus command-fragment bursts (illustrated in the earlier .doc attachment) are triggered only by commands issued by remotes (not by the CM15A), no bogus commands or line noise is detected by my Power Line Signal Analyzer, and my control systems run along fine indefinitely. It's only the Activity Log in ActiveHome Pro that is obviously malfunctioning.
So this doesn't really sound like the problem described in the above URL. It sounds more like a problem with the CM15A's line monitoring module and/or with ActiveHome Pro software. Nevertheless I will happily try another coupler if somebody will recommend one...
-- jclarkw
-
I will look at the attached doc file.
1) I know the JV Engineering XTB-IIR is the gold standard coupler repeater. Others with the ACT models should give you model numbers. I have
seen CR134 and CR234 models mentioned.
2) It doesn't sound like the problems some where seeing with bright and dim commands.
Since it only seems to happen with RF commands. Maybe it is the fact that X10 RF devices send two or more commands each time the buttons are pushed and the multiple command are being sent on the power line. The power line monitor maybe seeing the repeated commands and the originals from the TM751 and getting garbaged data.
-
Since it only seems to happen with RF commands. Maybe it is the fact that X10 RF devices send two or more commands each time the buttons are pushed and the multiple command are being sent on the power line. The power line monitor maybe seeing the repeated commands and the originals from the TM751 and getting garbaged data.
I'm afraid I have no patience with the OP's helter-skelter shotgun approach to troubleshooting, but...
Unless the CM15A is defective, or sorely in need of decoupling capacitors, there's no logical explanation for the things that are happening.
Most remotes send 5 or more copies of RF commands. The SH624 can send singles and it's very difficult to send less than 6 with the HR12A. I have never heard of a TM751 having problems with that. They tend to wait 500ms or more before responding to repeats although there was a problem several years ago related to the shortcut noted in the KB for dim commands that would cause TM751s to send infinite PLC dims in response to EMI from the 120kHz on the household wiring affecting the superregenerative receiver.
Short of a defective CM15A (or incompetent X10 programmers - note that I have never used AHP or the Cypress MCU in the CM15A so I cannot speak to this) there is no way the RF transmitter can be involved. Disconnecting it is as likely to cure warts as it is to address the problem.
If both the TM751 and CM15A hear the RF and send PLC, the CM15A should sense any collisions and stop sending. It will then retransmit when the line is clear. Add a coupler/repeater and you could get a cacophony or repeats/collisions, ad infinitum.
The best approach would be to ditch the TM751 and improve the antenna on the CM15A as I and Noam suggested earlier. That, at least, gives a clear starting point for troubleshooting.
One final point - RF interference or a stuck button on a remote could also be a factor.
-
Dumb question -
Have you tried another CM15A? Perhaps yours is defective, and no amount of monkeying around with it will correct that.
-
>>I will look at the attached doc file.<<
Great! Note that there is an (almost) repeating pattern of 8 command fragments, whatever that means.
>>1) I know the JV Engineering XTB-IIR is the gold standard coupler repeater. Others with the ACT models should give you model numbers. I have
seen CR134 and CR234 models mentioned.<<
Thanks! This is probably worth a try. I also have a new CM15A on order (now back-ordered at X10 again!), so I can compare behavior when that arrives...)
>>2) ...Since it only seems to happen with RF commands...<<
Not so. Same thing happens with commands issued by a wired keypad. -- jclarkw
-
Will be interesting to see if another CM15A does anything different.
You may want to turn off the Leviton Repeater and see if anything changes.
-
...
Most remotes send 5 or more copies of RF commands...
The best approach would be to ditch the TM751 and improve the antenna on the CM15A as I and Noam suggested earlier. That, at least, gives a clear starting point for troubleshooting...
dhouston -- As I reported above, after surgery my first test was with the CM15A receiver enabled, the TM751 unplugged, and the RF remote keyed close to the CM15A's inadequate antenna. This caused all of the same malfunctions as with RF through the TM751 (receiver disabled) or with the wired remote (MC10A).
My Power Line Signal Analyzer (Monterey Instruments) reports no repeat codes issued by either the MC10A or the TM751. (Of course the second set of 11 cycles has been amplified by the phase coupler.) -- jclarkw
-
...You may want to turn off the Leviton Repeater and see if anything changes.
Good thought! Unfortunately the logging behavior is the same with the phase coupler off.
One more thing I noticed: After the Activity Log locks up on remote commands (it continues logging direct ActiveHome commands and macros but NOT macros stored in the CM15A), if I quit the ActiveHome Pro software and then re-start it (just clearing the history isn't enough), the log starts working again. After logging a few commands, however, I get just one last command fragment logged and it locks up again. This last logged fragment does, in fact, represent the first half (e.g. "G4") of the issued command, the second half (e.g., "GON") being missing every time it locks up.
The fact that quitting and re-starting ActiveHome gets the logging started again temporarily (not to mention that all of the commands are actually getting executed whether logged or not) strongly suggests that I have a software problem, not a hardware problem, does it not?
But changing the software version (still running 3.10, as suggested by Dan at http://forums.x10.com/index.php?topic=27918.msg156707#msg156707) hasn't helped. Are there any other programs I might be running that are known to interfere with ActiveHome Pro on a Windows XP SP3 system?
Regards. -- jclarkw
-
Are there any other programs I might be running that are known to interfere with ActiveHome Pro on a Windows XP SP3 system?
I have been watching this thread with interest, thinking same as dhouston, that you were chasing gremlins or you have a problem with the CM15A (which I still lean towards) but would be easy to eliminate any background programs conflicting with AHP, through Task Manager or restart Windows in the clean mode.
-
I'd still suspect the CM15A is the problem.
Instead of restarting AHP to correct the logging issue, have you tried unplugging the USB, and plugging it back in? If something is locking up in the CM15A, that might get us more data points (I don't know what the more data would tell us, but it would be more data to look at).
Is your CM15A connection over a long USB cable (over 16 feet)? From my own experience, that can cause interference that causes the CM15A to partially lose the connection to the PC, but the PC doesn't always know (so it keeps logging activities triggered from within AHP).
I still would suspect your specific CM15A unit is the problem.
-
I'd still suspect the CM15A is the problem.
I think there is a strong clue in the OP's first post where he wrote, "When I opened the CM15A box...". Apparently this all started after he decided to fix his CM15A range issues.
-
I'd still suspect the CM15A is the problem.
Instead of restarting AHP to correct the logging issue, have you tried unplugging the USB, and plugging it back in?
...
Thanks for yet another good suggestion. Sorry to be non-responsive, but I'm presently buried in a different project.
In spite of Mr. Houston's disparaging opinion, any malfunction of my current CM15A originated at X10. Given my work load and the fact that I have another unit on back-order, I'll probably try the substitution first... -- jclarkw