mr_d_p_gumby wrote:Have you tried creating the keymoves on the remote itself? It might also help to do that, and post a download of the results.
Yes. Just standard 3-byte type keymoves where you move key to key. I don't know how to get the discretes EFCs manually keyed in with the setup button.
IR is picking up those correctly on the download. My test was mapping the volume/mute keys to my devices that were not working with VPT. That was until I figured out what was going on with VPT (posted previously).
gfb107 wrote:You'll have to post your IR & RMDU files so we can see exactly what you did.
Use the CD/1777 device and keys +100 and enter. I also have those mapped on phantom 1 & 2 and M1 & M2 (discrete on and off). This is for my Dish network 508 on remote address 7. When you press the +100 and enter(built in upgrade), it will send the correct signals. M1 and M2 (keymoves), no go.
jetskier wrote:I don't know how to get the discretes EFCs manually keyed in with the setup button.
Both RM & KM produce keymoves using the format that would be used when you assign an EFC on the remote using a keymove. What I'm after here is to see if maybe we have not fully understood how the JP1.2 remotes store such keymoves. If we have it wrong, then the remote isn't going to produce the correct functions.
I still think it would be helpful if you could create a couple of keymoves on the remote and post a download of that. If this remote works the same as older models, the keymove sequence is the same as normal, except instead of pressing the "source" button, you press SETUP and the (5-digit) EFC, then the "destination" button.
Here's the fix for values less than 1000. I knew I had some useful contribution here other than complaining.
To convert 5-digit EFCs that are less than 01000 (old 3-digit EFCs), the first byte is the Hex of the MSB of the EFC (mod 256) and the second byte is simply the Hex of the EFC (mod 256).
gfb107 wrote:Maybe it's because it is so early in the morning. But I don't see how your explanation matches the examples.
When the EFC5 is 00001, the equivalent hex is $0001, for which the MSB is $00 and the LSB is $01. How does this get converted to $66 01?
Go to IR, Click EFC Calculator under tools. Under EFC, enter 1. IN the MSB box it equals 102 or $66. This is what is working when I force these hex values into the raw data of IR for the 3 digit EFCs. In the keymove tab, the 2 byte hex values don't match the raw data. It may be the conversion back from Hex to EFC5 that is broke. I'm just speculating.
Ahh, so these JP1.2 remotes don't store EFC5 keymoves the way we thought they do.
We thought they stored the EFC5 directly, as a 2-byte value. (00001 would be 00 01, 01000 would be 03 E8).
They actually store the 2-byte hex command equivalent to the EFC5. It doesn't matter if the EFC5 is greater than or less than 1000.
gfb107 wrote:They actually store the 2-byte hex command equivalent to the EFC5. It doesn't matter if the EFC5 is greater than or less than 1000.
It kinda matters, the formula I came up with doesn't apply beyond 999. Really its 0-255 since when you go backwords that's the value it will return. I have an "if" statement in my spreadsheet. What ever you had for the EFC5 above 1000 was working. All of my upgrades all use the 3-digit EFCs so I haven't had to work above that.
Where Expected is simply the EFC5 represented in hex, and IR's hex is the Hex command produced by IR"s EFC calculator. It seems that we've completely misunderstood the keymove format.
gfb107 wrote:Oops, I was using your EFC5 spreadsheet when I tought I was using Rob's EFC5 spreadsheet.
My spreadsheet is a modified version of Rob's.
gfb107 wrote:It seems that we've completely misunderstood the keymove format.
That's why we are in beta, to figure this all out. I guess the easiest way for IR's Hex command to display correctly for values < 1000, We have to compare the inverse of the MSB in the first byte to the second byte. If they equal, then we have a EFC<1000
RM v1.65 should handle this correctly now (both in the "Classic RM" and "RM-IR" modes), althought you'll have to take out the AdvCodeFormat=EFC line in the RDF for the URC-10820
gfb107 wrote:RM v1.65 should handle this correctly now (both in the "Classic RM" and "RM-IR" modes), althought you'll have to take out the AdvCodeFormat=EFC line in the RDF for the URC-10820
That worked. I saw this after replying to your RM1.65 announcement.
jetskier wrote:With the exception of fast DSMs, it's just like my 8810w's!!!
I'm a little bit confused by that last comment. Did you mean to say "With the exception of fast MACROs..."? I can't see why DSMs would necessarily be treated differently than other keying sequences like LKP's or regular macros.
Remotes: OFA XSight Touch, AR XSight Touch TVs: LG 65" Smart LED TV; Samsung QN850BF Series - 8K UHD Neo QLED LCD TV RCVR: Onkyo TX-SR875; Integra DTR 40.3 DVD/VCR: Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A3 (HD-DVD), Panasonic AG-W1 (Multi-system VCR); Laserdisc: Pioneer CLD-D704. Amazon Firestick tape deck: Pioneer CT 1380WR (double cassette deck) (But I still have to get up for my beer)
jetskier wrote:With the exception of fast DSMs, it's just like my 8810w's!!!
I'm a little bit confused by that last comment. Did you mean to say "With the exception of fast MACROs..."? I can't see why DSMs would necessarily be treated differently than other keying sequences like LKP's or regular macros.
Both regular macros and Device specific macros. They are too slow in execution. Holding the device buttons to execute sucks as well. The 8810w extender executes macros significantly faster than the "stock" remote. I'll have to wait for the extender programmers to do their work before my wish can come true. I don't have a clue how to find the place in the remote to redirect the macro execution like the extenders do.
