Atlas JP1.3 Extender beta - Topic CLOSED

[unclemiltie]

Mark is correct on the F1 button thing. It's in the hardware cable button map which is what causes it to show up in RM. This "button" code has special meaning in the unextended remote that has to do with the cable company devices that are in the upgrade area. Just what I have never understood.

As for the others, Discrete On and Discrete off can't be shifted and xshifted since they will overlap with the Phantom0 key (the keymap is pretty full so there is lots of jamming things into space where they would fit and $40 and $80 are shifted/Xshifted versions of $00 which is unused) However, if you shift or xshift them, you get Phantom0 (I think this is from memory)

I must have left out the Xshift info on the RDF, I'll fix that. The remote does it by the way.

Also, the RDF points to the wrong place in the extender to chagne the Xshift and Shift key so don't use that, you'll break something!


-bill

[unclemiltie]

Oh, Finally. To enable XShift you need to add:

XShift=$40

just after EFCDigits=5 in the RDF


that should take care of it?

[unclemiltie]

do a 981 reset and send me the IR file at bill.jackson.0 at gmail.com

I'm beginning to believe that this "fixed data" in the E2 section is causing me issues and that different remotes have different stuff.

Also try changing the default CABLE device to 1376 from 1877 and tell me if that works. (do you have an upgrade in your file for either of those numbers)


This has got a long way to go to get it bullet-proof!

[Capn Trips]

Oh, Finally. To enable XShift you need to add:

XShift=$40

just after EFCDigits=5 in the RDF


that should take care of it?

Partial success! xShift is indeed activated in all locations in RM and IR. However, RM display anomalies continue to evolve.

Before adding that line to the rdf, RM's Layout sheet showed DiscreteOn as a phantom button below the remote image. After the addition of that line, RM's Layout tab displays DeActivate and ButtonF1 as phantoms, but now DiscreteOn is gone! (and DiscreteOff appears in Neither circumstance!)

[greenough1]

do a 981 reset and send me the IR file at bill.jackson.0 at gmail.com

Was that to me or Capn?

[Mark Pierson]

Before adding that line to the rdf, RM's Layout sheet showed DiscreteOn as a phantom button below the remote image. After the addition of that line, RM's Layout tab displays DeActivate and ButtonF1 as phantoms, but now DiscreteOn is gone! (and DiscreteOff appears in Neither circumstance!)

Perhaps an entry needs to be made for Shift= as well?

[greenough1]

I don't know if this helps, but I tested the latest beta last night abit and as downloaded, I can build it, load it and activate/deactivate it. If I try and add in my HT devices (added using latest KM to load the upgrade and generate the device info for the Atlas JP1.3 remote. This was done for AUD, DVD, and CBL. These devices work fine in the unextended remote.), to the extended IR file, the extender ceases to be activatable.

All I get is two blinks for any key press. It doesn't lock up and the vanilla extender can be reloaded and activate/deactivates fine. The vanilla unextended IR file can also be uploaded and controls the HT components.

Best,
jeff

[Capn Trips]

Still no joy with activating the currently-available version of the extender, so I cannot test anything beyond that step.

[unclemiltie]

Grrrrrr


Cap'n - I'm about to get on an airplane to go back to the east coast for the weekend. Here's a suggestion for you:

