JP1 Remotes

unclemiltie · Posted: Thu Feb 12, 2009 11:26 pm Post subject:

Thanks Mike, I'll leave the [FixedData] stuff in there for version control.

BTW, I just uploaded versions of all of the JP1.3 extenders that I have been working on that have the support for the new Pause timing that is in IR 8.0.
_________________
this JP1 stuff is a sickness!

mathdon · Posted: Fri Feb 13, 2009 7:21 am Post subject:

For Bill

It's not "no name on the PauseParams", it is "no username on the SpecialProtocols entry". The syntax doesn't change if you omit the "(Pause)", as the username defaults to the RDF name, i.e. to the name on the left of the "=". So it is just:

[SpecialProtocols]
Pause=01FB

[General]
PauseParams=Pause, 2/1, 10

This means, of course, that you don't need to change the [SpecialProtocols] entry from its old form, you just add the PauseParams entry in the [General] section. The bracketed usernames really come into play when you want to support two alternative Pause protocols in the RDF.

For Rob

Thanks for the extra info. I want to find out how the setting of the remote's time from the computer clock is done, so I will explore further. I don't intend to use the URC-8550 again "for real", but it is so different from my URC-7781 that investigating it adds a lot to my pool of JP1 knowledge.
__________________

Graham

The Robman · Posted: Fri Feb 13, 2009 8:14 am Post subject:

I just sent you invites to the Yahoo groups so you can do your research on the URC-8550.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

Capn Trips · Expert Joined: 03 Oct 2003 Posts: 3990

Much of this discussion is somewhat above my comprehension level, but I have been tracking it pretty regularly. Sounds like this update to IR provides quite a bit of user-friendliness and significant increase in capability. I look forward to using it.

Forward and backward compatibility, however, seem to be a concern to me.

How will this impact existing databases? As I read this, every RDF will have to be modified to take advantage of this new version of IR. Is that correct? Who is taking that task on? Will it still work with "old-style" RDFs? I see that Greg is working pretty closely here to ensure that RM will retain comapatibility as the RDFs evolve.

I imagine the guy who used the tools to set up his URC-8910 a year ago and next month he returns and wants to program his new URC-8820. He downloads the new RDF. Will it work with his old RM and IR? Or will he have to update ALL of the tools? After updating the tools, will his old URC-8910 IR file open properly? or will we have to retain legacy tools to convert old IR and RM files into this new style?

Perhaps this is all accounted for, but it's unclear to me at this point.
_________________
Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!

Remotes: OFA XSight Touch, AR XSight Touch
TVs: LG 65" Smart LED TV; Samsung QN850BF Series - 8K UHD Neo QLED LCD TV
RCVR: Onkyo TX-SR875; Integra DTR 40.3
DVD/VCR: Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A3 (HD-DVD), Panasonic AG-W1 (Multi-system VCR);
Laserdisc: Pioneer CLD-D704.
Amazon Firestick
tape deck: Pioneer CT 1380WR (double cassette deck)
(But I still have to get up for my beer)

mathdon · Posted: Fri Feb 13, 2009 9:24 am Post subject:

Capn Trips, I hope I can set your mind at rest about backward compatibility. IR version 8.00 works perfectly happily with existing RDFs. With one exception, the user will see exactly what he/she is used to seeing and it will work in exactly the same way as before. There are no changes to the format of .ir files, so old .ir files work with the new IR version and new .ir files work with all the old tools.

The exception mentioned is the Pause special protocol, which by default shows the new user-friendly interface in which you specify the pause duration in seconds. This will work correctly with the stand-alone Pause protocol available through RM but may give a wrong translation of duration to protocol data (probably by less than a factor of 2) with Pause protocols built into extenders. The "old" interface (i.e. raw hex) is available, if preferred, just by checking the "Hex" box.

RDFs that take advantage of the new facilities work perfectly happily with RemoteMaster in RM mode, as they do with other tools such as ExtInstall. Whether such new RDFs will work with old versions of IR.exe (or current versions of RMIR) depends on which of the new RDF capabilities have been used. The ones that may cause problems are the syntax extensions in the [SpecialProtocols] section, and entries in the [DeviceButtons] section that give default device setup codes.

