JP1 Remotes

When I create an extender, besides the HEX, I include an empty IR file, that has all the data in. I really think that's a lot easier than changing everything in the RDF. I can see having an extender self install as being a nightmare.

So I downloaded the IR 8.0 beta and wanted to adjust the RDF's for the JP1.3 extended remotes (Atlas, 15-13x, 15-100 and the Comcast DVR) to take advantage of the pause values

The pause values in the extenders are designed around being 100ms for each count in the pause value, the pause value is in the high byte of the 2-byte pause.

So, here's my guess at what I need

[SpecialProtocols]
Pause=01FB (Pause)

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


did I get that right?


Thanks

Bill, that's right, except that you don't need the '(Pause)' after the 01FB. If there is no user name, it defaults to the RDF name (which in this case is Pause). Didn't it work?

I suggested earlier that the default setup code for each device button could be an additional optional parameter, DefSetup say, in the [DeviceButtons] section of the RDF, provided this did not interfere with RM. The present syntax is

ButtonName=HiAddr LowAddr [TypeAddr]

so some means is needed to distinguish between a specified TypeAddr and an absent TypeAddr with specified DefSetup. I tried adding a DefSetup parameter in brackets, but that gave RM syntax errors. However, a syntax of

ButtonName=HiAddr LowAddr[,][ TypeAddr][, DefSetup]

does not create an RM syntax error. The comma after LowAddr is needed only if TypeAddr is absent.

I presume that RM is treating COMMA and SPACE both as white space, so if TypeAddr is absent, RM is reading DefSetup as a TypeAddr. If both are given, RM doesn't object as presumably it only reads the first three tokens.

I can't see that RM does anything with data from the [DeviceButtons] section, so I don't think that would upset how RM operates. But presumably it would upset RMIR for remotes (which I believe are the majority) that do not use TypeAddr.

It is a pity that putting DefSetup in brackets isn't acceptable to the current version of RM, as the existing parsing of DeviceButtons entries in IR would simply ignore it, whether or not a TypeAddr value were present. No commas would be needed, the syntax would just be

ButtonName=HiAddr LoAddr [TypeAddr] [(DefSetup)]

That would be my preferred choice but it would need Greg making a small amendment to RM to ignore a left bracket and anything that followed it.

I would welcome comments, please.

I realise I was being stupid about the syntax issue in my last message. Only one comma is required, a syntax of

ButtonName=HiAddr LowAddr [TypeAddr][, DefSetup]

is sufficient and I am happy with that, so the idea of putting DefSetup in brackets is no longer relevant. It still leaves the fact that it is probably misinterpreted by RMIR.

I am implementing this so that I can discover whether I can recreate a 981 reset state for my old remote, a URC-8550 that already seems to have quite a complicated RDF. If all seems well, do I post this as Beta(4) - even though I have said that I was freezing the development of v8.00 and leaving everything outstanding for a later version? I think I would like to do that, so others out there can also try creating 981 reset states with an RDF.

Graham

Sounds like a good idea Graham, making a beta 4. I'd like to try some of the new features, like the 981 reset states with an RDF for the atlas 3033 remote.

Best,
jeff

I have now posted IR.exe v8.00 Beta 4 here, the same location as before. It adds the facility to specify default device setup codes in the RDF. The revised syntax for the [DeviceButtons] section is as suggested above:

ButtonName=HiAddr LowAddr [TypeAddr][, DefSetup]

If you need TypeAddr absent but DefSetup present then DO NOT use the RDF with any version of IR.exe earlier than 8.00 Beta 4, and DO NOT use it with the current version of RMIR. The syntax is designed to be compatible with IR.exe v8.00 Beta 4 AND with RemoteMaster in RM (but not RMIR) mode.

I have made an RDF for URC-8550 Topline 8 that creates an equivalent of the 981 Reset state when loaded into Beta 4 on its own (no .ir file) and have tested that the remote works correctly when this state is uploaded to it. I've added the RDF to the few others included in the zip file. I've also updated the documentation to describe the new facility.

I mentioned in an earlier posting that you may need to create a few additional settings, possibly even for bytes whose purpose is unknown, in order to create a 981 Reset state. Add these to the end of your [Settings] section (with innocuous names!) and make them read-only by setting StartReadOnlySettings to an appropriate value in the [General] section. You will find three such settings in the URC-8550 example - and no, I don't know what they do!

If you try creating such an RDF for your remotes, please post a note of your experience here.

Graham

Some days ago, Rob wrote:

The problem with these fixed data notifications is that they scare many users and they don't know whether they should accept the change or not, and about 50% of the time they don't accept the change.

I must admit to being one of the scared users! I thought that if the fixed data in the remote and the RDF differed then it meant I had the wrong RDF, so the correct answer was NO, don't accept the change. But in my experiments with the URC-8550 Topline 8 I found that

(a) the fixed data in the remote after a 981 reset differed from that in the (standard) RDF,

(b) the initialization of the Upgrade and the Device Upgrade areas in the EEPROM (this is one of the remotes in which these areas are separate) differed between the real 981 reset and that created by my RDF (the standard one with added default setup codes and 3 new settings), and

(c) when uploaded to the remote, the pseudo-981 reset created by the RDF worked just fine!

