JP1 Remotes

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.

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.

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.

Changing the protocol to 0002:5 in the RDF file for URC-1060BC3 throws an error when used in RMIR:

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!

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.

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:
https://www.hifi-remote.com/forums/dload ... e_id=13169
I have uploaded the Dish upgrade rmdu file here:
https://www.hifi-remote.com/forums/dload ... e_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.

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.

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,

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

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

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.

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:
https://www.hifi-remote.com/forums/dload ... le_id=1401

As you can see, it doesn't use any assembler, it's all just standard timings.

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:

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: Select all

[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

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
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.