JP1 Remotes

OK, now I know mjadev was wrong, I'll see what I can do with a friendly user interface for Pause. Don't worry about tweaks, Bill. My millisseconds aren't exact, either. The ROM has a timing loop that's about a millisecond and I just use that. No-one is going to care about a pause that's a few percent out.

That'll probably be the next think I do. I'm doing Rob's buttons at the moment.

mathdon wrote:I'm doing Rob's buttons at the moment.

Cool!

mdavej wrote:I think I understand now. What Bill and Mike are saying is that byte two is a don't care in this case, so it could just be zero. Is that right guys? So although RM is calculating something beyond my comprehension for that second byte, it doesn't really matter.

That is correct. The mysterious second byte needs to be present, but its value has no meaning to the Pause protocol.

FYI, RM & KM are calculating the EFC value of the first byte and loading that into the second byte. Why? Because UEI initially had several implementations of the new keymove format, and some of the earliest versions seemed to check for the EFC value under some circumstances. Also, IIRC, I think IR sometimes tests for this in order to make a best-guess as to whether the keymove uses a 1 or 2 byte protocol.

mathdon wrote:I'll see what I can do with a friendly user interface for Pause.

Don't forget to include support for the stand-alone Pause protocol that is provided in RM & KM. I wrote all the other stand-alone versions of that protocol except for the S3C8s, and I made their timings match the S3C8+ version. As a result, they all use the same timing values except for the original S3C8 (non-+ version), which runs slower.

I think supporting the built-in Pause protocols in the EEPROM extenders is going to be difficult. A little history may help to clarify the problem. The original extenders implemented the time delay by blinking the LED, and this worked OK. As time went by, the extenders were ported to many different remotes. Somewhere along the way, the firmware in the remotes changed such that the LED blink was bypassed when called by the extender's pause protocol. The result is that the built-in pause provides extremely short delays. In most cases where this caused a problem, we have advised extender users to use the stand-alone Pause protocol.

I bring this up because I think you may need to provide a way for the extender RDF to activate both types of Pause protocols at the same time. This would require that one of them be called something other than "Pause".

Because of the change I've already implemented that allows for RDF-defined names to be used for special protocols (initially to allow for Vicky's request to be able to have two ToadTog protocols), there is no difficulty in havng two protocols both with the standard name of Pause. You would have an RDF entry such as which would then show up as PauseA and PauseB in the Special Protocols tab, both in the combo box dropdown list and in the grid entry.

Sounds like a good start. In thinking a bit more about this, a common case would be where both are using the same PID. Typically, the user would have switched over from the built-in pause to the stand-alone pause without altering the standard PIDs. The protocol upgrade code would be different, of course. So, the standard RDF might have to look like this:How are we going to let IR know which one to use in a case like this? (It does matter because the timing values are different.)

Mike, I don't understand how a remote can have two Pause protocols with the same PID. I presume "built-in pause" means one built into an extender, so its protocol will be in the upgrade area, as will the protocol for the stand-alone pause. If both have the same PID then surely the remote will always find whichever one occurs first in the upgrade area. If, on the other hand, the protocol for the built-in pause was deleted before the stand-alone pause was installed, then the remote only has one pause protocol and needs only one entry in the RDF. Can you explain in more detail, please?

mathdon wrote:If, on the other hand, the protocol for the built-in pause was deleted before the stand-alone pause was installed, then the remote only has one pause protocol and needs only one entry in the RDF. Can you explain in more detail, please?

Yes, that would be the case. Only one protocol upgrade would be present at any given time. They both use the same PID. However, how do you know which one is present so you can determine the correct timing calculations?

I created two test IR files here. Both use the pause protocol, but one is the extender's version and the other is the stand-alone version.

Maybe you can use some sort of fixed data thing, something like this...
In my fictitious example, the first number in the brackets is the start position and the second is the length (not including spaces).