I presume a user won't download updated RDFs without also downloading the updated IR.exe, so the incompatibilities I have just mentioned should have little practical significance. I can assure you that backward compatibility has been kept in mind, and maintained as far as practicable, throughout this development exercise.

Graham

mathdon · Posted: Mon Feb 23, 2009 9:00 am Post subject:

I have been giving some thought to the problems of compatibility between different versions of IR.exe, RDF files and extenders. Some of the enhancements to the RDF syntax that have been introduced for IR 8.00 will be seen as errors, or will be misinterpreted, by earlier versions of IR.exe. Also, Bill and I are creating new versions of our extenders that will include auto clock setting from the computer's clock and which will rely on the version of IR.exe being 8.00 or later for this to work correctly. I would like views on the following suggestions to meet these problems.

Compatibility between RDFs and IR.exe

IR versions 7.xx (and presumably earlier ones back to some unknown point) refuse to load an RDF file, or a .ir file requiring such an RDF file, if that file does not contain the entry

RDFsync=3

in the [General] section. They give an error message

unclemiltie · Posted: Mon Feb 23, 2009 2:13 pm Post subject:

Graham

All of my extenders (URC-9960B01, URC6960, and all of the JP1. extenders) have a version number in the data. It is two bytes, one major another minor version. If you want to do something different, let me know and I can change it.

It would be helpful in the remote to know which version of IR loaded it, that way if we know of incompatibilities we can try to program around them in the remote. But the overhead of doing so is often an issue since the remotes have very few resources while IR has more. If we can find a way to do all of what we need with the desktop app (IR, RMIR, RM) then I suggest we do so as the remotes are already pressed for space.
_________________
this JP1 stuff is a sickness!

mathdon · Posted: Mon Feb 23, 2009 5:42 pm Post subject:

Bill

What is the format of your two version bytes - ASCII (1 = $31) or Hex (1 = $01) or something else? Do you normally use a separator (dot or something) if you write the version?

Is your second para supporting my interpretation of your suggestion? I wrote

unclemiltie · Posted: Mon Feb 23, 2009 6:01 pm Post subject:

The format of my extender versions is:
Byte 1: Major version, in hex (i.e $02 is version 2.x)
Byte 2: minor version, in hex (i.e. $03 is version x.03)

The current atlas version is $02 $04 or 2.04

I generally put the two byte version at the end of the extender in the E2 area (for example the Atlas one is at $1FE)

I support putting a single byte with the IR version in it, but I'm just cautious that the extender doesn't have a lot of flexibility so if we can do things on the desktop side we should. It'll always be helpful for the extender to know the version of IR that programming it.
_________________
this JP1 stuff is a sickness!

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

Are you going to distinguish between IR versions and RM(IR) versions?
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

unclemiltie · Posted: Mon Feb 23, 2009 8:13 pm Post subject:

oooh... good question. Yet another reason to try to keep the heavy lifting on the desktop side and not the the remote side.

Perhaps an RDF Sync version is what we really need where we can talk about "feature versions" and not software versions?
_________________
this JP1 stuff is a sickness!

mathdon · Posted: Tue Feb 24, 2009 6:43 am Post subject:

Sorry, Greg, I hadn't thought of that one. Would you be happy with Bill's answer, so we have

RDFVersionAddr=Addr

with the highest RDFsync value supported by IR or RMIR being written to the given address? The extender would have to cope with this entry being ignored by current versions of IR and RMIR. Perhaps the byte addressed by Addr could be set to $03 by [AutoSet], so the extender would see Version 3 from IR and RMIR versions that didn't recognise the RDFVersionAddr entry.

I would make this entry operate in the same way as TimeAddr, in that the byte value is written to the remote but not to the IR buffer. On an Upload to Remote command the buffer value of the byte is saved, the new value written, the buffer uploaded to the remote and finally the original buffer value is restored. That way, the RDFsync value would never get recorded in a saved .ir file. This byte could therefore be $03 permanently in the .ir file but would be written to the remote as $04 by IR 8.00.
_______________________

Graham

mathdon · Posted: Thu Feb 26, 2009 1:18 pm Post subject:

I have put the following new functionality into IR 8.00 Beta 5 (which will be uploaded shortly in the File Section):

1. The changes concerning RDFsync and the associated messages that I proposed in my recent posting in this thread. In particular the enhanced version of the RDF spec supported by IR 8.00 is now called Version 4, and IR 8.00 accepts RDFs of either Versions 3 or 4.

