Page 3 of 4
Posted: Fri Aug 20, 2010 3:12 pm
by 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)
Posted: Fri Aug 20, 2010 3:18 pm
by 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.
Posted: Fri Aug 20, 2010 6:13 pm
by vickyg2003
gfb107 wrote: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.
gfb107 wrote: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.
Posted: Mon Aug 23, 2010 7:17 am
by 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
- Update protocols.ini to remove the variantName=1 for consistency with SharpDVD and
- Change the default FixedData for this variant so the first byte is 00
vickyg2003 wrote: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.
Posted: Mon Aug 23, 2010 11:21 am
by The Robman
gfb107 wrote: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.
Posted: Mon Aug 23, 2010 11:42 am
by 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
Posted: Tue Aug 24, 2010 5:19 am
by gfb107
Vicky,
Have you had a chance to try this?
Posted: Tue Aug 24, 2010 5:31 am
by 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.
Posted: Tue Aug 24, 2010 6:07 am
by 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.
Posted: Tue Aug 24, 2010 6:10 am
by gfb107
vickyg2003 wrote: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.
Posted: Mon Sep 13, 2010 10:45 am
by The Robman
Did we come up with an upgrade file that digital_silence can test?
Posted: Mon Sep 13, 2010 11:00 am
by 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
Posted: Mon Sep 13, 2010 12:07 pm
by The Robman
digital_silence, can we close this one out? Did you get your upgrade to work?
Posted: Wed Sep 15, 2010 7:04 am
by digital_silence
The Robman wrote: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.
Posted: Wed Sep 15, 2010 7:46 am
by 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