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.

--
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.)

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.

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

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.

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.

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?

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?

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.

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._________________Rob
www.hifi-remote.comPlease don't PM me with remote questions, post them in the forums so all the experts can help!