I think I've cracked the "two pause protocols in the RDF" issue, though it needs a bit more testing. Similar to but a bit simpler than Rob's suggestion, I've introduced a concept of an Extended PID (XPID). This is four bytes long. The third byte is an index into the bytes of the protocol code and the fourth byte is the value of the byte so indexed. Two protocols with the same (ordinary) PID must differ in at least one byte, so this will always be sufficient to distinguish between them. If a special protocol gives an XPID instead of a PID, and the indexed byte does not match the indexed value, then it is treated as if the device for that PID is missing. Tha protocol can't appear in the special protocols grid, and in the macro-type dropdown box it is greyed out.

Each Pause protocol gets an entry in the [General] section that gives the data format and duration multiplier. In my example for testing I have The General entry consists of
a) User name for the Pause protocol
b) One of 1, 2H, 2L, 2. Here 1 means one data byte, 2H means two data bytes but a one-byte pause value in the high byte, 2L means the same but the low byte, and 2 means a genuine 2-byte pause value.
c) A multiplier (decimal points allowed) to convert seconds to the pause data value.

I intend to have defaults for b) and c) - in which case of course the whole entry can be omitted - but haven't set them up yet. The defaults will probably need to be processor-specific. If you are happy with the above scheme, I would welcome suggestions as to what the default values should be. My first thought is to take the multiplier from the stand-alone RM pause protocol but I don't know what processors use one data byte (option 1) and what use option 2H. Does anything use 2L? I think my own extender is probably the only one to use option 2. There is probably not enough common ground for the HCS08 remotes (of which mine is one) to have useful default values.

mathdon wrote:I think I've cracked the "two pause protocols in the RDF" issue, though it needs a bit more testing.

Sounds good to me.

mathdon wrote:The defaults will probably need to be processor-specific. If you are happy with the above scheme, I would welcome suggestions as to what the default values should be. My first thought is to take the multiplier from the stand-alone RM pause protocol but I don't know what processors use one data byte (option 1) and what use option 2H. Does anything use 2L? I think my own extender is probably the only one to use option 2. There is probably not enough common ground for the HCS08 remotes (of which mine is one) to have useful default values.

Your extender pause is the only one I know of that uses two bytes. All the other pause protocols are modeled on the original stand-alone S3C8, meaning they are all designed to work with one data byte. The remotes that use two data bytes would all be 2H currently.

BTW, be careful with high-byte/low-byte terminology around here. The Mits P8/740 processor uses low-byte-first ordering, so it could be confusing.

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.)

The hard part will be to figure out the timebases for the various extenders. While processor type will certainly affect it, I don't think it will be the predominant factor.

re: https://www.hifi-remote.com/forums/viewtopic.php?t=10550

There are certain learns that IR doesn't know how to decode, and correcting that will be a separate exercise, but apparently IR is corrupting the learned data when it doesn't understand a learn. Would it be possible to trap this "out of bounds" error and instead of it being uncontrolled, have IR simply not decode the learned signal (maybe with a message or something).

I've taken Mike's point about low-byte-first processors and changed the second Pause parameter to use 1, 2/1, 2/2 and 2, 2/1 meaning two bytes passed, only first byte used (2 on its own means 2-byte data.)

A few days ago, Mike wrote:

This is really not an issue specific to the Pause protocol, though it certainly affects it. This is a keymove format variation used in the newer remotes. Keymoves used to accept any valid number of hex bytes, but UEI made a change such that keymoves may now contain only one or two bytes.

If I understand this correctly, it means that there is never any problem if the Pause protocol passes two data bytes. Since nothing seems to use format 2/2 and it is only my extender that uses format 2, I will use a default format of 2/1 that should cope with almost everything.

As to the timing multiplier, it seems from what has been said that it doesn't correlate well with processor type. IR recognises the following processor types:

S3C80, 740, 6805, HCS08, SST and S3F80

