JP1 Remotes

mathdon · Posted: Wed Mar 04, 2009 1:06 pm Post subject:

IR version 8.00 does of course handle RDFs with RDFsync=3 in exactly the same way as earlier versions. There is no backward incompatibility. It will indeed handle all RDF files in exactly the same way, whether RDFsync is 3 or 4. Once it has checked that RDFsync is either 3 or 4 (but nothing else) then the value plays no further part in its processing.

IR 8.00 will be entirely happy if you update an RDF to 4 and delete the RDF3 version. The problem is only with earlier versions of IR, and with RM (and RMIR). They will not accept some of the extended syntax in an RDF4 file. So until RM accepts an RDF4 file, even if by ignoring the enhancements, users will need to have an RDF3 as well as an RDF4 for the same remote.

I was proposing to put RDF4 in the filename so as to make the distinction clear when one is selecting an RDF. I'm happy to make the distinction in some other way, if that is preferred.

[Edit]
I should have said that earlier versions of IR, and current RM, will not accept some of the extended syntax and that this was the reason for changing the RDF Spec version number to 4. Earlier versions of IR will only accept RDFspec=3 and so will refuse to load an RDF4 file, so preventing the extended syntax from causing problems.
________________

Graham

mr_d_p_gumby · Posted: Wed Mar 04, 2009 10:10 pm Post subject:

One of the things that breaks RDF compatibility is to alter the nature of arguments for an existing entry, as is the case with the modification you've made to the TimeAddr entry. Is it really necessary to do it this way? As I mentioned in this thread, you could accomplish the same thing by creating a separate new entry to specify the time format, i.e., TimeFormat=BCD12, thus leaving the definition & interpretation of the TimeAddr entry as-is, and not breaking compatibility with RM.

I don't disagree with rolling the RDF spec to V4, but we have not attempted to do this in a very long time because of the difficulty in coordinating the change.
_________________
Mike England

JP1 Group at Yahoo!, JP1 Files Area

mathdon · Posted: Thu Mar 05, 2009 6:30 am Post subject:

Mike, I did think about a TimeFormat entry but the biggest change in RDF4 is the enhanced syntax for Special Protocols. It would certainly be possible to have made a new section, [SpecialProtocols+] or something, and similarly a new section [DeviceDefaults] rather than adding an extra parameter to [DeviceButtons] entries. The extra parameters in the Labels entry would also need to be separated into a separate entry.

I posted my intentions before I implemented these changes and took the lack of objections to be an implicit consent. My reasoning is that it is logically preferable to put the information needed for a particular function, such as Time setting or Labels display, into a single entry. I knew that there would be transitional problems but these will disappear in time and we will be left with the better solution. And "in time" doesn't really have to be very long. If Greg can extract the RDF3 info from an RDF4 file in the next issue of RM - it is a simple algorithm that I have posted for him in this thread - then there would be no need to retain RDF3 files when an RDF4 is available. The current versions of JP1 applications should then all be re-coordinated.

I still think the change to RDF4 is the right thing to do. If someone tries to use an RDF4 file with IR.exe prior to version 8.00 they will get an "out of sync" error, which will prompt them to get the latest IR version.

I could still unwind things and put the new features entirely into separate sections or entries according to the first paragraph above, if it were generally felt desirable to do so, but my personal preference is to leave things as they are in IR 8.00 Beta 5.
____________________

Graham

mathdon · Posted: Thu Mar 05, 2009 9:08 am Post subject:

All things to all people!

I think I have a solution that has taken minimal effort to implement. I have created a Beta 6 with the following behaviour. For the problematic entries, namely TimeAddr and Labels in the [General] section and the entire [SpecialProtocols] and [DeviceButtons] sections, it accepts two versions of the key, the normal one and one with a "+" appended. So you can have a TimeAddr+ entry in the [General] section and an entire [SpecialProtocols+] section. If entries with and without the "+" are present then it only acts on the first one it encounters.

This enables you to control independently how an RDF3 and an RDF4 application behave. If you want an RDF3 app to ignore TimeAddr then use TimeAddr+. If you want an RDF3 app to read an RDF3 version of Special Protocols and and RDF4 app to read an enhanced version, use RDFsync=3, put a [SpecialProtocols+] section with RDF4 entries and follow it with a [SpecialProtocols] section with RDF3 entries. The RDF3 app will ignore the [SpecialProtocols+] section but the RDF4 app will read it first and so ignore the following [SpecialProtocols] section.

You can also have an entirely RDF4 file in which you use the enhanced syntax in [SpecialProtocols] (no +). If this has RDFspec=4 then versions of IR earlier than 8.00 will give an out-of-sync error. Note that IR 8.00 makes no distinction in how it treats the data in entries/sections with or without the "+", it just reads the first one it finds.

