 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
digital_silence
Joined: 22 May 2004
Posts: 257
|
 Posted: Sat Jul 31, 2010 11:23 pm Post subject: |
 |
|
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
| Quote: | | We've got a wedding out east next Saturday... |
Game over?... :-)))
Just kiddin', m8... Congrats and have a nice time!
Thanks. |
|
| Back to top |
|
 |
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Sun Aug 01, 2010 4:23 am Post subject: |
|
|
| 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.
| Quote: |
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.
| Quote: |
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.
| Quote: |
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
| Quote: |
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?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
digital_silence
Joined: 22 May 2004
Posts: 257
|
| Posted: Sun Aug 01, 2010 5:07 am Post subject: |
|
|
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... :-))) |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Sun Aug 01, 2010 9:19 am Post subject: |
|
|
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: |
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 | Quote: |
Can you see how I get when I want to figure something out. I can't just let go! |
|
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Sun Aug 01, 2010 9:35 am Post subject: |
|
|
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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Sun Aug 01, 2010 11:27 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Aug 09, 2010 12:29 pm Post subject: |
|
|
| 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: |
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?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Mon Aug 09, 2010 2:01 pm Post subject: |
|
|
| 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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Aug 09, 2010 5:19 pm Post subject: |
|
|
| 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
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Mon Aug 09, 2010 5:57 pm Post subject: |
|
|
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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Aug 09, 2010 6:22 pm Post subject: |
|
|
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.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Fri Aug 20, 2010 10:09 am Post subject: |
|
|
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: |
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) |
|
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Aug 20, 2010 12:22 pm Post subject: |
|
|
| 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.
| Quote: |
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.
| Quote: | 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.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Aug 20, 2010 3:26 pm Post subject: |
|
|
All the upgrades that UEI has for Fujitsu devices that use this protocol have FF in bits 24-31.
Acording to John
| Quote: | 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.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
