Fujitsu 42" Plasma Display P42HHA30AS

[gfb107]

OK, so the Fujitsu executor is a combo (it supports any sub-device for any command), and the sub-device should be a command parameter, not a protocol parameter.

Code: Select all

FixedData=03 D7 39 FF FF
DevParms=Main Device:8=0
DeviceTranslator=Translator(lsb,comp,0,8,32)
DefaultCmd=00 00
CmdIndex=1
CmdParms=OBC=0,Sub dev={0}
CmdTranslator=Translator(lsb,comp,0,8,8) Translator(lsb,comp,1,8,0)

[gfb107]

The next question is whether or not we want to expose X as a protocol parameter. If we do it now we have the flexibilty to simply set it in a device upgrade without having to make changes to protocols.ini to enable that. OF course we can use a default value so that we don't require that users specify a value for it.

[vickyg2003]

OK, so the Fujitsu executor is a combo (it supports any sub-device for any command), and the sub-device should be a command parameter, not a protocol parameter.

Yes, that's what I was trying to say.

The next question is whether or not we want to expose X as a protocol parameter. If we do it now we have the flexibilty to simply set it in a device upgrade without having to make changes to protocols.ini to enable that. OF course we can use a default value so that we don't require that users specify a value for it.

I'm not sure DecodeIR will give the E parameter, X is always F.
If decodeIR doesn't identify it, will anybody know how to use it.

What I still want to know is how to get RM to recognize that there is a variant with a different different that needs different fixed data, so that if its there, we don't need to copy that whole big protocol in, instead of having the first fixed byte be 00 instead of 03.

[gfb107]

OK, the first thing to figure out is if the variant built into the 7800 is actually one of the 3 variants already defined in protocols.ini. My guess is that it is variant 1, but I don't know how to find out if that is indeed the case.

This is further complicated by the fact that the Fujitsu executor is also the Sharp DVD executor, and we must use the same variant names for both, so the correct variant of both can be identified with a single entry in the Protocols section of RDFs.

Assuming for the moment that it is variant 1, we need to

1. Update protocols.ini to remove the variantName=1 for consistency with SharpDVD and
2. Change the default FixedData for this variant so the first byte is 00

What I still want to know is how to get RM to recognize that there is a variant with a different different that needs different fixed data, so that if its there, we don't need to copy that whole big protocol in, instead of having the first fixed byte be 00 instead of 03.

[The Robman]

OK, the first thing to figure out is if the variant built into the 7800 is actually one of the 3 variants already defined in protocols.ini. My guess is that it is variant 1, but I don't know how to find out if that is indeed the case.

The URC-7800 has version 1 of the $00F8 executor.

[gfb107]

OK. Given that the 00F8 executor in the URC-7800 is already known as the "base" variant (all that means is it has no variantName) for Sharp DVD, we need to also use no variant name in the Fujitsu context. Based on Vicky's input we should change the default FixedData so the first byte is 0.

The revised protocols.ini entry is

Code: Select all

#This is version 1, same protocol binary as [Sharp DVD] 00 F8
#No variantName is used, to match [Sharp DVD]
#(It does not replace Sharp DVD)
#It selects 2 lead-out-off times based on bit 0 of 1st device byte
#KM does not allow this version of Fujitsu as an upgrade.
#(It will allow Sharp DVD as an upgrade.)
#Example: RCU810

[Fujitsu]
PID=00 F8
FixedData=00 D7 39 FF FF
DevParms=Main Device:8=0
DeviceTranslator=Translator(lsb,comp,0,8,32)
CmdIndex=1
DefaultCmd=00 00
CmdParms=OBC=0,Sub dev={0}
CmdTranslator=Translator(lsb,comp,0,8,8) Translator(lsb,comp,1,8,0)
ImportCmdTranslator=Translator(lsb,comp,0,8,0)
#Code.S3C80=43 8B 52 8B 14 8F 45 08 08 00 CB 00 C4 00 CB 02 \
#           6A 27 70 06 8F 03 3D 40 F8 20 01 76 03 01 6B 09 \
#           E4 22 1C E4 23 1D 56 28 F7 8D 01 46
#Code.740=0B 1A 52 80 10 E1 72 10 08 08 01 7F 02 94 19 10 \
#         80 03 2B 00 08 07 5D 06 E6 5B E6 69 80 0A E6 5B \
#         A9 5F 85 71 A9 68 85 72 4C 00 FF

[gfb107]

Vicky,

Have you had a chance to try this?

[vickyg2003]

No I hadn't tried it, but I'll do that today.

Question though, there is a

Does this replace the stuff that is in there for fujitsu where it currently says
VariantName=1

I know that the RDF's say 00f8, 00f8:2 and 00f8:3, so since there is no colon in the 7800 00F8 this would then be a "variant 1", but since the :1 isn't there the variantName should not have been there?

Its making more sense to me this morning.

[vickyg2003]

Very nice work Greg,

Tried the fujitsu on the 7800.

The upgrade worked as advertised. No upgrade required, signals sent decode properly.

If there is more that you want me to test, just say so.

Working through this has helped me with my understanding of protocols.ini.

[gfb107]

No I hadn't tried it, but I'll do that today.

Question though, there is a

Does this replace the stuff that is in there for fujitsu where it currently says
VariantName=1

Correct

I know that the RDF's say 00f8, 00f8:2 and 00f8:3, so since there is no colon in the 7800 00F8 this would then be a "variant 1", but since the :1 isn't there the variantName should not have been there?

Correct again.

[The Robman]

Did we come up with an upgrade file that digital_silence can test?

[vickyg2003]

There were plenty of fujitsu upgrades in the file area, that all used the same obc's, it was just that the fixed data was bad. They should all work now from RM, including the one that I uploaded.

Mike is aware of the change needed for KM, and I believe he was working on that for the 9.21

[The Robman]

digital_silence, can we close this one out? Did you get your upgrade to work?

[digital_silence]

digital_silence, can we close this one out? Did you get your upgrade to work?

Ummm... I must admit that I have not been following the detailed software discussion on this and on the previous page, so I am a bit unclear as to what exactly is the upgrade that I am expected to get to work.
At this moment, all I have been able to get going is a set of simulated learns from Pronto, as Vicky suggested on Page1.

Vicky, when you now say "They should all work now from RM, including the one that I uploaded", do you mean the one you uploaded in the third post of this entire thread on Pg1?
If it didn't work then, why should it now? Did you re-upload the file since?

So, if you could please clearly point me to the link to the upgrade (KM or RM) that I could try, I should be able to tell (after having tried it) whether we can close this thread out or not.

[vickyg2003]

Oh boy, I've gone through so many changes of RM versions since this post that I don't remember where RM Fixed this in protocol.

If when you choose Fujitsu off the menu, you only protocol parameter you see is Main Device, (no subdevice setting on the main page), then you've got a version of RM that correctly handles the Fujitsu protocol.

You should be able to open the Fujitsu TV upgrades in RM and they should work

The key is that the fixed data needs to be in the correct order, and it wasn't.

the screen should say

Main Device 132
Fixed Data 03 D7 39 FF DE