 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
 Posted: Mon Aug 27, 2012 10:05 pm Post subject: RMIR: Making Upgrades from Learned Signals |
 |
|
So I was noticing a lot of the documentation always talks about copying information from decoded learned signals into a device upgrade. Having to copy names, OBCs, parameters, etc, etc. I found myself doing it a lot too. It seems like such a pain so I wanted to see if I could make it easier.
I grabbed the RMIR source and started to poke about... I've added a "Convert to Device Upgrade":
To demonstrate this functionality, I've created a contrived example of some learned signals from a nearby remote. You can see they all decode properly. We can make the first two of them into a device upgrade by selecting them and clicking the new button:
Here is the resulting Device Upgrade:
| Code: |
Description=Learned Signal Upgrade
Remote.name=RCA RCRP05B black
Remote.signature=31793179
DeviceType=Cable
DeviceIndex=0
SetupCode=2000
Protocol=00 5A
Protocol.name=NEC1
ProtocolParms=1 254 0
FixedData=00 7F 80
Notes=Device Upgrade automatically created by RemoteMaster from 2 Learned Signals all with protocol NEC1, device 1, subdevice 254.
Function.0.name=1
Function.0.hex=3F
Function.1.name=2
Function.1.hex=1F
Button.15=1|null|null
Button.16=2|null|null
|
As you can see, the functions are created and they are also bound to the same buttons as they were learned to originally.
If an upgrade already exists for the same protocol, device, and subdevice (with "Learned Signal" in either description or notes for safety for now), then it tries to append the selected Learned Signals to the existing upgrade. In the contrived example, the final two learned signals are a duplicate key and a duplicate OBC respectively, but we can still append them to the upgrade:
(Note that the Function for the third Learned Signal is set to "OtherFunc" because that was the "Notes" for the learn. If the notes are blank, then function is set to the key name to which it was learned.)
It recognized that function "3" (OBC 3) was already present and so it was not added to the existing upgrade (although the second button assignment was added). It also recognized that two buttons were assigned to key 2, and so OtherFunc was instead assinged to Shift-2. Here is the resulting upgrade:
| Code: |
Description=Learned Signal Upgrade
Remote.name=RCA RCRP05B black
Remote.signature=31793179
DeviceType=Cable
DeviceIndex=0
SetupCode=2000
Protocol=00 5A
Protocol.name=NEC1
ProtocolParms=1 254 0
FixedData=00 7F 80
Notes=Device Upgrade automatically created by RemoteMaster from 2 Learned Signals all with protocol NEC1, device 1, subdevice 254.
Function.0.name=1
Function.0.hex=3F
Function.1.name=2
Function.1.hex=1F
Function.2.name=OtherFunc
Function.2.hex=37
Function.2.notes=OtherFunc
Button.15=1|null|null
Button.16=2|OtherFunc|null
Button.17=1|null|null
|
This is pretty rudimentary so far (I've only been coding on it for a few hours), but it does so some basic check as seen here. It also verifies that the selected learns decode properly and all decode to the same protocol/device/subdevice. It will warn you if otherwise. I'm always using Cable/2000 for the new Device (it does check that there is no conflict of the Setup Code), but I also figure anybody using this function would change the Description, Type, Setup Code, etc, etc of the upgrade to their liking.
Some other checks it does is that when appending is that it will not create a function with a duplicate name (it appends a "_2", "_3", etc). If a function cannot be assigned to Key or Shift-Key, then it goes unassigned (but the function still added) and you are alerted.
I could imagine with refinement this could streamline the process for some people. I could imagine with a lot of refinement, it could even learn to take a set of mixed-protocol learns and automatically select the appropriate combo protocol. I could also imagine building on this idea to import an IRScope .ict file as an Upgrade similar to using the learns as I'm doing here. I'm not sure what people think of this or how useful (or stupid) it is... I'm interested in others' opinions on the topic. It was mostly a simple exercise to familiarize myself with RMIR's code.
If you'd like to play around with the functionality, I've uploaded a build RemoteMaster.jar to the Diagnostics Area: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=11268 (Yes, it's a zipped jar file which is quite redundant I know.)
Vyro
Last edited by Vyrolan on Thu Aug 30, 2012 10:59 am; edited 1 time in total |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Tue Aug 28, 2012 7:45 am Post subject: |
|
|
Wow Vyro, you really did go from rookie to expert in 5 mins. This sounds great, I'll have to play around with it and give you some feedback.
_________________
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 |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Tue Aug 28, 2012 8:52 am Post subject: |
|
|
| The Robman wrote: | | Wow Vyro, you really did go from rookie to expert in 5 mins. This sounds great, I'll have to play around with it and give you some feedback. |
Please do. I fully expect that it won't be capable of handling all situations, but it should manage fine on some simple ones. For now, it has extremely simple parameter handling... Basically I search through the protocol's parameters and if I find one starting with "Device", then I give it the decoded device value, and then I do the same thing for sub device. All other protocol parameters will have their default values (although from what I understand we could parse them out of the DecodeIR results with more logic). |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Tue Aug 28, 2012 11:38 am Post subject: |
|
|
Vyrolan,
nice that you got going with building Remotemaster.
I have also been toying around with the idea of creating device update automatically. You consider the use case of converting a few learned signals to a device upgrade. I think the generation of a device upgrade from a, more or less arbitrary, list of IR commands (protocol, device, subdevice, obc, possibly other parameters), through Remotemaster API. Consider the import of IR command from another source, a LIRC file, a Pronto configuration, the signals from an IR capturing program. To be able to generate a, more or less complete, device upgrade would be quite interesting. I have been toying around with this for some time, but never had the time to implement it. Consider lirc2xml and lirc2rmdu for example. While lirc2xml does quite a good job of rendering LIRC signals, and sending them to DecodeIR, lirc2rmdu is intended as a backend to the xml output, and is not at all of the same quality. What remains to do is to get the protocol right, in particular the portocol parameters (this is the info protocols.ini), and getting the hex command right (this involves applying the EFC-function, and the (protocol-dependent) hex-function. It should be relatively easily doable.
So a good starting point would be something that takes the lirc2xml output and creates a working upgrade -- what lirc2rmdu unsuccessfully tries to do. Then we can augment an IR-capturing program like IRScope with the capability to generate a device update directly. Another related use case would be to create a device update containing all OBCs in an interval, to search for undocumented IR commands (of course, IrMaster together with appropriate hardware makes this better ("War dialer"), but if the appropriate hardware is not available...).
Please let me know if I should be more specific. |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Tue Aug 28, 2012 12:08 pm Post subject: |
|
|
| Barf wrote: |
You consider the use case of converting a few learned signals to a device upgrade. I think the generation of a device upgrade from a, more or less arbitrary, list of IR commands (protocol, device, subdevice, obc, possibly other parameters), through Remotemaster API. Consider the import of IR command from another source, a LIRC file, a Pronto configuration, the signals from an IR capturing program. To be able to generate a, more or less complete, device upgrade would be quite interesting.
|
I agree completely. I mentioned in my post that I can see expanding on such a concept to create a device upgrade directly from an IRScope .ict file. With that, (assuming a sufficiently simple OEM remote) making an upgrade would simply be blasting all the buttons on the remote at a Widget (adding notes to become function names) and clicking 1 button.
| Barf wrote: | ...lirc2rmdu is intended as a backend to the xml output, and is not at all of the same quality. What remains to do is to get the protocol right, in particular the portocol parameters (this is the info protocols.ini), and getting the hex command right (this involves applying the EFC-function, and the (protocol-dependent) hex-function. It should be relatively easily doable.
|
Definitely the hard part is getting the protocol parameters right. Looking through protocols.ini (and the Protocol class from RMIR), I believe you can extract enough information about the protocols to do a decent job. The real problem is matching up the output from DecodeIR to the right place. It would probably take a slog through all the protocols understanding how to parse DecodeIR's Misc to get it all right.
| Barf wrote: | | ...and getting the hex command right (this involves applying the EFC-function, and the (protocol-dependent) hex-function. |
DecodeIR gives the hex command (at least in the examples I've seen). I was able to take the hex provided by DecodeIR to produce the upgrades for this RMIR modification. |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Wed Aug 29, 2012 9:04 am Post subject: |
|
|
Wow - nice work!
I had been messing with this a couple of years ago, but never made much progress as high level languages are not my thing.
I really think this is a big work-flow improvement! Again nice work!
xnappo |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Wed Aug 29, 2012 3:57 pm Post subject: |
|
|
| Vyrolan wrote: | | IR uses another dll (ExchangeIR?) to produce the IRP notation of the signals...I don't think RMIR has that in it yet so I can't reproduce that part. |
ExchangeIr has been ported to Java and checked in to SVN by yours truly, see this posting.
The original version of ExchangeIR has a very old fashioned API, the Java version of ExchangeIR however not.
Last edited by Barf on Wed Aug 29, 2012 4:19 pm; edited 1 time in total |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Wed Aug 29, 2012 4:28 pm Post subject: |
|
|
| Barf wrote: | | Vyrolan wrote: | | IR uses another dll (ExchangeIR?) to produce the IRP notation of the signals...I don't think RMIR has that in it yet so I can't reproduce that part. |
ExchangeIr has been ported to Java and checked in to SVN by yours truly, see this posting.
The original version of ExchangeIR has a very old fashioned API, the Java version of ExchangeIR however not. |
/shrug I saw your Java version, but honestly I'd rather have a JNI to the native DLL like we do with DecodeIR... Then it should for sure give the same results as in RM as in IR... Why maintain two copies anyway? |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Thu Aug 30, 2012 1:40 pm Post subject: |
|
|
The way forward
I would like to suggest a route map for the incorporation of Vyrolan's work into the official development of RMIR. At present he has been working from the source code in SourceForge but not contributing to it.
Since Greg released RMIR v2.02 Beta, the most recent official version, there have been various development versions progressing the addition to it of JP1.4/JP2 support, the most recent of which was v2.02 Beta 1.5u. As Vicky remarked in this post, even since that version, she and I have been very active recently in sorting out some issues with RMIR which she brought to my attention that have nothing to do with JP1.4/JP2.
That work is now almost done. I would like there to be an official release of v2.02 that incorporates all these developments. In addition it should include v0.19 of jp12serial.dll and v2.44 of decodeIR, and a revised version of protocols.ini that includes MAXQ610 code and also some recent additions by 3FG. This should all be ready shortly.
The source code of RemoteMaster on SourceForge has been kept up-to-date during this development work, including that which Vicky and I have been doing outside of these forums, so Vyrolan's starting point will have included this recent work. I suggest that we complete v2.02 as soon as possible and that once this is issued, Vyrolan should upload his work to SourceForge as developments towards a v2.03.
_________________
Graham |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Thu Aug 30, 2012 2:02 pm Post subject: |
|
|
| mathdon wrote: |
I would like to suggest a route map for the incorporation of Vyrolan's work into the official development of RMIR. At present he has been working from the source code in SourceForge but not contributing to it.
|
I doubt there's anonymous write access, and I also didn't want to mess anything up for anyone.
| mathdon wrote: |
The source code of RemoteMaster on SourceForge has been kept up-to-date during this development work, including that which Vicky and I have been doing outside of these forums, so Vyrolan's starting point will have included this recent work. I suggest that we complete v2.02 as soon as possible and that once this is issued, Vyrolan should upload his work to SourceForge as developments towards a v2.03. |
Agreed...I pulled the latest svn when I started, and I can easily incorporate the latest svn into my git repo and then produce a single all-inclusive patch to apply to the top of svn. I just need to know when everything is pushed through so I know when to sync up. |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Thu Aug 30, 2012 5:10 pm Post subject: |
|
|
| Vyrolan wrote: |
| mathdon wrote: |
The source code of RemoteMaster on SourceForge has been kept up-to-date during this development work, including that which Vicky and I have been doing outside of these forums, so Vyrolan's starting point will have included this recent work. I suggest that we complete v2.02 as soon as possible and that once this is issued, Vyrolan should upload his work to SourceForge as developments towards a v2.03. |
Agreed...I pulled the latest svn when I started, and I can easily incorporate the latest svn into my git repo and then produce a single all-inclusive patch to apply to the top of svn. I just need to know when everything is pushed through so I know when to sync up. |
There's been only one commit to svn since I started...I pulled it into my svn-tracking branch and merged into my dev branch with only minor conflicts that were easily resolved. It should not be hard to add my changes to the codebase in svn unless there's some truly crazy stuff not yet commited to svn. |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Fri Aug 31, 2012 2:29 am Post subject: |
|
|
| Vyrolan wrote: | | There's been only one commit to svn since I started...I pulled it into my svn-tracking branch and merged into my dev branch with only minor conflicts that were easily resolved. It should not be hard to add my changes to the codebase in svn unless there's some truly crazy stuff not yet commited to svn. |
There will be nothing new from me in svn for v2.02 other than some debugging and I don't think anyone else is working on it. Vicky has found some bugs with my latest changes and is still looking for more. I hope to fix those already found in the next few days.
_________________
Graham |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Fri Sep 07, 2012 2:46 pm Post subject: |
|
|
Just FYI, in order to help keep this discussion on topic, I have split the "JNI vs. Java re-write" discussion off to a separate thread...
http://www.hifi-remote.com/forums/viewtopic.php?t=14232
_________________
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 |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Fri Sep 07, 2012 3:13 pm Post subject: |
|
|
Thanks Rob.
Also, just so no one thinks I died, I'll be gone until Wednesday. It's our anniversary on Monday so we're off to a resort in Cancun. To avoid technology withdrawl syndromes, I will no doubt be checking email and these forums via the wifi...just not with my usual high frequency. =) |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Fri Sep 07, 2012 3:24 pm Post subject: |
|
|
Wow, enjoy! But why so short, you should stay in Cancun longer!
_________________
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 |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
