JP1 Remotes

I've just uploaded V1.00 of the extender for the 15-100 here:



This version includes:

- Full support for IR 8 including IR version display, setup code checking and pause values
- bug fix on macro searching that caused odd errors
- new feature that enables long-press of setup to deactivate the extender
- optional long-press on backlit OCAP to display clock


Edit: updated to V1.02

fix bug in LDKP processing in all JP1.3 extenders

One of the people who has been testing this extender found that there is a typo in the RDF that causes some odd problems.

The definition of the Vol- key in the RDF is $055 and it should be $05.

It's easier for you to edit the file and fix it then for me to make a new release since I'm using a new version that has some issues and I'd have to go back and undo the changes to get one for the V0.01 extender. (and it's easy)

Bump: The original topic has been updated to announce a new version

Is IR Beta 5 available anywhere?

Graham has been working on it. We're trying to work out some of the syntax between different versions of IR. Right now, the syntax for clock setting causes RM to fail on the RDF for this extender so you have to have one version of the RDF for RM and another for IR. (not quite ideal)

Follow the IR8 enhancement topic as Graham has announced other versions there.


-bill

If you need to make this backward compatible with RM, take out the TimeAddr line and the fixed data in the RDF and save it as another version that starts with the signature. That way, RM can select that version when you set up the remote and IR will select the right one since it has the right version number in the fixed data.

IR8 Beta 4 also gives an error on the TimeAddr line. I don't know if it continues to process everything else or not, but either it doesn't, or I screwed something up on the ExtInstall step.

When I try to load the file I created with ExtInstall, I get the error: "'$147C,BCD12' is not a valid interger value." and when I check, there are no key moves, macros, devices or protocols.

The flag "BCD12" tells IR what format to put the time in. It's diferent from the odler remotes that had time setting in them, so Graham had to add a second parameter.

You'll have to keep two versions of the RDF until we get this straightened out, although I thought IR would ignore the older stuff. You can take that line out and save it as another version, the only thing you won't get is the clock set stuff.

unclemiltie wrote:The flag "BCD12" tells IR what format to put the time in. It's diferent from the odler remotes that had time setting in them, so Graham had to add a second parameter.

You'll have to keep two versions of the RDF until we get this straightened out, although I thought IR would ignore the older stuff. You can take that line out and save it as another version, the only thing you won't get is the clock set stuff.

One way we've handled this sort of incompatibility in the past was simply to create a new entry in the RDF instead of modifying an existing one. For example, when we discovered that there were two different types of 6805-based remotes, we needed to tell RM about it, but IR (mostly) doesn't care. So, instead of modifying the Processor=xxxx, we added a new entry, ProcessorVersion=xxxx. This usuaully works because, as a general rule, both IR & RM were designed to ignore any entry in the RDF that they don't recognize.

Maybe the TimeAddr entry could be left alone, and a separate TimeFormat=BCD12 entry created?

I just commented it out for now, so it is easier to put back in later. Things work fine that way. Thanks for the help and thanks for doing this extender just in time for a project I can only do this next weekend. Great timing.

That works for me. Graham is the guy doing the work on IR, so he'll have to comment.

pH7_jp1 wrote:I just commented it out for now, so it is easier to put back in later. Things work fine that way. Thanks for the help and thanks for doing this extender just in time for a project I can only do this next weekend. Great timing.

Make sure you leave the clock autoset "disabled" in the settings panel. (well, it really won't make a difference, I think the default data in the extender is soemthing like wednesday at 2:00am)

You can still set the clock with the long-press setup set to clock, so that should at least get you where you need to be this week.

I removed the $147, BCD12 line from the RDF and things seem to working.

Thanks for the updated Readme file. That really helps.

-Mike

Problem in readme.txt:

There are 7 Key sets: Menu, Channel, Volume, PIP, Transport, Other and
Temporary(X).

I assume this was just a copy/paste error. There is no PIP set.

yes, you are right. there is no PIP set on this remote since the PIP keys are shared with other keys

I have two files: works_yes.ir https://www.hifi-remote.com/forums/dload ... le_id=6294 and works_no.ir https://www.hifi-remote.com/forums/dload ... le_id=6295. The only difference between the two files is that for SAT/CBL the ToadTogs are defined on Phantom1/Phantom2 in the one that works and on DiscreteOn/DiscreteOff in the one that does not work. By "does not work", I mean that nothing is sent when I press the M1 or M2 button. The LED on the remote does not flash and IRScope sees nothing.

Some notes about my ir files:

1) I have just started testing, so most macros may or may not work. The only ones I have used in this test are: SHIFT-SAT/CBL, M1 and M2.
2) The ToadTogs just send the functions 1, 2, 3, 4 so that I can test what is going on with IRScope.
3) I usually document my ir file, but have not done that with this one yet - sorry.

It is possible that this is just a limitation of the extender and I can live with that, no problem, but the readme file gives an example in the ToadTog documentation that does exactly the thing that isn't working for me.