Print

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

[bkenobi]

I've switched from using AHP + SDK, but I have a question about the RF protocol or perhaps how AHP+SDK sees things.  I don't know if this has been covered, so if so, just point me in the right direction.

When using any RF receiver and pressing a button an a remote (palm pad for instance), there are always 2 commands seen.  AHP shows in the activity monitor that the command was something like:

Code: [Select]

63 1/29/2015 6:33:50 PM Receive RF A1 On
64 1/29/2015 6:33:50 PM Receive RF A1 On
65 1/29/2015 6:33:50 PM Receive A1
66 1/29/2015 6:33:51 PM Receive A On
67 1/29/2015 6:33:51 PM Receive A1
68 1/29/2015 6:33:51 PM Receive A On
But, anyone who's used the SDK probably knows that it shows different results.

Code: [Select]

2015/01/29 18:33:50 RecvAction: recvrf, a1, On, 0, 1/30/2015 2:33:50 AM,
2015/01/29 18:33:50 RecvAction: recvrf, a1, On, -1, 1/30/2015 2:33:50 AM,
2015/01/29 18:33:51 RecvAction: RecvPlc, a1, On, , ,
2015/01/29 18:33:51 RecvAction: RecvPlc, a1, On, , ,
There is a parameter with a value of 0 and -1 in the RF commands.  I assume this is a "button pressed" and "button released" value.  Does anyone know how this works in the RF protocol?  I haven't seen it listed and I don't see it when looking at the raw USB data.

[dhouston]

I'm not sure about what you are asking. Also, I've never used AHP nor the SDK so have no clue (and have always thought X10 programmers to be totally clueless) as to their inner workings. I have, however, done a lot with X10 RF and can comment on the RF protocol explained at http://davehouston.org/rf.htm. I also wrote my own software to handle receiving and acting on RF codes many years ago.

When you press a button on a handheld remote, most will send 5 or more copies (SH624 sends a single copy) of the RF code (a very quick push/release is needed to limit it to 5). Motion sensors, door/window switches, Stick-a-Switches, etc. also transmit multiple RF copies. Depending on the received signal amplitude, a transceiver may not act on the first (or first few) codes. The signals serve to reset the transceiver AGC, so later codes in the sequence are heard more clearly. The first code that the transceiver can interpret as a valid X10 code results in the PLC commands for address & function. PLC commands are sent twice. While sending PLC,  the transceiver is deaf to RF but, as soon as the PLC is sent may once again hear RF and duplicate the PLC. My software ignored further RF copies for 600mS to avoid duplicate PLC commands. There's a brief discussion of RF signal, noise, AGC, etc. at http://davehouston.org/rf-noise.htm.

There's nothing in the chain of events that might explain the 0/-1 so it's likely to have meaning only to the programmer(s) who created AHP and/or the SDK. There's a picture of X10's Programmer-in-Chief below.

[Tuicemen]

The SDK will send more then 2 signals when pressed depending on how long you hold down the RF button on a palm pad
0 is pressed -1 is released the longer you hold the button down the SDK will show this with a increasing count 1,2,3......
AHP just shows repeated receives

There's nothing in the chain of events that might explain the 0/-1 so it's likely to have meaning only to the programmer(s) who created AHP and/or the SDK. There's a picture of X10's Programmer-in-Chief below.

And the X10's Programmer-in-Chief is long gone so we will likely never know for sure the true intention.

[Brian H]

WGL Model: W800RF32
X10 HR12A Palm Pad. Momentary button push. Looks like multiple RF transmissions as Dave pointed out.
W800RF32 Demo Program.

8:15:21 AM - 00 FF 06 F9     X10 Cmd: A 1 On
8:15:21 AM - 00 FF 06 F9     Debounce
8:15:21 AM - 00 FF 06 F9     Debounce
8:15:21 AM - 00 FF 06 F9     Debounce
8:15:21 AM - 00 FF 06 F9     Debounce
8:15:21 AM - 00 FF 06 F9     Debounce
8:15:24 AM - 04 FB 06 F9     X10 Cmd: A 1 Off
8:15:24 AM - 04 FB 06 F9     Debounce
8:15:24 AM - 04 FB 06 F9     Debounce
8:15:24 AM - 04 FB 06 F9     Debounce
8:15:24 AM - 04 FB 06 F9     Debounce
8:15:24 AM - 04 FB 06 F9     Debounce
8:15:27 AM - 11 EE 06 F9     X10 Cmd: A 1 Bright
8:15:27 AM - 11 EE 06 F9     X10 Cmd: A 1 Bright
8:15:27 AM - 11 EE 06 F9     X10 Cmd: A 1 Bright
8:15:27 AM - 11 EE 06 F9     X10 Cmd: A 1 Bright
8:15:27 AM - 11 EE 06 F9     X10 Cmd: A 1 Bright
8:15:27 AM - 11 EE 06 F9     X10 Cmd: A 1 Bright
8:15:29 AM - 19 E6 06 F9     X10 Cmd: A 1 Dim
8:15:29 AM - 19 E6 06 F9     X10 Cmd: A 1 Dim
8:15:30 AM - 19 E6 06 F9     X10 Cmd: A 1 Dim
8:15:30 AM - 19 E6 06 F9     X10 Cmd: A 1 Dim
8:15:30 AM - 19 E6 06 F9     X10 Cmd: A 1 Dim
8:15:30 AM - 19 E6 06 F9     X10 Cmd: A 1 Dim

