JP1 Remotes

unclemiltie wrote:The data at $600 (in IR this is $000 since it has an offset of $600) is used as follows:

$600 - 8 bytes, signature
$609 - 2 bytes, checksum
$60B - 2 bytes, cable setup code
$60D - 2 bytes, TV setup code
$60F - 2 bytes, DVD setup code
$611- 2 bytes, AUD setup code
$613 - 2 bytes, AUX setup code
$615 -$625 a bunch of setup info including VPT config, VPT device, and then a bunch of bytes that are related to multi-macro
$626 - start of the extender

I'll be adding this to my notes. Thanks for the details.

unclemiltie wrote:I've found that the data in $615-$625 can make the remote behave weird. You'll see this data in the extender source after the default device setup codes are entered, there is a line that says something like

if remote eq 3033
dw xx
dw xx
dw xx
endif

if you copy the data from this range after a 981 reset into this range in the extender or into the raw data and tell me if it works that would be helpful.

As I noted above I have a diff at $625. I'll change that as per you above and see what it does. (I'm glad you're back to the forum so soon Unclemiltie )

What do you think about my half-baked hypothesis that I'm blowing out over some important stuff when adding 4 upgrades and 1 protocol?

A quick check that the extender build correctly is to look at the keymove tab. If you see some odd keymoves there after the Merge that were'nt there before, then your build is bogus.

Best,
jeff

OK, my Sunflower (Silver 1056 OCAP) remote, brand-new out of the box raw download had the following first four lines:

0600: 33 30 33 33 33 30 33 33 88 77 07 55 10 2F 21 F7
0610: 33 FF 20 3C 00 0C 01 FF 11 11 11 0F 0F 00 00 00
0620: 00 00 00 00 00 00 34 9F 04 09 1E 1B 1F 35 9F 04
0630: 09 1E 16 1F 36 9F 02 09 26 FF FF FF FF FF FF FF

and the Time Warner black non-backlit, non-learner had:

0600: 33 30 33 33 33 30 33 33 BE 41 05 60 10 2F 21 F7
0610: 33 FF 20 3C 01 0C 01 FF 11 11 11 0F 0F 00 00 00
0620: 00 00 00 00 00 00 34 9F 04 09 1E 1E 1E 35 9F 03
0630: 09 15 2D 36 9F 04 09 1D 1F 1F FF FF FF FF FF FF

and the Time Warner black, backlit learner had:

0600: 33 30 33 33 33 30 33 33 89 76 07 55 10 2F 21 F7
0610: 33 FF 20 3C 01 0C 01 FF 11 11 11 0F 0F 00 00 00
0620: 00 00 00 00 00 00 34 9F 04 09 1F 17 1F 35 9F 04
0630: 09 15 1F 15 36 9F 04 09 1F 16 1F FF FF FF FF FF

So what does any of this mean to me?
0615-0625 is identical in all three, as is 626.You describe what a lot of those bytes do, but what I noticed is that byte 0608 is not described, nor is it consistent between the three flavors of the remote. Could byte 0608 be our problem child?

Do I have to paste that data in manually somewhere? Before or after running extinstall?

0608 and 0609 form a checksum of the Setup Code/Settings Area. If you add the two bytes together, it is FFh.

OK, but that differs from what Bill wrote:

unclemiltie wrote:The data at $600 (in IR this is $000 since it has an offset of $600) is used as follows:

$600 - 8 bytes, signature
$609 - 2 bytes, checksum
$60B - 2 bytes, cable setup code
$60D - 2 bytes, TV setup code
$60F - 2 bytes, DVD setup code
$611- 2 bytes, AUD setup code
$613 - 2 bytes, AUX setup code
$615 -$625 a bunch of setup info including VPT config, VPT device, and then a bunch of bytes that are related to multi-macro
$626 - start of the extender

So are these descriptions all off by one byte?

I missed by one byte. The first 8 bytes are the signature, the checksum comes directly after that then two bytes each for CBL/TV/DVD/AUD/AUX setup codes.

After that the VPT setup stuff and then the stuff that I don't understand.

