Help with codes for Hunter Douglas remote for window blinds

sfhub · Post by **sfhub** » Thu Oct 16, 2003 5:27 pm

I'm able to learn the IR signals from the Hunter Douglas remote which
came with my window blinds, but IR doesn't seem to recognize any
protocol or device info automatically like it does for other learned
commands.

I'm using extender2 with my 15-2117 and it is my understanding when
using extender, there is no support for learned commands so I'd like
to be able to convert the learned commands into something I can use
while an extender is enabled.

Here is the raw data. Any help would be appreciated:

Code: Select all

Raw Data
Frequency 40201

Sent once when key pressed (same for all the buttons)
+2660 -2676 

Sent repeatedly while key is being held
BlindUp1 +994 -1000 +994 -2670 +994 -1000 +994 -2670 +2660 -2676
BlindDn1 +994 -1000 +994 -2670 +994 -2670 +994 -1000 +2660 -2676
BlindUp2 +994 -2670 +994 -1000 +994 -1000 +994 -2670 +2660 -2676
BlindDn2 +994 -2670 +994 -1000 +994 -2670 +994 -1000 +2660 -2676

--
I interpret the command to be something like:
(I'm an IR newbie so I don't really have any idea how IR protocols are
created.  This is just high-level pattern matching from computer science
background.)

BlindUp1 1000 2670 1000 2670  2660 2676
BlindDn1 1000 2670 2670 1000  2660 2676
BlindUp2 2670 1000 1000 2670  2660 2676
BlindDn2 2670 1000 2670 1000  2660 2676

BlindUp1  0 1 0 1 END
BlindDn1  0 1 1 0 END
BlindUp2  1 0 0 1 END
BlindDn2  1 0 1 0 END

johnsfine · Post by **johnsfine** » Thu Oct 16, 2003 7:32 pm

It is better to save the eeprom image to a file and upload that to the diagnosis folder (in the Yahoo JP1 group). Then we can look at the signals ourselves. You left out critical details in what you chose to quote from IR.

You can use the Protocol builder spreadsheet to create simple protocols. You can easily define the frequency and the number of bits and the fact that a '0' is +994,-1000 and a '1' is +994,-2670. That covers almost everything.

I forget whether protocol builder has any way to put that thing that looks like a lead_in burst (+2660,-2678) at the end rather than at the beginning where most protocols have it. Depending on the details you left out, maybe it really is supposed to be at the beginning. Repeating protocols without a big gap are often learned out of phase.

sfhub · Post by **sfhub** » Thu Oct 16, 2003 8:05 pm

Sorry, I edited the post to include everything in the IR tab (sent once
when key pressed was missing) for learned keys. There's no other
information available in the page for learned keys in IR. I'm not sure if
you meant something else was missing. Also I put the eeprom txt file at

http://groups.yahoo.com/group/jp1/files ... earned.txt

I'll try the protocol builder stuff you referred too.

Thanks.

johnsfine · Post by **johnsfine** » Thu Oct 16, 2003 8:35 pm

Even with everything there, we find it easier to understand when we run IR for ourselves, but you had previously left out the detail that confirms my guess that the +2660 -2767 really occurs at the start not the end (the capture of the learned signal was confused about the repeat pattern).

Since the +2660 -2767 is just a lead_in, this protocol is about as simple and generic as you can get with Protocol Builder. It sounds like you understand enough to use PB yourself. If not, ask again and someone will help.

sfhub · Post by **sfhub** » Thu Oct 16, 2003 11:17 pm

So I think I know what I'm doing with PB but I don't think I know how
to use the resulting Protocol. At first I was going to use 0 bits for device
since I just wanted to create 1 device in KM instead of 2, but it seems
KM won't let me enter 0 bits for device. So I created the protocol with
2 bits dev, 2 bits cmd.

I used manual settings in KM with
Device: 01
Protocol: 01 55
2nd Cmd: None
Signal Style: MSB
bits/dev: 0
bits/cmd: 4

Now in the KM-Functions screen I think I want to enter something
which results in a '0 1' sequence corresponding to window blinds up
and a '1 0' sequence corresponding to window blinds down.

I don't know the relationship between EFC/OBC/Hex to get the
results I want.

I know there is something simple I'm missing, because this protocol
seems very simple even to me. A few pointers would be appreciated.

I entered the following into PB:
Protocol ID: 01 55
Freq: 40.200
Duty: 30
SignalStruct: dev-cmd

DeviceByte: 0
bits/dev: 0

