Remote Master - Manual Settings

[johnsfine]

The variant of RC6-M-20n in protocols.ini that includes protocol code, and can therefore be used in remotes that don't have it built in, uses 6 bytes of fixed data.

The best path for the user is to switch from manual settings to RC6-M-20n and to use the version of that protocol that the .ini file tells RM to pick automatically. If the remote includes the big protocol with small fixed data then that is better. If the remote doesn't include that then the small protocol with big fixed data is better.

The fixed data of E0 00 corresponds to default values on all three protocol parameters: M=6, Device=0, Subdevice=0.

If RM will correctly compute the six byte version of the fixed data if you give it those settings or let them default.

The OBC and EFC values are consisten across all these versions (manual settings and the two different RC6-M-20n versions). In other situations you need to transform the OBC and or EFC when changing protocol versions, but this time you don't.

[The Robman]

The variant that doesn't have protocol code, and can therefore only be used in remotes that have it builtin, has 2 bytes of fixed data.

Here's the 2-byte S3C8 code:

40 9A 21 8B 13 C7 85 40 08 04 00 DE 00 00 00 00 00 CA 24 84 05 35 01 A8 E4 03 2D E4 04 2E E4 05 2F 08 2D F6 FF 62 19 03 E6 04 03 08 2E F6 FF 62 19 05 F6 FF 62 19 06 08 2D F0 C0 F6 FF 62 19 07 08 2F F6 FF 62 19 08 F6 FF 62 19 09 2C 04 10 09 10 08 10 07 10 06 10 05 10 04 2A F2 E6 10 06 8D 01 46 2C 04 CF 10 C1 DF 10 C1 90 C0 FB 03 B6 C1 03 2A F1 AF

[The Robman]

The fixed data of E0 00 corresponds to default values on all three protocol parameters: M=6, Device=0, Subdevice=0.

John, what are the rules for decoding the 2-byte and 6-byte versions of the fixed data for this protocol?

Also, where did the 6-byte version come from, is it home made or did it come from UEI? All remotes that have the $0020 protocol installed, have the 2 byte version.

[johnsfine]

John, what are the rules for decoding the 2-byte and 6-byte versions of the fixed data for this protocol?

I never remember such things. I just trust that it's correct in protocols.ini

