JP1 Remotes

3FG · Expert Joined: 19 May 2009 Posts: 3367

DecodeIR had a bug which occurred when the IR signal doesn't contain base 4 values 2 or 3. In that case DecodeIR was incorrectly estimating the duration of the 4 phases as 3 units instead of the correct 4. I've updated the dll and source lnked to in the first post in this thread. I changed DecodeIR.html to use the IRP recommended by Barf:

Barf · Posted: Wed Oct 24, 2012 3:04 am Post subject:

Thanx. It fixes some of the missing decodes, unfortunately not all. I still get 43870 fails Crying or Very sad

. The first is 0.34 68.

jetskier · Joined: 09 Dec 2003 Posts: 287 Location: Nevada

I just noticed there is an "Elan" decode added. Which Elan is it???

I'm trying to decode the carrier version of my Elan equipment under this thread:

http://www.hifi-remote.com/forums/viewtopic.php?t=14270

When I opened up the decode source, I found the IRP for Elan in the current DecodeIR.dll as

{40.2k,398,msb}<1,-1|1,-2>(3,-2,D:8,~D:8,2,-2,F:8,~F:8,1,^50m)

The IRP for the Elan I have is slightly different, but I know there are a few Elan variants out there too. I haven't had time to do more work on the protocol, but there is a CCF out there.

thoughts?

3FG · Expert Joined: 19 May 2009 Posts: 3367

The Elan equipment you have uses RECS80 (version 90) and it has no carrier. As you have found, lots of IR related equipment (repeaters, etc.) don't handle RECS80 well, especially the carrier less version. I don't think any company has designed equipment in the last decade or so that uses RECS80, although some companies (like Velleman) are using modified versions with longer on pulses.

Elan makes other equipment that uses a different IR protocol, which we have called Elan, for lack of a better name. BTW, from my point of view, RECS80 and Elan are really quite different. RECS80 has a very short on pulse, with off times of 31 or 47 times longer. The Elan IR protocol has off times that are 1 or 2 times as long as the on time.

jetskier · Joined: 09 Dec 2003 Posts: 287 Location: Nevada

Barf · Posted: Wed Oct 24, 2012 12:15 pm Post subject:

This seems to be the thread where the "Elan" protocol was "defined".

jetskier · Joined: 09 Dec 2003 Posts: 287 Location: Nevada

3FG · Expert Joined: 19 May 2009 Posts: 3367

Let me try to be more specific.
I'm quite sure that the Elan Z880 is designed to use RECS80(90) IR protocol, based on some private conversations and proprietary IR databases. It is not an "Elan" protocol.

The V883 uses the IR protocol we have called Elan.

The Elan XMR3 uses roughly {57KHz, 840}<1,-1|1-,-3>(4,-4,D:6,F:8,~D:6,~F:6). And there are some others that use NEC IR protocol. It is reasonable to believe that Elan brands equipment designed by others.

If I understand your situation correctly, recently you've added an IR receiver that doesn't pass RECS80(90), and are trying to use a 40KHz IR protocol that is neither REC80(90) nor Velleman, but which is recognized by the receiver and the Z880. Unless I misunderstand you, this IR protocol has nothing to do with Elan equipment, and is not the "classic" form of Elan.

jetskier · Joined: 09 Dec 2003 Posts: 287 Location: Nevada

jetskier · Joined: 09 Dec 2003 Posts: 287 Location: Nevada

Ok. I did a little more digging on the Elan signals in the VIA Tools IR library (proprietary software for programming Elan equipment).

The IR protocol that is called Elan in DecodeIR seems to be the version used in the newer equipment (i.e. a/v switchers & matrices). The one I call Elan Classic covers the old a/v switchers like the Z880, S6, Z630 with a carrier frequency of 40.2kHz and decodes as Velleman in DecodeIR. There are a couple other variants at 38kHz for some other volume controls, tuners and dj type devices but not their core A/V switchers.

The XMR3 looks to be a one of a kind. The wave form looks nothing like any other in the Elan library.

I don't think Elan brands their switchers from others.

3FG · Expert Joined: 19 May 2009 Posts: 3367

So I've uploaded yet another version of DecodeIR, which seems to work for all device numbers, and all even subdevices, and I believe actually for all subdevices.

Perhaps people are wondering why I haven't tested Humax more completely. The only real signals we have all work fine. Testing with IrpMaster or IrMaster basically works quite poorly on my computer. Almost all signals that have a even subdevice or function number don't decode. Yet the Pronto Hex is fine, and decodes correctly if pasted into IRScope. This isn't the only IR protocol where something like this happens-- for Bose, OBCs greater than 127 don't decode in IrMaster but do in IRScope.

The oddity is that for Humax 4 Phase, if I attach the C++ debugger to the IrMaster process, then it decodes the even subs and OBCs. This is true even if no breakpoints are set or if IrMaster is using the release version of the dll. I can check the durations passed to the dll using the debugger, and these agree between IRScope and IrMaster. But on the other hand, with the debugger running, everything decodes fine, so it is not surprising that the durations are OK.

Barf · Posted: Fri Oct 26, 2012 1:37 pm Post subject:

Dave, thanx for all the hard work. Much appreciated!

3FG · Expert Joined: 19 May 2009 Posts: 3367

Barf,
Thanks for the reply. I did more work last night, which I have tested for all devices and subcodes for function numbers up to 25. All of these do provide a decode of Humax, although quite a few also give Nokia 12 or the dreaded Asynch decode. I'll see if I can suppress the Nokia decodes, unless it turns out that Nokia12 really looks the same. BTW, DecodeIR does try multiple protocols unless the individual routines specifically disable that feature.

IR.exe was able to demonstrate the problem even with the debugger running.The bad news is that the change I made to get better decodes is probably (but I'm not quite sure) just covering up a more basic problem. DecodeIR begins by dividing the signal into frames, seemingly based on lead outs. For some signals, it packages two frames into one. So I've copied an approach already contained in one of the other routines that searches for each lead out in the array of durations. The issue only matters for those signals that change (e.g. toggle) between frames.

3FG · Expert Joined: 19 May 2009 Posts: 3367

The newly posted DecodeIR 2.44 v5 decodes all combinations of Humax 4Phase signals with no false decodes. It tightens up the decoding requirements for Nokia12 and Sony8 in order to avoid these false decodes.

However, the Async decodes can't be discriminated against--8192 Humax 4Phase signals are an exact fit to Async. I've decided to disable the Async decoder. We have dozens of posts describing false Async decodes, and none (I even checked learns in the Yahoo file section) that are legitimate decodes. We do see genuine decodes of AirBoard and AirAsync, which are also asynchronous serial signals, and DecodeIR will still recognize those.

To be decoded as Async, an IR signal needs only to have a high-low edge repeated 5 times with the same time spacing between those edges. Additional intervening edges don't matter. With the increasing number of biphase and other phased IR protocols in use, we're seeing more of these spurious Async decodes.