JP1 Remotes

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

[Edit by mathdon: This post concerns IRWidget/IRScope and was the first in a separate thread that I have merged with this one, as the solution is a matter for DecodeIR. The replies to this post are now on page 2 of this thread.]

Would it be possible to include some indication of repeating signals in the decoder part?

The reason I ask is that when a protocol puts out only the non-data part of the message (JVC, NEC1), the decoder reports the values once and only looking at the graph and/or the raw data file tells the complete story. In contrast, when the protocol puts out complete messages during the repeats, the decoder displays every repeat.

Two examples - pictures and raw data
NEC1: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6781
PanasonicCombo: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6784
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

mathdon

I wrote in another thread as follows:

The Robman · Posted: Thu Sep 03, 2009 9:49 am Post subject:

The PID issue is tricky. I gave my thoughts on one way that we could handle it here:
http://www.hifi-remote.com/forums/viewtopic.php?p=79097#79097

I don't know if UEI is going to use up the last few remaining sub-$01FF PIDs, but I expect they will (with the exception of $01FF itself, which is designated for "special" purposes).

Another possibility, at least as a short term solution, would be to have a special folder in the file section where there are sample upgrades that use all of these homemade executors, then if DecodeIR adds something to the protocol name to indicate that it's a homemade executor, that would be the user's clue to check that folder for a template for their upgrade.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

johnsfine · Posted: Thu Sep 03, 2009 3:27 pm Post subject:

Re decodeIr.dll, I'm real sorry about my lack of progress. I keep trying to find time.
You can release something without my testing if you like and I'll catch up later when I can. I don't think anyone would get too confused by that.

Re the shortage of pids, I think at some point we will need to make a significant change to IR.exe and to rmir so they can dynamically assign unused pids for upgrade protocols rather than force the pid to be selected when the device upgrade is created.

mathdon · Posted: Fri Sep 11, 2009 12:59 pm Post subject:

Thanks, John. I have done so and posted DecodeIR v2.37 here.
______________
Graham

mathdon · Posted: Sun Sep 13, 2009 5:30 am Post subject:

Unfortunately I used MS Word to edit DecodeIR.html and it made a real mess of it. As I don't have any dedicated HTML editing tools I have now re-done the edits, starting again from John's version, but this time using a text editor to edit the raw HTML. So no traces of MS Word remain. The link is the same as in the message above.
________________
Graham

arrow · Joined: 01 Sep 2009 Posts: 5

I have by Protocol Grundig 16 an error when trying to get Code Summary in DecodeIR version 237, and DecodeIR 236 versions is not. Also not receive indifitsirovat device - learned signals Protocol Grundig16 Device 81 , but Fixed data 33 ? Error include http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7240 .

mathdon · Posted: Tue Sep 15, 2009 12:04 pm Post subject:

Hi, Arrow. Thank you for your bug report. It seems to have been a memory overwriting problem, as I found with your file that it did not always happen, and when it did, I got a different error message from yours.

I think I have solved it. I have posted DecodeIR.dll v2.38 Beta for you to test. It is not intended for anyone else, as I think the circumstances in which this error occurs are very rare.

Please try it and post a message here to say if it solves your problem. Please post the message, whether it solves the problem or not, as I need to know in either case.

I do not understand "Also not receive indifitsirovat device". If you still have a problem with this, please try to explain it in more detail. I realise you have difficulty with the English language, but do the best you can.
_____________
Graham

arrow · Joined: 01 Sep 2009 Posts: 5

Thank you for patience . DecodeIR.dll v2.38 error repeated similarly DecodeIR.dll v2.37 .
Regarding "Also not receive indifitsirovat device" I wanted to say that the DecodeIR decodes the learning signal device 81, but the empirical data I get fixed data 33 and they cannot relate to each other. I was obtained protocol Grundig16 device 51 .

mathdon · Posted: Wed Sep 16, 2009 2:51 am Post subject:

