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

Do RMIR upgrades work on MAXQ610 based remotes?
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

PostPosted: Sun Feb 15, 2015 12:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
ruidosobruce



Joined: 04 Jan 2015
Posts: 91
Location: New Mexico

PostPosted: Sun Feb 15, 2015 6:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3224

PostPosted: Sun Feb 15, 2015 10:58 pm    Post subject: Reply with quote

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 Very Happy ) 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
View user's profile Send private message
ruidosobruce



Joined: 04 Jan 2015
Posts: 91
Location: New Mexico

PostPosted: Mon Feb 16, 2015 10:24 am    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3224

PostPosted: Mon Feb 16, 2015 10:48 am    Post subject: Reply with quote

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
View user's profile Send private message
ruidosobruce



Joined: 04 Jan 2015
Posts: 91
Location: New Mexico

PostPosted: Mon Feb 16, 2015 10:50 am    Post subject: Reply with quote

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


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

PostPosted: Mon Feb 16, 2015 12:11 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Feb 21, 2015 2:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
ruidosobruce



Joined: 04 Jan 2015
Posts: 91
Location: New Mexico

PostPosted: Sat Feb 21, 2015 8:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Sat Sep 12, 2015 1:09 am    Post subject: Reply with quote

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


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

PostPosted: Sat Sep 12, 2015 5:11 am    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


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

PostPosted: Sat Sep 12, 2015 9:09 am    Post subject: Reply with quote

Hi Graham, Neil is looking to create an upgrade for an iRobot Roomba floorvac (see this thread).

Here is the protocol builder file for the handmade executor:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=1401

As you can see, it doesn't use any assembler, it's all just standard timings.
_________________
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: 2871
Location: Cambridge, UK

PostPosted: Sat Sep 12, 2015 12:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
ncoig



Joined: 03 Oct 2004
Posts: 145

PostPosted: Sat Sep 12, 2015 5:28 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Sep 12, 2015 5:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 5 of 6

 
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