1: look at the data in your remote after a 981 reset in the area after the setup and before $626 and copy that into the extender source where I set that data from my remote (a silver 1056 with learning, Sunflower

2: rebuild the extender and then try that.


3: Make sure that the TV setup code is one that really exists. The remote is very picky about this. The setup has to either be an upgrade or a built-in setup code for TV.


if that's not it, I'll be out of action for a week or so, back in CA on 11/26 so that I can take a look



sorry I can't be more responsive....

-bill

[Capn Trips]

I'lltry to decipher what you wrote and implement it over the weekend, although frankly, I don't see right now (cursory scan) what you mean by

area after the setup and before $626 and copy that into the extender source where I set that data

.

After 981, I have:

Code: Select all

0000:  33  30  33  33  33  30  33  33  98  67  07  55  10  2F  21  F7
0010:  33  FF  20  3C  01  0C  01  FF  00  00  00  0F  0F  00  00  00
0020:  00  00  00  00  00  00  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF
...
0200:  00  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF
...
0400:  00  FF  0A  06  0A  06  00  00  FF  FF  FF  FF  FF  FF  FF  FF

and all the rest is FFs.

This is also a Silver, backlit learner from Sunflower. (Got the same post-981 data on my Black nonlearning, non-backlit OCAP from TWC)

[greenough1]

In the extender hex, EA33ext.HEX, search for 626. I see a line, the 10th beginning with 626:. This line also shows up in the 3A33ext.LST file.

This sets the line for before. From the EXT, I see 3 lines, 600:, 60A:, 610:, 620: which would end at the 626: line. Is this the setup stuff? Here's my extender 3A33ext.HEX:

600: 33 41 33 33 33 41 33 33
60A: 07 55 10 2F 21 F7
610: 33 FF 20 3C 01 0C 01 FF 00 00 00 0F 0F 00 00 00
620: 00 00 00 00 00 00

From my 981 reset:

600: 33 30 33 33 33 30 33 33
60A: 07 55 10 2F 21 F7
610: 33 FF 20 3C 01 0C 01 FF 00 00 00 0F 0F 00 00 00
620: 00 00 00 00 00 FF

Some differences (without a clue why or what it means): 601, 605, 625.

My TV setup is live.

Capn, I thought I posted this the other day, but be sure that your ExtInstall path in IR is set to ExInstall v2, not the ExtInstall with the extender distribution. I tripped over this for several hours the other night.

Why does your IR raw data begin at 0000? Mine begins with 0600. Isn't this an rdf issue?

Best,
jeff

[vickyg2003]

Jeff 600 is the signature,
600: 33 41 33 33 33 41 33 33 ="3A333A33"
600: 33 30 33 33 33 30 33 33 ="30333033"

We change the signature so that IR will call up a different RDF. In JP1 remotes the signature could be changed to anything you wanted, in JP1.x remotes, the checksum of the signature needs to be 0. The easiest way to create a checksum of 0 is to repeat the first 4 bytes of the signature.
Many of the JP1.2 remotes have a signature that starts 10xy10xy and many JP1.3 remotes have a signature 30xy30xy. There are are exceptions to this of course. But it seemed the easiest way to modify the signatures and still have them meaningful would be to replace the 0 with a different character. When I did the first JP1.2 extenders I replaced the 0 with a letter because that still left a clue as to which signature it was, seemed least likely to be the signature of some new remote and was less likely to be mistaken by humans. UncleMiltie did the same thing with the JP1.3 remotes.

[greenough1]

Thank Vicky. That explains the differences for 600: (the signature - doh!)
And by inspection it's true Capn is showing raw data for a JP1.2 remote.

Capn,
- are you not able to build, load, activate/deactive the current beta for which of your remotes : JP1.2 or JP1.3?
- are you sure IR's search path for ExtInstall is set to the v2 ExtInstall?

I can load, activate/deactivate all beta versions and control devices, but if I add several upgrades, I can no longer activate. So Unclemiltie, your hypothesis about e2 containing something important that might be getting overwritten seems reasonable. I've not systematically tested adding upgrades to see when it fails and what memory location gets clobbered, but I will try tonight.

Best,
jeff

[unclemiltie]

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'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.

BTW, this version did activate on my Silver Sunflower remote.

[Capn Trips]

Apologies to all that I have been unable to follow up on some more rigorous testing lately. The Pentagon forces one to keep strange hours.

The data I quoted above were from a RAW download following a 981 reset, so the data start at 0000: I understand that if I allow the rdf to be called by IR, the raw data fields all shift by 0600.

BTW, this is for the URC-1056 OCAP JP1.3 remote. It is NOT for a JP1.2 remote. I've managed to keep those segregated and am NOT mixing them up with this effort. The only JP1.2 I have is a URC-1055 10251025 which works fine with vicky's extender 1X251X25. It is not at issue at all in this thread.

I was looking for the "626" in the data after a "raw" download, which is just FF's all around.

So the "626" to which you refer would correspond to the 0020: line in my raw download above. The 0626/0026 field is where the FF's begin in the 981-ed remote.

Secondly, I assumed that you were referring to the asm file, in which I could find NO reference to 626. I will look at the HEX files and try to see what you're talking abobut.

Finally, I think I'm using the correct extinstall program, since when I had problems earlier, I recall upgrading to the newer one. I'll check that once again when I get an opportunity.,