|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sun Feb 15, 2015 12:55 pm Post subject: |
|
|
Bruce, that behaviour is exactly what I would expect if the remote was ignoring the 0F segment so I think our guesswork has failed. We still have other tricks up our sleeves but it may take quite some time. Unless 3FG has further ideas. _________________ Graham |
|
Back to top |
|
|
ruidosobruce
Joined: 04 Jan 2015 Posts: 91 Location: New Mexico |
Posted: Sun Feb 15, 2015 6:55 pm Post subject: |
|
|
As a further test, since the URC-1060 with the uploaded Dish upgrade and protocol upgrade appeared to be sending IR signals in (CBL) mode when buttons were pressed, I learned those signals on a Learning Remote. Then, on the same Learning remote, I learned the IR signals from a remote with a working Dish upgrade, with these results:
1. URC-1060 with Non-Working Dish upgrade:
2. URC-8820 with working Dish upgrade:
The learning remote was the RCA RCRP05B.
Last edited by ruidosobruce on Tue Feb 17, 2015 9:07 am; edited 1 time in total |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sun Feb 15, 2015 10:58 pm Post subject: |
|
|
This is excellent news! It means that the PID 0002 executor was found via the Type 0F segment.
Next thing to try is to add variant information to the RDF file-- I forgot this when telling you to add PID 0002. RMIR actually reports that the PID isn't found in protocols.ini and that the resulting values may not be correct. So, instead of just 0002, the RDF file needs (probably ) 0002:5.
Please make this change and try again. If it still isn't right, don't worry. We'll get it going. The Dish Nextwork section of protocols.ini seems a little bit confused to me. |
|
Back to top |
|
|
ruidosobruce
Joined: 04 Jan 2015 Posts: 91 Location: New Mexico |
Posted: Mon Feb 16, 2015 10:24 am Post subject: |
|
|
Changing the protocol to 0002:5 in the RDF file for URC-1060BC3 throws an error when used in RMIR:
Quote: | Error in RDF. Wrong variant specified for PID = 00 02 Number of fixed/command bytes should be 1/1, for specified variant it is 5/1. |
I am not sure what caused the error, but I was eventually able by downloading from the remote, to then create a new Dish device with protocol 2 variant 5 which works. We have a functioning Dish remote!
Last edited by ruidosobruce on Mon Feb 16, 2015 11:04 am; edited 1 time in total |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Mon Feb 16, 2015 10:48 am Post subject: |
|
|
I suspect this may be caused by a "hangover" effect from previous attempts with the wrong variant specified in the RDF file. Are you loading from a previously made RMIR file? The executor you've loaded via the 0F segment does expect 5 fixed bytes and 1 command byte, and the RDF should be telling RMIR to construct the upgrade using 5/1. The previous RDF would have specified 1/1, and I suspect RMIR is using information from our earlier attempts.
So we need to get RMIR to forget about the wrong variant in the RDF file. I would delete the 1775 upgrade, and then use New to reload it. If that doesn't work, don't even load a Dish upgrade RMDU file--just hand enter a few functions into the Functions tab. Right now we're just trying to get it to shoot the correct IR protocol and not necessarily get a fully functioning upgrade. |
|
Back to top |
|
|
ruidosobruce
Joined: 04 Jan 2015 Posts: 91 Location: New Mexico |
Posted: Mon Feb 16, 2015 10:50 am Post subject: |
|
|
I was eventually able by downloading from the remote, to then create a new Dish device with protocol 2 variant 5 which works.
We have a fully functioning Dish remote! I have verified all of the significant Dish functions.
I have uploaded the working RMIR file for Dish, Vizio TV, Apple Remote, etc. here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13169
I have uploaded the Dish upgrade rmdu file here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13170
This URC-1060BC3 is a very nice remote, with many colorful, easy to navigate buttons.
We should be able to do almost anything with this remote. It is available new on eBay as low as $4.
Many, many thanks to 3FG and Mathdon for some of the greatest detective work I have ever seen.
Last edited by ruidosobruce on Mon Feb 16, 2015 12:31 pm; edited 1 time in total |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Mon Feb 16, 2015 12:11 pm Post subject: |
|
|
3FG wrote: | So we need to get RMIR to forget about the wrong variant in the RDF file. I would delete the 1775 upgrade, and then use New to reload it. |
In MAXQ remotes, the number of fixed and command bytes is contained in both the device upgrade and the protocol. Since it is not in the device upgrade as loaded from a .rmdu file, RMIR looks these values up from the protocol. You loaded the upgrade when the RDF said that the protocol had 1 fixed byte, then changed the RDF to a variant with 5 fixed bytes. Hence the error message. Bruce, as 3FG suggests, you need to delete the upgrade and then re-load it with the RDF having this variant.
Now all is working, I will add the necessary facilities to RMIR so that you don't have any further messing to do. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Feb 21, 2015 2:15 pm Post subject: |
|
|
I have now posted build 11 of RMIR v2.03 Alpha 28, see also this announcement. This has, I believe, full support for the new type 0E and 0F segments and will load the Dish Network upgrade into the Charter remote without problem. Build 11 includes a modified RDF for the remote which does not need the "fudge" of adding 0002:5 to the [Protocols] section. _________________ Graham |
|
Back to top |
|
|
ruidosobruce
Joined: 04 Jan 2015 Posts: 91 Location: New Mexico |
Posted: Sat Feb 21, 2015 8:42 pm Post subject: |
|
|
Graham,
I installed RMIR v2.03 Alpha 28 build 11 and deleted the Dish upgrade from my current Charter remote file.rmir. Then I created a new dish upgrade within RMIR with no "fudges", and uploaded it to the Charter URC-1060BC3.
Segments are right (including the new $0F segment), and it works perfectly.
Thank You, Thank You
Bruce |
|
Back to top |
|
|
ncoig
Joined: 03 Oct 2004 Posts: 145
|
Posted: Sat Sep 12, 2015 1:09 am Post subject: |
|
|
mathdon wrote: |
In MAXQ remotes, the number of fixed and command bytes is contained in both the device upgrade and the protocol. |
Might you have any pointers to where the information on the MAXQ might be that would enable one to assemble the data for a known protocol conversion to MAXQ? I've looked over protocol builder, Vicki's IR primer, and several other docs trying to get my head around building a protocol, but am unsure on this processor what would need to be done.
Any help is appreciated!
Thanks,
-N |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Sep 12, 2015 5:11 am Post subject: |
|
|
ncoig wrote: | Might you have any pointers to where the information on the MAXQ might be that would enable one to assemble the data for a known protocol conversion to MAXQ? I've looked over protocol builder, Vicki's IR primer, and several other docs trying to get my head around building a protocol, but am unsure on this processor what would need to be done. |
The structure of a MAXQ protocol is extremely complex. It is nothing like that of protocols for earlier processors, which differ in detail but have a common general structure consisting simply of a data section followed by a program section. Creating a protocol even for these earlier processors is generally considered a job only for experts. Creating one for a MAXQ processor is a task suited only to the few experts who are steeped in the workings of these processors. Currently I think that 3FG and I are the only ones in JP1 who are capable of doing this.
Since MAXQ is the latest processor, most protocols are already available for it, which is why there are very few that we have needed to construct. What protocol is it that you are wanting to convert? We will see if we can help. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Sep 12, 2015 12:52 pm Post subject: |
|
|
Neil, please try adding the following entry to protocols.ini. You can add it at the bottom or anywhere else, as RMIR sorts them into alphabetical order by name. So wherever you put it, it will appear in its alphabetical position in the drop-down list of protocols in RM. The entry is:
Code: | [Roomba]
PID=02 FF
VariantName=JP1
CmdParms=OBC=0
CmdTranslator=Translator(0)
Code.MAXQ610=32 64 01 0A 6F 00 27 00 24 00 70 00 37 07 00 00 62 10 01 70 |
_________________ Graham |
|
Back to top |
|
|
ncoig
Joined: 03 Oct 2004 Posts: 145
|
Posted: Sat Sep 12, 2015 5:28 pm Post subject: |
|
|
mathdon wrote: | Neil, please try adding the following entry to protocols.ini. You can add it at the bottom or anywhere else, as RMIR sorts them into alphabetical order by name. So wherever you put it, it will appear in its alphabetical position in the drop-down list of protocols in RM. The entry is:
Code: | [Roomba]
PID=02 FF
VariantName=JP1
CmdParms=OBC=0
CmdTranslator=Translator(0)
Code.MAXQ610=32 64 01 0A 6F 00 27 00 24 00 70 00 37 07 00 00 62 10 01 70 |
|
Thanks for looking at this!
It works, but I think perhaps some of the information is a little off. In particular, when holding the LEFT/RIGHT buttons to send the vac on its way, it sometimes busts into DOCK mode when you release the button. I'm supposing there is something amiss in the repeating of these commands. It doesn't happen with every button, but it does happen sometimes. Would you like me to learn the commands, despite having these already in the existing upgrade for the S3C80?
As an aside, would this not be better placed as an entry under the 01 60 protocol that Rob (?) setup before for the Roomba for the other processors?
-N |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Sep 12, 2015 5:58 pm Post subject: |
|
|
Looking back, I see that the S3C80 protocol repeats every signal at least three times. I forgot to put that into the MAXQ version. Try changing the code line to
Code: | Code.MAXQ610=32 64 01 0A 6F 00 27 00 24 00 70 00 37 07 00 00 63 10 01 03 70 |
which has these repeats. As for the PID, there is already an official UEI protocol with PID=0160 that is not Roomba, so that cannot be used in protocols.ini. I chose a value higher than any known PID, but 02 60 would be equally suitable. Note that many remotes will not accept PIDs greater than 01FF, but the MAXQ remotes do so and there are now quite a lot of protocols that start with 02. _________________ Graham |
|
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
|