Fujitsu 42" Plasma Display P42HHA30AS

digital_silence · Post by **digital_silence** » Sat Jul 31, 2010 10:23 pm

vickyg2003,

The funny thing to me is that I am still following you! :-)

1) Which Pronto file did you use to generate hex data that you posted above? XHA10 or XHA40?

2) I've run decodeccf the way you suggested. Can you please highlight in colour only the timing part for me please in the following fragment of the text output:
(I mean, pls highlight the part that I need to do the Search'n'Replaces in, as you suggested, and then feed it to IRscope).

Fujitsu 132 139 64 165 VID 1 VID1 PLASMA-Basic TV-Basic 38.381 0 50 3334-1563 416-390 416-390 416-1224 416-390 416-1224 416-390 416-390 416-390 416-1224 416-1224 416-390 416-416 416-390 416-1224 416-1224 416-390 416-390 416-390 416-390 416-390 416-390 416-390 416-416 416-390 416-390 416-390 416-1224 416-390 416-390 416-390 416-390 416-1224 416-1224 416-1224 416-390 416-1224 416-390 416-390 416-416 416-1224 416-390 416-416 416-390 416-390 416-390 416-390 416-1224 416-390 416-51327
Fujitsu 132 139 65 169 VID 2 VID2 PLASMA-Basic TV-Basic 38.381 0 50 3334-1563 416-390 416-390 416-1224 416-390 416-1224 416-390 416-390 416-390 416-1224 416-1224 416-390 416-416 416-390 416-1224 416-1224 416-390 416-390 416-390 416-390 416-390 416-390 416-390 416-416 416-390 416-390 416-390 416-1224 416-390 416-390 416-390 416-390 416-1224 416-1224 416-1224 416-390 416-1224 416-390 416-390 416-416 416-1224 416-1224 416-390 416-390 416-390 416-390 416-390 416-1224 416-390 416-50519

We've got a wedding out east next Saturday...

Game over?... :-)))

Just kiddin', m8... Congrats and have a nice time!

Thanks.

Post by **vickyg2003** » Sun Aug 01, 2010 3:23 am

digital_silence wrote:vickyg2003,

The funny thing to me is that I am still following you!

Good, I was hoping that this would help somebody. The tools here are great, its just getting to know how to use them that is the difficult part.

1) Which Pronto file did you use to generate hex data that you posted above? XHA10 or XHA40?

I really don't remember. But they are pretty much the same.

2) I've run decodeccf the way you suggested. Can you please highlight in colour only the timing part for me please in the following fragment of the text output:
(I mean, pls highlight the part that I need to do the Search'n'Replaces in, as you suggested, and then feed it to IRscope).

I left out the part where I drop these in an excel spreadsheet so that I everything falls neatly into a column.

Fujitsu 132 139 64 165 VID 1 VID1 PLASMA-Basic TV-Basic 38.381 0 50 3334-1563 416-390 416-390 416-1224 416-390 416-1224 416-390 416-390 416-390 416-1224 416-1224 416-390 416-416 416-390 416-1224 416-1224 416-390 416-390 416-390 416-390 416-390 416-390 416-390 416-416 416-390 416-390 416-390 416-1224 416-390 416-390 416-390 416-390 416-1224 416-1224 416-1224 416-390 416-1224 416-390 416-390 416-416 416-1224 416-390 416-416 416-390 416-390 416-390 416-390 416-1224 416-390 416-51327

+3334 -1563 +416 -390 +416 -390 +416 -1224 +416 -390 +416 -1224 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -1224 +416 -390 +416 -416 +416 -390 +416 -1224 +416 -1224 +416 -390 +416 -390 +416 -390 +416 -390 +416 -390 +416 -390 +416 -390 +416 -416 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -390 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -1224 +416 -1224 +416 -390 +416 -1224 +416 -390 +416 -390 +416 -416 +416 -1224 +416 -390 +416 -416 +416 -390 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -390 +416 -51327

Fujitsu 132 139 65 169 VID 2 VID2 PLASMA-Basic TV-Basic 38.381 0 50 3334-1563 416-390 416-390 416-1224 416-390 416-1224 416-390 416-390 416-390 416-1224 416-1224 416-390 416-416 416-390 416-1224 416-1224 416-390 416-390 416-390 416-390 416-390 416-390 416-390 416-416 416-390 416-390 416-390 416-1224 416-390 416-390 416-390 416-390 416-1224 416-1224 416-1224 416-390 416-1224 416-390 416-390 416-416 416-1224 416-1224 416-390 416-390 416-390 416-390 416-390 416-1224 416-390 416-50519

