DecodeIR 2.44

Post by **The Robman** » Sat Oct 06, 2012 6:51 pm

3FG wrote:I've lost the correct protocols.ini fragment for Humax 4Phase to correspond to the distributed new version of BitExpander. Of course I can reconstruct this, but--

That sucks. I've lost stuff before myself and had to reconstruct it, but it's such a drag. The first time is always fun, because you're inventing something, but the reconstruct is just a chore.

3FG wrote:BTW, as you figured out some months ago, and I think you still know, the natural OBC for Power Toggle is 11, not 22. 22 includes the check bit, and your description of converting to bits does take that into account.

I had totally forgotten everything about this protocol until I re-read it all in the original thread. I just edited my previous post to say OBC 11.

Btw, what is the story with the device codes? Which is correct, the 199.128 that I found or the 15.0 that DecodeIR reports?

The Robman wrote:It doesn't appear that there's a checksum in the 2 device codes, so the fixed data "C3 1C 83 33" should resolve to device code 199 and sub-device 128.

I just found an original file of learns and see that the device codes decode as 15.0 but I'm confused how we got those values. When I convert "C3 1C" to binary, using the chart shown above, I get 11000111 which is decimal 199. Likewise for "83 33", I get 10000000 which is 128.

3FG · Post by **3FG** » Sat Oct 06, 2012 8:35 pm

Well, of course losing stuff is my own fault.
Regarding the device numbers, let's take button 0, which has OBC 10. That decodes to
301320000111 Base 4
110001111000000000010101 Base 2

Grouping these in two ways:

Code: Select all

  11000111 100000 00 0001010 1  199.128,         T = 0, OBC = 10, C = 1
11 0001111 00000  00 0001010 1    15.0   St = 3, T = 0, OBC = 10, C = 1

We don't know if either of these is correct, although a phased protocol must have a start feature of some sort to measure the phase of the following bits, and furthermore the start feature has to be constant in behavior. The initial 3 can't carry any information, and must always be 3. So instead of 199, the device would be 7. The subdevice in this apportionment of bits is 32, not 128, because there are 2 toggle bits.

Trouble is, in DecodeIR, I wanted to not include the 2 start bits in the device number, and somehow chose incorrectly to make it D:7 and S:5. Instead it should be D:6 and S:6 in order to make the device and subdevice numbers fall on base 4 boundaries.

So I think I have to change DecodeIR, and am waiting to read any comments on that.

3FG · Post by **3FG** » Sat Oct 06, 2012 11:32 pm

Use this in protocols.ini:

Code: Select all

[Humax 4Phase]
PID=01 DD
CmdParms=OBC:7=0
DefaultCmd=00 00
CmdTranslator=BitExpander(0,3,0,1,4,03,01,08,0C) BitExpander(0,1,12,0,4,01,08)
DevParms=Device:6=7, subDevice:6=32
FixedData=C3 1C 83 33
DeviceTranslator=BitExpander(0,3,4,0,4,03,01,08,0C) BitExpander(1,3,16,0,4,03,01,08,0C)
Notes=
Code.S3C80=2C 5E 42 8B 0E 8F 00 08 08 00 34 00 00 00 00 00 26 B5 73 F6 01 46 56 06 FD F6 01 0A 7B F5 AF

Use Device = 7 and Subdevice = 32. The conversion from the existing DecodeIR device.subdevice is 15.0 becomes 7.32
0001111 00000
000111 100000

Post by **mathdon** » Sun Oct 07, 2012 2:55 am

3FG wrote:I would appreciate any comments on this plan to issue DecodeIR 2.44b.

My only comment is on the version number. Since v2.44 is still only in the Diagnosis Area, I suggest keeping the version at 2.44 in the software and only changing the version number displayed in the file section entry (which at present is 1, so just make that 2). I am hoping that v2.44 will get into RM/RMIR v2.02 and prefer unqualified version numbers in official releases.

3FG · Post by **3FG** » Thu Oct 11, 2012 1:06 am

I've uploaded the slightly changed DecodeIR binary , source, and a companion protocols.ini.

