JP1 Remotes

gfb107 wrote: And changing the checking tool rather than the RDFs or RM avoids the version dependency problems between RM and the RDFs altogether.

Okay, we will go that route then.

xnappo

mathdon wrote:Could an alias of OEM Mode cause a problem? Yes. If converting from a device with the OEM Mode alias on some other remote to a URC-7781, it would use the HT type, which is meaningless. It would also, almost certainly, use an invalid setup code for this type. There are exactly two valid setup types for the device index 15 (which is HT). One is $FFF, signifying that the device slot is empty. The other is $3F3, signifying that the slot has been assigned to HT (Home Theater).

If this is true, don't you think it's somewhat dangerous to have HT be available as a general device mode? As things stand, there's nothing stopping people from creating upgrades using HT as the device mode and then adding them to IR.

My vote would be to eliminate HT as a valid device mode, which will eliminate the chance of someone using it as a device mode in RM, and then add some logic to IR to handle the assignment of HT mode to one of the device buckets. The new logic should be configurable in the RDF so that the next remote that acts like the URC-7780, but with slightly different settings, can be made to work.

While it is true someone could upload an upgrade using the HT device, this is just the same as someone uploading an upgrade using OEM Mode right? And most remotes aren't going to have an OEM Mode so that won't really work right.

Basically, along with the upgrade coding guideline of including all original remote buttons, we should also request that HT and OEM Mode are not used.

xnappo

I don't think KM knows about the HT device type, so there's no way it can create an HT device upgrade. RM allows only the device type aliases that are defined in the RDF for a remote. So if we don't define a device type alias for the HT device type in the RDF, there's no way to create an upgrade for the HT device type.

I see that IR allows changing the device type of an installed upgrade to HT, which is still a problem.

Now that we have the [SetupCodes] section in all RDFs, so that Code Validation works, I would like to return to an issue that was discussed at some length earlier last year. There was a general consensus that we should work towards making an RDF on its own, loaded through File/New in IR.exe, create a valid image equivalent to a Factory Reset of the remote.

Here are some excerpts from the discussion. More details can be found by clicking on the links and browsing the surrounding messages.

From this post:

The Robman wrote:So what we need is the ability to specify the default setup codes for each device button in the RDF, right?

then:

The Robman wrote:As I think we're headed towards making the RDFs create a "new" image that almost exactly replicates a virgin image, I think it might be a good idea to sneak in something so that we can tell when an IR file was created this way, just to help us diagnose possible problems.

I'm thinking that whenever someone uses the New > Select method of creating an IR file, IR could put a little signature of sorts near the end of the IR file, like maybe a couple of bytes with the value $1234.

and:

mathdon wrote:Bill wrote:

The setup codes are not the only thing, there is some other stuff. For example, the Comcast DVR has some things in there that I don't quite understand but if one of them is not $0F the remote uses the value in there for the device for all macros. Then if the device is greater than $03 the remote goes to never-never land.

It is this other stuff that made me introduce "read-only settings". You don't even need to know what the byte does, just what its value in a 981 reset should be. Give such settings innocuous names such as Aux1, Aux2,... - it really doesn't matter. If the user can't change the value, he/she doesn't need to know what it is for. But I think it is helpful for diagnosis, experiment, etc to have such values displayed. (I suppose I could even create "invisible" settings that are used in initialization but are not displayed, if that was felt to be better.)

and:

The Robman wrote:we need to make the RDFs able to create good virgin images. The marker that I suggested would only be added to images that were created using the New > Select option as it would tell us how the IR file was initially created. There would be no need for IR to ever get rid of the marker, and if it gets overlaid with valid data (eg, learned signals or upgrades) so be it. In fact, now that I think of it, rather than using a hard code marker, maybe we could make it a date. We could fit a date into 3 bytes (eg, $02 07 09).

If someone has problems with an IR file, the marker would tell us that it was created using IR.exe and the date would tell us how recently. So, if it's an old file, the problem is probably something else, but if it's new, then maybe there's a byte of data that should have been set but IR.exe didn't set it.

