Wrap-up thoughts on the current software and Atlas remote

[Capn Trips]

Well, I have successfully navigated the various challenges that I have been asking for help with in recent days and my Atlas 5-device DVR-PVR (w/settings button, JP1 sig SA_7SA_7) is actually set up and is, imho, the easiest and most intuitive to operate of the many JP1 remotes I've set up in the past/ Originally I was a 1994 fan, then 2117, and 8910 - all of which I still like very much. But I just really like the layout and arrangement of the keys in the Atlas remote. (I guess the big difference is the transport keys above the numeric keys)

With the extender, and IR's recently-added capability to overflow upgrades into Keymove/Macro memory (when was THAT added? I didn't even know, but that is EXTREMELY cool!) I've got it set up perfectly for my current modest system.

I'm using ToadTog, LKP, DSM, and have added two device upgrades, and am using 2 other built-in setup codes. I have 73 bytes left in total, so I suppose I could fit one more medium sized device upgrade.

Frustrations:
-KM and RM seem to be more divergent than in a long time.
--RM cannot handle the extender SA_71Kx1 rdf;
--RM incorrectly handles keymoves for 2-byte functions for this remote;
--KM does not (yet) support the JP 1.2/1.3 rdfs for this remote;
--KM does not include the RC6-M-20n protocol.
--There is STILL inconsistency in the handling of the related SharpDVD and Kaseikyo protocols (PIDs 00F8, 01C9 and 0171) such that converting decoded data to an efficient upgrade is not at all clear from any of the help files. Built-in Setup code DVD/0630 is most definitley present in this remote, and this is reflected in devices.xls, yet in RM, when building an upgrade, a protocol upgrade is called for. Does this mean that the rdf requires some tweaking? (Actually, devices.xls indicates that there are TWO versions of 00F8 in this remote. Is this possible? Regardless, RM doesn't generate the right answer.)

-RMIR will not open any IR files for the Atlas remote. It just imports a blank image.

-The EEPROM is just too small. When I get back to the US and set up my full HT, there is no way I'll be able to set up this remote to work it for me.

Consider this a plea for some smart person to develop extenders for the JP1.2/JP1.3 versions of the Atlas 5-device DVR-PVR (day) remotes, which do not suffer from such memory limitations.

[The Robman]

Does your remote have a 1k EEPROM in it? If so, you could try replacing it with a 2k chip.

[Capn Trips]

Yes, it's the factory 1K EEPROM and I'm not a DIY solderer.

Plus, there is currently no extender for a 2K variant (although bcardellini has been patiently awaiting one for over 6 months)

[Paolo]

can you do me a favour? when in the Cable or any other mode, when you press the volume up and down function, does your remote send the volume command to the TV mode, then switch to the cable mode hence the tv light blinking durring the volume button depression then the cable light blinking immediately after? this is the problem im haivng, the rogers default programming somehow can not be overridden?

[mr_d_p_gumby]

Well, I have successfully navigated the various challenges that I have been asking for help with in recent days and my Atlas 5-device DVR-PVR (w/settings button, JP1 sig SA_7SA_7) is actually set up and is, imho, the easiest and most intuitive to operate of the many JP1 remotes I've set up in the past/ Originally I was a 1994 fan, then 2117, and 8910 - all of which I still like very much. But I just really like the layout and arrangement of the keys in the Atlas remote. (I guess the big difference is the transport keys above the numeric keys)

Congrats! I tend to agree with you that the key layout on the Atlas works very well. I've been using a couple of them for a long time now. (When you get back to the states, you'll see just how essential the A,B,C buttons are for your cable box!) Unfotunately for me, the WAF is inadequate, since she demands a remote with backlit keys.

--KM does not (yet) support the JP 1.2/1.3 rdfs for this remote;
--KM does not include the RC6-M-20n protocol.

