Bug Report: DecodeIR.dll/KM/RM and SharpDVD vs. Kaseikyo

[Capn Trips]

Some time has passed, and I thought I would stir this Kaseikyo-SharpDVD pot again. From what little I can understand, there remain a few problems that need to be (at least temporarily) resolved.

Now there appear to be several versions of PID 00F8 out there, and in MOST JP1 remotes, there are two versions, a Kaseikyo 170.90 and/or a Kaseikyo 20.99 versions. This confusion aside, we KNOW that in a small group of remotes, the 170.90 version is resident as PID 0171. So:

(1) Kaseikyo 170.90 decodes can be properly coded (when building a device upgrade) using the SharpDVD protocol. A DecodeIR.dll update would be very helpful in correctly identifying these signals when learned. In the interim, a simple solution is to insert a Protocol Help in KM and RM pointing this out;

"Functions that decode as Kaseikyo-170.90, Dev 8, SubDev 48 can be built using either the Kaseikyo protocol (Dev=8, SubDev=48, OEM1=170, OEM2=90) or the SharpDVD protocol (using Dev=143, SubDev=48 ). Choose whichever one results in a smaller protocol upgrade (or none) for your remote"

(2) SOME remotes (8910/9910/HTPro in my personal experience, and according to devices.xls the Atlas 4 and REM400 B01 are the only others) have the SharpDVD (170.90 version) Protocol executor assigned PID 0171, whilst all other JP1 remotes use PID 00F8. KM and RM do not correctly distinguish these, such that a device upgrade for an 8910 using SharpDVD (Kaseikyo 170.90 version) protocol will INCORRECTLY "require" PID 00F8 vice calling on PID 0171.
(a) In KM this results in no protocol upgrade being called for, but ultimately results in the wrong PID being used;
(b) In RM, this incorrectly results in a protocol UPGRADE for 00F8 (thereby superceding the built-in 00F8
whereas IN REALITY, in BOTH KM and RM, the device upgrade should use PID 0171 and NOT require a protocol upgrade. KM and RM need to be corrected to select the right PID for this circumstance.

[Capn Trips]

Bump!

(Prompted by THIS exchange), excerpt quoted below:

RM support for the Sharp DVD and other related Kaseikyo-family protocols is incomplete/incorrect/immature (choose your euphemism). This is due to different executors being used in different remotes for the same protocol and RM not properly reflecting these.

Specifically (as I have raised several times in these fora, likely ad nauseam), for the 8910/9910/HTPro remotes, the built-in Sharp DVD executor appears to be 0171, YET, when I build the upgrade in RM, it uses executor 00F8 - REQUIRING A PROTOCOL UPGRADE! Since RM does not allow me to change the protocol to 0171 (without introducing a bunch of fields that are inscrutable to me), the workaround I have developed is to build the upgrade in RM and only copy the Device Upgrade into IR, leaving the Protocol upgrade behind.

I then EDIT the device upgrade in IR to call on executor 0171 vice 00F8. ....

..., let's just fix the bugs. I guess I haven't seen (or just don't remember) the discussions about the problems with Sharp DVD and other related Kaseikyo-family protocols.

[mr_d_p_gumby]

This situation is not quite as clear-cut as you have stated, Capn. Both the 8910/9910/HTPro and the Atlas 4 also contain variant 2 of the PID 00F8 executor (only the REM400B01 does not). Is KM wrong in attempting to use that variant in this circumstance? I took a quick look at the PID 0171 executor, and it most closely resembles variant 1 of PID 00F8 in that it changes the leadout off time based on bit 0 of the first fixed byte. I will have to look more closely when time permits to see if 0171 would really be needed for any remote other than the REM400B01.

[gfb107]

Maybe all we need to do is create an entry in protocols.ini for a variant of Sharp DVD that uses 00F8 variant 2

[Capn Trips]

This situation is not quite as clear-cut as you have stated, Capn. Both the 8910/9910/HTPro and the Atlas 4 also contain variant 2 of the PID 00F8 executor (only the REM400B01 does not). Is KM wrong in attempting to use that variant in this circumstance?

YES.

I quite agree that the situation is unclear, most particularly to me. Here are the facts to which I am privy from personal experience:

Fact 1:The Sharp DVD player's signals when learned, are decoded as Kaseikyo-170.90, Dev 8, SubDev 48;

Fact 2: If I build this upgrade for the 8910 in RM using the Kaseikyo protocol, it generates a protocol upgrade (Executor 01C9). This upgrade works fine;
Fact 2a: If I build this upgrade for the 8910 in KM using the Kaseikyo protocol, it generates a protocol upgrade (Executor 01C9). This upgrade works fine also;

Fact 3: If I build this upgrade for the 8910 in RM using the SharpDVD protocol, it generates a protocol upgrade (executor 00F8). This upgrade works.
Fact 3b: If I build this upgrade for the 8910 in KM using the SharpDVD protocol, it DOES NOT generate a protocol upgrade (yet calls on executor 00F8, just as in RM). This upgrade does NOT work;

Fact 4: If I take either of the above upgrades created in Facts 3/3a and MANUALLY CHANGE THE PROTOCOL CALLED FOR in IR from 00F8 to 0171, THEY WORK in the 8910 with NO PROTOCOL UPGRADE.

Now I'm ignorant regarding executors and leadout off times and all of that stuff, but I suggest that I'm on pretty solid ground in stating:

(1) Facts 3 and 3a are mutually incompatible. Both tools should generate the same output, regardless of how one defines protocol names and/or executors;
(2) If the 8910 has a version 00F8 that differs from the standard 00F8 and instead uses executor 0171 to generate the SharpDVD signal, then BOTH KM and RM should be updated to call on the correct executor;
(3) The preceding is dependent upon the DECODES of the LEARNS to be properly reflected as SharpDVD protocol, rather than Kaseikyo protocol, presumably calling for an update to DecodeIR.dll

I feel pretty confident that nobody can credibly dispute my statement (1) above.

However, I acknowledge that if different versions of the Kaseikyo and related SharpDVD executors 01C9, 00F8, and 0171 exist and produce different variations of these related signals in different remotes, my statements (2) and (3) above may NOT be quite as simple as I put them.

However, it seems to pass the common sense test that a Sharp DVD player OEM remote, which although possibly correctly decoded as Kaseikyo signals, should more properly decode as SharpDVD protocol, so that the user can use the protocl that requires a more compact upgrade - but that is contingent on KM and RM properly recognizing that the SharpDVD executor in the 8910 is NOT 00F8, but 0171.

I took a quick look at the PID 0171 executor, and it most closely resembles variant 1 of PID 00F8 in that it changes the leadout off time based on bit 0 of the first fixed byte. I will have to look more closely when time permits to see if 0171 would really be needed for any remote other than the REM400B01. ?

Considering that the 8910 family of remotes is rather widely used, and are not really "rare", I think it reasonable to ask that the tools be capable of producing the "most correct" result when this protocol is invoked by the tools.

[johnsfine]

1) I think Greg is correct.

Fact 1:The Sharp DVD player's signals when learned, are decoded as Kaseikyo-170.90, Dev 8, SubDev 48;

I think that is the best behavior for DecodeIR, although I do understand there are concerns.

Fact 2: If I build this upgrade for the 8910 in RM using the Kaseikyo protocol, it generates a protocol upgrade (Executor 01C9). This upgrade works fine;

If a Kaseikyo upgrade of this type can be built for the 8910 using a built-in PID instead (which seems likely from the other things you said) then there ought to be an entry in Protocols.ini to do so.

Fact 3: If I build this upgrade for the 8910 in RM using the SharpDVD protocol, it generates a protocol upgrade (executor 00F8). This upgrade works.

Again if a built-in PID could have been used, we should have Protocols.ini support so it would be used.

Fact 3b: If I build this upgrade for the 8910 in KM using the SharpDVD protocol, it DOES NOT generate a protocol upgrade (yet calls on executor 00F8, just as in RM). This upgrade does NOT work;

You may need to split this thread. I think we should first do any needed investigation on the RM side rather than duplicate effort. But once that is done, a KM bug should be discussed in a thread that is clearly about that KM bug.

Fact 4: If I take either of the above upgrades created in Facts 3/3a and MANUALLY CHANGE THE PROTOCOL CALLED FOR in IR from 00F8 to 0171, THEY WORK in the 8910 with NO PROTOCOL UPGRADE.

Someone, probably me, should investigate the bahavior of PID 0171 in the 8910 and add some protocols.ini entries for it with some guesses (RDF file edits if necessary) about which other remotes' PID 171 executors are compatible.

Now I'm ignorant regarding executors and leadout off times and all of that stuff, but I suggest that I'm on pretty solid ground in stating:

I think that lead off time issue needs investigation. Maybe the fixed data to 0171 lets you side step it. Maybe it generates the wrong signal, but close enough that YOUR device doesn't care. A test that says something works tells you less than you may think.

(3) The preceding is dependent upon the DECODES of the LEARNS to be properly reflected as SharpDVD protocol, rather than Kaseikyo protocol, presumably calling for an update to DecodeIR.dll

Why?

If 0171 is a better way to do SharpDVD it is probably also a better way to do generic Kaseikyo. I don't yet know a difference between SharpDVD and generic Kaseikyo.

[gfb107]

There is a 00F8 executor in the 8910/9910/HTPro, variant 2. However, it uses the fixed data (and/or variable data) differently than the "standard" variant of 00F8. It is likely that someone will figure out what the fixed data should be for 00F8:2, and then KM and RM could produce valid upgrades that use 00F8:2 and therefore wouldn't need a protocol upgrade.

It is also appears that executor 0171 in the 8910 is consistent with the "standard" 00F8 executor, and therefore RM and KM could be changed to use executor 0171 instead of 00F8:2. This would also produce device upgrades that don't require a protocol upgrade.

What isn't clear at this time, is which of these choices is the best one.
It'll probably come down to figuring out how many remotes have 00F8:2 but don't have 0171 as compared to how many remotes have 0171 but don't have 00F8:2.

[mr_d_p_gumby]

What isn't clear at this time, is which of these choices is the best one. It'll probably come down to figuring out how many remotes have 00F8:2 but don't have 0171 as compared to how many remotes have 0171 but don't have 00F8:2.

I agree. Only the three remotes the Capn mentioned have the 0171 executor. Later models have only the 00F8 variant 2 or variant 3, so if it could be made to work correctly with the 00F8 variants, it would have more general applicability.

It would be a gross oversimplification for me to say that the later variants of 00F8 are upward compatible with the first variant, mainly because there are multiple versions of each variant, each with slightly different timing tweaks. However, I'm sure it was UEI's intent that they be upward compatible, because only the 00F8 executor has survived and is present in the JP1.1 & JP1.2 remotes, and all of the S3C8 remotes that followed the 8910.

The 0171 executor has only one option, controlled by bit 0 of the first fixed byte. If it is 0, the leadout off time is 20056 uS and the 0-burst off time is 1246 uS. If the bit is 1, then the leadout off time is 72474 uS and the 0-burst off time is 1354 uS. All three known instances of the 0171 executor are identical.

Variant 1 of the 00F8 protocol also has only on option (in most versions) based on the same bit. The most common version changes only the leadout off time (0=20192 uS, 1=33264 uS), leaving the 0-burst off time fixed at 1276 uS.

Variant 2 has more options, using bits 1 & 0 of the first fixed byte. Four different leadout off times may be selected:
00 = 20192 uS
01 = 33264 uS
10 = 74960 uS
11 = 43596 uS
In addition, for the 10 case above, the carrier frequency is changed from 37.4 kHz to 34.3 kHz. The 0-burst off time remains fixed at 1246 uS.

Variant 3 is the version in current remotes. It also uses 4 leadout off times, but drops the carrier frequency change. However, for the 01 case, it only sends 1 command byte instead of 2.

The first person to make sense of all this probably has too much free time on their hands.

Considering that the 8910 family of remotes is rather widely used, and are not really "rare", I think it reasonable to ask that the tools be capable of producing the "most correct" result when this protocol is invoked by the tools.

That's my goal as well. I never implied the the remote was "rare"; it's just that there is more than one solution to this problem, and we need to discuss which path we are going to take.

[Capn Trips]

I see that most of this discussion is above my head (not surprisingly) and I am glad to see it happening. My point about updating DecodeIR.dll stems from the following:

(1) The signals in question decode as Kaseikyo
(2) IN ALL CIRCUMSTANCES (KM, or RM) building an upgrade using the Kaseikyo Protocol results in a call to Protocol executor 01C9, which is not resident in ANY remote (per devices.xls).
(3) In none of these processes (decoding, or referencing the Protocol Help whilst building the upgrade) is ANY reference made to the possibility that (perhaps it only applies to a particular set of Device/Subdevice/OEM1/OEM2/E parameters) the SharpDVD protocol might be a better fit, whether in its 00F8:1 guise or as 0171, so the average user would never even consider switching to another protocol executor
(4) Even after switching to the SharpDVD protocol (and presuming the 00F8:1/2 vs/ 0171 is properly sorted in protocols.ini and rdf's and in KM) THAT DECODED INFORMATION DOES NOT DIRECTLY TRANSLATE INTO USEFUL INFO to build the upgrade, which calls for a Device and subdevice only for SharpDVD (00F8), and calls for a LOT of different parameters if PID 0171 is selected.

THAT'S why I claim that DecodeIR.dll should be updated to recognize this protocol.

I understand what you are saying when you suggest that just because a signal works does not mean it's the "best" fit, but in this case, I believe the evidence is pretty compelling.

As I mentioned way back in May:

I understand your answers above and can wait patiently 8) but the info below might still be helpful in sorting out the mess



This excerpt from Devices.xls shows all of the currently identified preloaded device codes that use the SharpDVD protocol(s). I know (by setting and learning) that the DVD/0630 setup code decodes as Kaseikyo-170.90 Dev=8, Subdev=48. Hence all of my previous ramblings.

If I select SharpDVD in KM or RM, the only selections I can make are Dev1 and Dev2. All of the previous discussion in this thread sort of presumed that the 170.90 was somehow embedded in the "SharpDVD" protocol. Well here are examples of several OTHER OEM combinations (20.99 and 35.203) that seem to use THE SAME protocol (00F8 - (or 0171)).

The OEM remote for a my Sharp DVD player when learned, decodes as Kaseikyo 170.90 8:48

The 8910's built-in setup code DVD/0630 (which operates my Sharp DVD player just fine) when learned, decodes exactly the same. The devices.xls spreadsheet tells me that DVD/0630 is the SharpDVD 143:48. THAT is why I am saying that SharpDVD is a "better" protocol for this device than Kaseikyo. It corresponds to the correct device upgrade for that piece of equipment, yet an IR decode of Kaseikyo will never lead one to using it.

OK. I'm out of this discussion which continues at a level above my head, but it just seems wrong that an manually-built upgrade for a Sharp DVD player, that correctly responds to a setup code using the SharpDVD protocol, when built using the decode of learned signals, will never lead the average user to using that precise Sharp DVD protocol.

[mr_d_p_gumby]

OK, I've looked into the DVD/0630 setup code a little more. Here's a sample of that setup code in a few remotes.

Code: Select all

Remote       Fixed data         PID
URC-9910     00 AA A5 0E F3     0171
RCU-810      00 AA A5 0E F3     00F8:1
15-2107      00 AA A5 0E F3     00F8:2
URC-9960B01  00 AA A5 0E F3     00F8:3
URC-7780     00 AA A5 0E F3     00F8:3

[johnsfine]

(1) The signals in question decode as Kaseikyo

Which I still think is correct.

(2) IN ALL CIRCUMSTANCES (KM, or RM) building an upgrade using the Kaseikyo Protocol results in a call to Protocol executor 01C9, which is not resident in ANY remote (per devices.xls).

Which we should change.

I understand what you are saying when you suggest that just because a signal works does not mean it's the "best" fit, but in this case, I believe the evidence is pretty compelling.

I meant that regarding PIDs and variants, not regarding protocols.

SharpDVD is just a name we gave to Kaseikyo-170.90. There aren't two different kinds of signal. Any PID:variant that can generate SharpDVD can by definition also generate Kaseikyo-170.90, because they are the same thing.

One could write a PID:variant that could generate Kaseikyo-170.90 but couldn't generate generic Kaseikyo correctly with some other OEM numbers. But I assume no one has done so.

All of the previous discussion in this thread sort of presumed that the 170.90 was somehow embedded in the "SharpDVD" protocol.

The 170.90 is embedded in the rules KM or RM use to create the fixed data when the user selects "SharpDVD". The executor (PID:variant) does not have 170.90 embedded.

The 8910's built-in setup code DVD/0630 (which operates my Sharp DVD player just fine) when learned, decodes exactly the same. The devices.xls spreadsheet tells me that DVD/0630 is the SharpDVD 143:48.

I'd prefer to phase out "SharpDVD". Sharp documents their signals in various PDF files. Comparing those to the way we decode IR signals, it isn't too hard to see the relationship between what they document and the device code 8.48 and the rest of the Kaseikyo decode. It is very hard to see (though I understand it) where the number 143 comes from in all that.

[gfb107]

In order to phase out Sharp DVD, we need an executor that can generate any Kaseikyo signal. Does any remote have a builtin executor that can do this? I assumed someone wrote the custom 01C9 executor because there wasn't one.

[gfb107]

Or are we just talking about renaming Sharp DVD to "Kaseikyo-170.90" (with appropriate changes to the protocol parms (and their translation to fixed data) to use the different device and sub-device values).

[The Robman]

When we first saw the "Sharp DVD" signals, we didn't know anything about Kaseikyo, we just knew that the signal was a variation of the Panasonic signal (which is also a Kaseikyo variant).

IIRC, the reason we couldn't use the Panasonic exec for the Sharp DVD was that the rules for generating the last byte of the signal were different. Even though the 00F8 exec uses 2 variable bytes, KM would generate the 2nd byte for the user when Sharp DVD was selected based in the formula that Sharp used for their DVD player.

So, when you're comparing the different executors that generate Kaseikyo signals, you also need to keep in mind the devices that use these executors as they may use different formulas for the check byte, and if they do then seperate KM/RM entries might be needed so that the user doesn't have to handle the checkbyte themselves. The next question would be whether there is enough info in a single sample of a signal to tell which formula is being used for the check byte, as this is what DecodeIR would have to use to identify these offshoot protocols.

(note: this is all from memory, I haven't looked anything up, so I'm not necessarily remembering everything correctly).

[gfb107]

We've had quite a bit of discussion about this issue, but I don't think we ever resolved it. Is anyone still investigating this?