|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21210 Location: Chicago, IL |
Posted: Sat Oct 06, 2012 7:51 pm Post subject: |
|
|
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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3365
|
Posted: Sat Oct 06, 2012 9:35 pm Post subject: |
|
|
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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3365
|
Posted: Sun Oct 07, 2012 12:32 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Sun Oct 07, 2012 3:55 am Post subject: |
|
|
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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3365
|
Posted: Thu Oct 11, 2012 2:06 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Sun Oct 21, 2012 4:43 am Post subject: |
|
|
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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3365
|
Posted: Sun Oct 21, 2012 5:20 pm Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Mon Oct 22, 2012 5:20 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Mon Oct 22, 2012 7:04 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Mon Oct 22, 2012 7:27 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Mon Oct 22, 2012 7:35 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Mon Oct 22, 2012 8:10 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Mon Oct 22, 2012 9:46 am Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Mon Oct 22, 2012 10:41 am Post subject: |
|
|
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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3365
|
Posted: Mon Oct 22, 2012 1:13 pm Post subject: |
|
|
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 |
|
|
|
|
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
|