OK, now you are asking for too much! (Soon... patience Cap'n...)

--There is STILL inconsistency in the handling of the related SharpDVD and Kaseikyo protocols (PIDs 00F8, 01C9 and 0171) such that converting decoded data to an efficient upgrade is not at all clear from any of the help files. Built-in Setup code DVD/0630 is most definitley present in this remote, and this is reflected in devices.xls, yet in RM, when building an upgrade, a protocol upgrade is called for. Does this mean that the rdf requires some tweaking? (Actually, devices.xls indicates that there are TWO versions of 00F8 in this remote. Is this possible? Regardless, RM doesn't generate the right answer.)

No, there can only be one version in the remote, and in this case it is variant 3 of the 00F8 protocol. I don't know why RM requires the protocol update (KM doesn't). The RDF clearly shows 00F8:3 for this protocol. I have run into this before in RM in other cases where it gives a protocol update and should not. The problem lies in protocols.ini, and how priorities of various versions of the protocol are established in various circumstances.

[Capn Trips]

can you do me a favour? when in the Cable or any other mode, when you press the volume up and down function, does your remote send the volume command to the TV mode, then switch to the cable mode hence the tv light blinking durring the volume button depression then the cable light blinking immediately after? this is the problem im haivng, the rogers default programming somehow can not be overridden?

Paolo, I answered in your other thread, but the behaviour WAS as you described when I got the remote, and NOW, after overwriting the EEPROM image, it is gone and I cannot restore it (:lol:)

I tried 980 and 981 resets, and uploading the originally downloaded default IR image and it does NOT come back.

[Capn Trips]

--KM does not (yet) support the JP 1.2/1.3 rdfs for this remote;
--KM does not include the RC6-M-20n protocol.

OK, now you are asking for too much! (Soon... patience Cap'n...)

I am indeed patient, recognising how much all of you experts are paid for your services here. No problem - just a reminder that there will be at least one appreciative customer

--There is STILL inconsistency in the handling of the related SharpDVD and Kaseikyo protocols (PIDs 00F8, 01C9 and 0171) such that converting decoded data to an efficient upgrade is not at all clear from any of the help files. Built-in Setup code DVD/0630 is most definitley present in this remote, and this is reflected in devices.xls, yet in RM, when building an upgrade, a protocol upgrade is called for. Does this mean that the rdf requires some tweaking? (Actually, devices.xls indicates that there are TWO versions of 00F8 in this remote. Is this possible? Regardless, RM doesn't generate the right answer.)

No, there can only be one version in the remote, and in this case it is variant 3 of the 00F8 protocol. I don't know why RM requires the protocol update (KM doesn't). The RDF clearly shows 00F8:3 for this protocol. I have run into this before in RM in other cases where it gives a protocol update and should not. The problem lies in protocols.ini, and how priorities of various versions of the protocol are established in various circumstances.

I hate to be argumentative, but these are the Setup codes in the Atlas 5-device PVR/DVR remote that use 00F8 (according to devices.xls):

Code: Select all

TV	    TV		0683	00F8	248	Sharp DVD (ver 3)	  0	132	20.99	03	03 D7 39 FF DE
TV	    TV		0751	00F8	248	Sharp DVD (ver 3)	  0	134	20.99	03	03 D7 39 FF 9E
Video	DVD		0630	00F8	248	Sharp DVD (ver 0)	143	48	170.90	00	00 AA A5 0E F3

You write that 00F8 variant 3 is the only one in the remote, yet variant 0 MUST be there, since I'm using Setup Code DVD/0630 on my Sharp DVD player, which from previous experience I KNOW corresponds to the 143:48;170.90 version.

So how do we reflect this in the rdf so that RM will use it when appropriate?

[Mark Pierson]

You write that 00F8 variant 3 is the only one in the remote, yet variant 0 MUST be there, since I'm using Setup Code DVD/0630 on my Sharp DVD player, which from previous experience I KNOW corresponds to the 143:48;170.90 version.

AFAIK, there can only be one version of any given named (PID) protocol in any remote since the info is stored in the remote as nothing more than a table of data.

In this situation, it's quite likely that variant 3 is a newer version (compared to variant 0) that is backward compatible so that setup codes like DVD/0630 are still useable.

As for the specific RM problem with 00F8, I think it has to do with the fact that there is NOT a variant 3 named "Sharp DVD" in protocols.ini. The only 00F8:3 is named "Fujitsu".

[mr_d_p_gumby]

I hate to be argumentative, but these are the Setup codes in the Atlas 5-device PVR/DVR remote that use 00F8 (according to devices.xls):

Code: Select all

TV	    TV		0683	00F8	248	Sharp DVD (ver 3)	  0	132	20.99	03	03 D7 39 FF DE
TV	    TV		0751	00F8	248	Sharp DVD (ver 3)	  0	134	20.99	03	03 D7 39 FF 9E
Video	DVD		0630	00F8	248	Sharp DVD (ver 0)	143	48	170.90	00	00 AA A5 0E F3

You write that 00F8 variant 3 is the only one in the remote, yet variant 0 MUST be there, since I'm using Setup Code DVD/0630 on my Sharp DVD player, which from previous experience I KNOW corresponds to the 143:48;170.90 version.

I don't think the (ver x) in your list corresponds to the variant of the protocol executor in the remote. Below is a list of DVD/0630 setup codes in various remotes that I compiled while working on the 00F8 support in KM:

Code: Select all

remote                                 dev  setup  pid     fixed data      ID=oem1/2  oem1 oem2 Dev  Sub
Atlas 4-Device               02-VCR    2    0630   0171    00 AA A5 0E F3  SharpDVD   170  90   143  48
Atlas DVR                    02-VCR    1    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
Atlas XL URC-1047            02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
Comcast URC-1058             02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
Comcast URC-1068             02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
DirecTV v1                   02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
DirecTV v2                   02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
Millennium 4 BJ8             02-VCR    2    0630   0171    00 AA A5 0E F3  SharpDVD   170  90   143  48
RCU810                       02-VCR    8    0630   00F8:1  00 AA A5 0E F3  SharpDVD   170  90   143  48
REM400 b01                   02-VCR    2    0630   0171    00 AA A5 0E F3  SharpDVD   170  90   143  48
Scientific-Atlanta AT2000    02-VCR    2    0630   00F8:1  00 AA A5 0E F3  SharpDVD   170  90   143  48
Toshiba CT-90047             02-VCR    2    0630   00F8:1  00 AA A5 0E F3  SharpDVD   170  90   143  48
15-2103                      02-VCR    2    0630   00F8:2  00 AA A5 0E F3  SharpDVD   170  90   143  48
15-2104                      02-VCR    2    0630   00F8:2  00 AA A5 0E F3  SharpDVD   170  90   143  48
15-2107                      02-VCR    2    0630   00F8:2  00 AA A5 0E F3  SharpDVD   170  90   143  48
15-2117 / 15-2116            02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
15-2133 (RS Kameleon)        02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
15-2138 (RS Kameleon 8-in-1) 02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
15-2144 (RS Kameleon 4-in-1) 03-Audio  3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-3440                     02-VCR    1    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-4080                     03-Audio  3    0630   00F8:1  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-6131 PVR                 02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-6690                     02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-6960 (Kameleon 6-in-1)   02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-7555                     02-VCR    1    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-7780                     02-VCR    4    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-8060 (Euro Kameleon)     02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-8203 (Euro Kameleon)     00-Cable  2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-8206 (Euro Kameleon)     02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-8820                     02-VCR    2    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-9910 / 8910 / UEI HTPro  02-VCR    2    0630   0171    00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-9960 (OFA Kameleon)      02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48
URC-9960B01 (OFA Kameleon)   02-VCR    3    0630   00F8:3  00 AA A5 0E F3  SharpDVD   170  90   143  48

As you can see, all three variants of the 00F8 executor are used by DVD/0630, and some remotes even use the 0171 executor.

So how do we reflect this in the rdf so that RM will use it when appropriate?

You can't. The remote has only one variant of the executor in ROM. The RDF cannot specify more than one executor variant. The fact that RM is choosing not to use the built in 00F8 protocol executor is due to the way protocols.ini is set up, not the RDF.

[Capn Trips]

So how do we reflect this in the rdf so that RM will use it when appropriate?

You can't. The remote has only one variant of the executor in ROM. The RDF cannot specify more than one executor variant. The fact that RM is choosing not to use the built in 00F8 protocol executor is due to the way protocols.ini is set up, not the RDF.

OK, then.

I'm really a simple creature. Who has to correct protocols.ini and how?

I just think that it is reasonable that when one builds an upgrade that calls for a protocol that is resident in the remote, the tools should recognize this and use it.

I would point out that I have been highlighting almost the same issue with the 8910 and PID 0171 about once every 6 months for the past year and a half.

[mr_d_p_gumby]

As for the specific RM problem with 00F8, I think it has to do with the fact that there is NOT a variant 3 named "Sharp DVD" in protocols.ini. The only 00F8:3 is named "Fujitsu".

This is one really complicated situation, since both "Sharp DVD" and "Fujitsu" are the same protocol. The OEM1 & OEM2 values in the fixed data determine which is which. Oh yeah, and some remotes use 0171 instead of 00F8.

[mr_d_p_gumby]

I'm really a simple creature. Who has to correct protocols.ini and how?

I think either Greg or John will need to look at this. Rob also had some specific requirements for the way these protocols were to be handled that require some convoluted logic.

I just think that it is reasonable that when one builds an upgrade that calls for a protocol that is resident in the remote, the tools should recognize this and use it.

I agree.

I would point out that I have been highlighting almost the same issue with the 8910 and PID 0171 about once every 6 months for the past year and a half.

Have you looked at the way KM handles these protocols lately? I made a lot of changes in respnse to the issues you raised.

[Mark Pierson]

This is one really complicated situation

Yup...

The OEM1 & OEM2 values in the fixed data determine which is which.

Those values don't "fit" the parameters for the Fujitsu version. The pcode presented by RM when selecting Sharp DVD on the Atlas PVR is the non-variant version of Sharp DVD 00F8 as listed in protocols.ini. I still think it's as simple as protocols.ini needing a properly formatted entry for Sharp DVD 00F8:3.

[The Robman]

I just think that it is reasonable that when one builds an upgrade that calls for a protocol that is resident in the remote, the tools should recognize this and use it.

You won't find any argument from any of us, but you have to remember that we're working with UEI's executors here and they're not making it easy for us. Just FYI, UEI takes a completely different attitude to situations like this. Whenever they upgrade a protocol executor, they "delete" it from their records for all the old remotes, so whenever they add an upgrade for a device that uses that protocol, they ALWAYS include a protocol upgrade (even in the ROM version is good enough).

Case in point, the old version of the $007E executor used 1-byte variable data because there was logic that handled when to use the 1-part or 1-part signals (for Pioneer DVDs) but then Pioneer started breaking their own rules, so UEI made it a 2-byte executor and removed the logic. Somewhere along the line, I sent in some remotes to get upgrades (pre-JP1) and the remotes included a URC-9800 which had a perfectly good 1-byte working version of $007E, but when they added the DVD/0571 code, they also added the 2-byte version of the executor which meant I couldn't use EFC keymoves any more!

Back to this protocol, UEI has used two different executors to create this protocol, and there are several different versions of each executor. Futhermore, we have different names for the executor when it's in different modes. This is about as complicated a situation as you can possibly get regarding protocols and executors in JP1. So try as we might, coming up with the perfect solution (if it's even possible) is going to be difficult.

Maybe, as this is something that's obviously important to you, you should take this opportunity to learn all about the different versions (starting with the chart that Mike listed) and then learn all about protocols.ini and see if you can come up with a solution.

[Capn Trips]

You're point, Rob, is valid. For whatever reason - time, inclination, whatever, I don't expect that I will become fluent enough in dissecting this to offer a fix - and I recognize that that is a disingenuous answer. I really appreciate the fact that I am pretty much a parasite, using these great tools and contributing little to their development, but I don't foresee that changing.

I do try to offer what seem to me reasonable suggestions or alternatives, from time to time, and seeing as how this is an isolated case that affects a very few remote/PID combinations, I would suggest (and have proposed text in the past) that the protocol help for those affected protocols be updated with clarifying notes.

Yet when I call up one of those PIDs in KM or RM, the Protocol help does not highlight any of these issues. It seems to me that SUCH a change ought not be too hard to make.

I would point out that I have been highlighting almost the same issue with the 8910 and PID 0171 about once every 6 months for the past year and a half.

Have you looked at the way KM handles these protocols lately? I made a lot of changes in respnse to the issues you raised.

Yes, and it's pretty good, having a Sharp DVD (old) and not (old) choices. However, the Protocol Help provides no information to the user that would help him/her choose which one works (choosing EITHER yields no protocol upgrade for the 8910).

Guys, I'm not trying to be contrary, and have routinely admitted that I'm not sufficiently versed in these matters to intelligently comment on technical fixes. If (as it seems) I'm the only member of the forum with the unique set of circumstances (remotes, equipment, memory space limitations due to my crazy IR setup) whom this issue affects, I'll drop it, since I have my workaraounds that are adequate.