"Common Source" JP1.3 extender

unclemiltie · Post by **unclemiltie** » Wed Feb 01, 2012 12:31 am

This has been on my list of things to do for a while. Right now I maintain 6 sets of source for the JP1.3 extenders. most of the code is identical between them all (3000-3033, 3039, 3085, 3060, 3147 and 3179)

I've been thinking of trying to "merge" the extender source into a single file that has can generate any of the JP1.3 extenders through command line options. That way, if I discover a bug in one, a single fix and multiple-rebuilds and I can release all of them at once.

However.....

half way through the JP1.3 extenders I switched from the 9960 HT(i.e. C_TV, V_AUD) style to the 8910 (i.e. Dev_TV, Set_Vol) style. I've often thought that I should back port the 8910 style and re-release those extenders. This would allow me to do it.

I've actually gotten the 3147 (Insignia) and 3179 (RCA) source to generate identical HEX files since those remotes have the 8910 style HT codes. Now comes adding the other remotes in. This will require that I move a few key codes around to make things consistent so it'll have some impact on someone who using the extender.

Anyway, thoughts on this? Is it a valuable exercise, especially since there aren't any new JP1.3 remotes coming out and it appears that the extenders are pretty much bug free?

A couple of other questions:

I've thought that I would change the signature for these versions of the extender from the typical "3Axx" to "3BXX" or something like that. good idea? I thought it would minimize confusion since keys are going to move on most of the extenders.

I also thought that they'd all have the same version number (i.e. 3.00) instead of the mishmash of versions that I have now across the extenders.

Comments welcome. Like I said, I was able to get the 3179 and 3147 to use the same source, that was pretty easy. A little bit of restructuring the code since one has PIP keys and the other one doesn't, but that wasn't too hard.

-bill

xnappo · Post by **xnappo** » Wed Feb 01, 2012 6:57 am

From a technical point of view it is of course a good idea. But from a practical view, I don't think many, if any, people would benefit.

I would rather you apply your considerable talents to studying the whacky new 1.4/2.0 processors and how to extend those remotes. Maybe just protocols for a start (like DSM etc).
xnappo

eferz · Post by **eferz** » Wed Feb 01, 2012 10:01 am

xnappo wrote:From a technical point of view it is of course a good idea. But from a practical view, I don't think many, if any, people would benefit.

Hmm... I would think that once he unifies the JP1.3 extenders, he would have more time over the long run to develop and refine new 1.4/2.0 extenders while still simultaneously maintaining all the JP1.3 ones under his supervision. Therefore, everyone would benefit.

I guess its an issue of priorities and time investment. In my opinion, RM/RMIR is still not quite ready for these remotes. So, I'm not sure it is a good idea trying to extend them before transfer mechanism is ready. It is probably more effective use of his time to unify the JP1.3 extenders while the details of Remote Master's compatibility are fully fledged out.

unclemiltie · Post by **unclemiltie** » Wed Feb 01, 2012 10:27 am

I've been reading the programming manuals for the MaxQ processors, they are a bit strange but nothing that difficult. But delving into how the remotes work is another issue and it's a long, hard push to get there.

But I agree that there is a lot to learn about how the remotes work before any extenders or something like that can be started.

mdavej · Post by **mdavej** » Wed Feb 01, 2012 10:49 am

I'm all for it. I'll also volunteer to help debug the 15-13x and RCA (I sold all my Insignias).

xnappo · Post by **xnappo** » Wed Feb 01, 2012 11:02 am

eferz wrote:
xnappo wrote:From a technical point of view it is of course a good idea. But from a practical view, I don't think many, if any, people would benefit.
Hmm... I would think that once he unifies the JP1.3 extenders, he would have more time over the long run to develop and refine new 1.4/2.0 extenders while still simultaneously maintaining all the JP1.3 ones under his supervision. Therefore, everyone would benefit.

I guess its an issue of priorities and time investment. In my opinion, RM/RMIR is still not quite ready for these remotes. So, I'm not sure it is a good idea trying to extend them before transfer mechanism is ready. It is probably more effective use of his time to unify the JP1.3 extenders while the details of Remote Master's compatibility are fully fledged out.

