JP1 Remotes

Capn Trips,

I tried whatever Sky "flavour" was present in the database of codes that came with my SB.
No single one code made my SkyHD box even detect the command.
I verified that the IR emitters were working (so the problem is not "hardware"-bound).
They simply CANNOT get understood by the HD Box.
I've read the thread myself and if I'm not mistaken, the British SkyHD box is a Thomson unit while the Italian SkyHD box is a Pace.

I can confirm, though, that my Pronto RU890 was able (and still IS) to learn and use those codes... the ones I posted in form of a .ccf in the analysis area of this forum (see link above).

Andrea

I do not dispute that your Pronto works. Just making a logical suggestion. The brand of the box is immaterial for Sky products.

Have you tried relearning to try to get better decodes of the Pronto hex?

Capn Trips wrote:I do not dispute that your Pronto works. Just making a logical suggestion. The brand of the box is immaterial for Sky products.

So far as we knew before now. But clearly this "Sky" device is different.

Capn Trips wrote:Have you tried relearning as suggested previously to try to get better decodes of the Pronto hex?

I'm surprised and confused that the signals work. You usually can't learn these well enough for any decent fraction of them to work. As they're already working better than they should, I wouldn't have much hope that they could be improved by relearning.

Sorry I haven't had time yet for the serious look these will require.

I don't recall whether anyone other than Jon Armstrong ever understood this protocol better than I do. If there is anyone, I hope they'll jump in here.

I have examined the learns in the CCF file and they're prefectly clean learns, so there's no problem there. It's been a while since I've looked at this protocol, but this is the same protocol that is used for the Dreambox and the ECS Fireball, among other things. This is a UEI proprietary protocol that uses 16 different burst pairs (it's exec $016C).

I've created a spreadsheet that does a breakdown of the signal here:
https://www.hifi-remote.com/forums/dload ... le_id=3761

There's one aspect of the learned signals that puzzles me however, the first nibble of both the fixed and variable portion of the signal is set to 1, whereas it's usually set to 0 and I don't think the official exec is coded to handle non-zero values for that nibble.

Robman,

First of all THANKS for trying to shine some light on this matter!
I'm afraid though that this enlightenment would not help ME, since (and I admit my TOTAL DUMBNESS!!!) I have no clue about what to do with this XL breakdown of codes...
Are these hex strings something that must be put in the RM application?

I beg everyone's pardon for my possibly silly questions, but I'm a complete newbie in this field. BTW, now I'm not in front of RM, so that I can't have any possible "clue" about using these codes with it...

Andrea

Rob, I share pp's confusion. Can you please relate your column headings to the fields available in RM? There is no protocol help for this one, so precious little to guide one through.

For example, you decoded Dev1, Dev2, and Dev3, whilst the Setup page in RM for Dreambox protocol has "Device" and THEN "OEM Dev1" thru 3. If your decoded Devs correspond to the OEM Devs, what goes in the Device field in RM?

Similarly, RM's functions sheet calls for a subdevice (is this to be left blank?) and has a single OBC column, whereas you show NO subdevice decodes and have three OBC columns (although only OBC2 shows any non-zero values).

I mustconfess that I have absolutely no idea who this protocol has been implemented in either KM or RM, so that spreadsheet was not designed to help an end-user get started, I loaded it primarily for John and any other expect that already has some knowledge of what this protocol looks like.

Furthermore, I'm not even sure that the current version of the executor can replicate it as I'm pretty sure that it's hard wired to send a zero in the first nibble.

However, as this is a UEI protocol, I would have to assume that they have an upgrade for it, so I've asked them if they can send me a copy as it would save me having to work it out myself (though it shouldn't be too difficult).

The Robman wrote:I mustconfess that I have absolutely no idea who this protocol has been implemented in either KM or RM

Well, I can confirm that the protocol is not even available as a selection in KM, so RM is the only game in town right now.

As far as I can tell, now the ball is in UEI's field... right Robman?

The more I see your discussion, the more I feel deep respect for this community.
I feel confident that, one way or the other, this mess will be sorted out!

Andrea

The Robman wrote:Furthermore, I'm not even sure that the current version of the executor can replicate it as I'm pretty sure that it's hard wired to send a zero in the first nibble.

