| View previous topic :: View next topic |
| Author |
Message |
gosu
Joined: 09 Oct 2007
Posts: 8
|
 Posted: Wed Oct 10, 2007 12:36 am Post subject: Can I derive JP1 codes from existing Hex Codes? |
 |
|
Dear All,
If I have the following information for my Satellite FTA set top box RCU:
-RCU Main Chipset
-Protocol
-Protocol ID
-Device #
-Subdevice #
-All IR Codes in Hex format
Can I derive the needed JP1
-EFC
-OBC
-Hex
?
I'm trying to avoid having to buy a learning JP1 remote since I am overseas. The resulting exported bin would be used for Slingbox. Any help would be appreciated.
***Edit to Add...
I did a little reading and found that if I can just get the OBC, RemoteMaster will calculate the EFC for me. So I guess the original question stands: Can I fill in the necessary data in the RemoteMaster functions tab based on the aforementioned data that I currently have from my RCU supplier? |
|
| Back to top |
|
 |
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Wed Oct 10, 2007 2:03 am Post subject: |
|
|
The answer is almost certainly yes, you will be able to use that data to build your upgrade.
If you could show us the actual data, somebody here will be able to give you guidance as to how to use it.
Also, please tell us Manufacturer/Model of your device.
thanks |
|
| Back to top |
|
|
gosu
Joined: 09 Oct 2007
Posts: 8
|
| Posted: Fri Oct 12, 2007 1:43 am Post subject: |
|
|
Thanks for the offer of assistance mate,
There is no Model number yet since the product is still in development. NDA prevents me from disclosing the name of the Manufacturer. My apologies.
I don't have the rcu ir codes yet but i have one for an older model. Can you teach me how to fill in the data properly so I can try to do it myself?
POWER 10
SLEEP 02
INFO 05
MENU 1C
TXT 1A
ARROW_UP 1E
ARROW_LEFT 0F
OK 1F
ARROW_RIGHT 0E
ARROW_DOWN 0D
1 11
2 12
3 13
etc...
I guess what I'm wondering is if I just have to fill in the hex IR column with the data presented in the above example.
Cheers~ |
|
| Back to top |
|
|
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Fri Oct 12, 2007 2:38 am Post subject: |
|
|
| gosu wrote: |
I guess what I'm wondering is if I just have to fill in the hex IR column with the data presented in the above example. |
You use RM (RemoteMaster) to build the upgrade, and export the binary, as per the details in the:
"sticky" post at the top of the Slingbox forum.
You'll need the Protocol, Device Number, (SubDevice Number if any)
If you use the Functions tab in RM, you can key the Hex values into the Hex column, and it'll fill in OBC and EFC values for you. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Fri Oct 12, 2007 8:03 am Post subject: |
|
|
| gosu wrote: | | I guess what I'm wondering is if I just have to fill in the hex IR column with the data presented in the above example. |
Maybe, but probably not. It depends on the protocol, and on the standards the manufacturer uses to document codes in hex.
In most cases, you would need to convert the manufacturer hex code from hex to decimal, then use that as an OBC number. JP1 hex is usually not the same thing as the hex value of the OBC.
In other cases you might need to subtract the manufacturer hex from FF hex and use that as the JP1 hex.
There are other possibilities as well.
If you can tell us the protocol, we can probably make a better guess at how to use the info.
Also, it is surprising the manufacturer would be able to give you device # and Subdevice #. That terminology isn't used much outside JP1. Typically those values have other names, such as "Custom Code", or "System" or "Address", or "Unit". Typically manufacturers don't tell you that info at all and if they do it is in a form that needs some translation before use in JP1. |
|
| Back to top |
|
|
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Fri Oct 12, 2007 9:13 am Post subject: |
|
|
| johnsfine wrote: | | JP1 hex is usually not the same thing as the hex value of the OBC. |
After I made my post above I actually wondered about the hex/obc relationship, and I was just about to come back and post some vague waffle warning you that what I had said might not work, because I wasn't really clear, on reflection, what the "hex" values you had were.
I am pleased to see that John has jumped in and explained the situation far more clearly and eloquently than I could - because in the process he's helped me to see where my confusion was too...
 |