An upturn in my fortunes. Here's what I did:
(1) 981 reset;
(2) Uploaded the ORIGINAL factory downloaded IR image back to the remote, with the Time Warner macros and upgrades;
(3) Ran extinstall;
(4) It worked! (Activated and deactivated);
(5) incrementally:
(a) deleted the macros;
(b) deleted the device upgrades;
(c) added MY desired device upgrades.

After each change, I uploaded to the remote and tested activation, a random selection of buttons and deactivation.

It has been working EVERY TIME!

Have yet to build all of my desired Device Selection macros, and Special Protocol Functions (REALLY NEED THAT LKP working, Bill), but I am optimistic.

A (very) few observations at this point:
(1) You still have to fix the rdf to include the xshift=$40 and to insert an underscore between the (black) and (silver) in the file name;
(2) other rdf issues I outlined previously (ButtonF1 and "DeActivate" appear as buttons on RMs layout tab, whilst DiscreteOn and DiscreteOff do not)
(3) An operational anomaly: After activating the extender, the first time I use certain buttons (A-D, F1, F2, and OnDemand...there may be others) in TV device mode (selected using the default device selection macro from the extender), the remote switches to CBL device mode, but the SECOND time I press TV, all subsequent button presses use the TV mode until I actively switch devices. I've checked that there is no macro anywhere that could unintentionally (or INtentionally) call a "CBL" function, so it's a bit of a mystery.

I still don't like that one cannot just go to File>New and build oneself an extender IR file, but must start from the default profile for the remote. One would hope that we can identify what magic entries have been preventing activation in the former circumstance and build in corrections to the process to overcome that.

Capn motivated me to try his strategy tonight. I rebuilt the extender from using the factory installed image.
I deleted the default devices and began adding upgrade (and protocols when needed). I tested activate/deactivate and basic functionality after each load. each step was cummulative.
I added:
1) oppo 970HD upgrade from the file section - worked
2) moto 6412 upgrade from file section - worked
3) my tweaked version of the onkyo 575x upgrade + protocol - worked.
4) changed the device TV button to 0150 for my mits tv - worked.

So I've confirmed Capn's most excellent discovery. Thanks Capn!

A side note on 4), I was using an unknown setup code for the remote and the extender would activate, but not deactivate and the remote bacame unresponsive and would only blink twice on any keypress. Reuploading the IR file with a valid setup code for the remote fixed it. I saw the signature changed message at the upload step confirming what Vickyg writes below (I dropped the last part of this sentence somehow last night).

I sent unclemiltie my 981 reset IR file and the vanilla IR file a couple of days ago. Maybe the magic is contained in those?
Best,
jeff

A side note on 4), I was using an unknown setup code for the remote and the extender would activate, but not deactivate and the remote bacame unresponsive and would only blink twice on any keypress. Reuploading the IR file with a valid setup code for the remote

The JP1.x remotes hate it when you use an invalid setup code. They go through a bunch of error routines that can really really mess up an extender. In the JP1.2 remotes this changes the signature and reverts all the setup codes to the default setup codes.

greenough1 wrote:
A side note on 4), I was using an unknown setup code for the remote and the extender would activate, but not deactivate and the remote bacame unresponsive and would only blink twice on any keypress. Reuploading the IR file with a valid setup code for the remote fixed it.
jeff

my guess on this is that the "failsafe" feature of the extender is kicking in. If you look in the extender source, all the way at the end you'll see some logic that checks to see if the current signature is the extender signature. If not, it will blink twice and then call the "normal remote" entry point that I patched out when I activated (so every key blinks twice)

Like Vicky said, the remote is picky about setup codes that don't exist and it will re-write the signature and the setup codes to the default. That will activate the failsafe. My bet is that when you re-uploaded, IR complained about the signature, this would be a clue that the fail-safe has kicked in.


Cap'n. I haven't had a chance to even look at why the LDKP isn't working. Binky's been playing with it and vicky has offered some suggestions based on her Atlas JP1.2 work but we're not there. Sorry.