I would hope that in due course, new RDFs would have RDFsync=4 and would not use the "+" suffix, but in the meantime this enables the creation of RDFs acceptable to everything.

If this makes everyone happy then I'll do more testing, update the documentation etc and post it. So far I've tested it with an RDF for my URC-7781 Extender A2 (which is heavily RDF4 dependent) that is accepted by IR 8.00, IR 7.15 and RM.
____________________

Graham

mr_d_p_gumby · Posted: Thu Mar 05, 2009 4:15 pm Post subject:

mathdon · Posted: Thu Mar 05, 2009 4:36 pm Post subject:

Just out of interest, when was RDFspec rolled from 2 to 3? I tried to find out from the Yahoo files - I presume it is that long ago - but couldn't find it.

Graham

tennessee titan · Joined: 18 Nov 2008 Posts: 117

Is there anything new here for NON-EXTENDER users?

mr_d_p_gumby · Posted: Thu Mar 05, 2009 8:37 pm Post subject:

mathdon · Posted: Fri Mar 06, 2009 6:15 am Post subject:

What's new in IR 8.00 (currently at Beta 5 with Beta 6 imminent) for the non-extender user? The following features are available to all users:

* A new toolbar with buttons for the most common menu actions, plus a button to open RemoteMaster.

* "Real" help now available through the File/Help menu.

* Raw Data page now displays the make and model of the processor and the JP1 interface it uses (JP1, JP1.2 etc).

* A user-friendly interface for the "Pause" Special Protocol, in which you simply enter the required pause duration in seconds (decimal point allowed). Note that the stand-alone Special Protocol for the Pause function, available in RM, can be installed on non-extended remotes.

Also available for non-extended remotes by making additions to the RDF:

* Read-only Settings. These display on the Settings panel of the [General] page but cannot be changed by the user.

* Entries for an RDF that enable it, on its own, to create the Manufacturing Reset state (also known as Factory Reset, or 981 Reset) of the remote. This enables an entire setup for the remote to be created without needing to download and enhance an existing setup.

IR 8.00 is also fully compatible with remotes that use "soft" devices. These are remotes that do not have dedicated device selection buttons. They support a variable number of devices with user-defined names. A device is selected by choosing from a list on an LCD screen and pressing Enter. At present the remotes with this feature are the URC-7780 and URC-7781.
____________________

Graham

tennessee titan · Joined: 18 Nov 2008 Posts: 117

Thank you...

mathdon · Posted: Thu Mar 12, 2009 8:39 am Post subject:

IR 8.00 Beta 6 posted

As there has been a week without further comments on Beta 5 or my proposals for Beta 6, I have now posted IR 8.00 Beta 6 here. The changes to Beta 5 are as described in my post headed "All things to all people", a little earlier in this thread.

The documentation has been revised accordingly and the RDFs included in the package no longer mention RDF4 in their name. The revisions to the RDF4 spec incorporated into Beta 6 enable the construction of RDFs that are compatible with both RDF3 and RDF4 applications. The differences between the RDF3 and RDF4 specs are described in the file RDF3Spec_rev004_Addendum.doc included in the package.
___________________

Graham

mr_d_p_gumby · Posted: Fri Mar 13, 2009 6:55 pm Post subject:

I noticed a minor discrepancy. On the Raw Data tab, when an RDF with Processor=SST is loaded, the interface type is incorrect. It currently shows up as JP1, but should be JP1.1.
_________________
Mike England

JP1 Group at Yahoo!, JP1 Files Area

mr_d_p_gumby · Posted: Sat Mar 14, 2009 10:42 am Post subject:

Going through my notes on the IR to-do list again, I ran across this:

mr_d_p_gumby · Posted: Mon Mar 16, 2009 7:52 pm Post subject:

I have posted the latest draft of the RDF Specification Version 4 for review.

Graham--let me know if I have any new stuff incorrect.
_________________
Mike England

JP1 Group at Yahoo!, JP1 Files Area

mathdon · Posted: Fri Mar 20, 2009 10:17 am Post subject:

IR 8.00 Beta 7 posted

I have now posted IR 8.00 Beta 7 here. This fixes the following bugs in Beta 6:

Wrong interface shown on Raw Data page for remotes with SST processor.
Auto clock setting, which worked in Beta 5, did not do so in Beta 6 due to a silly error.
Correct checksum put into exports of Wav upgrades for HCS08 remotes, see this thread for more info.
Imports of Wav upgrades for URC-7781 now go into correct part of E2. I found that an E2 base address of $EC00 was hard coded into the Wav import routine for JP1.2 remotes, but for the URC-7781 it should be $F000. Base address now taken from RDF.

I am hoping that this will be the last Beta version before general release. I hoped that for Beta 6, but it was not to be.
__________________

Graham