I apologize that this will require a recompile of the Linux version, and as a reminder, we're still looking for a volunteer to make a Mac OS version.

Barf, the only change is the IRP for Humax 4Phase. It was D:7, S:5, and is now D:6, S:6. This works out better with base 4 arithmetic! So IrProtocols.ini should take that into account, please.

Barf · Post by **Barf** » Sun Oct 21, 2012 3:43 am

I have update the Linux libs; same links as before (second posting in this thread).

Barf, the only change is the IRP for Humax 4Phase. It was D:7, S:5, and is now D:6, S:6. This works out better with base 4 arithmetic! So IrProtocols.ini should take that into account, please.

Exactly what IRP do you want me to use? The one in DecodeIR.htlm differs from the one you gave me in the PM (more than the 7,5 -> 6,6 issue). (The one in the comment in the source is still different, btw.)

Version number: I would strongly prefer all versions to have distinct version numbers.

Let me also point out that we need also a 64 bit Windows version, see e.g. this thread. Using a 32 bit JVM on a 64 bit Windows is a work-around, not a solution.

3FG · Post by **3FG** » Sun Oct 21, 2012 4:20 pm

Code: Select all

irp={56k,105, msb}<-2,2|-3,1|1,-3|2,-2>(T=0,(2,-2,D:6,S:6,T:2,F:6:1,(F+1):2,^95m,T=1)+)  [D:0..63, S:0..63, F:0..127]

This works with IrMaster, and is cleaner/shorter.

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:6:1,<-3,1|1,-3>(F:1,~F:1),^95m,T=1)+)

which is shown in DecodeIR.html makes more clear that the last 2 bits can only take on 2 rather than 4 values. However, I wasn't able to make it work in IrMaster.

Barf · Post by **Barf** » Mon Oct 22, 2012 4:20 am

Those two forms are not exactly equivalent. Instead of (F+1):2 you probably mean (F:1+1):2 (the former takes on all values 0,1,2,3). Secondly <-2,2|-3,1|1,-3|2,-2>((F+1):2) generates one burst pair, <-3,1|1,-3>(F:1,~F:1) generates two.

I seen to have got most signals consistent by using

Code: Select all

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

There is also an issue with the decoding: decode() in DecodeIRCaller.java is supposed to be called until it delivers false. However, the first call always seem to deliver false, subsequent calls, even after calling initDecoder() and even after calling the constructor to construct a new DecodeIRCaller(), returns the decodes that should have been returned the first time. I have implemented a work-around in DecodeIR.java of IrpMaster -- calling decode() again after it delivers false -- that seems to work well.

Even with this work-around, I get 98133 (out of 64*64*128 = 524288) decodes wrong or missing, first being 0.1 8.

Sorry for being such a PITA...

Post by **mathdon** » Mon Oct 22, 2012 6:04 am

Barf wrote:There is also an issue with the decoding: decode() in DecodeIRCaller.java is supposed to be called until it delivers false.

decode() is obsolete and is superseded by decode2(). It is retained only for compatibility with early versions of RMIR.

Barf · Post by **Barf** » Mon Oct 22, 2012 6:27 am

Graham, you are talking about the C API, while I was talking about the Java API in DecodeIRCaller.java. This should hopefully have been clear from my posting. BTW, it reads

Code: Select all

/**
   * Decode.
   * 
   * @return true, if successful
   */
  public synchronized boolean decode()
  {
    return decode2( decoder_ctx, bursts, repeatPart, extraPart, frequency );
  }

Post by **mathdon** » Mon Oct 22, 2012 6:35 am

Sorry, Barf, you are right. I was looking at the versions with arguments:

Code: Select all

  // declaration of decode(...), now unused, retained so that it is
  // included in DecodeIRCaller.h
  private native boolean decode( int[] decoder_ctx, int[] bursts, int r, int freq );

  private native boolean decode2( int[] decoder_ctx, int[] bursts, int r, int e, int freq );

All I can say is that the following code from RMIR has been unchanged for years and has not resulted in any problems:

