Need help creating upgrade for URC-8011 for UK SKY digibox

jaco_scotland · Post by **jaco_scotland** » Thu Dec 11, 2003 1:10 pm

Well I am certainly surprised by the interest my question has generated. I have read all the replies but have to admit that some of it is going way over my head. However thanks to all that have contributed and I look forward to seeing how this thread ends up.
One further question, maybe my inexperience is showing here but if the 8811 can learn commands isn't it learning protocols too and if so isn't there any way to extract this information and use it to perform an upgrade?

johnsfine · Post by **johnsfine** » Thu Dec 11, 2003 1:17 pm

The Robman wrote:I don't know enough about the RC6-?-?? protocols to comment the similarity to those.

All types of RC6 have a start bit followed by three bits encoding a value named "M", followed by a double wide T bit, followed by BB more bits. A given type of RC6 is RC6-M-BB indicating the value of the M field and the number of bits after the T bit.

So when I say Replay is RC6-6-24 I mean that Replay always has 6 in the M field and Replay always has 20 bits after the T bit.

You could say the base version of RC6 is RC6-0-16 but no one ever calls it that.

The Robman wrote: I would imagine that you would want to use the simple RC6a protocol as your base (found by selecting RC6a or Replay (Simple) in KM, and IIRC this protocol has all 8 bits of the OBC as variable data, not fixed.

Right after I posted the idea above, I did write an RC6-M-20 version and I did start with RC6a and make the trivial change to drop 4 bits and the less trivial change to have two less fixed bits and two more variable bits. The T bit counts as two bits and the RC6a code was simplified by having the number of fixed bits divisible by 4:
1 start bit
3 M bits
2 T bit
8 device bits
8 subdevice bits
2 OBC bits
-- ------
24 Fixed bits

Vs. the new one

1 start bit
3 M bits
2 T bit
8 device bits
4 subdevice bits
-- ------
18 Fixed bits

I still need to construct the protocols.ini entry and maybe test it. The code, if you're currious is:

DB 47H, 93H
DB 61H
JR begin
DB 87H
DB 05H
DB 08H
DB 04H
DW 00DEH
DW 0000H
DW 0000H
DW 00CAH
DW D444H
DW 0535H
DW 01A8H
begin: LD RC0, #0AH ;Count: 8 OBC bits and 2 fixed bits
LD RC1, R07 ;Pick up final two predoubled fixed bits
L1: ADD RC1, RC1 ;Shift R07:R08:RC1 for extra bit
RLC R08
RLC R07
RLC R09 ;Shift a bit from hex command
RLC RC1 ;Shift that bit into R07:R08:RC1
INC RC1 ; both inverted and carried to the extra bit position
RLC R08
RLC R07
DJNZ RC0, L1
LD R09, RC1 ;Store last four doubled bits
JP 0133H

silron1 · Post by **silron1** » Thu Dec 11, 2003 1:22 pm

Just over 4 weeks ago I had never heard of JP1 technology - Yet I am now programing universal remotes for friends & family - all due to this super

most helpful group.

You have completely resolved my last issue after checking out my upload to diagnostics.

I now have an, all button working, Upgrade Code for a Sky Digibox.

Final check tomorrow and then I shall upload to the file area

Ron

Post by **The Robman** » Thu Dec 11, 2003 2:27 pm

jaco_scotland wrote:if the 8811 can learn commands isn't it learning protocols too and if so isn't there any way to extract this information and use it to perform an upgrade?

It depends how you define the word "protocol". In it's purest form the word simply describes what an IR signal looks like. If we look at a learned signal and see that the wavelength of the IR signal is 38kHz, and there's 32 bits in the signal, there's a very good chance that the protocol is a variant of NEC. When a learned signal matches a known profile, IR.exe will display the name of the protocol along with the device code, OBC, etc. But when the protocol doesn't match a known profile all that gets displayed is the timing information.

Now, when we talk about protocols here in the JP1 world, we're often really talking about "executors", in other words, the code used by the remote to re-create the infrared protocol.

So, when you learn a single signal with your remote, all you can truely determine is the IR frequency and the number of bits in the signal (plus a few other bits & pieces). You would need to capture the signals from several buttons for us to be able to spot patterns, which in turn would give us an idea of which bits are "fixed" (and probably represent the device code) and which bits are variable (and represent the OBC/EFC). We would also be able to make an educated guess as to whether the format is LSB or MSB at this point (ie, do you read the data left-to-right or right-to-left).

Now, if we don't know of an existing "executor" that re-creates this protocol we would have to create one, which is usually where Jon Armstrong jumps in with the Protocol Builder spreadsheet.

Post by **The Robman** » Thu Dec 11, 2003 2:28 pm

silron1 wrote:I now have an, all button working, Upgrade Code for a Sky Digibox. Final check tomorrow and then I shall upload to the file area

Ron

Better yet, load it up now and then replace it tomorrow if you improve it. That way, even if you forget about it, we still have a working upgrade for this device.

johnsfine · Post by **johnsfine** » Thu Dec 11, 2003 2:40 pm

I just posted a protocols.ini file in the diagnosis folder
http://groups.yahoo.com/group/jp1/files ... is%20Area/
and I commited it at SourceForge (even though it's untested).

Is there a way to post a URL for the new copy at sourceforge, so I don't need to duplicate it at Yahoo?

I added two versions of "RC6-M-20n".
I put "n" on the end of the name to indicate that the toggle bit is not toggling. If we ever need a true RC6-M-20 protocol, I'd like that name to be available.

One entry uses the protocol that is built in on three models of remote. The other entry uses the short version I just wrote. RM automatically decides between the two based on the RDF file.

Both entries ask for protocol parameters using the same numbering and names as used by the decoder, so it should be easier in the future than KM manual mode was in this thread.

For this thread, if you want to save some upgrade space convert to this smaller one.

It still needs testing. If no one volunteers to try this for me, I'll create a couple upgrades with different protocol parameter values and learn from one remote to another and verify that the decodes are right and that the lead out times are reasonable (vs. the many Sky samples we have). But I won't have time for that too soon, so I hope I got this right on first try.

gfb107 · Post by **gfb107** » Thu Dec 11, 2003 2:49 pm

johnsfine wrote:Is there a way to post a URL for the new copy at sourceforge, so I don't need to duplicate it at Yahoo?

I don't know of a good way to do that without making a whole new
release. The problem is that the web-based source browser runs a day or 2 behind the actual CVS repository.

P.S. Could you take a look at the Button maps, RM and the URC-8060 thread. Nils and I need some assitance.

silron1 · Post by **silron1** » Thu Dec 11, 2003 3:25 pm

Rob - Its there now.

Ron

johnsfine · Post by **johnsfine** » Thu Dec 11, 2003 3:41 pm

I had a serious typo in that protocols.ini, which I just corrected. So if you got it too soon after my previous post, try again.

silron1 · Post by **silron1** » Thu Dec 11, 2003 4:09 pm

Have tried the new RC-M-20n in a RM file I had already set up in anticipation.

Can confirm it works equally well for a Sky Digibox in RM as the one I made earlier with the manual protocol in KM

Ron

johnsfine · Post by **johnsfine** » Thu Dec 11, 2003 6:23 pm

You tested that surprisingly soon after I corrected that serious typo.

I did find time to do the remote to remote learn and decode. So far as I can tell I got it all right (after fixing that first typo).

jaco_scotland · Post by **jaco_scotland** » Thu Dec 11, 2003 11:15 pm

Thank you, thankyou, I used the upgrade spreadsheet posted by Silron and changed the remote to the 8811 and it appears to work perfectly. One question, the "text" function (EFC=179) is shown against "@phantom2", which button would that be on the 8811?
Although I didn't understand all of what was being discussed in the replies, I'm sure I'll come back to this thread on my journey up the learning curve.
Thanks again for all your valuable time.

usblipitor · Post by **usblipitor** » Fri Dec 12, 2003 2:02 am

jaco_scotland wrote:One question, the "text" function (EFC=179) is shown against "@phantom2", which button would that be on the 8811?

It is the invisible button.

Phantom Buttons are not tactile buttons that you can press; they are used to hold functions that you might not want to press directly but that would be very nice to use as part of a macro.

silron1 · Post by **silron1** » Fri Dec 12, 2003 3:09 am

I looked at the 8811 and would suggest you move red, green ,yellow and blue to L1, L2 L3 L4 and find another availiable button for text which you can rename in functions,

Next week I am expecting a URC-8810w (same as 8811) to arrive from US and I will be making another Device code from scratch for this remote.

Hoping to reduce many of the key moves and extra protocol. Will post the result. In the meantime later today look again at the file you downloaded as I have added a few notes.

Interestingly on the URC-8060 there was no need for extra protocol code with the manual protocol I used but I noticed the mammoth amount required for the 8811

Ron

johnsfine · Post by **johnsfine** » Fri Dec 12, 2003 5:27 am

silron1 wrote: Interestingly on the URC8060 there was no need for extra protocol code with the manual protocol I used but I noticed the mammoth amount required for the 8811

The 8060 has pid 0020 built in so you don't need a protocol upgrade. It also has SAT/0847 built in so you didn't really need the device upgrade either. Using a device upgrade gives you the ability to rearrange keys any way you want, but assuming the built in SAT/0847 is mostly correct anyway, it would have been easier to just use a few KeyMoves starting with that setup code.

For models that don't have pid 0020 built in, I suggest using RC6-M-20n in RemoteMaster rather than pid 20 in KM. You get a much smaller upgrade protocol. (Don't try testing both upgrade methods together in one remote. The pid is the same, so they can't be correctly installed in the same remote at the same time. On the 8810 remove the upgrade created by KM, if you had tried it, before installing the smaller one from RM).