JP1 Remotes

mr_d_p_gumby wrote: As I mentioned before, all the stand-alone pause protocols use the same timebase regardless of processor, with the lone exception of the non-+ S3C8. They all are in 1/16th second (62.5 mS) steps. (The non-+ S3C8 is in 1/10.66 second (93.7 mS) steps because the code is the same as the S3C8+ but the processor executes slower.)

Mike

Should I re-do the pause protocol included with the extender to use the same built-in time base that you used in all of the other Samsung based protocols? It seems silly for us to special case the tool to deal with oddball decisions made by extender writers (i.e. me) and instead ask me to try to conform a bit. I would bet that changing the extender pause protocol is a heck of a lot less work, and less confusing


-bill

unclemiltie wrote:Should I re-do the pause protocol included with the extender to use the same built-in time base that you used in all of the other Samsung based protocols? It seems silly for us to special case the tool to deal with oddball decisions made by extender writers (i.e. me) and instead ask me to try to conform a bit. I would bet that changing the extender pause protocol is a heck of a lot less work, and less confusing

No, I wouldn't bother re-doing your pause. As long as you know what your timebase is, the RDF for your extender can be made to supply the correct info to IR. Besides, you're assuming that the choice of 1/16th second was mine. In fact, I just made mine match the original S3C8+ version (which I did not write), it being the only one available at the time.

Note that I have only suggested to Graham that the default value be 16. Each RDF can override the default if needed, since the default is only used if the RDF does not specify a timebase value. (Also, trying to save Nils some editing time, since most of the RDFs are for unextended remotes.)

How do you measure things like 1/16th of a second? All I've ever done is check that my pause protocols have a noticible delay at my highest hex value. One of my pause protocols will give times as long as 20 seconds, that I can measure, but how on earth do you measure times slower than 1 second!

And btw, one of my extenders uses both bytes of data to set the timer. Its my best pause. I never use pauses, but if I did, I'd make sure that my JP1.2 remotes used my 2byte protocol.

You do it by timing big multiples and then dividing them back down.

For example, I measured 25 seconds, 20 seconds, 15 seconds and 10 seconds ($FF, $C8, $96 and $64 pause values in my extender protocol)

But it's not highly accurate, but close enough

xnappo wrote:

mdavej wrote:This is a little OT, but how is the Key Move / Macro Import function supposed to work? I understand key moves could come from KM and be pasted in. But how are macros formatted and what do you import them from? Would some kind of Export be useful, to copy from one instance of IR to another, or would that be impossible to implement?

An export would have been very nice last weekend when I moved from the Atlas 1.0 extender to 2.0!

xnappo

I will third this The ability to export key moves / macros / special protocols will be very nice, especially when you upgrade extenders.

Here's an update on progress. First, many thanks to Mike for the very helpful info on how to identify processors from the RDF. This is so useful I feel it should be copied and made into a sticky in the General forum.

The PauseParams RDF entry now has the following syntax:

PauseParams=UserName, DataBytes, Multiplier

where UserName is the name in brackets in the Special Protocols entry (if no name given in brackets, UserName defaults to Pause), DataBytes is one of 1, 2/1, 2/2, 2/B or 2/L and Multiplier is the conversion from seconds to data entry. The DataBytes entries mean

1 = one data byte,
2/1 = two data bytes, only first used by protocol,
2/2 = two data bytes, only second used by protocol,
2/B = two-byte data value, big-endian (high byte first),
2/L = two-byte data value, little-endian (low byte first).

If a PauseParams entry is given, all three parameters are mandatory. There can be multiple PauseParams entries and the UserName is not checked for validity. If the UserName is not assigned in the Special Protocols section then the PauseParams entry is ignored. But if a UserName assigned in the Special Protocols section does not have a corresponding PauseParams entry, a default applies. The default is

DataBytes = 2/1, Multiplier = 16 (unless processor is S3C8 - with no plus - when the multiplier is 10.66).