Sorry I wasn't successful. I'll look further, but it's become more difficult now as I cannot repeat your error. I may post a temporary version for you to check, in which I disable a suspicious part of the code, to try to locate where the problem occurs.

Please post a message to say what version of Windows you are using. I assume you are using IR 8.01 RC5, the latest development version, but if not then please also say what IR.exe version you are using.
__________________
Graham

mathdon · Posted: Wed Sep 16, 2009 7:38 am Post subject:

I can explain the translation of the pulse train in your graphical image into data parameters. The IRP for the Grundig16 protocol is:

{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,D:1:6,T:1,F:8,D:6,-100)+

The line in your image which says Fixed Data = 33, Device = 81 has the following pulse lengths, after the 3 lead-in pulses on the left:

(-2 +1 -2 + 1)(-4 +2)(-4 +2)(-4 +2)(-3 +1 -1 +1)(-3 +1 -1 +1)(-4 +2)(-3 +1 -1 +)

where the brackets are mine, to divide the pulses into the groups shown in the IRP. Those groups in the IRP represent the bit pairs 00, 01, 10, 11, so the pulse train converts to binary as:

(10)(00)(00)(00)(01)(01)(00)(01).

If you bracket these according to the IRP parameters you get

(1)(0)(00000001)(010001)

which means

D:1:6 = 1 (this is bit 6 of D)
T:1 = 0 (this is T)
F:8 = 00000001 (this is F)
D:6 = 010001 (this is bits 0-5 of D)

So putting the 7 bits of D together gives 1010001 = $51, which in decimal is 81. So

D = 81 (device code), T = 0, F = 1 (OBC).

I don't know where the Fixed Data = 33 comes from, as I cannot see anything like 33 in the pulse train, but Fixed Data does not come from DecodeIR. I have tried to explain how the pulse train (which seems to be for key PPV) is translated into the values shown in the decode by DecodeIR. I hope this is helpful.
______________
Graham

mathdon · Posted: Wed Sep 16, 2009 8:27 am Post subject:

Hi again, Arrow. Could you please do some tests to help me to find the source of your problem with DecodeIR v2.37.

1. With your Grundig16 learned signals, please open each of the keys in the list box (the up and down cursor keys will move from one to another). I need to know whether they all display correctly, whether none of them do, or whether some are correct and some give your Floating Point Error. If some keys give an error, please tell me which ones. (With the problem I experienced yesterday with your file, I found that certain keys gave an error. Just Green and Stop, I think, but there may have been one or two more.) This will give me more information than just knowing that Code Summary gives an error, since Code Summary reads all the keys at once.

2. Please learn some signals from another remote control, one with a different protocol than Grundig16, and see if that gives trouble. I need to know whether it is specific to Grundig16 or is a more general problem.

3. When you get the "Invalid floating point operation" error, what happens if you press OK on the error box?

4. When you said that the DecodeIR v2.38 Beta gave the same problem, did you check that the version number on the Learned Signals page did say 2.38 Beta? I would just like to be absolutely certain of this, as I cannot make 2.38 Beta go wrong and as yet I cannot find any other error with the program.

Thank you in advance. I really would like to get to the bottom of this problem.
______________
Graham

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Ok, will do. I'm still trying to get a baseline of what might be the cause of this utterly UNIMPORTANT event. Will be back on this one. Thanks for rc6beta, as you say, switching versions just does the job. And if you really fixed it, it'll be rough to prove the negative ...

More important,
I notice that learned signals are decoded slightly differently in RC5(8.0.1.11) than 8.0.1 dev build3. I have JVC signals, and normally they decode to JVC and JVC{2}. But in RC5 is also Gap. That's just opening the file from previous version.
I don't understand much of the Decode.IR changes discussed above, and likely this is a feature, but I just wonder.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

mathdon · Posted: Wed Sep 16, 2009 3:07 pm Post subject:

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348