When trying to read incoming raw data from the serial
port (using cutecom) I was receiving strange packets,
and as far as I currently know X10 commands appear as
32 bit frames (after decoding), being 16 of them the
inverse of the rest (I haven't found anything about
some kind of "control" frames in X10 protocol
specification..).

So checking the environment I saw incoming raw data
even after powering off motion sensors. I don't know
if this could be the (unknown for me) control frames I
mentioned before, but I tried to find any other near
RF devices that would be sending data (433 MHz). I
finally found an old logitech wireless keyboard, and
it seems that old models use this frecuency band, so
maybe I'm receiving data from this keyboard and is
breaking "right frames" (the problem here is that this
keyboard if from a neighbor office, so I can't switch
it off..).

What do you think about it?
When receiving raw data at the serial port, should I
only see 32 bit sequences? or maybe the complete
undecoded stream?

RE: W800RF32 problem

Alfredo,

Mine just sends a nice neat packet when it gets a signal from the sensor. I
don't think there is a checksum in the X10 RF security signal - but there
are byte compliments.
I have the module declaration and rf relay defined the same.

I assume that Misterhouse is running as root or has appropriate permissions
for /dev/ttyS0

If you really think it is RF interference - why not shield the antenna and a
module in some grounded metal box (like the fridge, oven, microwave) and see
if the problem goes away. If it does - then you would be looking at making a
directional antenna to ignore you neighbors keyboard.

When trying to read incoming raw data from the serial
port (using cutecom) I was receiving strange packets,
and as far as I currently know X10 commands appear as
32 bit frames (after decoding), being 16 of them the
inverse of the rest (I haven't found anything about
some kind of "control" frames in X10 protocol
specification..).

So checking the environment I saw incoming raw data
even after powering off motion sensors. I don't know
if this could be the (unknown for me) control frames I mentioned before, but
I tried to find any other near RF devices that would be sending data (433
MHz). I finally found an old logitech wireless keyboard, and it seems that
old models use this frecuency band, so maybe I'm receiving data from this
keyboard and is breaking "right frames" (the problem here is that this
keyboard if from a neighbor office, so I can't switch it off..).

What do you think about it?
When receiving raw data at the serial port, should I
only see 32 bit sequences? or maybe the complete
undecoded stream?

Re: W800RF32 problem

Well, as I was thinking there's another device using
the 433 MHz band near me. I tried to do tests in
another place far enough and reading raw data from the
serial port (using cutecom) I can see the incoming
messages :D

I'm working with MS13E and MS90 motion sensors from
Marmitek, and the first one seems to send ON/OFF
standard x10 commands. You also can change its values
for house/unit-code manually at the device. But MS90
works different.. It selects automatically its own
codes "randomly" when powering it on, and is also
using own format messages (without being 1st and 3rd
bytes the complements of 2nd and 4th).
The most interesting for me here should be being able
to change the codes from the central station with x10
commands, not manually/automatically at the devices.
Is there any way to do it?

> W800_port = /dev/ttyS0 (it's the right one)
>
> After this I've launched the program by typing:
> mh x10_rf_relay.pl

Don't know anything about this module. But I can tell you that the current
w800rf module is broken. The logic used to validate packets is wrong. It
works for some HC/UC addresses but not others. The various other devices like
the security remote(s), universal remotes are unusable. I fixed all of the
bugs here as all of my devices work, but I had to create serial packages for
them (which flies in the face of current mh convention for RF devices.) I
don't remember why I had to do this, but I couldn't get it to work any other
way. If anyone wants the updated code with the various packages, I will post
them. Maybe someone can compare the updated logic to the current module(s)
and update them. I just don't have the time right now.

I should also point out that mh dupe handling is broken for RF. The whole
thing with multikey and multireceive (or whatever) is in need of a rewrite.
For one, there is no way for RF and serial controllers to share the same hash
for dupes and multi-key commands. Dupes need to look at all previously
received data. As for combining multiple keys like A1 (pause) AK, that is not
a serial issue. I will fix this soon as I am sick of having to use timers to
throw out dupes.