Elan Equipment (Z880, Z100, Z150 & System 6)

[jetskier]

Does any one have any codes for the Elan Home Systems Equipment? I am looking to program a remote to interface with the in-room keypads, but there seems to be no support other than dealer only.

[The Robman]

Please read #1 FAQ

[jetskier]

Please read #1 FAQ

Where does one find this #1 FAQ? If you click the FAQ at the top, it does not have a #1. Maybe you can post a link for me.

Thanks

[jetskier]

Nevermind..

You should have said

"The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) "

[The Robman]

More typing than I was prepared to do. As you might imagine, we have to tell people this over, and over, and over, again!

[jetskier]

Now that I have read the #1 FAQ. Let me elaborate.

I have the JP1, two compatible learning remotes (RS 2104 and OFA 8810) that do interface with the JP1 quite nicely. Problem is, Elan does not supply any OEM remotes with their equipment. They used to, but not anymore. Most programming is done with the dealer and his "VIA Tools" Programming interface. They will not sell these to the consumer. I'd like to program my remotes until the dealer can get to my place.

I have searched and searched the Yahoo group and Remote-Central with no success. My dealer can learn me some codes, but he is not available for weeks. I thought someone out there may have the protocol and a few OBC/EFC codes so I can find the rest with experimentation.

Also, my dealer did say that the Elan components do not have a frequency in their IR strings. Will that be problem with learning?

That's all.

[johnsfine]

I haven't read that item myself, so I don't know whether it mentions advanced methods for dealing with the lact of original remote, such as finding codes somewhere like this
http://www.remotecentral.com/cgi-bin/fi ... r=elan&fc=
and running those through DecodeCCF to get a JP1 usable form.

Probably, you'll need some expert help after trying that, but you should at least check to see if one of those code sets sounds like it is the same thing you're trying to get (we don't have the device, which makes it much harder for us to guess whether something at RC is the same thing as what you're asking for).

[johnsfine]

Also, my dealer did say that the Elan components do not have a frequency in their IR strings. Will that be problem with learning?

I'm impressed with that dealer. Most dealers of such equipment wouldn't be able to get as close to understandable as "do not have a frequency in their IR strings" to describe an unmodulated IR signal.

Those are a little harder to learn, but not terribly hard.

I looked at the CCF for the Z-100 and Z-150 keypads. It uses unmodulated RECS80 protocol, devices 0 and 3.

There are a few forms of RECS80 and you need the right one. I wrote DecodeIR and its documentation, but I still needed to look in the DecodeIR documentation myself to see what it says to do with RECS80.

Unfortunately it only lists the UEI protocol for two of the forms of RECS80 and neither of them is this one.

I expect there is a UEI protocol for this form of RECS80, but I don't know which it is. Maybe Rob or Jon or another expert can tell us.

If there isn't a UEI protocol for it, I think it would be fairly easy to create one in PB. But if there is one, it would be better to use it (and update DecodeIR and preotocols.ini to make it easier to use).

But it also may work to use the modulated version which has the same overall timing (0045). The device receiving the commands probably ignores the signal for a long enough time after each "leading edge" that it could ignore the modulation entirely and do the right thing.

[jon_armstrong]

I expect there is a UEI protocol for this form of RECS80, but I don't know which it is. Maybe Rob or Jon or another expert can tell us.

$0090 -- I just tested and decode IR identifies it as RECS80 and it is Zero frequency.

[johnsfine]

$0090 sure looks like the right protocol for the Elan devices. I'm now less confident that it's actually RECS80. But if it isn't RECS80, it may be too similar to RECS80 for DecodeIR to ever tell them apart.

Am I correct that $0090 has two toggle bits?
(T:2,D:3:F:6,^???)+

