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: Where do we go from here?
Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2308

PostPosted: Mon Jun 01, 2009 12:47 pm    Post subject: DecodeIR: Where do we go from here? Reply with quote

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


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

PostPosted: Thu Sep 03, 2009 8:26 am    Post subject: DecodeIR: Where do we go from here? Reply with quote

I wrote in another thread as follows:

mathdon wrote:
IR 8.01 RC4 with DecodeIR 2.37 Beta posted

I have posted IR 8.01 Release Candidate 4. ...

I have included DecodeIR v2.37 Beta in a separate folder in this distribution, together with updated ReadMe and ChangeLog files. ...

This distribution also includes a file ProtocolsX.ini. This contains the additions needed to protocols.ini to enable RM to create device upgrades for the protocols newly added to DecodeIR. I have needed 4 non-UEI PIDs and have used 01EC to 01EF, for want of anything better. ...

I look forward to receiving comments.

So far, no comments. I trust that no news is good news. But where do we go from here? I asked earlier:

The Robman wrote:
mathdon wrote:
Is there any point in DecodeIR identifying protocols that do not correspond to any UEIC PID?

Abso-friggin-lutely! Having DecodeIR recognize a non-UEI protocol saves me from accidentally decoding it more than once, and in the case of complicated protocols like XMP it would save me from having to do some really tedious time-consuming decodes.

So there are six new protocols in DecodeIR v2.37 Beta, of which four have no known UEI PIDs. That's OK in the sense that DecodeIR shows protocol names (generally of JP1 invention, as far as I can tell) rather than PIDs, but it will be frustrating to a user if that is the endpoint. Sure, he or she then knows that the OEM remote's protocol is, say, TDC. But if KM or RM know nothing of it, what then? A post in the Protocol Decodes forum, I suppose, and Rob will create a customised upgrade. But why, when this is un-necessary? It's just as easy to create an entry for protocols.ini, so that a novice user can use RM to create a device upgrade. But there remains one problem. PIDs.

I have created protocols.ini entries for the six new protocols in DecodeIR and, for want of anything better, have used PIDs 01EC-01EF for the non-UEI protocols. Two of the newly added protocols correspond to existing UEI PIDs. One of them has been included in RM v1.96.

At some time, DecodeIR v2.37 may pass sufficient testing for it to become the "official" version. When that happens, I hope its new protocols will become sufficiently "official", in so far as anything in the JP1 world is official, for all of them to find their way into RM, and into KM if new protocols are still being added to that. If that is not to happen, I see little point in me continuing to work on DecodeIR, for I will be left with a job half done. I am happy to create protocols.ini entries for anything I add to DecodeIR, but I don't want to be left having to post an unofficial "add-in" file for RM as I have done with the Beta version, and I can do nothing with KM. But this requires some resolution of the PID issue and an acceptance within the JP1 world of non-UEI protocols as having equal status to UEI ones.

There may be another PID crunch, of course. At some point UEI will start using PIDs greater than 01FF, and even before that, PIDs that JP1 uses for Special Protocols. The preparation is already there, as they are now using 2-byte PIDs instead of the kludge used to squeeze values up to 01FF into remotes with 1-byte PIDs. JP1 will want to support such protocols for users who still have remotes with 1-byte PIDs. This will require JP1 to give such protocols a second, non-UEI, PID.

So as I said above, where do we go from here?
__________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

PostPosted: Thu Sep 03, 2009 9:49 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

PostPosted: Thu Sep 03, 2009 3:27 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Sep 11, 2009 12:59 pm    Post subject: Reply with quote

Thanks, John. I have done so and posted DecodeIR v2.37 here.
______________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sun Sep 13, 2009 5:30 am    Post subject: Reply with quote

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



Joined: 01 Sep 2009
Posts: 5

PostPosted: Mon Sep 14, 2009 9:55 pm    Post subject: Reply with quote

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


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

PostPosted: Tue Sep 15, 2009 12:04 pm    Post subject: Reply with quote

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



Joined: 01 Sep 2009
Posts: 5

PostPosted: Tue Sep 15, 2009 9:39 pm    Post subject: Reply with quote

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


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

PostPosted: Wed Sep 16, 2009 2:51 am    Post subject: Reply with quote

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


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

PostPosted: Wed Sep 16, 2009 7:38 am    Post subject: Reply with quote

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


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

PostPosted: Wed Sep 16, 2009 8:27 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2308

PostPosted: Wed Sep 16, 2009 1:36 pm    Post subject: Reply with quote

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


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

PostPosted: Wed Sep 16, 2009 3:07 pm    Post subject: Reply with quote

ElizabethD wrote:
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.

No, not a "feature". I've noticed that apparently insignificant changes in DecodeIR can either add, or remove, "spurious decodes". You've clearly got an addition. It's not clear to me why this happens, but if I look at the raw data I can usually see that it does fit within the parameters of the spurious decode. If you would like to post the .ir file and tell me exactly what the difference is, I'll have a look. I'm still learning the peculiarities of the inner workings of DecodeIR, and oddities are helpful to me.

On the other issue, yeah, its difficult to prove a negative, but you've had enough positives in the last few days that the absence of positives, if you do similar things, can lead to at least a hope that I've hit on it! Smile But I'm not banking on it having fixed things.
_______________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2308

PostPosted: Wed Sep 16, 2009 7:08 pm    Post subject: Reply with quote

mathdon wrote:
If you would like to post the .ir file and tell me exactly what the difference is, I'll have a look. I'm still learning the peculiarities of the inner workings of DecodeIR, and oddities are helpful to me.

It causes me no problems whatsoever. File here
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7259
This was very recent learned signals and downloaded from 8910 under 8.0.0.17. When I look at it under that version (8.0.1 dev3) it looks like what I'm accustomed to. When I look at this same file under 8.0.1.11, there's this extra GAP thingie. Does it surprise me? Not really. I'd think a loooong key-hold, in order to get SUCCESS message on 8910, might have something undecodable at the end. Johnsfine might be able to comment (if it's even worth bothering with). Really, only a curiosity and a learning item for me.

Incidentally, this file, which I just uploaded, is what I'm using as a base for the List out of bounds play.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
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 1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 1 of 9

 
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
Get Smart! the band's official homepage Rockabilly Central