need help with protocol mods for URC-8811

[Joe Kane]

First off, as someone with a fair amount of IR experience, I have to say 'hats off' for the tools produced in conjunction with this forum.

In the early 90s, my then employer was working with an upstart company that was building a database of IR code, a language to describe the protocols , and developing a line of 'universal' remotes that were programmable via proprietary software, a 3 pin interface (not yet 6) in the battery compartment. From my knowledge of those days and the protocols and descriptive language, I'd day you've really accomplished a great deal with the JP1 interface.

After that time I have spent far more time in Pronto IR code space. I have an ADI (Ocelot) IR setup at home, a large database of Pronto based codes, and both homegrown and acquired tools. The system works more on a keycode storage system, as opposed to the protocol algorithm that UEIC uses. Accordingly, I'm more versed in Remote Central and Makehex.

I was aware of the JP1 site for what it is, but since I don't primarily use UEIC remotes these days, I never spent a whole lot of time exploring the site.

I do have a UEIC-centric need now, and after spending lots of time exploring the various tools offered here (RM, IR, PB, IRSCOPE), I can see definite uses for your toolsets, especially since you have added Pronto based import and export. I have worked on many flavors of tools in the past, but since I tend to work on/process new IR code in spurts, I never really polished anything to the level you have here.

The tools themselves provide various pieces of functionality that I could include in my current IR work-flow. If I could find a way to script them for my particular work-flow it would be more beneficial to me, but I digress.

So prelude aside, here is what I'm trying to do:

I have a small population of URC8811B00 (Signature 6_806_60) remotes that I'd like to reprogram for a custom purpose. Long story short, I need to make some small custom alterations to a known protocol (GI Cable), and program a set of remotes for a proof of concept.

I know the protocol well, and I know its also well described in IRP form. Before I modified the protocol, my first step is to attempt to recreate it using the various tools here, and load the protocol upgrade into a new device. Once I was convinced that I can do this reliably and can control the target device, I'd work on making the custom modifications.

Rather than re-capture codes for a protocol that was well known, I was trying to get cleanly from IRP format to a protocol upgrade that would load on the 8811 remotes. So far this has proved to be a little challenging.

Knowing that UEIC puts their 'well known' protocols in ROM (at least in the past), I don't think there is any clean way to read out the stored ROMed database/protocol definition of GI for this particular remote. I have searched through the forums and upgrades, and couldn't find an explicit protocol upgrade for GI cable that works on the 8811. Yes there are device upgrades, but I didn't find a combo that was appropriate for my case.

I have now played with PB, IR, and RM quite a bit, and even tried to copy the protocol.ini definition for GI cable into the 'decode' section' of PB (after added the appropriate 'protocol upgrade =' etc While I'm pretty familiar with this protocol, I'm not entirely sure how to completely describe it in the PB builder fields, particularly it's unique checksum. What I also noticed is that the protocol upgrade definition produced in PB is several bytes smaller than the definition in the ini file, and smaller than what I paste into the 'decode'.

As far as I can tell, the URC8811B00 remotes are using Sc38+ processors. I also note that in the protocol.ini definition only includes references to SC38. I know that the protocol upgrade definitions differ between the two, but haven't yet found the decoder ring to translate. Perhaps the translation to SC38+ is handled in s/w by IR/RM?

Among the various tools, I haven't found (but have tried many combinations) of getting from an IRP definition to the specific protocol upgrade.