Code: Select all

      decodeIR.initDecoder();
      decodes = new ArrayList< LearnedSignalDecode >();
      while ( decodeIR.decode() )
      {
        decodes.add( new LearnedSignalDecode( decodeIR ) );
      }

Barf · Post by **Barf** » Mon Oct 22, 2012 7:10 am

The versions with arguments are private, so they are not a part of the API.

If decode() (Java!) returns false, the RMIR code just returns "no decode" which is not a "problem". Also, it is not unlikely that this is a new problem with 2.44. Anyhow, the present (development) code in IrpMaster (DecodeIR.java) is similar to RMIR, and reads

Code: Select all

ArrayList<DecodedSignal> work = new ArrayList<DecodedSignal>();
        while (dirc.decode()) {
            work.add(new DecodedSignal(dirc.getProtocolName(),
                    dirc.getDevice(),
                    dirc.getSubDevice(),
                    dirc.getOBC(),
                    dirc.getHex(),
                    dirc.getMiscMessage(),
                    dirc.getErrorMessage()));
        }
        
        if (work.isEmpty() && decodeIRBugWorkaround) {
            while (dirc.decode()) {
                Debug.debugDecodeIR("DecodeIR bug workaround produced result for devide = " + dirc.getDevice()
                        + ", subdevice = " + dirc.getSubDevice()
                        + ", function = " + dirc.getOBC());
            work.add(new DecodedSignal(dirc.getProtocolName(),
                    dirc.getDevice(),
                    dirc.getSubDevice(),
                    dirc.getOBC(),
                    dirc.getHex(),
                    dirc.getMiscMessage(),
                    dirc.getErrorMessage()));
            }
        }

So, if the decode() works as specified, the debug message should never occur. But it does:

Code: Select all

$ java -jar dist/IrpMaster.jar -c data/IrpProtocols.ini -d 2048  --decodeir "humax 4phase" 0 0 0
Debug[DecodeIR]: Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
DecodeIR result: Debug[DecodeIR]: DecodeIR was setup with f=56000, repeat=24, ending=0, data=[210, 420, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 315, 105, 89960, 210, 420, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 210, 315, 105, 210, 210, 210, 210, 210, 210, 315, 105, 89960]
Debug[DecodeIR]: DecodeIR bug workaround produced result for devide = 0, subdevice = 0, function = 0
Debug[DecodeIR]: DecodeIR bug workaround produced result for devide = 0, subdevice = 0, function = 0
Debug[DecodeIR]: protocol = Humax 4Phase, device = 0, subdevice = 0, obc = 0: success
success
Debug[DecodeIR]: protocol = Humax 4Phase, device = 0, subdevice = 0, obc = 0, misc = no start frame: success

Looking at the code in DecodeIR.cpp, tryHumax(), there is some very creative use of function-local static variables...

Post by **mathdon** » Mon Oct 22, 2012 8:46 am

Barf wrote:There is also an issue with the decoding: decode() in DecodeIRCaller.java is supposed to be called until it delivers false. However, the first call always seem to deliver false

I took "also" to mean that what had gone before was specific to Humax but that now you were raising a general issue, and were saying that the first call to decode() always seems to deliver false. I didn't think that could be right.

I believe now you meant that this happens always with Humax but not other protocols. Since I know nothing of Humax, I can't comment on this behaviour. Sorry for my misunderstandings.

Barf · Post by **Barf** » Mon Oct 22, 2012 9:41 am

My present state of knowledge is this:

It happens for some, possibly all, decodes of Humax 4Phase. I do not know if it happens for some other signals. I have just started a longer run (takes a few hours), and will possibly know more then.

3FG · Post by **3FG** » Mon Oct 22, 2012 12:13 pm

Barf,
Yes, what is actually needed is (F:1+1):2. Thank you.

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.

Regarding tryHumax, there are two general areas where it could be wrong. The first is the decode of the 4 phase burst pairs. The second is logic which is intended to be analogous to that used for all IR signals which have toggle bits that change state. For example, Amino, Zaptor, or CanalSat. That's where the interesting use of local static variables comes in. Those are not my invention, and I may have erred in copying that logic.