And to everyone else, I'm going to have to figure out why this remote is so dependent on the contents of the E2 area and will just fail miserably if the data is not right. until then, we're going to have to resort to the strategy laid out by Cap'n to get this extender activated.

thanks all

Another little test. The IR image referred to above, built on the baseline cable provider download on the Black, non-learning, non-backlit TWC OCAP, works equally well in the other two variants of the OCAPs I have, even though they start out with different data (see 7 posts above).

If you want the complete raw IR files from all three, I can upload them to the diagnosis area for you to analyze and see what magical entries make the remote work, and what is missing after a 981 reset.

Observation: With the extender activated, still using default Device Selection macros, occasionally the "active" device shifts all by itself. I have not identified a specific pattern, but I have had the remote switch from "AUD" to "TV" device all by itself after pressing a F1, OnDemend, F2, Source, A-D and other buttons. Not every time, but at least once each - and frequently enough to be a nuisance.

(I know that in the extended remote, the term "active device" is a misnomer, but in this circumstance, since the device buttons are the only ones with any device-selection/button assignment capability programmed, and the "active" device button flashes upon any button press, indicating when such a shift has occured, I'm using that terminoligy for simplicity, instead of referring to "active button assignment" or some other construct that is unclear.)

I also tested tonight beginning with the 981 reset download from the 1056 OCAP JP1.3 remote as the base and then merging with the current extender.
I added the same 3 upgrades given in my last post. I set the TV setup code to 0150 to control my mits. The extender activated/deactivated at each step and and the end.
So at least in my case, this remote's extender activated/deactived (and other limited testing) either with the manufacturer's download or with the 981 reset version download.
My previous issues were apparently due to using an invalid setup code and triggering the failsafe. Thanks Unclemiltie and Vickyg for the explanation above.

Does this result mean that there's nothing special in the manufacturer's setup that interfers with the extender, at least for this version of the remote?

Best,
jeff

OK, Summarizing my current state of affairs:

As Jeff experienced above, starting from either the factory-loaded IR image, or following a 981 reset, using extinstall creates a working (i.e. activates and deactivates) extended OCAP remote.

I previously thought that the post-981 extender image was non-working, but now I realize that is not the case (too many plates spinning to keep track), only the "base" image provided with the extender zip file, when converted using extinstall, resulted in locking up my remotes, so I would suggest as a first step removing those "base" IR images from the distro, and provide instructions to either:
(1) do a 981 reset and "Merge using extinstall" before adding one's upgrades, keymoves and macros; or
(2) ensure that the IR file which you are going to "merge using extinstall" has assigned setup codes on the General Tab that are resident in the remote (either as upgrades or built-in) before one begins (although I haven't really tested the latter theory myself).

However, I now see as the biggest problem facing this extender being the inadvertent (random?) switching of active devices. I don't really believe it's random, but have yet to discern the pattern, but I have had it automatically switch to TV or CBL device mode on multiple occasions as I have been attempting to test functionality over the weekend. That's really a usability showstopper. Won't have much chance to continue testing until after Thanksgiving, but will try to keep up.

Cap'n

In the end, the distribution will be very different in that it won't be asking you to rebuild the ASM yourself. I'll distribute a HEX file that will be merged using Extinstall and instructions to do so.

I'm glad that you guys were able to chase this down. It would be useful to see a DIFF of the non-working IR files as well as the working IR files to see what was going on. That may lead to a clue of how to build one of these from scratch.


As for the mysterious device selection, I'm going to have to look at things. One thing that is suspicious is that I store the device tables in what I thought were "unused" registers and maybe something is changing those registers when I'm not looking.

I think that the only time I've made a non-activating/non-activating extender version was when I had a bogus setup code. My failures were user error - bogus setup code or pointing at the wrong ExtInstall.

I've not observed random device reselection. But then I've not been looking for that. I'll spend some time looking at that as well as testing DSM and Pause.

I have a question about phantoms. When I try and create a special protocol, e.g. DSM, I pick a device and a key. I see no phantoms as key choices. In past extenders I put DSM's on phantoms. In the macro definition, I see phantom1-6. Is this an RDF issue?

Best,
jeff