What I can do:
I have the simple parallel port to Jp1 cable, and can read/write the 8811 remotes. I have added a new device (1479) along with a protocol upgrade (PID set to 1E1, because my remote doesn't have it natively).

I tried converting the protocol.ini GI cable data into a protocol upgrade as follows:

Code: Select all

Upgrade protocol 0 = 01 E1 (S3C8) gi (PB v4.02)
43 8B 01 8B 12 CC 4D 00 08 00 FA 08 B6 00 FA 04
51 C3 3C 11 94 08 B6 20 11 08 03 F6 FF 36 08 04
F0 C0 56 C0 F0 04 04 C0 60 C0 56 C0 F0 06 C0 10
F6 FF 36 8D 01 46 1C 08 C0 C0 10 04 1A FA AF
End

I can load this into the remote, and as I test I only mapped one key (power), but so far the key hasn't worked on the target (I have target GI cable devices). I suspect this is because of the S3C8 protocol definition in the ini file, as opposed to the S3C8+ implementation that I need. PB creates a much smaller upgrade set, and I'm pretty sure I tried that generated upgrade too, and it didn't work.

Since I normally use the ADI Ocelot for my IR captures and deal in Pronto (and don't own an IR widget), I can't direct use IRscope to check the output. I guess I could capture indirectly, produce a Pronto output, and then import that into IRscope.

I guess it could also be an issue with the OBC/Hex codes for the keys, I am using Hex 0A for the power key (should be right), but maybe I have a complement issue or lsb/msb issue.

So after that long winded diatribe, maybe some can suggest the proper work-flow for this problem, or can give me the protocol definition in PB that satisfies this remote? This would be ideal, since I could then make the protocol changes that I need using PB.

[Capn Trips]

The GI Cable protocol (00C4) is built in to the 8811 and both RM and KM fully support making upgrades for the 8811 with this protocol. I'm not sure that I understand your dilemma. The protocol upgrade (not required for the 8811) is:

Code: Select all

Upgrade Protocol 0 = 00 C4 (S3C8+) GI Cable (KM v9.19)
 43 8B 01 8B 12 CC 4D 00 08 00 FA 08 B6 00 FA 04
 51 C3 3C 11 94 08 B6 20 11 08 03 F6 FF 36 08 04
 F0 C0 56 C0 F0 04 04 C0 60 C0 56 C0 F0 06 C0 10
 F6 FF 36 8D 01 46 1C 08 C0 C0 10 04 1A FA AF
End

[Joe Kane]

What I what to be able to do is modify the protocol for a specific purpose. Before I did that, I wanted to confirm that I can load the original protocol (as an upgrade) int othe 8811 and convince myself that that part of the process works. As part two, I want to make changes to the protocol. I was hoping to be able to do that from within PB.

When I paste the protocol.ini version of GI into PB, and do the decode, it produces a smaller output, and one that (so far doesn't properly) control the target device.

[Capn Trips]

Yeah, but I'm telling you that the protocol upgrade you "calculated" from the S3C8 matches exactly the protocol used by the tools for S3C8+, so I'd wager that it is correct for the 8811. If by "doesn't work" you mean that one OBC that you tested does not do what you hoped it would do, I would first try other OBCs. The protocol is fine.

You provide a LOT of background but you're still talking in riddles that simply obscure the missing info. What device are you trying to control? We cannot guess at OBCs without SOMEthing about the device.

[ElizabethD]

The protocol CapnTrips posted from KM is identical to what RM puts out for 881x remotes

Upgrade protocol 0 = 00 C4 (S3C80) GI Cable (RM v1.97)
43 8B 01 8B 12 CC 4D 00 08 00 FA 08 B6 00 FA 04
51 C3 3C 11 94 08 B6 20 11 08 03 F6 FF 36 08 04
F0 C0 56 C0 F0 04 04 C0 60 C0 56 C0 F0 06 C0 10
F6 FF 36 8D 01 46 1C 08 C0 C0 10 04 1A FA AF
End

and when the Decode is assembled back in PB it puts out

Upgrade protocol 0 = 00 C4 (S3C8+) PB v4.02
43 8B 01 8B 12 CC 4D 00 08 00 FA 08 B6 00 FA 04
51 C3 3C 11 94 08 B6 20 11 08 03 F6 FF 36 08 04
F0 C0 56 C0 F0 04 04 C0 60 C0 56 C0 F0 06 C0 10
F6 FF 36 8D 01 46 1C 08 C0 C0 10 04 1A FA AF
End

also identical. I do not see any missing bytes. Sorry.

Edit - Hi CapnTrips, we were typing at the same time

Edit2: the statement "I guess it could also be an issue with the OBC/Hex codes for the keys, I am using Hex 0A for the power key (should be right), but maybe I have a complement issue or lsb/msb issue." is not helpful. Hex 0A for power does not mean a thing in the absence of knowing what you're trying to control. For instance, in Motorola boxes power is hex 50, and I'm sure there are others.

[The Robman]

I have created a commented PB file that exactly replicates the executor that's built into UEI remotes, and I have created a KM file that uses the protocol so you can test it.

Both files are zipped together here:
https://www.hifi-remote.com/forums/dload ... le_id=8553

Load the PB file into PB to make changes, then re-assemble it. If you don't change the protocol id or the number of input bytes, you can copy the new protocol straight to IR to test it, but if you want to save it for future use, you should also copy it to the KM file.

If you want help making the changes for this first attempt, describe how you want your new version to work and I can help you make the changes. Then once you know how to do it, you should be able to do it yourself next time.

[The Robman]

When I paste the protocol.ini version of GI into PB, and do the decode, it produces a smaller output, and one that (so far doesn't properly) control the target device.

I see what you're doing. When you do the initial decode, PB will initialize all the timing data for you but it will also disassemble the executor code in the Disassembly tab. If you don't check the "Use Assembled Protocol Code" box (cell G5) the generated code will just be based on the timing data, so it won't include the checksum,

What you need to do, after decoding the pasted executor code, is go to the Assembler tab and click the "Load Disassembly" button, which will copy the assembler from the Disassembly tab to the Assembler tab. Then click the "Assemble" button to compile the code, then go back to the Setup tab and check the "Use Assembled Protocol Code" box.

[The Robman]

You provide a LOT of background but you're still talking in riddles that simply obscure the missing info. What device are you trying to control? We cannot guess at OBCs without SOMEthing about the device.

Let me explain what I think Joe is trying to do.

He wants to build a brand new protocol, one that I assume he is inventing himself, so there's no device to be controlled at this point, nor is there an original remote to learn from.

He wants to use the GI Cable protocol as a starting point, and then make some subtle changes to it to make it his own.

As a "proof of concept" he wants to load the GI Cable protocol into his remote as an upgrade so he can verify that he knows what he's doing, before he starts tweaking it for his own purposes.

He tried pasting the current executor into PB but noticed that the generated code was smaller than the code he started with, which was a pretty good clue that something wasn't working, but being new to the tools, he didn't know what. I explained in the previous post what the mistake was.

Anyway, welcome Joe, I hope you're able to achieve what you want, and maybe stick around to have some fun when you're done.

[Joe Kane]

Let me explain what I think Joe is trying to do.

He wants to build a brand new protocol, one that I assume he is inventing himself, so there's no device to be controlled at this point, nor is there an original remote to learn from.

Yes, what he said. (But with a small caveat, I'll get to that...)

As a "proof of concept" he wants to load the GI Cable protocol into his remote as an upgrade so he can verify that he knows what he's doing, before he starts tweaking it for his own purposes.

He tried pasting the current executor into PB but noticed that the generated code was smaller than the code he started with, which was a pretty good clue that something wasn't working, but being new to the tools, he didn't know what. I explained in the previous post what the mistake was.

Yes! What he said x2. That was my error. I reads lots of documentation and posts, but I think I missed this flow: (1) Load disassembly, then 2) assemble, then 3) check 'use assembled protocol code' in setup tab. I think I was skipping step 1. Following this flow, I can now get the correct output in PB.

Thank you, Rob.

Small caveat: I do have a remote and a target device to be used for my confidence test: I have a cable box (Motorola) that uses gi protocol. If I could successfully control this device after I did the protocol upgrade (manually reloading the original GI protocol), then I'd know my work-flow steps were good, and I could proceed with protocol changes.

I did at one point just copy the protocol upgrade for GI right out of the protocol.ini and loaded that into my remote. This didn't appear to work. However, I thought that I had read in previous posts that the protocol upgrade codes for [S3C80] and [S3C80+] were different (incompatible). That's when I went to PB and starting trying to recreate it. But since everyone has supplied the identical protocol upgrade here (and its the same as in protocol.ini) so maybe the blanket statement about incompatibility is not quite correct.

The reason that I was also working with the OBC codes is that I needed to have at least one key working in the device upgrade, in order to test the device/protocol on my target test device (Mot cable box) so I picked the power key.

After examining Rob's KM file, I see that I was also missing the 'LSB' check-box (Manual Settings), and so my key code wasn't correct. After fixing that in RM and reloading with IR, the key works.

Thanks again.

[The Robman]

Small caveat: I do have a remote and a target device to be used for my confidence test: I have a cable box (Motorola) that uses gi protocol.

Right, but you don't have a device that uses the modified protocol that you're about to create, nor a remote that transmits it that you can learn from, right? That's what I meant.

Did you pick the GI Cable protocol just because you have the Motorola STB? Are you planning on using that protocol as a starting point for your new protocol, or are you going to create one from scratch? Protocols are kind of my specialty, so I'd be happy to help if you need it.

However, I thought that I had read in previous posts that the protocol upgrade codes for [S3C80] and [S3C80+] were different (incompatible).

They are different, the difference being the vector addresses that are used to jump to the IR engine. The main vector address in the old S3C8 code is $0133 and the equivalent address in the new format is $0146. If you generate code in the new format using PB and then paste it into KM, if you subsequently change the selected remote to one that requires the old format, KM will change it for you.

After examining Rob's KM file, I see that I was also missing the 'LSB' check-box (Manual Settings), and so my key code wasn't correct. After fixing that in RM and reloading with IR, the key works.

When in doubt, use EFCs instead, that's what I did. I just took the known EFCs for the CBL/0476 setup code and plugged them into KM. It wouldn't have mattered if I got the LSB thing right or not because the hex code would have been correct, but when I first did it, the OBCs looked wrong, so I guessed that they didn't need to be complimented. I changed LSB-COMP to LSB and that made them look right. Then I checked a GI upgrade to confirm.

Just FYI, when it comes to dealing with "Manual Settings" protocols (which is what you need when you're writing the executor yourself) KM is a better tool than RM, at least for the development stage. Once the upgrade is finished, the final KM file can usually be imported into RM and work, though sometimes it will still need tweaking in RM.

[vickyg2003]

Just FYI, when it comes to dealing with "Manual Settings" protocols (which is what you need when you're writing the executor yourself) KM is a better tool than RM, at least for the development stage. Once the upgrade is finished, the final KM file can usually be imported into RM and work, though sometimes it will still need tweaking in RM.

Rob, why do you say that? I only have a small amount of experience with protocols, using both KM and RM and I didn't find one having an advantage over the other, so I'm looking for insight?

[The Robman]

Manual Settings upgrades have typically been a problem for RM. For the longest time there wasn't a way to start one in RM, you could only import them. There is a way to start them in RM now, but it's not fool-proof, I've had cases where the executor code just wouldn't save, or the settings that state how to handle it wouldn't save, I don't remember exactly. But regardless, the controls are somewhat hidden whereas in KM they are all out in the open.

Like I said, I'm just talking about the development stage, once the upgrade is finished the final test should be to import it into RM and if it doesn't import correctly (which is sometimes the case when the code uses more than 1 variable byte) you can make the final corrections in RM and save an RM copy too.

[Joe Kane]

Thanks Rob.

Running through the tools for a while, it still wasn't entirely clear to me which one was better suited (KM vs RM). I get some funny behavior sometimes in KM and PB where the function buttons were resizing and just about disappearing after I had gone through a number of iterations. I'd have to quit the spreadsheet and restart. Some of the process flows in RM seem a little awkward and it took me a while to get the process down, and some of the subtleties are just that. I don't mean it as a knock in any way; the tools are very powerful.

I've got everything working now, and have confirmed I can edit with PB and see the proper protocol changes reflected in output.

As to EFC vs. OBC. vs. Hex and this comment from Liz:

Code: Select all

Hex 0A for power does not mean a thing in the absence of knowing what you're trying to control. For instance, in Motorola boxes power is hex 50, and I'm sure there are others

It is all a matter of the relative reference. In purest form, Motorola's power key is actually Hex 0x0A. EUIC representation is bit reversed and 0x0A becomes 0x50, and then you need the manual check-box for 'LSB'. If memory serves, I think UEIC Hex representation was originally based on actual bit transmit order.

If you get the right number of flips it all works out. But in this forum you are right (Moto cable box power code is UEIC Hex 0x50 instead of Hex 0x0A), and I should only speak in EUIC terminology.

[The Robman]

As to EFC vs. OBC. vs. Hex and this comment from Liz:

Code: Select all

Hex 0A for power does not mean a thing in the absence of knowing what you're trying to control. For instance, in Motorola boxes power is hex 50, and I'm sure there are others

It is all a matter of the relative reference. In purest form, Motorola's power key is actually Hex 0x0A. UEIC representation is bit reversed and 0x0A becomes 0x50, and then you need the manual check-box for 'LSB'. If memory serves, I think UEIC Hex representation was originally based on actual bit transmit order.

If you get the right number of flips it all works out. But in this forum you are right (Moto cable box power code is UEIC Hex 0x50 instead of Hex 0x0A), and I should only speak in UEIC terminology.

When Liz says "Hex 0A for power does not mean a thing in the absence of knowing what you're trying to control" she's referring to the fact that we often get people posting questions with very little context in the assumption that a hex code is a definitive thing and we should know all that we need to know from it. An example of such a question might be "I need to program the POWER button on my remote, I know the hex code is 0A but I don't know what to do next." As you can imagine, without knowing where the hex code came from, we don't know whether it's reversed or not, etc and we don't know what protocol it's for, etc.

With a UEI executor, a hex code is a definitive thing, because we can read the assembler to see how it gets treated.

In general, we prefer to deal with OBCs rather than hex codes or EFCs because many of UEI's executors are combos or mini-combos where some of the bits in the hex code are used to control which device code is used. For example, if you were to learn a Sony signal using your URC-8811 and then download the memory, IR would report a single OBC but multiple EFCs and hex codes. This is because there are multiple ways that you could generate the OBC using UEI's executor.

Having said all that, using OBC is the only preferred method when we're dealing with a documented protocol (ie, one that's already been set up in KM and/or RM). When dealing with a "Manual Settings" protocol, the OBCs will only be correct if you get the settings correct (ie, LSB, etc). In your case, I knew the EFCs for the CBL/0476 upgrade, and EFCs have a one-to-one relationship with hex codes, so I knew that these would generate the right signals for your upgrades. As I had entered the codes using EFCs, it wasn't essential that I get the OBCs right, but I did so anyway just for the sake of consistency.

So, now that you have your setup working, would you like to share what your thoughts are for the new protocol that you want to invent?

[mr_d_p_gumby]

However, I thought that I had read in previous posts that the protocol upgrade codes for [S3C80] and [S3C80+] were different (incompatible).

They are different, the difference being the vector addresses that are used to jump to the IR engine. The main vector address in the old S3C8 code is $0133 and the equivalent address in the new format is $0146. If you generate code in the new format using PB and then paste it into KM, if you subsequently change the selected remote to one that requires the old format, KM will change it for you.

PB also has S3C8/S3C8+ translation. If you generate assembled code for an S3C8+, and then select S3C8 on the main tab, it will output the translated code block, assuming there is not also S3C8 assembly code, which would override translation. (Also, vice-versa.)