It has been stated that some low-cost RF receiver modules at 315MHz can be tuned to the X-10 frequency of 310MHz.
My question is, can X-10 transmitters such as palmpads, slim-switches and motion-detectors, be [easily] tuned to 315MHz? If so, one could have, for example, motion-sensors on 315MHz and controllers on 310MHz, to prevent one from stomping on the other. Is that feasible?
No. X-10 transmitters are not easily tuned - most can only be tuned by bending the wire loop that forms part of the resonant circuit and you need sophisticated equipment to do this accurately. On the other hand, the 315MHz superregenerative RF receivers like the ones I list on my website are easily tuned - they have a tuning slug and a linear output that can be used as a tuning indicator.
315MHz and 310MHz are also close enough that strong signals will be received from either frequency by the superregenerative receivers typically used. You need more separation.
What is feasible with something like roZetta is to use multiple receivers of two or more well separated frequencies on serial ports, the RS485 network or the internal receiver and use other methods to send control signals and/or use security motion sensors, door/window switches, etc. from other systems that use different (and well separated) frequencies.
Most of the high-end touchscreen remotes (Pronto, MX3000) use 418MHz in N. America. They can be programmed to send control codes. It's also fairly easy to replace the X-10 daughterboard in the universal remotes with a 4-pin
418MHz or 433.92MHz transmitter module but this is not possible with Palmpads, Stick-a-Switches, etc. (I have a few remotes that have leads with alligator clips that I use with various transmitters for testing and a Pronto TS1000 to which I've added 310MHz RF.)
However, RF interference from multiple transmitters is not much of a practical problem. PLC interference when various receivers try to send to the powerline simulaneously is the "usual suspect".
With Palmpads, etc. you can disable the X-10 transmitter circuit (single transistor) and send the data signal to one of the 4-pin transmitters if you can fit it inside the case. You can use a short flexible wire as the antenna.
A simple way to handle multiple frequencies with roZetta will be to use an MR26A (310MHz) and MR26E (433.92MHz) on separate serial ports. However, you would need European versions of the palmpads and their power output is higher than FCC (or Industry Canada) rules allow.
For some reason, I've just seen your replies today, even though sent two days ago.
Yes. In later reading through some X-10 forums, I saw mention of the x10.com transmitters being /very/ loose in frequency, so I suspected
310MHz and 315MHz would be too close.
This is interesting. As you know, I'm planning on switching to Insteon, but hope to keep the X-10 RF (and plug-in) transmitters for control at least until suitable Insteon versions are available. And, to interface them to the Ocelot via roZetta, rather than via RR501's as they currently are.
But I recently dusted off some X-10 motion sensors to try again, and found that I was frequently getting collisions when sending palmpad commands. So from what you said above, would you suspect that the collisions were occurring on the PLC side, rather than the RF side? If so, then without the PLC in the picture, perhaps palmpads and motion sensors can co-exist peacefully?
That's mostly urban legend propagated by the "X-10 is the spawn of Satan" crowd. In fact, I find they are remarkably accurate given that they use LC components (and crude tuning methods during manufacturing) instead of SAW or XTAL to control the frequency.
I do not have laboratory type of equipment to measure frequencies from ultra low power transmitters but I do have SAW controlled 310MHz transmitters. If I tune one of the RF receiver modules to the SAW transmitter, the receiver tends to work equally well with the LC tuned X-10 transmitters (using its linear output as an RSSI indicator).
It's really hard to speculate without knowing details. How are you determining that there are collisions? It's been a long time since I looked at this in detail but the motion sensors will not respond to further motion for some period of time after transmitting. The RR501 will detect PLC collisions, back off and retransmit once the powerline is clear. The RR501 can also buffer one command. All this makes collisions improbable.
RF collisions will not result in a anything on the powerline as the RR501 only transmits to the powerline after validating the received RF is a valid X-10 command. There's no simple way aside from a 'scope watching the linear output of a receiver to detect RF collisions.
My earlier comments reflected the prevalence of newbies putting multiple motion sensors where they can detect the same motion with only a brief interval or no interval and using TM751 transceivers which do not buffer any commands and cannot avoid PLC collisions since they cannot detect PLC activity.
Well, I had these five or so MS13As that were freebies included with an order several years ago. When I received them, I tried them out, but soon put them away.
So recently, I took one out, put fresh batteries in, and placed it in the computer room facing me. I also set a transceiver to the same house code as the Hawkeye and placed it in the same room, which is also the room the Ocelot is in. It's one of the smaller of the two transceivers, so that would be a TM751 rather than an RR501, correct?
In the room also is a palmpad, on a different house code than the motions sensor/transceiver. The transceiver for the palmpad's house code is in the next room. It can control, via the Ocelot, any device in the house, some of which devices are on the same house code as the sensor/transceiver, but most of which are not. But none of the devices are on the same house code as the palmpad; all commands go first to the Ocelot. Some of the palmpad buttons activate macros.
With the Hawkeye in the room, pressing palmpad buttons often resulted in no action. When I removed the Hawkeye from the room, palmpad operation returned to normal.
Are the European versions of the motions sensors also higher powered? I don't know which would be cheaper to replace, a handful of sensors or a handful of palmpads. Either way, one would also need to get the European MR26E. I wouldn't know how to get the European versions here, and likely wouldn't do so anyway, if their operation here would be considered illegal.
Still not enough information. The lack of response could be either RF or powerline collisions. If you had an ESM1 meter it would probably show powerline traffic but without indicating a valid X-10 signal.
Yes, they are higher powered and they would probably be against the rules although it depends on whether the rules are against selling it or against using it. Europe allows sales of almost anything as long as it's labelled as "not for use in EU countries" putting the burden on the user and meaning there's absolutely no enforcement. The FCC puts the burden on the seller but enforcement is also non-existent. I really don't know which way Canada does it.
Well, once the RF is going direct to Ocelot instead of via PLC, that will eliminate PLC collisions of these signals, leaving only RF. But, it stands to reason that if many sensors are in use, and/or are located in high activity areas, that /some/ (many|few) palmpad RF transmissions will collide with sensor transmissions.
The best thing, or course, would be to have them on different frequencies. Hoping someone will be able to point me to some reasonably-priced RF motion sensors using a different frequency than the x10.com transmitters.
It's a little more complicated. You need a receiver of the same frequency and the receiver module needs to have enough smarts to decode the RF and output something you can act on.
Most of the suppliers of security devices have wireless motion sensors. I do not want to support these directly in roZetta because each protocol supported requires some amount of code space and code space is somewhat sparse. I will design separate modules with RF receiver and a PIC that will receive, decode and output via RS232/RS485. You can input this via any of roZetta's serial ports or the RS485 network. This requires minimal internal code space. Initially, I want to limit this to a few of the most widely used like GE ITI, Caddx, Visonic. It also needs to be limited to ones using ASK modulation and frequencies which the 8-pin Wen Shing or Radiotronix RF receiver I prefer can handle.
Yes, I was wondering about that. From what I can see regarding the (optional?) RF receiver on roZetta, it simply provides a signal envelope, and requires the cpu to supply all the smarts?
That sounds fine to me. I'll try to find some info/prices on the names you mentioned, to see if I can afford them :-). The motion sensors must (for me at least) take a second place to handling Insteon.
And because the CPU has limited capability and there is limited EEPROM for code and data, I need to offload this type of input. The cpu and optional receiver will handle X-10 and a few other simple things that use the same frequency.
I've started a thread on the roZetta group dealing with this and listing the devices of this type that I plan to support initially.
You've just discovered the basic flaw of the Hawkeyes. They do not simply detect your *first* entry into a room. Every time you move, they put data on the line. Worse, still, is that you're almost always moving when you reach for a PalmPad or other controller, so the opportunity for collisions where a Hawkeye can see another X-10 transmitter are high.
I had hoped with the advent of the variable timer, they would simply detect startup motion and then not send another command until the timed period had expired, but instead, they keep on sending RF and X-10 signals as you move about in their presence. That's quite enough traffic to step on commands from other controllers. If you have any sort of logging facility like Activehome or a Monterey analyzer, you'll see the incredible increase in X-10 traffic as soon as even a single Hawkeye is put on line.
Perhaps a circuit mod that disabled the PIR element until the OFF signal is sent via the Hawkeye's internal timer would help.
Actually discovered some years ago when I got them as freebies with an x10.com order. After trying them, this is one reason that I stopped using them.
I seem to recall reading in this forum some years ago that the previous model (MS12A?) worked that way. Is that correct, and if so, what was the reason for the change?
Using an Ocelot, one can have the Ocelot receive the motion ON commands, and itself send the device ON/OFF commands. The Ocelot will do the timing, and will ignore the sensor's OFF commands, so the sensor can be set to time out at 256 minutes (~ 4 hours), which will at least keep most of those commands off the frequency.
Another brand of reasonably priced motion sensors has been found which transmit on a different frequency from the x10.com ones, so they won't interfere with the controllers (palmpads, etc.). And they re-transmit only every 30 seconds rather than x10.com's every 10 seconds, which will help somewhat to keep the traffic down.
So, the plan is to use these other sensors in high activity areas, and the Hawkeyes only in low traffic areas such as stairwells, which will help to avoid collisions.
Yes. Is such a mod possible, and does anyone know how to do it?
Another thought, if using another brand of sensor for motion, would be to entirely disable the Hawkeye's PIR, and just use the Hawkeyes to send dusk/dawn signals from areas you'd like to know the (very) approximate light level of. Anyone know how to do that?