+3334 -1563 +416 -390 +416 -390 +416 -1224 +416 -390 +416 -1224 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -1224 +416 -390 +416 -416 +416 -390 +416 -1224 +416 -1224 +416 -390 +416 -390 +416 -390 +416 -390 +416 -390 +416 -390 +416 -390 +416 -416 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -390 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -1224 +416 -1224 +416 -390 +416 -1224 +416 -390 +416 -390 +416 -416 +416 -1224 +416 -1224 +416 -390 +416 -390 +416 -390 +416 -390 +416 -390 +416 -1224 +416 -390 +416 -50519

I can see I forgot to mention that you need to get rid of the final + and add a + to the beginning after you do your search and replaces. I highlighted the + you need to add in Red.

If you drop these into IRScope as a timing list, with a frequency of 38318 you can then export to uei or pronto hex. I chose pronto hex, because my frequency was creaping up,. I could adjust the frequency quite easily back to where I wanted to with pronto. I don't understand UEI learns, but pronto hex has been thoroughly dissected in the forum.

I'm hoping that you are doing this as an exercise to see how to use the tools. You did see that I figured out how to generate this stuff from the RDMU, by either editing the upgrade that you paste in, or editing protocols.ini didn't you?

digital_silence · Post by **digital_silence** » Sun Aug 01, 2010 4:07 am

Thanks for this.

I have pretty much figured all this out (including adding leading + and getting rid of trailing +), just wasn't sure whether I should include the first block (3334-1563) in the timing data, as it looks quite different from the rest. Now I can see from your highlight that it IS a part of the timing data. I am guessing that it must be a header for receiver synchronisation, just like a long 0101010101... sync header in the beginning of each magnetic stripe Manchester data.

And yes, the tools here are great, especially when accompanied by step-by-step user guides from vickyg2003's posts... :-)))

gfb107 · Post by **gfb107** » Sun Aug 01, 2010 8:19 am

There's definitely a problem with the protocols.ini entries for Fujitsu, but this doesn't look quite right to me.

There are two device parameters but only one device translator. So only the Main device is being encoded in the fixed data. We need add an entry for the Default Sub Device as well. Based on what I see in the KM file you posted, I think the Main Device should stay at bit 24, and the Default Subdevice should be at bit 32.

Code: Select all

DeviceTranslator=Translator(lsb,comp,0,8,24) Translator(lsb,comp,1,8,32)
CmdIndex=1

But I do not understand (or care to understand) the details of IR protocols and executors. I just understand how to get RM to generate fixed data and cmd hex to accomplish what you protocol/executor experts tell me is needed.

vickyg2003 wrote:The fixed data out of RM is in the wrong order. If you change FF and DE are reversed. If you switch them into this order when you paste it into IR, it will send the signals we are looking for.

03 D7 39 FF DE

Protocols.INI needs to be fixed
The DeviceTranslator is pointing at the wrong byte. It says 24 but it should say 32. The EFC's are translating the wrong byte so we need a CmdIndex line added to the [Fujitsu] section.

DeviceTranslator=Translator(lsb,comp,0,8,32)
CmdIndex=1

Can you see how I get when I want to figure something out. I can't just let go!

Post by **The Robman** » Sun Aug 01, 2010 8:35 am

I've only been skimming these messages, so correct me if I'm wrong, but is the main point of this exercise to get the signals in pronto hex form so that you can drop them into IR.exe as learned signals?

If so, you shouldn't be using DecodeCCF and IRScope, you should be using CCF2EFC (which is the predecessor to DecodeCCF). The main drawback with DecodeCCF is that it doesn't give you the full pronto hex whereas CCF2EFC does. The main drawback with CCF2EFC is that it doesn't work with some of the newer CCF files (as the format changed).

If you use CCF2EFC you will have to raw original pronto hex, which you can then drop directly into IR.exe.

cauer29 · Post by **cauer29** » Sun Aug 01, 2010 10:27 am

The Robman wrote:I've only been skimming these messages, so correct me if I'm wrong, but is the main point of this exercise to get the signals in pronto hex form so that you can drop them into IR.exe as learned signals?

If so, you shouldn't be using DecodeCCF and IRScope, you should be using CCF2EFC (which is the predecessor to DecodeCCF). The main drawback with DecodeCCF is that it doesn't give you the full pronto hex whereas CCF2EFC does. The main drawback with CCF2EFC is that it doesn't work with some of the newer CCF files (as the format changed).

If you use CCF2EFC you will have to raw original pronto hex, which you can then drop directly into IR.exe.