The S3C8 is identified from Mike's info. When DataBytes is 2/1 or 2/2 then the second byte is always the EFC of the first byte, regardless of which of them is the actual data value.

I've also used Mike's data to enhance the Processor display on the Raw tab page. This was something put in much earlier, but only with the RDF name so that, say, S3C8 and S3C8+ would not be distinguished. I've now put in the full names from Mike's list. I've also added the manufacturer, but could someone confirm that I have these right. I've put the ones beginning with S as Samsung, the 6805 ones as Motorola, HCS08 as Freescale, SST just as SST (it seems to be both the manufacturer and the processor name?) and the P8/740 as Mitsubishi.

I think any meaningful integration between IR and RM is a long way off, but as a tiny step I have put an "Open RM" button on the new button bar. There is a corresponding entry in File/Set Directory, needed before Open RM will work. I believe there is a .exe version of RM as well as the Java .jar one, so the button checks the directory first for a .jar file, and failing that, for a .exe file.

I've put three new entries in the Help menu. The first opens Vicky's IRHelp.hlp, if present (again you need to set the directory). If no directory is set up, it prompts you to do so and tells you that if you are using Vista then you need to install WinHlp32 from the web location it gives. (I use Vista and it does work.) The other two open Web pages. One is for Rob's "IR - Just How Easy Is It?" and the other is for the JP1 Home Page. I would like to include Vicky's IRHelp files in what will become the IR 8.00 package, with due acknowledgement of course. Would you be happy with that, Vicky?

That's about it for now, but I have a question. Would you like to see it in its present state, while work is continuing and on the basis of "use it at your own risk", or would you prefer me to wait till it is more mature?

You could make a "beta" version available, but put it in the Diagnosis Area so people will only really find it by following a link here.

It sounds like you have the processor manufacturers correct. They reflect the names as they were at the time the chips were made, at least. (No point in getting tangled in the fact that Motorola is now Freescale, Mitsubishi is now Renasas, etc.)

If you think it's ready for some beta testing, I'd go ahead and post it in the diagnostic area, linked in this post for now.

I may have some questions on your RDF syntax at some point, since I'll now have to edit the official RDF specification document to include the new features.

Sorry for the "lateness" of this, Question on the pause params and the defaults


Should we consder not having a default and if PauseParams is not there, IR behaves as it does today?

I'm not sure which is more confusing for users. The way things are today, especially in the 2/x cases, or by changing things on people who know how to deal with stuff..

(as an example, how many people HATE MS Vista because Microsoft moved damned near everything and those who really did know how to use XP were all of a sudden faced with learning everything over again)


-bill

mr_d_p_gumby wrote:It sounds like you have the processor manufacturers correct. They reflect the names as they were at the time the chips were made, at least. (No point in getting tangled in the fact that Motorola is now Freescale, Mitsubishi is now Renasas, etc.)

I agree. Besides, if you open up any of our remotes and are able to read the name of the chip, it will be Mitsubishi or Motorola as those were the current names at the times that the chips were made (well, the HCS08 might have been Freescale already, but who cares).

Bill, my feeling is that if we abandon the defaults for pause timing, then the existence of the user-friendly interface will be invisible to those with unmodified RDFs. If we keep the defaults and some users don't like them, all they have to do is check the "Hex" box and they will be back with what they know. Even if the defaults are wrong for some users (those using pause protocols built into extenders that use a different multiplier), they will still get a pause, just not one of just the duration they intended. But it is unlikely to be out by other than a factor of 2 or so, unless they have one of the remote/extender combinations for which the inbuilt extender can never give a decent pause.

I forgot to mention, in my previous message, that I have tried to meet one of Liz's concerns, two columns in the Key Moves grid that are both headed "Device Button". I've renamed them "From Dev Button" and "To Dev Button", which I hope is an improvement.

Here's a quick minor change that I'd like, when you CLONE a keymove, IR automatically clears out the EFC code (the assumption being that you will enter a different code). I'd like it to not clear anything out because sometimes you might want to copy a keymove to the same button in different device modes.