I like the idea of display only data too.

The ability to specify default setup codes in the [DeviceButtons] section and read-only settings through a parameter in the [General] section are in version 4 of the RDF Specification and have been implemented in IR.exe since version 8.00. It even puts in the date, in a year/month/day format, at the end of the Advanced Code section as the marker that Rob asked for.

I did one RDF of a fairly complicated remote as an example. This one creates a Factory Reset image when loaded through File/New:

ET80ET80 (URC-8550_5550 Topline).rdf

I can't put a link to it now that they are all on SourceForge, but it is in the recent zip file of RDFs.

With RDFs now under active development once again, it would be very good if this could be done for all RDFs.

All well and good for non OEM remotes, but with our OEM remotes, there are all sorts of setups that vary by provider.

I've been a JP1 user for 10 years, and before Graham added the RDF Edit buttons, I had never done a File->New because early on it was drummed into my head to let IR choose for me.

Perhaps the File->New should carry a warning. File->News will give you all sorts of problems.

Oh cr** I probably should address this in help.

You should always start with dumping the remote whenever possible, but as long as the File>New option is there, there will be somebody who will use it. Plus, it's useful to have for situations where you don't have the remote in your hands (perhaps because you're setting one up for someone else).

I don't think it was ever the intention for this option to replicate the factory settings of an OEM remote, in other words, it won't pre-load any upgrades that might have been loaded at the factory. The intention is to replicate the memory image that you would get if you pre-loaded the EEPROM with all FFs and then did a 981 reset (ie, what we call a "virgin" dump).

Not sure it will work if you don't have an account, but try this link for the RDF Graham mentioned:

http://controlremote.svn.sourceforge.ne ... vision=871

Please let me know either way.

xnappo

xnappo,
Using IE8 with no SourceForge account, your link brought up the text of the rdf file. I copied and pasted into Notepad, then copied and pasted the file name from Graham's post into the SaveAs dialog.

I haven't tested the resulting file, but it looks perfectly normal.

The link xnappo provided links to a specific revision of the RDF (which in this case happens to be the current right now). This following link will always get the latest version:

http://controlremote.svn.sourceforge.ne ... ine%29.rdf

mathdon wrote:The ability to specify default setup codes in the [DeviceButtons] section and read-only settings through a parameter in the [General] section are in version 4 of the RDF Specification and have been implemented in IR.exe since version 8.00. It even puts in the date, in a year/month/day format, at the end of the Advanced Code section as the marker that Rob asked for.

I like it. Is the position of the date configurable in the RDF? My preference would be to position it at the end of the upgrade section as this is less likely to get filled with user data than the advanced code section. Another possibility is the learning section.

mathdon wrote:I did one RDF of a fairly complicated remote as an example. This one creates a Factory Reset image when loaded through File/New:

ET80ET80 (URC-8550_5550 Topline).rdf

One minor thing that I noticed with this RDF is that the AUX2 button defaults to LASER/0029, which is not a valid code. I suspect that the correct code is LASER/0059, which is present in the remote.

3FG wrote:xnappo,
Using IE8 with no SourceForge account, your link brought up the text of the rdf file. I copied and pasted into Notepad, then copied and pasted the file name from Graham's post into the SaveAs dialog.

I haven't tested the resulting file, but it looks perfectly normal.

I think you could right-click on the text view (or the link itself) and select Save As... and then all you have to choose is the destination folder, the file name would be filled in for you.

Yes, it does do that.

The Robman wrote:One minor thing that I noticed with this RDF is that the AUX2 button defaults to LASER/0029, which is not a valid code. I suspect that the correct code is LASER/0059, which is present in the remote.

With the RDF I have, the @AUX2 button defaults to TAPE/0029, which is valid and correct. If it now defaults to LASER/0029 then that is a bug that has arisen in the latest juggling with the RDF, over the issues of "@ symbols" and duplicate device type aliases.

The Robman wrote:Is the position of the date configurable in the RDF?

No, it's not configurable but there is no reason why it could not be written at the end of more than one section. It does no harm and it serves its purpose if at least one of them survives.