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

RMIR: Importing ICT files
Goto page 1, 2, 3  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: Mon Jul 06, 2020 9:17 pm    Post subject: RMIR: Importing ICT files Reply with quote

split from:
http://www.hifi-remote.com/forums/viewtopic.php?t=102504

I love the sound of being able to import an .ict file into RM, so I am trying to test it. I randomly found an .ict file in the Diagnosis Area and am trying to import that.

Here's the file, it uses NEC1 with 32.8 and according to IRScope there are 7 buttons with different OBCs:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=25335

When I go to RM and use File > Open to select the ict file, it correctly determines the protocol and device codes, though it does ask me to chose which is the best NEC protocol before I've seen what combination of device codes are present. It says there are multiple executors that can handle this, even though all of the buttons are NEC1. But regardless, when I go to the Functions tab, there's just a sinle un-named function with OBC 0. (The first OBC in the ict file is OBC 0).

Am I doing something wrong, or did I just pick a bad example of an ict file?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Fri Aug 07, 2020 4:47 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


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

                    
PostPosted: Tue Jul 07, 2020 7:26 am    Post subject: Reply with quote

The Robman wrote:
When I go to RM and use File > Open to select the ict file, it correctly determines the protocol and device codes, though it does ask me to chose which is the best NEC protocol before I've seen what combination of device codes are present.

If a listed protocol is unable to support all the signals in the file, a note will tell you how many it fails on and the list is in increasing order of failure count. So you don't need to see the combination of device codes in order to choose the best protocol.

Quote:
It says there are multiple executors that can handle this, even though all of the buttons are NEC1.

It says this because it is true, there are many executors that can handle NEC1 signals and you may choose whichever you want.

Quote:
But regardless, when I go to the Functions tab, there's just a single un-named function with OBC 0. (The first OBC in the ict file is OBC 0).

I should put a warning message about this. An ict file is divided into sections headed by "note=" entries and the import process uses the note as the function name. If there is no note attached to a signal, IRScope does not put in a "note=" line with an empty note, it just leaves the entry out. The import process finds no note headers and treats the timing data as all belonging to one signal. So you need to load the file into IRScope and add note entries for each signal. The notes do not even have to be all different, as the import process will add a suffix to distinguish the function names in case of duplicates.

So how does IRScope handle the undivided list of timing data? DecodeIR handles it and splits it into separate signals. At the time I was extending Kevin's original IRScope I was also working on John Fine's DecodeIR and I put in some specific handshaking to make the two interoperate in such situations. The import process in RM and RMIR, however, uses IrpTransmogrifier for decoding and this treats the data as a single signal. You can see this if you load your file into IrScrutinizer, which imports just a single signal. So the note entries are unfortunately required.

Investigating this has revealed two issues, however. In v2.11 build 1, notes are converted to lower case to form function names. This was unintentional and I will fix it. I also discovered that duplicate functions are handled in two different ways, depending on the import route. Your file has 7 signals, but the first and last are both OBC=0. On importing with RM (with notes added), the last signal is omitted as it is treated as a duplicate. This is a hang-over from Vyrolan's original code for converting learned signals to a device upgrade. If instead you use RMIR, open any setup file, go to the devices tab and use the Import button to import the file, all 7 signals are imported. I will fix that too, as I think all the signals should result in functions, even if they are duplicates.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Tue Jul 07, 2020 9:23 am    Post subject: Reply with quote

Regarding the NEC thing, if every signal in a file is NEC1 and they all have the save device codes, I don't see any reason to complicate the process by asking the user to chose between the dozen or so NEC variants that we have, the resulting upgrade should just use NEC1. They still have the option of switching to a combo version later if they want. I can totally see people getting thrown for a loop right there and giving up on the process as being "too complicated".

I think to make this work, RMIR would need a chart which rates the executors in terms of how complicated they each are, with the basic NEC1 being the simplest, and the one that allows the most combinations being the most complicated, and then it picks the simplest "matching" executor.