The 7000 format strings for the Elan Z880 (that DecodeCCF.exe can't decode) seem to have two toggle bits. I haven't manually checled the 0000 format decodes for any evidence of two toggle bits.

Also, IIUC, the low bit of fixed data in $0090 selects between two different bit timings. The one that matches these signals is low bit clear, correct?

So a protocols.ini entry should have a pull down choice for timing, as well as having a 3 bit device number.

I also should check whether the two different device numbers reported by DecodeIR were correct, or a bug, or a misalignment caused by the extra toggle bit.

[jon_armstrong]

$0090 sure looks like the right protocol for the Elan devices. I'm now less confident that it's actually RECS80. But if it isn't RECS80, it may be too similar to RECS80 for DecodeIR to ever tell them apart.

Am I correct that $0090 has two toggle bits?
(T:2,D:3:F:6,^???)+

Yes it does, but I didn't realize that before you asked

The 7000 format strings for the Elan Z880 (that DecodeCCF.exe can't decode) seem to have two toggle bits. I haven't manually checled the 0000 format decodes for any evidence of two toggle bits.

Also, IIUC, the low bit of fixed data in $0090 selects between two different bit timings. The one that matches these signals is low bit clear, correct?

Didn't realize that either

The default in protocols.ini in RM is FixedData=00 (I just copied the RECS80(45))

That results in burst pairs <+20 -5028|+20 -7552> for the data bits and a lead out of +20 -55862

So a protocols.ini entry should have a pull down choice for timing, as well as having a 3 bit device number.

I also should check whether the two different device numbers reported by DecodeIR were correct, or a bug, or a misalignment caused by the extra toggle bit.

I didn't see that. I only did a few OBC's and they decoded perfectly.

I'll go test when the bottom bit is 1 in fixed data, but I thought I would answer first.

[The Robman]

I'm normally good at this stuff, but you guys (John and Jon) are going too fast for me. I downloaded the CCF and ran it against DecodeCCF but it didn't recognize the signals (lots of GAP statements) so i ran it against CCF2EFC instead and it shows a "0100" in the first word of Pronto Hex (rather than the customary "0000" for raw learned signals) and I don't remember what "0100" means.

So given that, how did you manage to already figure out that it's RECS80, etc?

[johnsfine]

I'm normally good at this stuff, but you guys (John and Jon) are going too fast for me. I downloaded the CCF and ran it against DecodeCCF but it didn't recognize the signals (lots of GAP statements) so i ran it against CCF2EFC instead and it shows a "0100" in the first word of Pronto Hex (rather than the customary "0000" for raw learned signals) and I don't remember what "0100" means.

So given that, how did you manage to already figure out that it's RECS80, etc?

I used DecodeCCF, not CCF2EFC. I'm not sure Jon even looked at those CCF files (maybe he took my word for THAT and decoded just the learn from one remote to another of $0090).

0100 instead of 0000 means unmodulated (zero frequency).

Long after switching to DecodeCCF (which handles 0100 just fine) I had occasion to try with CCF2EFC some 0100 signals that worked in DecodeCCF and was amazed that it didn't work, because I was decoding 0100 type signals with CCF2EFC before even JP1 existed. I think somewhere along the line I dropped a good version of CCF2EFC and accidently started adding enhancements to a version from before 0100 support worked right. I'm not sure of all that, because I'm not really interested in debugging or improving CCF2EFC. If it doesn't work, use DecodeCCF instead.

Edit: Oops. I just reread your message more carefully. I shouldn't have triggered off the CCF2EFC so much on first reading.

Are we talking about the same CCF files? I didn't get any gap decodes and did get lots of RECS80 decodes.

[johnsfine]

elan-key-z150.zip contains a lot of signals which decode as RECS80, every one of which has a T value of 2. Plus it has a single signal that didn't decode.

The T=2 tells me I must have previously decided (and forgotten) that the decoder can't distinguish this protocol from the real RECS80, and I made it at least able to report the correct (I hope) T value.

The fact that they all have T=2 probably means that the CCF was not created by a learn from a correct OEM remote but from some other universal programmed without the toggle support.

But maybe it means the TRUE protocol is neither RECS80 nor that 2-toggle-bit thing that looks like RECS80, but something else with no toggle bits.

Anyway the fact that this CCF is supposed to work probably means getting the toggle bits right isn't important.

elan-vid-z880.zip contains only 7000 format signals of a type DecodeCCF doesn't decode. But manually they are device 0 of that two_toggle_bit thing that looks like RECS80.

elan-vid-z880a.zip contains some of those 7000 format signals, plus a couple signals like the ones in that first file. But one has T=0. I think that means toggling the T value is OK, even if it isn't mandatory.

[jon_armstrong]

0100 means Zero frequency learned command in Pronto hex. John figured out RECS80. I really just guessed that $0090 was close and tested it and it decoded as RECS80.

Fixed data bottom bit=0
{0k,msb}<20,-5028|20,-7552>(T:2,D:3,F:6),^121.5m)+

Fixed data bottom bit=1
{0k,msb}<20,-3546|20,-5316>(T:2,D:3,F:6),^89m)+

Add this to RM protocols.ini:

[RECS80 (90)]
PID=00 90
DevParms=Device:3=0,Timing=0:bool
DeviceTranslator=Translator(0,3,2,comp) Translator(1,1,7)
FixedData=00
CmdParms=OBC:6=0
CmdTranslator=Translator(0,6,comp)
DefaultCmd=FC
Notes=Fixed data bottom bit=0 (unchecked)\
\n\n\
{0k,msb}<20,-5028|20,-7552>(T:2,D:3,F:6),^121.5m)+\
\n\n\
Fixed data bottom bit=1 (checked)\
\n\n\
{0k,msb}<20,-3546|20,-5316>(T:2,D:3,F:6),^89m)+.
Code.S3C80= 00 00 11 8B 18 C5 41 05 06 00 06 09 BF 00 06 0E AB EC 40 00 06 06 DB 00 06 0A 4F AC AA 76 03 01 6B 0A 1C 0A 87 21 1D 97 21 13 1A F8 08 00 E0 C0 E0 C0 60 C0 56 C0 C0 56 03 3F 44 C0 03 8D 01 46
Code.740= 00 00 11 80 12 E0 A2 41 04 05 06 07 7E 0A C8 76 2A 05 88 07 D5 56 5F 17 5D 09 A2 06 B5 72 95 6C CA D0 F9 A5 5A 6A 6A 6A 29 C0 05 5D 85 5D 4C 00 FF
Code.6805-C9= 00 00 11 20 12 E0 E0 40 07 05 06 07 72 0A B9 30 42 05 81 07 CE 24 24 01 5A 09 AE 06 E6 6F E7 69 5A 26 F9 B6 57 46 46 46 A4 C0 BA 5A B7 5A CD 01 83 CD 01 92 3F 53 A6 05 B7 52 0F 50 11 00 5A 07 A6 D9 4A 26 FD 26 00 A6 03 AE 4A CD 01 9F 38 50 3A 52 26 E6 00 53 0B 10 53 A6 06 B7 52 CD 01 95 20 D8 CC 01 89
Code.6805-RC16/18= 00 00 11 20 14 C5 41 05 06 04 02 EA 07 02 60 76 2A 03 02 78 05 02 32 56 5F 01 5A 09 AE 07 E6 72 E7 6A 5A 2A F9 B6 57 46 46 46 43 A4 C0 BA 5A B7 5A CC 01 B2