[dhouston]

Looks like 5 RF commands as Dave indicated.

Actually, that looks like six - it takes a really, really quick push/release to get five.

[dhouston]

The SDK will send more then 2 signals when pressed depending on how long you hold down the RF button on a palm pad
0 is pressed -1 is released the longer you hold the button down the SDK will show this with a increasing count 1,2,3......

And the SDK appears to be predicting events that will happen 8 hours into the future.

[Brian H]

Yes it did look like six messages and I changed my post.

[bkenobi]

I figured as much.  I saw nothing in the raw RF code that the CM15A reported nor anything in the USB communication with the PC.  At least there's no hidden stuff I couldn't find going on...just the crazy AHP programmers as usual.   

I appreciate the feedback!

[toasterking]

2015/01/29 18:33:50   RecvAction: recvrf, a1, On, 0, 1/30/2015 2:33:50 AM,
2015/01/29 18:33:50   RecvAction: recvrf, a1, On, -1, 1/30/2015 2:33:50 AM,
[...]
There is a parameter with a value of 0 and -1 in the RF commands.  I assume this is a "button pressed" and "button released" value.  Does anyone know how this works in the RF protocol?

The help file that comes with the "full" SDK confirms your suspicion:

When RF commands are received, RecvAction returns "recvrf" as the action parameter, with additional data beyond the command and address:

"<X10 address>", "<RF command>", "<keydata>", "<timestamp>"

These paramers are:

    X10 Address: A1-P16
    RF Command: string constant, as described in the RF Command Reference.
    Key Data returns three possible pieces of data: 0 (indicates key pressed, or key down); -1 (key released, or key up); 1...n (repeat sequence indicating how long remote key is pressed).
    Timestamp: in UTC.

And the SDK appears to be predicting events that will happen 8 hours into the future.

The help file states that the timestamp is in UTC, so 8 hours into the future would be somewhere around the Pacific time zone in the present.  

[bkenobi]

Yup, Pacific timezone here.  I haven't read the SDK guide in ages since I haven't been using it.  Thanks for pointing out the details!   

[dhouston]

   Key Data returns three possible pieces of data: 0 (indicates key pressed, or key down); -1 (key released, or key up); 1...n (repeat sequence indicating how long remote key is pressed).

There is ABSOLUTELY NO WAY to determine when the key is released. There is NOTHING within the RF data transmitted by the remote to indicate this. So the SDK documentation is full of CRAP!

[toasterking]

There is ABSOLUTELY NO WAY to determine when the key is released. There is NOTHING within the RF data transmitted by the remote to indicate this. So the SDK documentation is full of CRAP!

LOL! 
Tell us how you really feel about the documentation, Dave!

Of course, I believe you since you have far more knowledge than I on the subject, but may it's just a timing thing. Maybe it assumes the key is released when there is a gap where the next command should be received but isn't. And of course, that certainly doesn't prove that the button was released; it's just an assumption.

I'm going to try that at my next opportunity -- hold down a button on a remote and walk out of range -- and see if I get a -1 from the SDK.

[dhouston]

Maybe it assumes the key is released when there is a gap where the next command should be received but isn't. And of course, that certainly doesn't prove that the button was released; it's just an assumption.

If you capture the RF data with a receiver, displaying it on an oscilloscope (as I've done many, many, many times) you will see a series of codes each of which looks like the the first illustration at http://davehouston.org/rf.htm with the exception that there is a 40mS silence between each code. Each code takes ~108mS with some minor variation caused by the LC components in the remote. The 6 codes transmitted by most remotes will take ~648mS on nearly 2/3 of a second. With a rapid press/release, the codes continue well after the release. If the button is held down the sequence will repeat endlessly or until the batteries are depleted. You can find numerous reports here of RF flooding caused by a remote lost between couch cushions, etc. It has been several years since I captured the codes but I probably still have hundreds of oscilloscope screen shots on long retired Windows 3.1 and Windows 95 HDDs. The technique is documented at http://davehouston.org/learn.htm.

Also, the data provided by Brian (from non-X10 hardware/software) shows the 6 RF copies while the AHP & SDK data only shows two.

[bkenobi]

I can confirm the same data that Brian saw with my chosen software (HomeGenie).  It shows a series of ~5-6 instances per button press.  I was having issues because the command was being sent by the CM15A multiple times on the PLC and I was trying to figure out what was causing it.  I assumed it was the button down/button up command (which doesn't exist).  In reality, the duplicate PLC instance was either the CM15A or HG not waiting long enough and issuing a second command.  The software developer has tweaked things and I believe it should be resolved now.

That being said, I've always thought AHP was a bit questionable in it's design.  But, now that I'm learning more about some of the other things the developers have done, including with the SDK...  Let's just say I'm glad that there are other options for people to use the hardware.  The software may be questionable, but the hardware (within limits) is very good.

[bkenobi]

Oh, since capturing RF was brought up, I wanted to use my SDR to capture RF primarily to determine relative signal strengths.  But, whenever I try to look at 310MHz and transmit a command, I don't see anything.  Has anyone used SDRSharp or some other code to capture RF?  I don't need to decode, just see the command to determine relative magnitudes.

sdrsharp.com
http://www.rtl-sdr.com/rtl-sdr-quick-start-guide/

For reference, I bought a cheapo USB dongle for ~$6 off ebay to play with.  It works great with the software.  I just don't know how to use it for this purpose.