I presume there is a connection between the different fixed data and the different initializations both being acceptable to the remote. But what this all has shown me is that I have no idea what fixed data is all about, or just how "fixed" it actually is.

Can anyone enlighten me, please?

Graham

The word "fixed" in "fixed data" doesn't mean fixed (as in "repaired") it means fixed (as in "static"). Normally, we used the fixed data option to populate areas where we either don't know what they do or we know that they should always be set to the specific values. (We also use it for the 2nd part of the signature in some of the old 6805 remotes).

I don't remember why we put all that fixed data in the URC-8550 remote, I'm sure we had our reasons but that doesn't mean we were right. It's quite possible that we should we letting the user change some of that data in IR, and we would if we knew what it meant.

OK, the memory just came flooding back to me, I remember what the $00A data is, it's the address of all the ends of the various sections. Keeping in mind that addresses are stored backwards in the Mits-740 remotes, here's the $00A data...

$00A = $3B $00 $FF $00 $FF $04 $FF $06 $CE $07 $CE $07 $CE $07 $CE $07 $CE $07 $FD $07

and here's what it means:
$3B $00 = $003B - end of header section (ie, setup codes and settings)
$FF $00 = $00FF - end of keymove/macro section ($03E..$0FF)
$FF $04 = $04FF - end of upgrade section ($104..$4FF)
$FF $06 = $06FF - end of device specific upgrade section ($502..$6FF)
$CE $07 = $07CE - end of timed macro section ($702..$7CE)
$CE $07 = $07CE - (section missing)
$CE $07 = $07CE - (section missing)
$CE $07 = $07CE - (section missing)
$CE $07 = $07CE - (section missing)
$FD $07 = $07FD - end of unknown section

You'll notice that each section starts with a checksum as specified in the [Checksums] section:

[Checksums]
+$000:$002..$03B
+$03C:$03E..$0FF
+$100:$102..$4FF
+$500:$502..$6FF
+$700:$702..$7CE
+$7CF:$7D1..$7FD

I see now that there's a final section in the URC-8550 (ie, $7D1..$7FD) that's not present in remotes like the URC-9800 and I'm guessing that we didn't know what it was for, so we just hard coded it using fixed data.

mathdon wrote:Some days ago, Rob wrote:

The problem with these fixed data notifications is that they scare many users and they don't know whether they should accept the change or not, and about 50% of the time they don't accept the change.

I must admit to being one of the scared users! I thought that if the fixed data in the remote and the RDF differed then it meant I had the wrong RDF, so the correct answer was NO, don't accept the change.

We should start using the [AutoSet] section for this kind of thing. It was added way back in IR v6.00, but I don't think any of the RDFs have ever been updated to use it instead of [FixedData]. The only thing that should be in fixed data really is the older second-half signatures, and anything we're not sure about.

Thanks a lot, Rob. Now I know what that first section of fixed data is all about, I see that my URC-8550 is a little different. After a 981 Reset, the values that are $CE $07 in the RDF are $FD $07 in my remote. Also, IR reports a checksum error at $0700. The checksum present in the remote at $0700 actually corresponds to the range $0702-$07FD. So it appears that my URC-8550 doesn't have the unknown section $7D1..$7FD, instead the Timed Macro data goes all the way to $7FD. The fixed data in ranges starting at $7D1 and $7E2 that are in the standard RDF are also unnecessary. If I change $7D1..$7FD entirely to $FF's, my remote continues to work happily.

So perhaps I have a second edition URC-8550? Was there such a thing? In any case, I now understand the one I have a lot better.

Graham

Actually, something we figured out a long time ago, but never did much with, was that the sections in the Mits-740 remotes are moveable. So, if you want a little more memory in one of the sections and less in another, you can move things around. Of course, if you do that, you'll also need to create a custom RDF for yourself, but it's do-able.

As the Mits-740 remotes are pretty scarce and out of date in so many other ways, we never even thought about overhauling IR to make the changing of the section sizes easier for the end-user.

I'm just looking at the RDF for the URC-8550 again and I notice that it says "with Time and HT Support" in the heading, and this is jogging something in my memory. I think that code was actually added by us to fix the time and HT settings on a reload. Look at the RDFs for the 'HT80HT8C" URC-8090 remote and you'll see there's a standard one without the extra section and one with TIME support that has the extra code.

As these remotes are really old and we haven't done anything with them in ages, if you want to search for old messages about it, you'll need to search in the Yahoo forum. The guy who was the expert with these remotes is Scott Johnson (aka "scottj75074").

mr_d_p_gumby wrote: The only thing that should be in fixed data really is the older second-half signatures, and anything we're not sure about.

Mike

I just got settled in on the JP1.3 extenders to use [FixedData] to allow for multi-versions of the extenders to co-exist. Should I be using [AutoSet] for this?


mathdon

so the syntax with no name on the PauseParams would be???? (since the RDF help says that all of the items in that statement are required.

unclemiltie wrote:I just got settled in on the JP1.3 extenders to use [FixedData] to allow for multi-versions of the extenders to co-exist. Should I be using [AutoSet] for this?

The two sections function identically with regard to putting data into the remote image, but the AutoSet section will do so without prompting the user. So I'd say to use AutoSet if you don't want to give the user an option to refuse the data. However, if you want IR to match up the RDF with the various versions, then some unique data should be in the FixedData section.