and the S3C80 seems to have variants that have different timings from one another. The only real need for a default is for current RDFs that do not know about the PauseParams RDF key. Any RDFs that are updated can obviously put in the correct parameters for both any pause protocol internal to an extender, and those for the stand-alone pause. It wouldn't be appropriate to make defaults in IR be specific to particular remotes as it is the job of the RDF to provide remote-specific data. I can't see any other existing RDF parameter that the timing multiplier could correlate with, so I suggest using a default of 16 (from Mike's messages) except for JP1.3 remotes (which I believe are those with S3F80 processor), where I understand Bill has written the pause protocol with a multiplier of 10.

If Vicky has any suggestions for a different HCS08 default, I would be happy to have them.

Have I got this right, and will it do? Any alternative (but specific) suggestions are welcome.

Identifying the processor type from the RDF is not as straightforward as it might have been, but this is a result of the evolutionary nature of the JP1 tools.

Here is a list of processors, and the RDF entries that identify them. (The names used here are the ones we most commonly use when referring to the various processor types.)

• 1) S3C8 - JP1, older variant, executes slower than newer versions, RAM located at $8000
  Processor=S3C80
  RAMAddr=$8000
  
  2) S3C8+ - JP1, newer variant, RAM located at $FF00
  Processor=S3C80
  RAMAddr=$FF00
  
  3) S3F8 - JP1.3, flash version of S3C8+
  Processor=S3F80
  RAMAddr=$FF00
  
  4) HCS08 - JP1.2, flash based HCS08
  Processor=HCS08
  
  5) 6805RC16/18 - JP1, mask ROM HC05 with hardware IR generation
  Processor=6805
  ProcessorVersion=RC16/18
  
  6) 6805C9 - JP1, mask ROM HC05 (similar to C9 but more ROM), software IR generation
  Processor=6805
  ProcessorVersion=C9
  
  7) SST - JP1.1, flash based chip made by SST with HC05 instruction set, similar to 6805RC16/18
  Processor=SST
  
  8) P8/740 - JP1, Mitsubishi (now Renasas) processor, software IR generation
  Processor=740

With regard to defaults for the Pause timings, I think the only thing that makes sense is to use the stand-alone timings. That way all of them are the same except for #1 (S3C8), which would use the 10.66 multiplier as a default. It also puts the responsibility for determining the correct timing for an extender Pause protocol on the extender author.

mathdon wrote:If I understand this correctly, it means that there is never any problem if the Pause protocol passes two data bytes. Since nothing seems to use format 2/2 and it is only my extender that uses format 2, I will use a default format of 2/1 that should cope with almost everything.

I agree. It still leaves flexibility for future extender writers.

mathdon wrote:I can't see any other existing RDF parameter that the timing multiplier could correlate with, so I suggest using a default of 16 (from Mike's messages) except for JP1.3 remotes (which I believe are those with S3F80 processor), where I understand Bill has written the pause protocol with a multiplier of 10.

I would not make an exception for the JP1.3 remotes. Bill's pause protocol is part of an extender. The stand-alone pause generated by RM or KM can still be used with the S3F8 processors (extended or not) since the timing is identical to the S3C8+.

mathdon wrote:If Vicky has any suggestions for a different HCS08 default, I would be happy to have them.

I'm not Vicky ( ), but again, I'd not make an exception for the HCS08. Use the 16 multiplier as the default like all the others.

How about having 16 be the default but have an RDF parameter that can override it. Then we would go back and fix all the old S3C8 RDFs.

Rob, that's why it is a default! In the General section you put something like

PauseParams=PauseB, 2/1, 10.66

and then the Pause protocol that has been given (or more likely, in the standard ordering, will be given - it doesn't matter which way round) the user name PauseB in the Special Protocols section will be taken as requiring two data bytes, only the first being significant, with that data byte being 10.66 times the pause in seconds. This will over-ride the default - and there can be two (or even more) such entries for different Pause protocols with the same protocol ID, each given a different user name, provided they are distingushed from one another by their 4-byte Extended PID. See my message of Jan 26, 4.28pm for more details.