JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

DecodeIR 2.44
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Sat Oct 06, 2012 7:51 pm    Post subject: Reply with quote

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.

_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Oct 06, 2012 9:35 pm    Post subject: Reply with quote

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:

  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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sun Oct 07, 2012 12:32 am    Post subject: Reply with quote

Use this in protocols.ini:
Code:
[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
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Oct 07, 2012 3:55 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Thu Oct 11, 2012 2:06 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun Oct 21, 2012 4:43 am    Post subject: Reply with quote

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

Quote:
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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sun Oct 21, 2012 5:20 pm    Post subject: Reply with quote

Code:
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:
{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.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Oct 22, 2012 5:20 am    Post subject: Reply with quote

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:
(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...
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Oct 22, 2012 7:04 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Oct 22, 2012 7:27 am    Post subject: Reply with quote

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:

/**
   * Decode.
   *
   * @return true, if successful
   */
  public synchronized boolean decode()
  {
    return decode2( decoder_ctx, bursts, repeatPart, extraPart, frequency );
  }
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Oct 22, 2012 7:35 am    Post subject: Reply with quote

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

Code:
  // 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:
      decodeIR.initDecoder();
      decodes = new ArrayList< LearnedSignalDecode >();
      while ( decodeIR.decode() )
      {
        decodes.add( new LearnedSignalDecode( decodeIR ) );
      }

_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Oct 22, 2012 8:10 am    Post subject: Reply with quote

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:
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:
$ 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...
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Oct 22, 2012 9:46 am    Post subject: Reply with quote

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. Embarassed
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Oct 22, 2012 10:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Oct 22, 2012 1:13 pm    Post subject: Reply with quote

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

On the other hand, I don't think that
Code:
(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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control