I could be wrong, but I've been following along with this thread and my understanding is the OP is trying to create an upgrade for his JP1 remote that will control this Fujitsu TV that he has. Using learned signals instead of a proper protocol, is a stopgap measure to deal with the fact that the current KM and RM tools do not properly handle the Fujitsu protocol. Vicky pointed out that there was a reversal of two bytes in the fixed data that was being generated and manually correcting that, appears to fix some of the problems, but not all of them.

A.A.

Post by **vickyg2003** » Mon Aug 09, 2010 11:29 am

gfb107 wrote:There's definitely a problem with the protocols.ini entries for Fujitsu, but this doesn't look quite right to me.

There are two device parameters but only one device translator. So only the Main device is being encoded in the fixed data. We need add an entry for the Default Sub Device as well. Based on what I see in the KM file you posted, I think the Main Device should stay at bit 24, and the Default Subdevice should be at bit 32.
Code: Select all
DeviceTranslator=Translator(lsb,comp,0,8,24) Translator(lsb,comp,1,8,32)
CmdIndex=1
But I do not understand (or care to understand) the details of IR protocols and executors. I just understand how to get RM to generate fixed data and cmd hex to accomplish what you protocol/executor experts tell me is needed.

No, we want to leave bits 24-31 alone, as you already defined them as FF in the fixed data. That leaves the e:4 x:4 variables blank as 00000000. I am not quite sure what e and x were. I think at one time the decodeIR.html had a different organization where the e and x were discussed in a family format, but now that its alphabetical that is getting lost on me.

DeviceTranslator=Translator(lsb,comp,1,8,32)

The_Robman wrote:I've only been skimming these messages, so correct me if I'm wrong, but is the main point of this exercise to get the signals in pronto hex form so that you can drop them into IR.exe as learned signals?

If so, you shouldn't be using DecodeCCF and IRScope, you should be using CCF2EFC (which is the predecessor to DecodeCCF). The main drawback with DecodeCCF is that it doesn't give you the full pronto hex whereas CCF2EFC does. The main drawback with CCF2EFC is that it doesn't work with some of the newer CCF files (as the format changed).

Is CCF2EFC going to give you the pronto hex if the signal already decodes?

Post by **The Robman** » Mon Aug 09, 2010 1:01 pm

vickyg2003 wrote:Is CCF2EFC going to give you the pronto hex if the signal already decodes?

Yes, it will *always* give you the full Pronto hex, regardless of whether a signal decodes. But it can't handle the more recent CCF files as they use a different format. Unfortunately, John has "retired" this program, so he won't make any more changes to it in order to get it to open the newer CCF files. Therefore, if the CCF that you're using won't open using CCF2EFC you will have to use the more long-winded approach that you laid out earlier.

Post by **vickyg2003** » Mon Aug 09, 2010 4:19 pm

The Robman wrote:
vickyg2003 wrote:Is CCF2EFC going to give you the pronto hex if the signal already decodes?
Yes, it will *always* give you the full Pronto hex, regardless of whether a signal decodes. But it can't handle the more recent CCF files as they use a different format. Unfortunately, John has "retired" this program, so he won't make any more changes to it in order to get it to open the newer CCF files. Therefore, if the CCF that you're using won't open using CCF2EFC you will have to use the more long-winded approach that you laid out earlier.

I don't know which are the newer and which are the older CCF files. Do we have a list of the protos that it will work with?

Count of upgrades at Remote Central, by remote type.

_691 Philips ProntoPro
3958 Philips TS-1000
1150 Philips TSU2000
217 Marantz RC5000
341 Marantz RC5000i
117 Marantz RC5200
_130 Marantz RC9200

Post by **The Robman** » Mon Aug 09, 2010 4:57 pm

I don't have a list, if you try running the file against CCF2EFC and you get a file with 1 error message in it, you've found one of them.

DecodeCCF can handle all CCFs, so if someone were to read the source code for both programs, they might be able to modify CCF2EFC so that it can handle the new ones too.

Post by **vickyg2003** » Mon Aug 09, 2010 5:22 pm

Well I went to download CCF2EFC to see what kinds of CCF files it won't open, but neither a File Search nor a look in Main nor Programs turned it up.

Post by **The Robman** » Mon Aug 09, 2010 5:40 pm

I didn't realize that we didn't have a copy of it here. Here are some links...

Remote Central - an old version (2000)
Old Yahoo JP1 group - updated version (2003)
Old Yahoo JP1-KM group - source code (2003)

Plus, I've added it here:
https://www.hifi-remote.com/forums/dload ... le_id=8766

and the source here:
https://www.hifi-remote.com/forums/dload ... le_id=8767