CmdByte: 0
bits/dev: 4

'1' on: 994
'1' off: 2670
'0' on: 994
'0' off: 1000

lead-in style: same for every frame
lead-in on: 2660
lead-in off: 2676

sfhub · Post by **sfhub** » Thu Oct 16, 2003 11:42 pm

Never mind, I realize my mistake. I wasn't pasting the Protocol I created
into the "Notes" section of KM. After I did that, everything works.

Also I didn't realize KM allowed me to enter 0 bits for the device portion
because it didn't show up in the popup. How's that for growing up in the
point-and-click generation? I just entered 0 in the field instead of using
the popup and it works fine.

BTW is there a numbering convention for protocol IDs or do I just
pick something unused?

Thanks for getting me over the hump.

sfhub · Post by **sfhub** » Fri Oct 17, 2003 12:39 am

Apparently I spoke too soon. Although my remote is controlling the
blinds and the blinds are responding, it seems my remote is rebooting,
crashing, or resetting, as after a few key presses, all the LCDs in the
screen are on (like when I upload using jp1) and it resets to the default
device.

After the reset, it continues to operate the blinds properly. I'm guessing
the protocol I generated results is some register operations that the CPU
doesn't like, but debugging that seems a bit more than I'd like to chew
right now. Perhaps it has something to do with setting the device bits to 0?

Here's what was generated:

Code: Select all

Upgrade Code 0 = DC 1F  (Home Auto/1055)
 55 00 61 05 06 09 0A                           
End

Upgrade Protocol 0 = 01 55 (S3C8+) 
 3A 89 00 8B 12 80 25 00 04 01 F1 05 23 01 F1 01
 E0 00 00 05 32 05 26 8D 01 46
End

sfhub · Post by **sfhub** » Fri Oct 17, 2003 1:35 am

So it seems like my 15-2117 doesn't like the protocol I created which
used 0 byte commands. It kept resetting after a few key presses, but
surprisingly after it reset it controlled the blinds perfectly.

I tried simulating the same thing by creating a new protocol
dev: 0byte 0bit/dev
cmd: 1byte 8bit/cmd

leadin: same for every frame
burst mid frame: yes
after # bits: 4

This seems to work ok without causing the remote to reset, but the timing
or ordering isn't quite right, as it is hard to get all the blinds opening or
closing at the same time. Multiple blinds respond to the same commands
and with the OEM remote and with the 0byte version of the protocol, I
could wave the remote from left to right and the blinds would open in
unison.

With my simulated versions, each blind open individually and it is hard
to get them to open in unison.

If someone could help me rewrite the protocol using 1byte commands
to mimic as closely as possible what would have been generated with
0byte commands, I think that would work more like the OEM remote.

sfhub · Post by **sfhub** » Fri Oct 17, 2003 2:00 am

Finally got it working. I had messed up the lead out time in my
experimentation. Once I changed it back to 0=[-LO], the protocol
works well again.

So to summarize, in both cases, I had 0byte 0bit/dev.

I changed from

0 byte 4bit/cmd

to

1 byte 8bit/cmd

In the latter case, I also changed lead-in to burst midframe after 4 bits.

When I defined the OBC commands in KM, I doubled up the commands.
Where in the 4 bit version, I used:
blind1 up - OBC:005 HEX:$05
blind1 dn - OBC:006 HEX:$06
blind2 up - OBC:009 HEX:$09
blind2 dn - OBC:010 HEX:$0A

With the 8 bit version I used:
blind1 up - OBC:085 HEX:$55
blind1 dn - OBC:102 HEX:$66
blind2 up - OBC:153 HEX:$99
blind2 dn - OBC:170 HEX:$AA

and depended on the midframe burst to insert the LeadIn at the beginning
of each 4 bit portion of the 8 bit command.

Post by **The Robman** » Fri Oct 17, 2003 8:17 am

Congrats SF. Once you have finalized the KM file, be sure to load it up into the file section. There's also a folder just for PB files, so be sure to load the PB file there also.

sfhub · Post by **sfhub** » Fri Oct 17, 2003 11:53 am

The Robman wrote:Once you have finalized the KM file, be sure to load it up into the file section. There's also a folder just for PB files, so be sure to load the PB file there also.

Done. Thanks for all the help guys.

If anyone is curious the files are here:
http://groups.yahoo.com/group/jp1/files ... ind_KM.txt
http://groups.yahoo.com/group/jp1/files ... ind_PB.txt