JP1 Remotes

I just tried to fix this LKP issue on TV, but have only gotten odd behavior.

How should I do it if the desired bahavoir is to, on the short side set the TV keyset (DSM?), on the long side, to execute some macro.
jeff

unclemiltie wrote:Update: 11/27/07

I uploaded a new version of the extender with some bug fixes in it as well as a number of touch-ups in the RDF files. This version is NOT shipped with the source and the build environment but as a hex file that can be installed into an existing environment.

This configuration is closer to what will be a "release" version of the extender so I wanted to start getting feedback on installs, etc. The Readme has been updated to reflect what is in the extender as well.

Many, many thanks to Capn' Trips, Binky and Jeff for their help in finding and fixing bugs in this extender and to Vickyg for her suggestions on how to fix some things that were confounding me.

As usual, keep those comments coming and enjoy!

Bill,

I had not noticed this latest update (nor have I had much time for testing) but will try to put it through its paces this weekend. Thanks for all of the hard work.

Go NAVY! Beat ARMY!

Still building my extender file, but in the meantime, here are my initial comments on the readme. (I used MS Word "Track Changes" format, hopefully for clarity. Hope you can read it).

They are mostly typos and grammatical mods, with 1 or 2 "substantive" comments.

GO NAVY! BEAT ARMY!!!!!

I'm going to assume I'm doing something wrong. I have 2 1056-BC1 remotes (a Time Warner backlit one and a Brighthouse non-backlit). Both do the same thing. I ran extinstall on a fresh download from the remote. So far so good. The old cable macros and devices are in the newirfile.ir. I have not added any devices yet. The extender activates and deactivates.

I can't get macros of any sort to work properly. The two macros that were on F1 and OnDemand buttons of the Brighthouse remote seem to lock up the remote (no more device key lights when pushing any buttons) until I remove the batteries. I put the following macro on the "1" key:

X_CBL;2;2;2;X_TV;2;2;2;X_DVD;2;2;2;X_AUD:2;2;2;X_Cancel

I get a long light on the current device key, but no lights bouncing through the different devices (which is what my old 1k JP1 Atlas does). If I'm on the CBL devices when I push 1, the cable box acknowledges only 1 "2." If I'm on a different device when I push 1, the cable box shows nothing received. The very next key pressed after the macro lights the AUD device key no matter what device I was on when I push 1 (it does that with whatever device is last in the macro). The next press after that lights the correct device.

I put my IR file here if anyone would like to take a look at it:
https://www.hifi-remote.com/forums/dload ... le_id=5192

Hopefully I've just done something wrong.

I can confirm Adam's results, on the macro behavior, with a small exception. After getting the bahavior he describes for the "1" macro, trying to execute a different macro results in a locked up remote. Re-uploading+deactivating solves the lock-up.

Any comments on how I should use LKP (or rather what I'm doing wrong)?

Best,
jeff

greenough1 wrote:Any comments on how I should use LKP (or rather what I'm doing wrong)?

I think if you just add:

X_TV;Phantom 1

to the end of your TV device selection macro, then change the short side of the LKP to just X_Cancel or Blank you will have what you want. Phantom 2 isn't necessary since your device selection is already done by the TV macro.

That is how I do it in my other remotes. I can't get that to work on these JP1.3 remotes but I think that's because I can't get macros to work at all.

Hi Adam,
That helped, but I've run into a device selection issue.
On VCR (AUX), I have a default macro defined (T_VCR, M_VCR, P_VCR, V_VCR).

I activate the extender. to select a device other than TV, say CBL, I have to press VCR, then press, CBL twice to get CBL. Then to change back to TV, I have to press VCR, the TV twice to get TV as the active device. On the first press, before the device key becomres active, the key ( no key actually) will blink. It blinks on the second press.

The temporary device selections also don't seem to work. Within a macro, you can only control the current device, i.e. X_ doesn't work.

Best,
jeff

yea, there's something wrong in the temp device selection, I didn't account for the logic in the 9960B01 working only on an "8-device" remote and the 5-device Atlas won't work with this logic.


I'm looking at it and will hopefully have time to figure this out tomorrow

I would add that there is still something weird happening with certain buttons.
If I use any of the PIP family buttons, the remote is tossed back into TV device mode.
If I use the ONDEMAND button in VCR mode, the remote is thrown back into TV or CBL device mode, whichever was more recently used. (this does NOT happen in other device modes)
Finally, whenever the device mode changes in this manner, the remote blinks the OLD device button rather than the NEW, so you don't KNOW that it has changed until the subsequent button press!

Bill, in the effort to update Nils' rdf.zip file, binky has just corrected the Atlas 1055 and 1056 baseline rdf's. In those, he made some changes/corrections in their [ButtonMap], [DigitMap], and [Protocols] sections.

Question: Should the [ButtonMap], [DigitMap], and [Protocols] sections of an rdf and its associated extender rdf be identical? Intuitively, that would seem to be the case, but can an rdf expert confirm this?

If so, then your 3A00 and 3A33 extender rdfs do not currently match the latest 3000 and 3033 rdf's that Binky just uploaded.

I'm happy to update your extender rdf's to reflect this conformity, but want to be sure that is the correct thing to do.

(This is a repeat of a post in the software forum, Bill)

For the JP1.2 Atlas, the answer is yes. But I probably should revisit the Atlas RDF, because when I answered a question for Jeff Greenough, I realize that I might have used allbind on some phantom codes, that probably should be a different kind of bind. I should only be using Allbind on the Hometheater keys like C_TV and X_TV and X_Cancel, where you don't want any kemoves or macros on them. I just didn't want them to be shifted or xshifted. But allbind makes it so you can't assign them a function.

And the genesis of my question to Vicky was why didn't I see phantoms as available bound keys.

In general those sections of the RDF should be identical. There are no new protocols and the button maps for the devices are the same as well.

The button definitions will be different in that the new pseudo-device selection keys will be there as well as the new phantoms and they have to be made consistent with having an Xshift function.

Everything else will be the same. I guess I have to go back and fix up the RDF's to match the latest. Yet another project to work on in my non-existant free time!

I understand that the [Buttons] sections vary, my question was specific to the [ButtonMap] section. I don't see any discrepancies thre, but there are a few in the [Protocols] sections, so I figured I'd ask just for my clarity.

I will update your extender rdf's with binky's [protocols] sections and zip all of that together to update the atlas rdf, map and image zip file for Nils.

Bill,

I've re-zipped all of the Atlas RDF's, correcting your extender RDF's as discussed above.

I only messed with [Protocols] to match Binky's latest updates to the baseline RDFs for those remotes.

I feel your pain about time to work on this stuff, so this is not badgering, but I'm merely asking (1) if you see the issue described a few posts back with changing Device Types when certain buttons (TuneIns and PIPs) are pressed and (2) I presume that you will get to it when you can get to it.

Or do you see no problem there?