Atlas PVR JP 1.2 (1025) extender beta testing comments

[Capn Trips]

Picking up on our discussion HERE, Vickyg has generated an extender for the Atlas 5-device PVR (URC-1055, JP 1.2 version with signature 10251025).

I have done some preliminary testing (with a slightly modified rdf) and my results (including the rdf and IR file) are uploaded here.

Bottom line: It works - mostly. Exceptions:
(1) Pause doesn't work (despite using 2-byte Pause commands)
(2) "Temporary" device selection isn't really temporary as it seems to remain in effect even after completion of a Macro.

Note: Anybody looking to open and potentially test my IR file included in the zip, be advised that my Atlas JP 1.2 remote has a malfunctioning Power button, so the Raw Data in the IR file has a manual kludge to set up the TV:1 button as the extender activation key instead of the more traditional (and built-in to the extender) TV:Power key.

[Capn Trips]

And HERE are the comments on the readme. Enjoy!

[Capn Trips]

An additional observation after a few hours of using the extended remote. There appears to be a latency period of some duration that was not noticeable in the unextended remote. Specifically, there is a period of time after releasing a button during which a subsequent button press will not be recognised/executed. The example is when one wants to execute a few quick multiple keypresses, like tweaking volume up a few increments, or jumping ahead three or four channels. Unextended, I would just press-press-press-press and each "press" would execute. In the extended remote every other "press" will do nothing, unless I really increase the wait between presses. I can't measure this, but it approaches .5-1 secs in duration. Is there a tweak to the extender that can reduce this "latency period"?

[vickyg2003]

Pause is fixed, and automatic x_device cancel has been added to the remote. I've got to go back and fix this on the 8820 as well.

I've tried to address the sluggishness, but its still not fast. I'm going to have to do more research on this. I have this problem on both of my extenders. I don't see it because I'm slow at the buttons, but I tried the rapid press of one button and now I see what you and underquark are talking about. I think this is going to take quite a while to find the source of this.

The RDF is different because the settings got moved in the extender.

[Capn Trips]

You returned the [MultiMacros] section? I'vever understood how to use this capability from IR.

Typos in the ReadMe:

INSTALLATION AND ACTIVATION

You can use the base IR file. . Open the included IR file <Atlas5DeviceDayPvrExtender.ir> and simply commence adding your device upgrades and building your Keymoves, Macros and Special Protocol Functions. If you have an existing UNextended setup, then YOU may want to use Extinstall.exe to convert your existing IR file to an Extended one.

[...]
To activate the extender press TV>Power, the LED will flash 4 times to indicate that the extender is started

Do I have to rebuild all of my RM upgrades since the rdf is changed?
Do I have to rebuild my IR setup? ... or can I just open my old IR file using the new rdf?

[vickyg2003]

Whoops, I didn't mean to allow the multimacro stuff in. I must have picked up a stray RDF. I'll remove that.

If your upgrades are in the unextended remote they'll carry in. You'll need to rebuild anything you added in the extender (special keymoves and such).

Could you craft a passage for the readme that says something about

a) the importance of saving a copy of your remote before you start with the extender

b) that you shouldn't use the extender on cable company property.

c) that if you use the base IR you'll over write cable company specific hidden upgrades.

[Capn Trips]

Question about the hidden upgrades. If one initially does a download of the remote and saves the IR file, does it have the hidden upgrade data in there somewhere such that re-uploading that file unaltered would restore that initial condition?

Or can these "hidden upgrade" data be preserved with a RAW (no RDF available) dump into IR which is then saved?

Or is it lost forever as soon as you upload ANYTHING from IR?

The various Atlases that I have received have always had several CBL device upgrades in the upgrade area already, they were not "hidden" in any way. These I know for certain can be restored from a saved image.

[vickyg2003]

Question about the hidden upgrades. If one initially does a download of the remote and saves the IR file, does it have the hidden upgrade data in there somewhere such that re-uploading that file unaltered would restore that initial condition?

Or can these "hidden upgrade" data be preserved with a RAW (no RDF available) dump into IR which is then saved?

Or is it lost forever as soon as you upload ANYTHING from IR?

Yes it can be seen. You already saw it. When you did a manufacturer's reset (981), it wiped out the cable company specific upgrades and put in a blank upgrade,
F200: F2 04 F2 00 00 00

Unfortuenately, the 981 erases the company specific data, but it IS visible in the raw data.

That's why its important to always start by downloading the remote.

[Capn Trips]

Re-tested. Pause is fixed. X-dev, auto-cancelling properly. All works good. Other comments follow.

(1) RDF Changes:

[Settings]
replaced
Turn OffVPT=$014.2.1.1.0 (Off;On)
with
VPT Status=$014.2.1.1.0 (Off;On)

[Buttons]
replaced
C_AUX=$79:AllBind,T_AUX,V_AUX,P_AUX,O_AUX,X_AUD
with
C_AUX=$79:AllBind,T_AUX,V_AUX,P_AUX,O_AUX,X_AUX

deleted [MultiMacros] section

(2) ReadMe continues to refer to two extra device indexes, but I don't see any sign of them in IR nor the RDF.