I hope you find the time to learn the notation in protocols.ini (if you haven't already) so you can help us add new entries.

Meanwhile, the two byte version has this line in protocols.ini

DeviceTranslator=Translator(0,3,1) Translator(1,8,8) Translator(2,4,4)

That says the first value (M) is 3 bits that go into the position 1 bit below the top of fixed data. The second (device) is 8 bits that go into place 8 bits below the top (in other words into the second byte). The third (subdevice) is 4 bits that go to position 4 bits below the top (botton of first byte).

E0 00 has a 1 in the top bit (which is hard wired by the FixedData=80 00 line and not connected to the three parameters) then the next 3 bits are 110, which is M=6, then the rest are zeroes, so device 0, subdevice 0.

The version with short protocol and long fixed data (I think I wrote that one, but UEI has written similar for other RC6 varients, so I may be confused about which is which) takes a lot of DeviceTranslator entries because the bits must duplicate and scatter. One pair of that:
Translator(0,1,2,2) Translator(0,1,3,2,comp)
Says that position 2 (from the top) of fixed data gets 1 bit from position 2 (from the bottom) of field 0 (M), while position 3 (from the top) of fixed data gets the comp of that same bit.

It may seem strange at first that fixed data bit positions are measured from the top in continuous sequence over all of fixed data, while the protocol parameter side is measured from the bottom and specified by item and position within item. But once you're used to it, it's easy to work with (and there were some good reasons for doing it that way).

[mr_d_p_gumby]

I haven't checked whether non S3C80 follow the same rules. I think they do.

Yes, they do. The first two bytes always specify the frequency/duty cycle, though the absolute values vary because the timebase is different. The third byte is consistently encoded among all four types of processors.

[gfb107]

Thanks everyone for the help.

I see John deliberately left the protocol code out of the 2-byte fixed data variant, so that it would only be used with remotes that have it builtin. The 6-byte version has much shorter (49 bytes instead of 116 bytes) protocol code and is therefore preferred when a protocol upgrade is required. I suppose that is why John gave it the variant name "short"

I tried using RM to switch between a remote that has the protocol buitin (URC-7562) and one that doesn't (URC-8910), and RM was only able to automatically make the switch in one direction. That's because the "short" version doesn't have a device parameter for T. Since not all parameters could successfully be copied to the new protocol, RM doesn't make the switch.

I think I'll change this code so that it only fails when there is a parameter with no match in the new protocol, and that parameter has an assigned value different from the default value.

[harley]

PID 0020 is the RC6-M-20n protocol, which is already defined in protocols.ini. Fixed data "E0 00" matches setup code SAT/0847.

ahhh, I see. Decodeir picks it up as nokia32 then...

Just FYI, according to my files, this protocol only gets pre-loaded into certain European remotes, it's not present in any US remotes that I know of.

That makes sense - The KM upgrade I used was a Sky upgrade, and Sky and Foxtel are very much cousins. SAT/0847 is the correct code for the built in definition, but it isn't really good enough for me, not to mention the 8810 and 8910 don't have them.

So, in summary - my problem is not that RM can't do what it needs, it's that decodeir is picking it up as something else!

I'm off to try the RC6 protocol.

[harley]

I just assumed this was a not_yet_supported protocol in the .ini file. But it sure looks like Rob is right that it's RC6-M-20n, which would be quite easy to set up in RM (and probably matches and .rmdu file already posted).

So what is the Nokia32 decode about?

I dunno - when I asked you about the NECx2 issues last week, I included some captures from the Foxtel remote. It was reporting 3 Nokia entries for each command. In the later builds of Decodeir you report that as Nokia32, so maybe there is a terminology difference between you all, or maybe they are just too damn similar.

I am so not keeping up with you guys...

[harley]

The fixed data of E0 00 corresponds to default values on all three protocol parameters: M=6, Device=0, Subdevice=0.

John, what are the rules for decoding the 2-byte and 6-byte versions of the fixed data for this protocol?

Also, where did the 6-byte version come from, is it home made or did it come from UEI? All remotes that have the $0020 protocol installed, have the 2 byte version.

the home made version was created by silron Sky_Digibox_fullyworking_KM and edited by heckydave then me. Greg has now ported it to RM as well...

[Mark Pierson]

Sky_Digibox_fullyworking_KM

Harley, I fixed your link... take a moment to read about Posting Links to Yahoo files.

[harley]

thanks mark - I was working on it when you did that.

[gfb107]

the home made version was created by silron Sky_Digibox_fullyworking_KM and edited by heckydave then me. Greg has now ported it to RM as well...

That RM file I created is the best I could do at directly importing that KM upgrade, but it isn't the best upgrade to use. It uses Manual Settings instead of RC6-M-20n, and will include a protocol upgrade in the output even when that isn't necessary. Fixing the upgrade is easy. Just change the protocol to RC6-M-20n and everything should carry over successfully.
I've already done that updated Foxtel Digital.rmdu

[johnsfine]

RM was only able to automatically make the switch in one direction. That's because the "short" version doesn't have a device parameter for T.

Thanks for figuring that out. It has been confusing me for a while. I saw the symptom but failed to realize the extra parameter was the cause.

I think I'll change this code so that it only fails when there is a parameter with no match in the new protocol, and that parameter has an assigned value different from the default value.

Great, I'll try to pay attention to this in other cases where one varient supports choices for an obscure part of the signal and another doesn't. It makes sense that the default for the version supporting a choice must match the hard wired behavior of the other version. I'll just need to make sure the protocol.ini entries get that right.

[johnsfine]

ahhh, I see. Decodeir picks it up as nokia32 then...

I don't believe that could be true. The transmitted protocol is RC6-6-20 (The protocol in RM is called RC6-M-20n, with M indicating that it can generate all the different RC6 varients with various numbers in that position, and n indicating the toggle bit doesn't toggle). RC6-6-20 would not be confused for nokia32.

I have seen several SAT devices in CCF files at RC in which two totally different protocols were used. It appeared that the two protocols operated two different aspects of the device. But I don't understand enough about SAT devices to be sure of that.

It is also possible that the device responds to two overlapping code sets. The Sky code set (which uses RC6-6-20) is an agreed standard across many brands of device. Some manufacturer might have decided to include recognition for a private protocol as well as the multi-brand public protocol.

I assume the learned Nokia32 functions worked. Do you now have RC6-6-20 signals for those exact same functions in the upgrade that also work? Or do the RC6-6-20 functions operate a different aspect of the device. In checking that, remember learned signals override the upgrade regardless of which sequence they were programmed in. So you can only test functions in the upgrade if the learned versions are deleted or were on different buttons or device mode.

IIRC, you only had a few SAT learned signals. Maybe if you learned signals for other aspects of the device, some of those would be RC6-6-20

So, in summary - my problem is not that RM can't do what it needs, it's that decodeir is picking it up as something else!

RM also should be able to make an upgrade for Nokia32. But none of us have gotten around to creating the protocols.ini entry for that. If we had, then you might have duplicated the learned Nokia32 signals with an upgrade, and if your device supports overlapping code sets you might never have needed RC6-6-20.

[harley]

Ok, first things first - R6-6-20n is the correct protocol, tyvm. It all works like a charm.

Second - I have learned 90% of the codes from the OEM remote (It happens to be a URC-1633B00-00 btw) and they ALL decode as Nokia32 See Diagnosis File

The only other thing from my POV is that I have now got the EFC for the volume commands (which I don't care about, but the next guy might) and I will upload this later.

Greg - please take down your variants of the file, as the naming is very specific for a purpose. I have Foxtel Digital Cable on a UEC box, but my dad has a different Foxtel Digital on a Pace box, and I know there are other unit types out there as well. I think Foxtel use the aforementioned URC-1633 so that they can ship one remote to all customers, regardless of the box. Though that said - John mentions the "Sky Code Set" sgreement so the Pace box may well use the same protocol and EFCs... I won't know till dad brings his remote control down...