Print

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

[bkenobi]

Does anyone know of a way to output the raw RF signal received by the CM15A?  I have an application that would benefit from knowing what is actually coming in rather than just using the PLC result.

[Tuicemen]

You need the AHSDK.
Many RF signals have no PLC equivalent anyways.
 

[bkenobi]

I've got the SDK installed, but I don't know how to get the RF codes out.  Any reference that you could point me to?  I've been using the SDK for at least a year for PLC commands, but the code I based mine on does not output the raw RF (only a statement rfrecv).

[Brian H]

It has been awhile since I looked at the receiver in the RF CM15A.
There is a raw data output from the receiver daughter card. One issue is the receiver has no squelch type circuitry. So there is a constant output of random noise until the data is outputted.
I will try and look at one today and see if I can find out more information for you.

Dave Houston has information on using an RF external receiver board to do decoding. The scope displays look close to what the internal receiver in the CM15A outputs.
http://www.davehouston.net/learn.htm

[bkenobi]

It seems like this shouldn't be that difficult to obtain since mochad can do it.  I don't know how it obtains. Data though (not with AHP SDK since mochad is on Linux).

[Brian H]

If mochad can output the raw X10 RF data. There could be a way to get it from other programs.

[bkenobi]

I installed mochad on my Raspberry Pi and it seems to be able to see PLC and RF commands.  The default setup processes those commands such that it's output is human readable (e.g., A1 ON).  There is a switch to have mochad output the raw RF string, but I haven't figured out how to get it to work yet.  The program is a service, so I could simply add the switch to the instantiation...if I knew Linux well enough to find the call.

[bkenobi]

I'm an experienced user of Linux (I use it all the time at work, but only for a set of specific activities).  I am not an experienced sys admin of Linux.  I just spent the better part of the last day and a half trying to figure out what RF data the CM15A was outputting to client software.  In the end, I used mochad to output the raw RF data in hex and can now show that when compared to HomeGenie (the 3rd party app), it does produce the same string.  The problem is, that string does not match the documentation I've found on the net.

For example

Code: [Select]

Command    RF string received    RF string from protocol docs    Verdict
A1 ON      5D 20 60 9F 00 FF     5D 20 60 9F 00 FF               Correct
A15 OFF    5D 20 64 9B 68 93     5D 20 64 9B 68 97               Incorrect

The last byte is always wrong for some reason.  I guess I don't care at this point since I'm sure what I'm getting is what the HR12A is sending.  If anyone knows why the last byte is different, I'd be interested to know!

[Brian H]

Dave Houston has the RF protocol information on his web site.
Maybe it can give you some clues.
http://www.davehouston.net/

[bkenobi]

Yes,that is one of the resources I used.  I also used the ref document linked from Wikipedia and it included the actual raw codes as well.  Unfortunately, those don't match what's actually produced for UC 9-16.

[dhouston]

Sorry that I did not notice this thread earlier. While I never explicitly looked at the bit pattern for each and every RF code, I did write software that decoded the RF signals reported by RF receivers like those listed on my web site as well as software that sent RF using RF transmitters like those I list. Those codes correctly operated the modules that were addressed.

In all cases the codes agreed with the CM17A documentation which is no longer available from X10 but there's a copy on Neil Cherry's website.

• http://home.comcast.net/~ncherry/common/cm17a.html

I can only surmise that either the CM15A microcontroller is reporting the wrong bit pattern or that mochad is in error. I suspect it's the CM15A which is at fault.

[Brian H]

Ed Cheung also has some X10 RF data on his site.
http://www.edcheung.com/automa/rf.txt

[bkenobi]

I did an extensive study on this a few weeks ago by actually capturing every RF code from the HR12A to the CM15A as reported by the CM15A and displayed in HomeGenie.  My results showed that the first 1 unit codes of every house code followed what is published by X10 and also what Ed has on his web site (one that I used).  However, the second 8 unit codes do not match for whatever reason.  I don't know if this is due to the documentation or the CM15A not interpreting things per the documentation, but what I can say is that it is consistent.  I tried multiple transmitters and 2 different CM15A's.  I have no other wireless controllers that I could use for checking, so I cannot verify dhouston's suspicion, but he is probably right that the CM15A is at fault (design not specific unit).

Either way, since it is consistent in what it reports, HomeGenie seems to know how to work with the RF that is used.  I was primarily trying to determine the RF code so that I would know what to enter into the HG interface.  As it turns out, I can simply use the log of what was received as an indication of what I should use.

[dhouston]

It does seem to be merely an error in how it reports the codes as we haven't seen complaints that it wasn't addressing the expected lights/appliances. As long as it's consistent, you can create your own translation to human readable codes.

The example you gave earlier in the thread shows where the error occurs.

The standard RF codes are sent as 32 bits. The first 8 bits are repeated in two's complement form as the second 8 bits. And, the third 8 bits are repeated in two's complement form as the fourth 8 bits. Two's complement is done with a logical NOT operation. All the bits flip from 0 to 1 and vice versa. This allows for some rudimentary error checking as the byte pairs should be two's complements of each other and sum to FFh or 11111111. It also allows for DC balance in the RF signal.

• https://en.wikipedia.org/wiki/DC_coefficient

And, the 1st & 3rd bytes are those given in the CM17A protocol from X10.

Your example shows this but uses hexadecimal rather than binary notation. The first two bytes identify the source as RF (5Dh) and indicate that 32 bits follow (20h).

A1 ON is 01100000 10011111 00000000 11111111 in binary and 60 9F 00 FF in hexadecimal.

But, in the second example, A15 OFF, the 3rd & 4th reported bytes are not two's complements of each other.

64 9B 68 93 in binary are 01100100 10011011 01101000 10010011.
(NOT 01101000 = 10010111)

68h + 93h = FBh or 11111011 binary.

Most likely, the CM15A is doing some undesired bit shifting but it would require a larger sample to verify this.

[Brian H]

Do you think some data captured from a WGL W800RF32A would be of any use?
The Demo program shows the data in Hex format. As I have not figured out how to extract the last four bytes received boxes also showing the 1's and 0's.

I know the AHP Monitor Function showed different data for the security devices depending on my CM15A having the P10792E controller chip or the P10792M controller chip.