So just to expand on my thoughts:

- I don't think there is much need to update the 1.3 extenders, I think they are mature and can be left as-is. It is unlikely there will be show-stopper issue or a bunch of new users.

- While JP1.4/2.0 is not quite ready for prime-time, there is plenty of learning to be done on how they work, and as I said I think special protocols would be the second step before a full-on extender. The first step being understanding how the remotes work at all of course

Just my opinion!

xnappo

unclemiltie · Post by **unclemiltie** » Wed Feb 01, 2012 1:57 pm

The only "update" or change in the extenders would be to switch them to the 8910 style of HT processing (which uses a lot less keycodes and is actually easier to implement) for the earlier JP1.3 extenders (Atlas, 15-13x, 15-100, Comcast)

As for the 15-13x, that one is still troubling since the folks at UEI put a sparse set of keys into the key map in the $40-$7F range and there still is no room for the HT keys without some special case handling of a few keys. Makes my job more difficult!

pH7_jp1 · Post by **pH7_jp1** » Wed Feb 01, 2012 6:06 pm

The only "update" or change in the extenders would be to switch them to the 8910 style of HT processing (which uses a lot less keycodes and is actually easier to implement) for the earlier JP1.3 extenders (Atlas, 15-13x, 15-100, Comcast)

There is a large enough audience for the Atlas and Comcast remotes, that this may be a real advantage. I do question how many of the existing users of these extenders would go to the effort to convert. If I were doing something new and had the option to use the 8910 style, that is what I would do.

As for the 15-13x, that one is still troubling since the folks at UEI put a sparse set of keys into the key map in the $40-$7F range and there still is no room for the HT keys without some special case handling of a few keys. Makes my job more difficult!

How inconsiderate of them! We should register a complaint!

Bottom line - if this is how you want to spend your time that is great, it will benefit some people. If this were a business for profit and you had to justify the cost to implement vs the potential income, then I doubt if the project would be approved. Thankfully that is not how things get accomplished around here.

unclemiltie · Post by **unclemiltie** » Thu Feb 02, 2012 10:29 pm

As I dug into this project a bit deeper I realized that there are a lot of things that I didn't do on the early extenders that I did in the later extenders that may be useful for everyone. (early = Atlas, OCAP, Comcast and the Radio Shacks) They are:

Long-press Setup to deactivate (although I think some of them were back ported)
Interruptable pause
blinking 2x for hidden devices on single-LED remotes
blinking 2x on hidden devices via specific device LEDs on multi-LED remotes
delay in the pause protocol
8910 style HT setup

I started on the project and got the 3147, 3179 done (they compare byte for byte against the last version of the extender) Those were the basis.

I now have the 3039, 3000 and 3033 assembling but I'm going to need to test them.

But I'm being hijacked to go work on something else by someone so this project is going to be on hold for a while. It's still on my list of things to do, just not right now.

unclemiltie · Post by **unclemiltie** » Wed Feb 15, 2012 10:43 pm

Well, I've gone and done it....

What I have now is an extender that will assemble for all of the remotes with the exception of the 15-100 which doesn't fit in the allotted memory (I still have to figure that one out) and on the 3147 and 3179 remotes generates an identical HEX file as the original extenders did. These were the two remotes with the 8910 style HT processing.

The other remotes look like they will work, now I have to do a bit of debugging when I get some free time, I'm trying to understand one of the MAXQ remotes right now.

What's interesting is that I did find a bug (an extra key in a key list) on the 3170 remote and a couple of things that I didn't put in the 15-13x and 15-100 remotes that did find their way back into the others.

Was an interesting exercise, I've never seen so much conditional assembly in a single file. When I get some time I'll clean it up and then will be looking for beta testers to make sure that they work as advertised.

I'm going to change the second letter of the signature on these ones so that people can clearly tell them apart. There is a lot different on the older JP1.3 remotes!