I took a closer look at the learned signals. I was wrong earlier about them being bad learns. They're quite good.

In addition to checking for various other evidence that a learn is bad, DecodeIR also checks that first nibble. If it isn't zero, then the decode is reported as bad.

I don't think I ever saw one of these signals before in which the first nibble was correctly decoded but non zero. I had forgotten that I put that check in the code. I still don't recall why I put that check in the code. Maybe Jon or Rob told me the first nibble must always be zero.

I haven't had time yet to look at the executor. But I'm sure Rob knows what he is talking about.

It seems likely that UEI has the executor that originally generated this signal. Probably Rob can get that. Otherwise, I guess I should rewrite the executor to be more flexible and add that to RM.

If I remember correctly, the target of all this is a Slingbox. So if the executor must be an upgrade its size matters a lot.
Rob, do you know if there's any chance a usable executor is already built-in on the Slingbox? I never got a good understanding of what we do/don't know about Slingbox internals. Does the RDF have an accurate list of PIDs and variants?

Capn, You can create upgrades using KM, but you need to use the Manual Settings option if the protocol isn't built in. As I can't use RM on this machine, I will still end up using KM to create the upgrade.

John, the UEI exec for this protocol is $016C, it's the same one that's used for the Dreambox and the ECS Firebal.

The executor is too big to be added to the Slingbox, but fortunately, all models have it installed.

I have an old dis-assembly of the exec here:
https://www.hifi-remote.com/forums/dload ... le_id=3768

I'll try and describe the structure of the protocol:

There are 16 burst pairs, as follows:
0 = 0008 001F
1 = 0008 0024
2 = 0008 0029
3 = 0008 002F
4 = 0008 0034
5 = 0008 0039
6 = 0008 003F
7 = 0008 0044
8 = 0008 0049
9 = 0008 004F
A = 0008 0054
B = 0008 0059
C = 0008 005F
D = 0008 0064
E = 0008 0069
F = 0008 006F

Therefore, each pair represents one nibble (half-byte) in the final signal. The first 4 bytes of the signal are the fixed portion, this is followed by one longer burst pair, then the next four bytes are the variable portion, which are also followed by a longer burst pair.

The signal that I just described is sent once, then if the button is held, a toggle bit is flipped and the signal is repeated for the duration that the button is held.

The first byte of both the 4-byte fixed portion and the 4-byte variable portion is a checksum. The first nibble of the checksum has always been zero (but is '1' for this Sky box). The next nibble is a SUM of all the other nibbles in this 4-byte signal.

The next 3 bytes of fixed data are referred to as dev1, dev2 and dev3 in the spreadsheet.

The next 3 bytes of the variable data are referred to as obc1, obc2 and obc3 in the spreadsheet (except that the MSB of OBC1 is the toggle bit). OBC1 has always been zero for all the devices that we've seen, including the Sky box. As for OBC2 and OBC3, so far each device has used one of the other, but not both (with the unused one constantly being set to zero). UEI should have included a switch in the fixed data which would tell the exec which OBC byte to use, but unfortunately they didn't, instead they chose to make the exec use 2 bytes of variable data where one of them is always set to zeroes.

I've just re-read the dis-assembly of the executor and the good news is that the first two bytes of the variable data are actually copied from the first two bytes of fixed data (except for the checksum nibble, of course), so we can easily generate a '1' in the first nibble.

