JP1 Remotes

[Capn Trips]

1. Device: SOMFY 3-channel IR transmitter
2. Type of device: Power window shade operator
3. JP1 Remote model: 1994/2117/8910/HTPro (learned to 8910)
4. JP1 user? Yes
5. Still have original remote? Yes
6. Checked the file section? Yes
7. Checked Pronto file section (at R/C)? No
8. Partially working setup code? No
9. Learning remote question? Yes

I have a European (living in London) automatic window shade controller (model listed above) that can raise or lower three sets of shades individually or together. I have learned all of the raise/lower commands to my 8910, but decoding them is another matter.

I have learned signals for the four different pairs of raise/lower commands. TV, VCR and Home Theater up/down correspond to channels 1, 2, and 3, respectively. DVD up/down operates all of them at once. The file is posted HERE

My version of IR (6.0) with the most recent decodeIR.dll , I get a series of bizarre decodes for the eight signals.
4 with no decode,
3 "clean" decodes (s16a:4, NEC2:114.214,Old Panasonic:22); and
1 "error" decode (Emerson:50)

Any ideas?

Edit: A little additional info. The learned commands all seem to work, some better than others. The Channel 1 (TV) work both directions, the channel 2 (VCR) up works, and the All Channels (DVD) both work. I can't test Channel 3 (HT) since I have only two receivers controlling two sets of shades. The only signal that appears to transmit continuously when the button is held is the TV up. The rest only give one short burst of the transmit LED.

I guess I ought to learn individual button presses several times to see if the learns are repeatable.

[Capn Trips]

Well, the learns are NOT repeatable, as indicated in THIS FILE. Most do not decode at all, but I can add to the list of protocols/devices above, now: an s16a:0, an Emerson:62, and an Aiwa:7989

A number of them give me the following alert in IR's Learned Signals Tab:

"This signal contains a section that IR doesn't know how to analyze. Please save this data and post it in the diagnostics section of the jp1 group, and post a message indicating that you have done so."

Help decoding this, please?

The Capn

[johnsfine]

I assume all the decodes are wrong.

I haven't had time to investigate seriously.

The s16a and "Old Panasonic" decodes are coming from the old decoder inside IR.EXE, not from the new one in DecodeIr. I'm not certain about the other decodes.

There is a ProtocolSupportLevel entry point in DecodeIr, which is supposed to tell IR.EXE to suppress certain decodes from the old decoder. It should be suppressing those (but I've previously observed that it doesn't). I'm not sure whether I can change something to fix that or whether Mark needs to.

I'll try to find time to figure out this Somfy protocol and add it to the decoder and hopefully add it to RemoteMaster's protocols.ini as well (since decoding doesn't do you much good without the ability to create an upgrade.

[Capn Trips]

Right - thanks.

Most of the learned signals work just fine. On a whim, I created a Device Combiner upgrade to "test" the handful of decodes, and - not at all surprisingly - none of them worked.

Searching out SOMFY's websiteyielded nothing of any particular use on the technical documentation page. The PDF for the Multi-Channel Infrared Control (MCIR) resembles in name only the unit I have, but none of the pictures match the dinosaur OEM remote I'm trying to replicate here.

[johnsfine]

I think I see the pattern mixed in the trash of those learns, but:

1) If it is the simple pattern that it seems to be then TV:Up and TV:Right from your last file are the same command. Is that correct?