Could you craft a passage for the readme that says something about

a) the importance of saving a copy of your remote before you start with the extender

b) that you shouldn't use the extender on cable company property.

c) that if you use the base IR you'll over write cable company specific hidden upgrades.

I don't really see this caveat as an extender-specific issue, as overwriting the memory is overwriting the memory, isn't it?

Usually, if you get this remote from your cable provider, it is likely to have preloaded several device upgrades. Additionally, this remote has a "hidden" upgrade section where the provider may save additional upgrades/data. The first time you upload an IR image to the remote, you are likely to overwrite these data.

If you believe that for any reason you may need to restore the remote to its "cable-provider-supplied" configuration (like you don't OWN it, but are just LEASING it), you should always DOWNLOAD the preloaded remote IR image before you do ANYTHING to reprogram the remote, and save that IR file for later restoration of its initial programming if necessary.

(Heck, it's good idea ANYWAYs, to save the initial image just to allow you to get back to a common starting point if all of your programming really screws it up!)

[vickyg2003]

I like the readme add in.

I've been working on the speed issue, and have made great improvments. I hope to have the changes done tomorrow night.


As far as the VPT, using that instead of the V_ settings may give you some strange results.

[Capn Trips]

I like the readme add in.

I've been working on the speed issue, and have made great improvments. I hope to have the changes done tomorrow night.


As far as the VPT, using that instead of the V_ settings may give you some strange results.

How so? If I NEVER, EVER, EVER use a V_DEV command, what could screw up my VPT assignment?

(I also notice that you are ignoring my question about extra devices. 8) I presume this means that mention of extra devices is just a holdover from the readme's previous incarnation for a different remote and does not apply here?)

Also I would point out that I have not tested, even a bit, the Device Multiplexer, mostly out of laziness, since I don't really have enough devices here to make it a useful feature for me. But all of the other Special Protocols seem to work just fine.

[unclemiltie]

rE: VPT

in the other extenders, I haven't looked at this one, there is no such thing as VPT. All VPT (and any other punch through) is done via the psuedo-device selection commands (V_xxx, etc)

Given that the extender probably never even looks at the VPT enable or VPT device bits (and maybe even re-used that info in the E2) I doubt that you can say that VPT does anything reliably.

[Capn Trips]

From the Radio Shack 15- 1994 Extender 5 Read Me file:

If you want full VPT (same V_ selection in all device selection macros) you can save some macro memory by omitting all the V_commands. You can set the initial V device using IR. That remains as the V device as long as no V_commands specify a different V_ device.

From the Radio Shack 15-2116 Ext3 ReadMe:

If you want full VPT (same VOL selection in all device selection macros) you can save some macro memory by omitting all the SET_VOL_KEYS commands. You can set the initial VOL device using IR. That remains as the VOL device as long as no SET_VOL_KEYS commands specify a different VOL device.

From the URC 6131 2K Ext ReadMe:

If you want full VPT (same V_ selection in all device selection macros) you can save some macro memory by omitting all the V_ commands. You can set the initial V device using IR. That remains as the V device as long as no V_commands specify a different V_ device.

There are similar words in EVERY extender ReadMe. This concept has been around forever in extenders, has it not? Perhaps there is a different way to "set the initial VOL device using IR", but I see nothing aside from making the VPT setting on the General Tab in IR. How else can that initial Vol setting in IR be made?

EDIT: Heck, I don't know how or why it works, but it has always worked for me, in ALL of these extenders referenced above, and it's working so far in this one, as well. So operating on the theory that "If it works, don't fix it!" I'm happy.

[unclemiltie]

Aha!

Some of the extenders have a method to allow you to set the initial V (and other) device when the extender loads. However, this is not just setting the VPT device in as you would on a non-extended remote. (in fact you have me thinking about the 9960/6960 extender in that I shoudl have re-used the VPT device setting in the EEPROM as the initial V_ device to avoid confusion like this)


Vicky, did you put the ability to set the initial devices in the extender? (they would either be saved somewhere along with the code and the RDF to match or they'd be re-used registers that are read by default at power up)



-bill

[Capn Trips]

Ahhh... I see the distinction you are making.

Setting an "Initial V_ device" is NOT the same thing as setting VPT (which can be on or off for different devices). Interestingly, this "initial V_device" setting is not clearly annotated as such in those other extenders I refer to.

The 1994 clearly indicates in IR that that (initial setting) is what the setting is. In the 2116 and 8910 extenders, it appears to be "masked" as the "My System" and "Home Theater" settings, respectively.

I'm not sure what "Turn OffVPT" is SUPPOSED to do, but I sort of assumed since it was present, that it allowed me to assign an initial V_ device, used it that way, and it has worked that way - perhaps unintentionally.

I will continue monitoring for "strange results" - but as of right now, I never execute a V_<DEV> command at any time after activating the extender and it has started and remained with V_ assigned to the TV device every time, all the time.

Like I said - if it works, don't fix it!

P.S. I can, of course, conduct a simple experiment and change that VPT setting to a different device and see what it does. In fact, I may do that this evening when I get home from work! (Since I am making no progress with my Atlas OCAP remote )