2. An enhanced syntax for the TimeAddr entry in the [General] section, to meet the needs of current processors. This is now

TimeAddr=Addr[, Format]

where Addr is the start address for the three time bytes and the optional Format is one of

Hex - the default value, giving the old Producer 8 format
BCD12 - newer US remotes, hours is BCD value 1-12 with bit 5 = 0 for AM, 1 for PM
BCD24 - newer European remotes, hours is BCD value 0-23

For both BCD formats, minutes is BCD value 0-59 and day is 1-7 with day 1 = Monday.

3. In the [General] section, a new entry

RDFVersionAddr=Addr

When this is present, it implicitly adds an [AutoSet] entry with Addr as its address and the maximum supported RDFsync value as its data. If there is an actual entry in the [AutoSet] section with address Addr, then this is overwritten. This means that you can put a default RDF Version (normally 3) into the [AutoSet] section which will be used by IR.exe versions that do not support this new entry - provided, of course, there is nothing in the RDF that is incompatible with RDF Spec Version 3.

4. Also in the [General] section, a new entry to allow the Extender Version to be shown on the Raw Data page. This is

ExtenderVersionAddr=Addr1, Format1[, Addr2]

where

Addr1 is the EEPROM address of the major (or only) version byte
Format1 is the format of this byte, either Hex (eg '1' encoded as $01) or Asc (eg '1' encoded as $31)
Addr2 is the EEPROM address of the minor version byte (if needed), format always Hex.

The Asc option is needed for my URC-7780/81 extenders, where the versions are A1 and (shortly) A2. When Format1 is Asc, there is no separator between the major and minor values. When Format1 is Hex, there is a '.' separator and the minor value is two digits, with a leading zero if < 10.

5. A marker, as discussed earlier in this thread, for .ir files that have been produced entirely within IR.exe - possible when the RDF on its own creates a 981 Reset state (or equivalent). The marker is the date of loading of the RDF, as three BCD values written to the last three bytes of the Advanced Code area. To avoid a question of US/European ordering, I have used the international ordering year-month-day. This date is overwritten when a .ir file is loaded, but if that .ir file has been created entirely within IR.exe then it will contain the date present when it was saved.

There is also a minor change to the handling of part of the new Special Protocols syntax, as I had misunderstood one of Mike's requirements.

If any of the above enhancements cause you difficulties, please post them here.
___________________________

Graham

mathdon · Posted: Wed Mar 04, 2009 7:21 am Post subject:

I have now posted IR 8.00 Beta 5 here. It includes everything described in the preceding post and two more minor changes: (1) improved glyphs for the toolbar buttons, (2) corrected handling of Export to Wav for HCS08 remotes. Item (2) is described in this thread.

I have been thinking about how to handle the development and issue of RDFs that are specific to RDF Spec Version 4. I see no reason why RDFs that use entries new to RDF4, but do not use syntax enhancements of RDF3 entries, should not continue to say RDFspec=3. This assumes that all applications using RDFs ignore entries that they do not need. (Is this true?). RDFs that use syntax enhancements of RDF3 entries would have RDFspec=4. Does this seem OK?

The RDF files included in the Beta 5 package now say RDF4 in their names (previously they said they were for IR8.00) and have RDFsync=4 in their data. This removes any explicit mention of IR.exe as distinct from RMIR.

It would be nice if we could have a new category, RDF4 Files, in the Tools file section for RDFs that say RDFspec=4.
____________________

Graham

Nils_Ekberg · Posted: Wed Mar 04, 2009 9:02 am Post subject:

Greg will have to speak for how RM would handle the RDF's since I don't remember exactly but I do think it ignores things it does not recognise in most cases.

I do however see no reason why IR could not handle RDF's with RDFsync=3 as if they were purely RDF3. If they have RDFsync=4 then they should handle them as RDF 4's expecting new parameters.

I really don't like the idea of adding RDF4 to the name of the file and am assuming you are not suggesting that. So, the big question is if we update an RDF to 4 and delete the RDF 3 version what will IR do with upgrades that were built on RDF 3? You may have addressed that but I don't remember.
_________________
Nils
Files Section
Diagnosis File Section