Regarding the ict signals, I get what you're saying, but I think in the majority of cases the notes will be missing, so this would be perceived as a problem. Given that IRScope is able to split them into separate OBCs, I think RMIR should be able to too. Maybe the first fault is that IRscrutinizer doesn't split them when DecodeIR does. If IRscrutinzer split them, would RM be able to handle them? Is the answer here to set RM to use DecodeIR first?
_________________
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
Barf
Expert


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

                    
PostPosted: Tue Jul 07, 2020 10:48 am    Post subject: Reply with quote

IrpTransmogrifier's decoder has a recursive option too, that does a fairly thorough job:
Code:
unnamed_0:      NEC1: {D=32,F=0,S=8}, beg=0, end=75, reps=2 {NEC1: {D=32,F=28,S=8}, beg=76, end=151, reps=2 {NEC1: {D=32,F=29,S=8}, beg=152, end=227, reps=2 {NEC1: {D=32,F=30,S=8}, beg=228, end=303, reps=2 {NEC1: {D=32,F=64,S=8}, beg=304, end=379, reps=2 {NEC1: {D=32,F=65,S=8}, beg=380, end=455, reps=2 {NEC1: {D=32,F=0,S=8}, beg=456, end=531, reps=2}}}}}}


Also, splitting a long sequence is a fairly trivial thing to do; see for example in IrpTransmogrifier IrSequence.chop(double threshold). BUT, it is not the universal solution to all problems: there is a parameter, that surely sometimes will cause problem, and has to be explained to the user. Note Graham's interest in IR signals with huge internal gaps lately. And how is then the name to be selected? All of which can be solved, but it increases the user coplexity...

IrScope is an age-old program that is not maintained. The icp format certainly was not intended as a universal and documented IR signal format.
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: Tue Jul 07, 2020 11:11 am    Post subject: Reply with quote

The Robman wrote:
I think to make this work, RMIR would need a chart which rates the executors in terms of how complicated they each are, with the basic NEC1 being the simplest

Didn't you notice that NEC1 was the first one on the list? And anyone creating a device upgrade has to choose what protocol to use.

Quote:
I think in the majority of cases the notes will be missing

I find it strange that anyone would post a file of signals with no indication of what they are, which is what the note field is intended for. But your example shows that I am wrong on that point, so I will see if I can use Bengt's recursive option (thanks, Bengt, for pointing that out), though as he points out, splitting by algorithm can never be perfect.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Tue Jul 07, 2020 12:40 pm    Post subject: Reply with quote

mathdon wrote:
Didn't you notice that NEC1 was the first one on the list? And anyone creating a device upgrade has to choose what protocol to use.

I did, and I did. When I got that message, I went back to the source file and opened it using IRScope to see what the combination of protocols and device codes really was, then based on what I observed in IRScope, I did indeed select NEC1. I just feel that those extra steps were unnecessary and might put off a less knowledgeable user.

Just FYI, as an experiment, I tried switching RMIR to DecodeIR and then opening the ict file, but I still get just one function.

I also edited the ict file and added notes and can confirm that it imported 6 of the 7 functions, eliminating the duplicate OBC 0, as expected.
_________________
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
mathdon
Expert


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

                    
PostPosted: Tue Jul 07, 2020 12:49 pm    Post subject: Reply with quote

The note at the top of the list of protocols (= executors) says, among other things:

Quote:
If the executor is not compatible with all the signals, then the number of failures is also given. The list is in increasing order of failure count.

In your case, none of the entries has a failure count, so you can pick any one. I don't see that it was necessary to look at the file with IRScope to know that the one at the top of the list would be OK.

Concerning experimenting with DecodeIR, changing the decoder does not affect this import process. DecodeIR will not work with it. As I mentioned before, there is a custom handshaking written into IRScope and DecodeIR to make the two work together to construct the signal list, and that cannot be reproduced in RMIR. The only hope is Bengt's recursion, which I will look at.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Tue Jul 07, 2020 1:42 pm    Post subject: Reply with quote