One thing that does concern me though is the pair that's used to separate the 4-byte sections. For the Fireball it was a constant "0008 01E9" (using Pronto hex) and for the Dreambox it's a constant "0008 0210" (which is close enough). However, for the Sky they use a different pair between the fixed and variable sections to the one they use after the variable section. Between the sections they use "0008 01F5" (which is a match) and after the variable section they use "0008 0C06" (which isn't). I don't know whether the Sky would work if we use the standard, shorter pair after the variable data.

Andrea, I have created an upgrade that uses the standard executor (and will therefore use the standard pairs as separators) which you can test to see if it works. (You used a symbol for one of the buttons, so I don't know what it really is. I've called this function "unknown" in the upgrade file).

https://www.hifi-remote.com/forums/dload ... le_id=3769

If the upgrade doesn't work, and it's because of the seperator pair, I might be able to create a different upgrade, but I would need to know which model of Slingbox you have (I'm assuming it's the PAL "RV" box).

Rob,

I downloaded your upgrade, imported in RM (1.68 from SourceForge), together with BINRV .rdf file from this site (because my SB is a RV protocol unit).
I've already made a small correction to your upgrade concerning the "unknown" function that in reality was the "Info" function on the original remote.
Now, RM seems to have "swallowed" your upgrade with pleasure!
I did already the .bin export and as soon as I'll be home tonight (I'm at work at the moment) I'll try to include the .bin I got from the export into SB's RC database.
BTW, the export produced a file called S2000_RV.bin, so (according to some hint I've read elsewhere) I'll try the include specifying S2000 as filespec.

If everything will be fine... well you'll have my ETERNAL gratitude (and more) and I'll post the .bin file as well for all the others to use (if there will ever be any...).

Andrea

(more to come...)

I called the code SAT/2000, for no reason in particular, so if another code would be easier to deal with, you can always change it in RM. However, once you've generated the bin file, you should not change the name of it. The reason being that the code name is inside the file also and it needs to match the name of the file.

As for loading the bin file into your Slingbox, check the sticky at the top of this forum where it describes how to use it as an "other" code.

If it turns out that the upgrade doesn't work, could you do another test for me using your Pronto.

Here is the Pronto hex that I extracted from your CCF file for the "POWER" button...
0000 006C 0012 0012 0008 0022 0008 0032 0008 001D 0008 006C 0008 0032 0008 0032 0008 002D 0008 0022 0008 01F5 0008 0022 0008 001D 0008 001D 0008 001D 0008 001D 0008 006C 0008 001D 0008 001D 0008 0C06 0008 0022 0008 0032 0008 001D 0008 006C 0008 0032 0008 0032 0008 002D 0008 0022 0008 01F5 0008 0022 0008 0047 0008 0047 0008 001D 0008 001D 0008 006C 0008 001D 0008 001D 0008 0C06

and here is a modified version of it...
0000 006C 0012 0012 0008 0022 0008 0032 0008 001D 0008 006C 0008 0032 0008 0032 0008 002D 0008 0022 0008 01F5 0008 0022 0008 001D 0008 001D 0008 001D 0008 001D 0008 006C 0008 001D 0008 001D 0008 01F5 0008 0022 0008 0032 0008 001D 0008 006C 0008 0032 0008 0032 0008 002D 0008 0022 0008 01F5 0008 0022 0008 0047 0008 0047 0008 001D 0008 001D 0008 006C 0008 001D 0008 001D 0008 01F5

All I've done is shorten the gap time for the final burst pair (the item in bold). I'd like you to cut & paste the two codes above onto two new buttons on the Pronto and then test them both. If the 2nd one doesn't work but the 1st one does, this will confirm that the Sky HD requires the longer pair, which our current executor won't generate.

If both buttons work, but your Slingbox upgrade doesn't, that implies that there's a problem with the upgrade itself rather than the signal we expect it to generate.

IT WORKS!!!!!!!!!!!!!!!!!!!!

As in the subject, 100% SUCCESS!!!
Rob, you're the MAN! It works like a charm!
I'm just home, and I loaded the .bin I've produced on my Mac at work (thanks Sun for Java as well).
I'm not sure there's another single one in my country having a SB *AND* Sky HD; SB are not even sold in my country. I had to find an UK unit on eBay, not to mention the quantity of HDTV owners here.
In Italy, HDTVs are becoming more and more popular nowadays, but they are BIG and were very expensive. They started selling HDTV sets at an affordable price since last christmas season. Sky itself begun broadcasting HD channels not earlier than last August, so all the technologies we're talking about are pretty recent!
Anyways, now my home theater setup is COMPLETE and everything is working fine; My job (I work for Italy's space industry) forces me to travel A LOT in other european and not-european countries and with my (now-100%-working) SB I'll be a little more at home now... wherever I go.

THANKS A LOT again.

PS: The link to the bin file is:
https://www.hifi-remote.com/forums/dload ... le_id=3771