gfb107 · Post by **gfb107** » Fri Aug 20, 2010 9:09 am

I managed to borrow a PC that has Excel so I could look at what KM does.
It is definitely encoding the Main Device in bits 24-31, and the Sub Device in bits 32-39.

We need two DeviceTranslator entries, one for the Main Device and one for the Sub Device. Your single DeviceTranslator entry encodes the Sub Device in bits 32-39, but doesn't encode the Main Device in the fixed data at all. So we end up with only the default Main Device as coded in the FixedData entry in protocols.ini. The value if the Main Device entry field is not reflected in the generated Fixed Data (except when the default value is used).

vickyg2003 wrote:
gfb107 wrote:There's definitely a problem with the protocols.ini entries for Fujitsu, but this doesn't look quite right to me.

There are two device parameters but only one device translator. So only the Main device is being encoded in the fixed data. We need add an entry for the Default Sub Device as well. Based on what I see in the KM file you posted, I think the Main Device should stay at bit 24, and the Default Subdevice should be at bit 32.
Code: Select all
DeviceTranslator=Translator(lsb,comp,0,8,24) Translator(lsb,comp,1,8,32)
CmdIndex=1
No, we want to leave bits 24-31 alone, as you already defined them as FF in the fixed data. That leaves the e:4 x:4 variables blank as 00000000. I am not quite sure what e and x were. I think at one time the decodeIR.html had a different organization where the e and x were discussed in a family format, but now that its alphabetical that is getting lost on me.

DeviceTranslator=Translator(lsb,comp,1,8,32)

Post by **vickyg2003** » Fri Aug 20, 2010 11:22 am

gfb107 wrote:I managed to borrow a PC that has Excel so I could look at what KM does.
It is definitely encoding the Main Device in bits 24-31, and the Sub Device in bits 32-39.

And it is wrong too. I believe Mike told me he copied the Fujitsu from RM.

We need two DeviceTranslator entries, one for the Main Device and one for the Sub Device. Your single DeviceTranslator entry encodes the Sub Device in bits 32-39, but doesn't encode the Main Device in the fixed data at all. So we end up with only the default Main Device as coded in the FixedData entry in protocols.ini. The value if the Main Device entry field is not reflected in the generated Fixed Data (except when the default value is used).

Fujitsu
IRP notation: {37k,432}<1,-1,1,-3>(8,-4,20:8,99:8,X:4,E:4,D:8,S:8,F:8,1,-110)+
EFC translation: LSB comp
Fujitsu is the member of the Kaseikyo family with OEM_code1=20 and OEM_code2=99.

Bits 24-31 of the fixed data corresponds to two other parts of the signal x and e. The subdevice is encoded in the 2 byte function data.

I had pm'd John for help on this thread, but didn't get any response.

So I don't know if e and x are ever anything but 0 and 0 which the FF in bits 24-31 But I do know that if you start putting the device or subdevice in there decodeIR doesn't recognize them as Fujitsu signals and neither does the fujitsu TV!

I am way over my head here.

So we may indeed need something two DeviceTranslator entries, one for the Main Device and one for the XE byte. But it has nothing to do with the subdevice.

But I do not understand (or care to understand) the details of IR protocols and executors. I just understand how to get RM to generate fixed data and cmd hex to accomplish what you protocol/executor experts tell me is needed.

We definately need the help of an expert here. I'll pm John again.

Post by **vickyg2003** » Fri Aug 20, 2010 2:26 pm

All the upgrades that UEI has for Fujitsu devices that use this protocol have FF in bits 24-31.

Acording to John

Since this is a subset of Kaseikyo, X is set by the Kaseikyo standard.

If I'm doing the math right, 20,99 in hex is 14, 63 so
X = 1 ^ 4 ^ 6 ^ 3 = 0

So that 0 is not a variable part of the info, it is a fixed part of the structure of the signal.

so bits 24-27 are ALWAYS going to be F

If we saw a wider range in the kind of Fujitsu device we might see variation in bytes 28-31

This has no relationship to the subdevice.

I'd like to get a handle on how to work with Protocols.ini, but at this time its a little beyond my grasp.

I'd like to know how to fix this for the other version of the executor that is in my 7800 so that I wouldn't have to load the protocol upgrade. That version has different fixed data, but I haven't been able understand the whole variant aspect of protocols.ini. That version uses 00 in byte 1, instead of the 03 like the version that RM wants me to paste in. Other than that, the fixed data would be the same.

I'm finally comfortable using RM, and I like it very much, but dipping into protocols.ini is beyond my grasp.