2) If it is that simple pattern then there is a problem with the batteries in your Somfy remote. The signal starts out OK in each learn and then weakens so that the 8910 can no longer follow it after a couple frames (and can't detect the repeat pattern).

To see what the full repeat pattern looks like, I'd need learns done with new batteries in the Somfy remote.

It's a slighly tricky protocol for our simple methods of creating a protocol executor. The Zero bit is an ordinay burst, but the One bit is two bursts.

[Capn Trips]

[Capn Trips]

HERE is the NEW FILE of Learned Signals

There is a total of 8 commands. "Up" and "Down" for each of three channels and for "All channels"

I learned them all once (to "Up" and "Down" buttons for TV, VCR, DVD, and Aux, respectively as channels 1, 2, 3, and "all") and then repeated seven of them (until I ran out of memory) on the corresponding "Right" (Up) and "Left" (Down) buttons.

Many fewer spurious decodes, and the mis-identified decodes are at the "end" - if you will, after several consecutive learns, so perhaps the battery drain contributed to that.

[The Robman]

If you're 100% positive that the batteries are good (did you use a battery tester?), maybe you should try spraying some contact cleaner on the battery contacts.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

In that third set I don't see anything to hint at battery problems.

I nearly have this all understood. I have been confused about which learns were supposed to be the same and which were supposed to be different. But now I think I can tell.

What I'm calling a '1' bit seems to randomly learn as one of two different things:
+336 -92 +252 -518
or
+644 -526

The zero bit consistently learns as:
+308 -878

All of those numbers are subject to the usual random variations.

Initially I thought that the '1' encoded as +336 -92 +252 -518 was correct and the +644 -526 was incorrect (sampling error). But then I would expect these learns to work very badly or not at all. If I understand the description, too many of them work for that theory. So that says +644 -526 is correct and +336 -92 +252 -518 is a learning error, which implies a phase glitch in the original. UEI learning systems are rather picky about the phase glitches generated by some original remotes. If all that is correct the Somfy IR receiver is very non picky about anything that happens at the point where the phase glitch exists. It seems to even accept the gap at that point generated by the UEI mislearn.

Anyway, +644 -526 is a lot easier to generate in a simple protocol than +336 -92 +252 -518. I should be able to throw something together with the PB spreadsheet later today.

It's a little annoying that in just 8 different signals the bits at both ends of the string of nine seem to vary independently. If a bit at either end were redundant, I could use single byte hex commands. For nine independent bits I need 2 byte hex commands.

[johnsfine]

I just added DecodeIr support for my approximate understanding of Somfy.
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip

There are 9 bits.

The first two are the command: 1 for up, 2 for down. I put that in the OBC field.

The next two are the device: 1, 2, 3 and 0 in the order you learned them.

The next bit is always zero. DecodeIr makes it part of the device, so it would report a device 4 through 7 if that bit were ever set.

I have no clue what the next 4 bits are. I made DecodeIr decode them as Subdevice. But that is certainly not correct. They are probably some check nibble whose rules I can't figure out from 8 samples.

Next I'll try to add protocols.ini support to make an upgrade. I think I can kludge the bit that's always zero, so that only one byte of fixed data is needed and so that RM can have all fields (device, subdevice and OBC) on the functions sheet independent per command (so calling this 4 device numbers doesn't mean it needs a combo nor multiple upgrades).

[johnsfine]

To create an upgrade in RM, edit the following block into Protocols.ini

[Somfy]
PID=00 A1
VariantName=Somfy2
CmdParms=Device:3,SubDevice:4,OBC:2
CmdTranslator=Translator(lsb,0,3,2) Translator(lsb,1,4,5) Translator(lsb,2,2)
DefaultCmd=00 00
Code.S3C80= 41 9B 02 8B 15 88 05 08 08 01 4E 00 F0 00 9A 01 A4 04 9C 04 0C 00 DE FF FF 01 8D 01 46

I did that in my copy and created an upgrade to put the 8 commands onto digits 0 through 7. RM's output is:

Upgrade protocol 0 = 00 a1 (S3C80) Somfy (RM v1.21)
41 9b 02 8b 15 88 05 08 08 01 4e 00 f0 00 9a 01
a4 04 9c 04 0c 00 de ff ff 01 8d 01 46
End

Upgrade code 0 = d5 4d (Home Auto/1357) (RM v1.21)
a1 00 81
a0 80 61 80 94 80 55 80 b2 80 73 80 87 00 46 80
00 00 00 00
End

I haven't tested it yet (learned from one OFA remote to another and decode).

While typing in the upgrade I saw a simple pattern to the unknown byte:

SubDevice = OBC*4 + Device + 3

I'm not sure that isn't accidental. But if there are only 8 commands it doesn't matter if it's accidental. RM could be programmed to compute it for you and save you getting the Subdevice from a decode.

If you want to test commands outside the basic 8 (Such as OBC's 0 or 3) it would be nice to know if that SubDevice formula is real.

[The Robman]

Here's the binary, for anyone else that's trying to follow along...

A up; 10 000 1110
1 up; 10 100 0001
2 up; 10 010 1001
3 up; 10 110 0101

A dn; 01 000 1101
1 dn; 01 100 0011
2 dn; 01 010 1011
3 dn; 01 110 0111
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[Capn Trips]

[Capn Trips]

I have found these SOMFY codes for screen controls over at RC Central. I'm not sure how to decode them with DecodeCCF, however. Do they fit into any overall scheme you're seeing with these signals?

[johnsfine]