We'll have to agree to disagree on the executor list. I think I know enough to know how to use it going forward, but I also think I have a pretty good feel for where things get intimidating for the less experienced user and I think this is an example of that, especially as NEC1 is by far the most common protocol used for signals. If every signal in the file uses NEC1 with the same device codes, I don't see any point in presenting the multitude of combo protocols to the user.
_________________
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
Barf
Expert


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

                    
PostPosted: Tue Jul 07, 2020 2:04 pm    Post subject: Reply with quote

Borrowing from IrpTransmogrifier and IrpProtocols.xml there could possibly be a "prefer-over" property in protocols.ini. And, or course, an option to show all possible executors, also the prefer-over'ed.

Just a wild idea... Idea
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: Tue Jul 07, 2020 3:32 pm    Post subject: Reply with quote

Rob, this is one part of a complex algorithm that handles the conversion of learned signals to device upgrades as well as the import and export of Girr and ict files. I do not like introducing special cases - indeed, I don't think I have needed any in RMIR so far - and so do not want to write one to handle the import of NEC protocols in ict files. I also wonder how many inexperienced users will be attempting to import ict files as device upgrade functions.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Sat Jul 11, 2020 1:04 pm    Post subject: Reply with quote

I have now posted development build 2 of RMIR v2.11 in the RMIR Development folder on SourceForge. It contains three files to replace the corresponding files in the installation folder of build 1.

At Rob's instigation this now handles the import of IRScope ict files that do not include notes to separate the timing data into individual signals. This uses the recursion feature of IrpTransmogrifier and I am grateful to Bengt for drawing my attention to this feature. The other change is improvement in the export of a device upgrade as a Girr file in the case where the protocol of the device upgrade uses toggles.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Sat Jul 11, 2020 2:32 pm    Post subject: Reply with quote

Thanks for this Graham, I just tried it and can confirm that it works. I had to click away a lot of pop-ups in the process, so I went back to RMIR and checked all of the Suppress Messages options, then tried it again but I still got all the pop-ups. Would it be possible to add an option to suppress all the messages, including having it pick the first available protocol executor?

The pop-ups are...
1. IRScope allows you...
2. Protocol Chooser
3. The 7 signals of the file...
_________________
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
Barf
Expert


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

                    
PostPosted: Sun Jul 12, 2020 11:07 am    Post subject: Reply with quote

I have written a fix that does three things:

1. Given the other threads, I was irritated on how clumsy it was to get the raw learned data from the learned panel. For me, the threshold between "getting irritated" and doing something about it is relatively low. So I replaced the csv export by a Girr export, exporting the learned signals as raw duration. (Pronto Hex is a bonus by-pack.) As written, it replaces the csv- export (I did not remove anything), but there is nothing prohibiting you to deploy both; just have to have user elements for invoking. (But the csv exporter is really not that valuable. Also you can generate cvs from girr with a simple xskl-script.)

2. The popup file was incorrectly placed between the main window, and the popup leaned signal pane. Since the popup was modal, the learned popup could not be moved, sometimes making it impossible to reach the file selector. This has been fixed.

3. Renamed "OK" to "Close". "OK" means that some action is invoked, "Close" ... just closes without invoking an action.

The Robman wrote:
Would it be possible to add an option to suppress all the messages, including having it pick the first available protocol executor?

How do you like the console of IrScrutinizer?
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: Sun Jul 12, 2020 11:17 am    Post subject: Reply with quote

Barf wrote:
I have written a fix

You know I can't handle diff files (other than manually, and this is quite a long diff), so please upload it so I can see how it works.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


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

                    
PostPosted: Sun Jul 12, 2020 11:37 am    Post subject: Reply with quote

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26005
Back to top
View user's profile Send private message Send e-mail Visit poster's website
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  Next
Page 1 of 3

 
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