DecodeIR 2.44

[Barf]

On the other hand, I don't think that

Code: Select all

(T=0,<-2,2|-3,1|1,-3|2,-2>(2,-2,D:6,S:6,T:2,F:7,~F:1,^95m,T=1)+)

can be correct IRP. <-2,2|-3,1|1,-3|2,-2> specifies 4 values, and this needs to consume two bits to get a single value. So how are we to interpret F:7? If we take this as three 2 bit values, and interpret the last odd bit as specifying values 0 or 1, then we need also to interpret ~F:1 as specifying bits 0 or 1, and now there are too many burst pairs. If instead we interpret as F:7 as just three two bit values, ignoring the last bit, then we should also ignore ~F:1. Even if we don't ignore ~F:1, that specifies a last value (base 2) of 0 or 1, but the allowed values are 1 or 2.

IMO, when we have specified timings in base 4, IRP should only be valid for bitstreams that have an even number of bits.

This part of the specification states that the individual bitfields are concatenated together before being transformed by the bitspec. Thus, individual bitfields do not have to be of even length, only the sum needs to be. It is also implemented that way in IrpMaster.

I have just started a longer run (takes a few hours), and will possibly know more then.

No more cases occurred.

[3FG]

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:

Code: Select all

{56k,105, msb}<-2,2|-3,1|1,-3|2,-2>(T=0,(2,-2,D:6,S:6,T:2,F:7,~F:1,^95m,T=1)+)

[Barf]

Thanx. It fixes some of the missing decodes, unfortunately not all. I still get 43870 fails . The first is 0.34 68.

[jetskier]

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:

https://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]

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]

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.

There is a 40.2k carrier version of the Elan that I'm trying to get working in my thread. The "no carrier" version seems to get filtered in the newer IR receivers that are LCD resistant.

[Barf]

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

[jetskier]

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

Yep. That is the newer one for the component video switcher that is more complex. The classic one is the one I'm trying to get figured. It doesn't have the mid frame burst

[3FG]

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]

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.

That is the situation. But the carrier version of the IR protocol seems to be specific to Elan and not Velleman since it doesn't respond to it.

[jetskier]

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]

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]

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

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.

I am sorry to say, but I still get 3432 erroneous decodes, A number of signals (first is 2.5. 42) decodes to Nokia12, and nothing more. The good news is that this is the only form of error; previously there were no decodes at all. DecodeIR probably decides that since Nokia12 0 0 fits, it cannot be anything else, and stops trying.

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.

Using an intermediate layer like Java JNI is of course not quite ideal for testing a C++ library and just that. A while ago, I published a main routine that can be used for e.g. testing the library, even surpassing the dynamical loading.

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.

I think Bose is a completely different issue. We discussed this matter in a PM a few weeks ago: First of all, RMIR behaves identical to IrMaster, so it is rather something with JNI as with IrMaster. Secondly, the decoding of Bose for F%128 == 1 in DecodeIR is extremely non-robust, just changing the first "0013" in the CCF to 0012 and it decodes. Or changing the IRP to {...}<1,-1|0.99,-3>, and, again it decodes. This sensitivity is IMHO a DecodeIR-issue, not an IrMaster or RMIR issue.

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.

I strongly suspect that this is the bug described earlier, that makes it necessary to call (Java-) decode() also after it has returned false. That bug faced so that the decodes were failing for every second call, which can easliy be confused with "even argument".

For your convenience, I have uploaded my developement version of IrMaster+IrpMaster as "prerelease". Note the debugoption for DecodeIR, enabled by setting the debug variable to 2048. Options -> DEbug -> 2048: DecodeIR from GUI.

Another thing to try, using 2.44v* and the old IrpMaster 0.2.1 / IrMaster 0.3.0 is to press the decode button TWICE.

Edit (2012-11-25): Prerelease version deleted, since the final version has been released.

[3FG]

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]

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.