|
| Back to top |
|
|
gosu
Joined: 09 Oct 2007
Posts: 8
|
| Posted: Fri Oct 12, 2007 11:04 pm Post subject: |
|
|
Thanks for the clarification John.
You're correct. My RCU supplier will be providing me the custom code. I will post the complete data once I receive it. |
|
| Back to top |
|
|
gosu
Joined: 09 Oct 2007
Posts: 8
|
| Posted: Thu Oct 18, 2007 12:07 am Post subject: |
|
|
OK I received some more information from my RCU supplier:
Protocol: NEC (but I don't know exactly which one)
Custom Code: 01 40
Button:Hex
1:01
2:02
3:03
...
0:00
OK:15
UP/CHUP:11
DOWN/CHDN:14
LEFT/VOLDN:12
RIGHT/VOLUP:13
EPG:0E
INFO:1F
EXIT:41
I have more codes, but I don't think it will be necessary to post them all.
I guess the question that remains is what to do with the custom code? Is it only a coincidence that the "NEC Combo" Protocol ID is also "01 40" (same as my custom code)?
Am I dead in the water until I can get the exact Protocol ID from the supplier?
Thanks in advance. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Thu Oct 18, 2007 6:50 am Post subject: |
|
|
Are your Slingbox and the equipment ready to be tested together?
Probably the correct protocol is NEC1. Otherwise it is NEC2. You don't need a combo protocol.
Probably the Device number is 1 and the subdevice number 64 (those are from the custom code 01 40).
The function numbers they gave you should be converted from hex to decimal, then used as the OBC numbers in KM or RM.
That info is all you need to build the upgrade. Then test it. If it isn't correct, we can try some of the less likely interpretations of that info. |
|
| Back to top |
|
|
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Thu Oct 18, 2007 7:04 am Post subject: |
|
|
 Bugger
I typed out almost exactly that reply an hour ago, and I was going to post it, but I thought "no - I'm bound to be missing something here, so I'll let John answer" - because I've noticed John's had the habit of posting around this time.
I was mostly scared that 01 40 to 1:64 was too obvious and I'd mislead gosu.
I think I'll go off and cry, because I missed my opportunity to look clever...
 |
|
| Back to top |
|
|
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Thu Oct 18, 2007 7:09 am Post subject: |
|
|
| John - was the fact that the hex values were consecutive what made you certain they were actually decimal OBC values ? |
|
| Back to top |
|
|
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Thu Oct 18, 2007 7:13 am Post subject: |
|
|
And if gosu doesn't mind me using his thread for my own education:
(these are probably silly questions)
[1] Is the subdevice number bound to be important ?
[2] Could it be a kind of LSB thing, so 64:1 ? |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Thu Oct 18, 2007 7:57 am Post subject: |
|
|
| jimdunn wrote: | | John - was the fact that the hex values were consecutive what made you certain they were actually decimal OBC values ? |
Notice I said they must be converted from hex to decimal and then they are OBC number.
The fact that the digit values were consecutive certainly helped my confidence that this answer was correct. But it was the likely answer regardless. The most common way any manufacturer documents function code numbers is OBC numbers in hex.
| jimdunn wrote: | | Is the subdevice number bound to be important ? |
I almost wonder if I'm misunderstanding your question, because I assume you know. You need to get the subdevice number correct or the upgrade won't work.
| jimdunn wrote: | | Could it be a kind of LSB thing, so 64:1 ? |
There is some chance of that. At least once I saw a manufacturer specify a custom code that way (misunderstanding the conventions for representing NEC custom codes). But it isn't likely.
The common misunderstanding would be bits within each byte, so 01 40 would mean device 128, subdevice 2. But if they did that for custom code, they probably would do the same for function code (so 01 would mean OBC 128 and 02 would mean OBC 64), but that error is uncommon anyway and even less common when it scrambles the sequential OBC numbers that way. |
|
| Back to top |
|
|
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Thu Oct 18, 2007 8:24 am Post subject: |
|
|
| johnsfine wrote: |
Notice I said they must be converted from hex to decimal and then they are OBC number.
The fact that the digit values were consecutive certainly helped my confidence that this answer was correct. But it was the likely answer regardless. The most common way any manufacturer documents function code numbers is OBC numbers in hex. |
I did notice that you said that - I was just looking for confirmation of my basic logic - I'm still, although an accomplished programmer, frequently confused by some of the JP1 terminology, and when it strays slightly outside of standard, as this does, I look for expert guidance to support my hunches - thanks for confirming my basic supposition, and explaining its relevance in this case.
| jimdunn wrote: | | Is the subdevice number bound to be important ? |
| johnsfine wrote: |
I almost wonder if I'm misunderstanding your question, because I assume you know. You need to get the subdevice number correct or the upgrade won't work. |
On reflection, I'm not surprised you answered that way, because intuitively I do know that - but I've seen a few posts when browsing the forum which almost indicate you can get subdevice wrong and the upgrade will still work - or at least that's how I've read them.
If I'm wrong, please say "YOU ARE WRONG" - because that will just mean I was browsing instead of understanding when I thought that, and you will have, again, helped me understand all this.
| jimdunn wrote: | | Could it be a kind of LSB thing, so 64:1 ? |
| johnsfine wrote: |
There is some chance of that. At least once I saw a manufacturer specify a custom code that way (misunderstanding the conventions for representing NEC custom codes). But it isn't likely.
The common misunderstanding would be bits within each byte, so 01 40 would mean device 128, subdevice 2. But if they did that for custom code, they probably would do the same for function code (so 01 would mean OBC 128 and 02 would mean OBC 64), but that error is uncommon anyway and even less common when it scrambles the sequential OBC numbers that way. |
Thank you.
That's the kind of knowledge which I know you have which forced me to wait for your answer in this thread before blundering in with my own - I will try to absorb it.
I appreciate your time, John, and apologise again to gosu for "hijacking" his thread.
Jim |
|
| Back to top |
|
|
jimdunn
Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia
|
| Posted: Thu Oct 18, 2007 8:57 am Post subject: |
|
|
| jimdunn wrote: | | although an accomplished programmer |
I just re-read this thread and realised that I ought to point out that my programming accomplishments are mainly VB/VBA/Windows API, so I don't want to be considered as a "real" programmer by anyone in this environment...  |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