Here's another, could we have a Notes column to the right of the setup codes in the Device buttons panel in the General tab.

Finally, I think it would be useful to be able to rename buttons. The most obvious use of this would be for renaming phantom buttons to discrete names, but you could also use it for buttons like the L1/L2/L3/L4 learning buttons and the M1/M2/M3 macros buttons. I think the re-named information should be stored in a separate text file with the remote's sig as part of the file name, rather than having the updates go into the RDF or the IR file. That way, even if the user downloads a new copy of the RDF, their customizations will remain.

The Robman wrote:Here's a quick minor change that I'd like, when you CLONE a keymove, IR automatically clears out the EFC code (the assumption being that you will enter a different code). I'd like it to not clear anything out because sometimes you might want to copy a keymove to the same button in different device modes.

Seconded! That is one of those little things that you forget about because you are used to it.

xnappo

Multiple ToadTogs with minimal overhead

Vicky raised the issue earlier in this thread of how to have two ToadTog special protocols, such as 0181 and 0182, to give 16 toggle bits. It has dawned on me that the enhanced special protocol syntax now allows a single special protocol to achieve this. Suppose you have the entries and set up protocol $0181 to have one fixed byte. Create device upgrades for VCR/1800 to use protocol $0181 with fixed byte $00 and for VCR/1801 to use protocol $0181 with fixed byte $01. In the code for protocol $0181, read the fixed byte and use it as an offset into a bank of two or more ToadTog toggle bytes. You then have 16 - or even more - toggle bits with minimal overhead. The protocol code will only marginally increase in length, the only other overhead is the additional device upgrade entry, and nothing need be changed in the IR interface for ToadTog.

Note that this only works because it is now possible to specify which upgrade device to use, rather than letting IR.exe search for one that uses the protocol concerned.

Incidentally, can anyone enlighten me on the origin of the standard device setup codes and PIDs for the various special protocols? Until I took over maintenance of IR.exe I thought these values must be built into it, but in fact it is only the protocol names, and the function names for protocols with several functions, that are built in. I've used VCR/1801 in this example for the second ToadTog just because VCR/1800 seems to be the standard device for a single ToadTog. I've no idea if it is appropriate in any other way.

mathdon wrote:[Incidentally, can anyone enlighten me on the origin of the standard device setup codes and PIDs for the various special protocols? Until I took over maintenance of IR.exe I thought these values must be built into it, but in fact it is only the protocol names, and the function names for protocols with several functions, that are built in. I've used VCR/1801 in this example for the second ToadTog just because VCR/1800 seems to be the standard device for a single ToadTog. I've no idea if it is appropriate in any other way.

Well, the international joint industry committee on JP1 standards met for several months to determine... NOT!

Actually, I think most of the setup code numbers and PIDs for the special protocols were picked out of thin air when they were first created. The main emphasis at the time was just to use a numbers that would likely not conflict with known setup codes & protocols, so higher numbers were used. Standardization of sorts came about when they were integrated into the earliest extenders and into the Extender Code Calc spreadsheet (predecessor to IR's SP tab).

We've always tried not to embed hard-coded things into the JP1 tools unless there was no other way, and I'm happy to see we've been able to continue in that tradition with these latest changes to IR. You're efforts have given the RDF much greater flexibility in controlling the special protocols without having to resort to "cheating"!

If you are still game, there is one other issue that I'd like to see addressed in IR. It has not been publicized much, but some of the newer remotes can handle setup codes greater than 2047. Remotes that have this entry in the RDF file:can have setup codes up to 4095. I've already modified KM to deal with this, and IR will accept such setup codes on the General tab, but the Add/Edit functions on the Devices tab will not allow them to be entered or imported.

In parsing the imported upgrades, it would only be valid to accept setup codes 2048 through 4095 if the header is "Upgrade Code2" like this: