Entone Kamai

[vickyg2003]

Ken

I am unsure what went wrong.
I am using an alpha version of RemoteMaster, so maybe it is incompatible.

Try Y2002.bin and see if this works.
https://www.hifi-remote.com/forums/dload ... e_id=11358

Vicky,

I have a quick try on the new bin you just upload, it still have the problem of repeating key and incorrect key map on some key.... any suggestion on what else should I try or what should I get from my side in order to figure out the problem? The version of software I am using is

RM device upgrade eidtor v2.01
RM-IR version : 1.32

Thanks a lot for your help

Hmm, it sounds like a prior version of the 0040 PID is taking control. Scrambled values would seem to indicate that there is a version that takes a different number of fixed variables. That shouldn't happen.

Alan, is there a way to do a reset of a sling and erase all the prior upgrade attempts? We can always change the PID, but one wonders at what point the memory will be full.

[alanrichey]

You can reset it as part of the setup, but I install remotes on a daily basis and never experince any problems. So I assume that each install overwrites the previous one automatically.

I've just been watching the progress on this thread without commenting, but Just for interest I installed this on my Harmony and did a learn and as expected got the Replay IR Protocol but also noticed that for each key press I get 2 entries, where the OBC for the second 'fire' is 128 more than the first 'fire' and this is consistent. Never seen this before.

I also don't know what the relationship between the IRDecode of 'Replay' is and the 3 ReplayTV protocols available in RM (Simple, Advanced and Official) ?

And I normally just set the repeat rate to zero by changing a single byte in the protocol, although I do not know which one applies here. The RMDU file Vicky provided looked incredibly complicated ?

Al

[vickyg2003]

You can reset it as part of the setup, but I install remotes on a daily basis and never experince any problems. So I assume that each install overwrites the previous one automatically.

If an RV can control more than one item at a time, then having multiple upgrades may be a problem, if the old upgrade that used the 'Simple Replay" is still in effect.

Also it could be that my RV RDF is wrong, but nobody ever complained about my upgrades being scrambled before this.

I've just been watching the progress on this thread without commenting, but Just for interest I installed this on my Harmony and did a learn and as expected got the Replay IR Protocol but also noticed that for each key press I get 2 entries, where the OBC for the second 'fire' is 128 more than the first 'fire' and this is consistent. Never seen this before.

Hmm, the replay has a toggle bit that toggles, After looking at this code, I see that the toggle bit isn't flipping.

I also don't know what the relationship between the IRDecode of 'Replay' is and the 3 ReplayTV protocols available in RM (Simple, Advanced and Official) ?

Neither did I. I just started with simple and shot codes to match. No Repeat. Now I see that the "simple" doesn't flip the toggle bit. And the toggle bit appears to be in the wrong place, if Harmony has it correct.

And I normally just set the repeat rate to zero by changing a single byte in the protocol, although I do not know which one applies here. The RMDU file Vicky provided looked incredibly complicated ?

Al

Vicky started with the "simple" just because it had so much less code than the normal one.

[alanrichey]

If an RV can control more than one item at a time, then having multiple upgrades may be a problem, if the old upgrade that used the 'Simple Replay" is still in effect.

No, it doesn't work like that, I assume there are 3 'blocks' of memory in the flash memory, one for each of the inputs (component, composite, S-Video) and when you install a BIN file for an input then the code is stored in that appropropiate 'block' and then used by the viewing systems. So installing a BIN file for an input will automatically overwrite a previous one.

There is one 'odd' thing, in that if you install a second file with the same code number then it will overwrite a previous one even if it belongs to a seperate input. I don't have an explanation for that.

[The Robman]

I also don't know what the relationship between the IRDecode of 'Replay' is and the 3 ReplayTV protocols available in RM (Simple, Advanced and Official) ?

The "official" option is designed to use the built-in version of the executor if one exists. Originally the official version always used 2 bytes of variable data, but eventually UEI changed it to use 1 byte. You would select this option if you don't have enough memory for the protocol upgrade.

The "simple" version is an executor that we wrote ourselves that uses a lot less memory than the UEI version. Typically, if you're going to have to install a protocol upgrade anyway, it's better to use this version.

The "advanced" version does some extra tricks that the other two versions don't do. Basically, it has some mini-macros built in that do things like "3 minute skip" (which is a '3' followed by a 'skip').

[vickyg2003]

Thank you Rob.

----------------------------------------

Ken, we need another ICT

I want to see a long keypress of a number

I also want to see #1 learned two times in a row.

I want to see how the toggle is behaving.

[ken chan 397]

Vicky,

I have generated another ICT file for the key press.

#1 and #2 on the file is captured when try to long press number 2 on the remote.

#3 and #4 or #5 and # 6 on the file are the key presses when I try to press number 1 slowly

#7 is the key press of number 1 quickly.

https://www.yousendit.com/download/TEhW ... MnMwTWRVag

[vickyg2003]

Ken, thank you for the files. They confirm what alan said.

I've changed the protocol ID, because I thought maybe there was interference.
https://www.hifi-remote.com/forums/dload ... e_id=11358

This one DVD/VCR code should not repeat.

I think the "Right" = " 4" thing might be due to the Replay Toggle bit being in the wrong place for the Entone.

[vickyg2003]

I think the "Right" = " 4" thing might be due to the Replay Toggle bit being in the wrong place for the Entone.

Whoops, I just tested it, and the protocol doesn't work with the right and left. It is shooting a different code than that which was entered on the simple replay.

I'll have to figure out what the simple replay was supposed to be doing. It appears that OBC's that are larger than 64 aren't correct. Probably a carrying thing.

[vickyg2003]

I've created 3 different versions of the protocol. 3 Bins, give them a try. These take care of the Toggle bit, and repeating.

https://www.hifi-remote.com/forums/dload ... e_id=11358

[vickyg2003]

The "simple" version is an executor that we wrote ourselves that uses a lot less memory than the UEI version. Typically, if you're going to have to install a protocol upgrade anyway, it's better to use this version.

The Simple also has a 5-bit OBC limit. So any OBC > 63 will not work.

[The Robman]

The "simple" version is an executor that we wrote ourselves that uses a lot less memory than the UEI version. Typically, if you're going to have to install a protocol upgrade anyway, it's better to use this version.

The Simple also has a 5-bit OBC limit. So any OBC > 63 will not work.

I don't think that was the intention but, as ReplayTV doesn't use any OBSs > 63, it's possible that either (a) it's a bug and we never caught it or (b) John decided to not program for larger OBCs as we wouldn't need them.

Just FYI, the way the simple version works is, the fixed bits have been doubled beforehand (hence the large # of fixed bytes) so it's just the OBC byte that needs to be doubled in the assembler. However, the doubled OBC byte shares a byte with the last fixed byte, so some of the bits need to be rotated into place.

[The Robman]

I also just noticed that if you select the Official version, RM offers you up the old 2-2 version rather than the newer 6-1 version. To fix this, you need to move the variant=3 Official version before the 1st official version in protocols.ini and you need to add the S3C8 code for it.

Code.S3C80=47 93 61 8B 16 CE 85 40 08 08 00 DE 00 00 00 00 00 CA 0D BF 05 35 01 A8 04 CC EE 08 00 58 04 37 50 06 37 00 03 B6 04 F0 37 52 09 E4 23 1C E4 24 1D 56 2A BF 2C 08 38 09 CF 10 0A 10 09 DF 10 0A 10 09 90 C3 FB 03 B6 0A 03 2A ED E6 10 02 E6 11 06 8D 01 46

[vickyg2003]

I also just noticed that if you select the Official version, RM offers you up the old 2-2 version rather than the newer 6-1 version. To fix this, you need to move the variant=3 Official version before the 1st official version in protocols.ini and you need to add the S3C8 code for it.

Code.S3C80=47 93 61 8B 16 CE 85 40 08 08 00 DE 00 00 00 00 00 CA 0D BF 05 35 01 A8 04 CC EE 08 00 58 04 37 50 06 37 00 03 B6 04 F0 37 52 09 E4 23 1C E4 24 1D 56 2A BF 2C 08 38 09 CF 10 0A 10 09 DF 10 0A 10 09 90 C3 FB 03 B6 0A 03 2A ED E6 10 02 E6 11 06 8D 01 46

Yes the 2-2 version is a much larger protocol than variant 3. I started with variant 3, and then made the toggling and repeating changes required for the Entone Kamai

The "simple" version is an executor that we wrote ourselves that uses a lot less memory than the UEI version. Typically, if you're going to have to install a protocol upgrade anyway, it's better to use this version.

The Simple also has a 5-bit OBC limit. So any OBC > 63 will not work.

I don't think that was the intention but, as ReplayTV doesn't use any OBSs > 63, it's possible that either (a) it's a bug and we never caught it or (b) John decided to not program for larger OBCs as we wouldn't need them.

Just FYI, the way the simple version works is, the fixed bits have been doubled beforehand (hence the large # of fixed bytes) so it's just the OBC byte that needs to be doubled in the assembler. However, the doubled OBC byte shares a byte with the last fixed byte, so some of the bits need to be rotated into place.

I am sure the simple version was done that way to keep the size of the code to a minimum. I tried to follow the simple versions code, but it was too clever for me. Sometimes the tricks that are used to keep code small go totally over my head. There was now HCS08 version to follow, and with that awful S3c8 language, I was lost.

[The Robman]

Bit doubling is tricky to do, which is why UEI used so many bytes to do it. John is very clever at writing small code and it was him that came up with the "simple" code. I'll have to have a look to see if I have any documented PB files for it.