JP1 Remotes

I've spent the last couple of days fine-tuning my implementation - to eliminate redundant code, reduce execution time and save macro/keymove memory (fewer than 50 bytes remained). What was to have been a half-day exercise lasted much longer since, in consolidating two macros, the resultant longer one apparently caused the macro buffer to overflow. (The first step in a 9-step DSM called the new 11-step macro and the fourth step of that macro called a 9-byte Toadtog.) The extender documentation says the macro buffer can hold 32 pending commands, so I didn't investigate in that direction until everything else failed. However, the actual limit appears to be about 20. To overcome the problem, I split the 11-step macros into two sections.

While the extender documentation doesn't discuss the Pause protocol timing, the readme file with the Pause special protocol suggests intervals of about 0.1 seconds for a URC-7560. The interval on the 8910 seems much smaller; $ff resulted in about a half-second delay. Does this seem right?

The documentation for the Custom Name protocol indicates that each name must have 9 bytes - even if one just wants to display, say, "TV". This seems like a real waste of valuable macro/keymove memory. (I suspect this is a limitation of the remote itself, but I thought I should raise the issue anyway.) While using only 2 bytes for "TV" results in the display of "TV" in the first two character positions, whatever was previously displayed in the other character positions remain. I tried terminating the 2-byte string with a null, and that fixed the third character position, but the 4th to 9th positions remained unchanged. Since the length of the string is defined in the keymove, couldn't the extra character positions just be cleared?

Finally, a comment re IR. I would have found it extremely useful if IR translated keymove hex strings into a list of button names. Having to move hex strings into ExtenderCodeCalc for translation is a real "pain". I realize that a full translation would not be straightforward due to the first byte of data for special protocols. However, since you seem to have standardized on the device type and code for these special protocols, they could be recognized and the first byte treated differently (or, perhaps not treated at all). This would have been the single most helpful thing to me (other than information on what to expect with macro buffer overflow) over the past few days.

Once again, you guys are doing a terrific job. Keep up the good work!
Don

DGG wrote:The extender documentation says the macro buffer can hold 32 pending commands, so I didn't investigate in that direction until everything else failed. However, the actual limit appears to be about 20.

There is a certain tendancy when porting an extender from one model to another to copy the documentation with less than enough review. There is at least one extender with support for 32 pending commands, but most support less. I have no specific knowledge of that buffer size on that 8910 extender.

DGG wrote: Finally, a comment re IR. I would have found it extremely useful if IR translated keymove hex strings into a list of button names. Having to move hex strings into ExtenderCodeCalc for translation is a real "pain".

An extender DSM or TOADTOG is much more like a macro than like a KeyMove, both from the user's point of view and for any easy ways of supporting it in a program such as IR. The fact that it is technically a KeyMove shouldn't matter.

The IR GUI ought to be able to manage extender DSMs and TOADTOGs on the Macros tab, sharing the Macros GUI.

That is a fairly large chunk of work for our few and busy Delphi programmers, so I don't really expect it to happen. But if some Delphi programmer want's to do it, I'd be glad to clear up any questions about the internal technical details.

Having spent a good part of my working life (and a lot of my spare time) designing and programming software systems, perhaps I can lend a hand. While I've never used Delphi, I am familiar with Pascal.

Don

There is source code for some version of IR in one of the Yahoo JP1 file areas. Mark is pretty good about getting current IR source code to anyone who seems like they will make some real enhancements to it, but I don't think he posts the current source code to the group very often.

Look at the posted source code first. If you think you understand it, and some requested change, well enough to make such a change, ask Mark for current source.

However, I expect not having Delphi would make it hard to do serious GUI work and impossible to debug any new code. I don't really know the status of Delphi. I don't have a copy and I assume any free copies you might find aren't legal.

We also can use help in RemoteMaster, especially if you could do part of the big project of making it able to replace part or all of IR, rather than just part of KM. RemoteMaster uses Java. The Java SDK is a free download from Sun.

Hey I do Delphi....I can't find the code anywhere..I looked under source code but didn't see it....

e34m5 wrote:Hey I do Delphi....I can't find the code anywhere..I looked under source code but didn't see it....

Here is the link to the latest source: IR401Source
It has been moved to the jp1-km group so you may have to join it if you haven't already

The extender documentation says the macro buffer can hold 32 pending commands, so I didn't investigate in that direction until everything else failed. However, the actual limit appears to be about 20.

Like John suggested, I tested the limit on the 2116 version of the extender and then did a quick port over the the 8910 and it looks like I never tested the limit again. I'll update the documentation. The original 2116 extender actually displayed a warning message when the buffer was exceeded, but I had to take it out to save space. Thanks!

While the extender documentation doesn't discuss the Pause protocol timing, the readme file with the Pause special protocol suggests intervals of about 0.1 seconds for a URC-7560. The interval on the 8910 seems much smaller; $ff resulted in about a half-second delay. Does this seem right?

The 8910 interval is a lot smaller. I created a different version that worked for me but evidently not for others. Looks like you can use the version in the Special Protocols folder if you need longer delays.

The documentation for the Custom Name protocol indicates that each name must have 9 bytes - even if one just wants to display, say, "TV". This seems like a real waste of valuable macro/keymove memory. (I suspect this is a limitation of the remote itself, but I thought I should raise the issue anyway.) While using only 2 bytes for "TV" results in the display of "TV" in the first two character positions, whatever was previously displayed in the other character positions remain. I tried terminating the 2-byte string with a null, and that fixed the third character position, but the 4th to 9th positions remained unchanged. Since the length of the string is defined in the keymove, couldn't the extra character positions just be cleared?

I actually considered three different options for this protocol.

1. Always pass 9 bytes.
2. Pass a null terminated string.
3. Pass the lengths of the strings for line 1 and 2 along w/ the strings themselves.

In the end, I went w/ version 1 because after you added in the extra protocol code needed for options 2 & 3 along w/ the overhead bytes (null or length) it actually would have taken up more memory than option 1 in most instances. There are some extreme cases (i.e. 2 character names) where it would save space, but in many cases, it would end up taking more. If all of your labels are short, you could use one call to blank out both lines and then just change the first 2 characters for all of the rest of your calls.

Finally, a comment re IR. I would have found it extremely useful if IR translated keymove hex strings into a list of button names. Having to move hex strings into ExtenderCodeCalc for translation is a real "pain".

I guess it all depends on where you started from. For those of us who remember having to calculate all of the hex codes manually for each different remote, Hal's ExtenderCodeCalc is the best thing since sliced bread.

David

Thanks for your review efforts David (and your original efforts in making this port).

Looks like you can use the version in the Special Protocols folder if you need longer delays.

The Special Protocols version works just fine in my 8911.

. . . it actually would have taken up more memory than option 1 in most instances

I suspected that to be the case.

For those of us who remember having to calculate all of the hex codes manually . . .

It wasn't the original calculation of the code that bothered me. (I agree, ExtendCodeCalc does a great job at that.) It was the distraction of repeatedly having to cut and paste to ExtendCodeCalc to be reminded how I had coded over 50 Toadtogs (my main use of Toadtogs is for mode control, not power), LPKs and DSMs, some several days before, while "chasing my tail" trying to understand the symptoms of a problem the documentation suggested shouldn't be occuring. (I've since realized that having a simple button-to hex-code table at hand would have eliminated much of the need for the cut and paste activity. Could that be put in a "popup" easily?) I appreciate implementing such a translator isn't a trivial task. But, I still think its is a good idea - in RM as well if IR functionality is included.

To "johnsfine", re my offer several posts above to assist, I don't have a Delphi compiler, but I'd be happy to help "spec" the changes and debug/test the result - if the person doing the coding thinks its useful. As for RM, while it sounds like a very interesting project, my schedule precludes a long-term commitment. But, once again, if I can help with the testing, just let me know. (From several earlier posts, you can see I'm quite adept at finding problems.)

Thanks again to all of you who contributed to the toolset.
Don

DGG wrote:The documentation for the Custom Name protocol indicates that each name must have 9 bytes - even if one just wants to display, say, "TV". This seems like a real waste of valuable macro/keymove memory. (I suspect this is a limitation of the remote itself, but I thought I should raise the issue anyway.) While using only 2 bytes for "TV" results in the display of "TV" in the first two character positions, whatever was previously displayed in the other character positions remain. I tried terminating the 2-byte string with a null, and that fixed the third character position, but the 4th to 9th positions remained unchanged. Since the length of the string is defined in the keymove, couldn't the extra character positions just be cleared?

Here is what I do: My longest custome name is 5 character (e.g. RADIO). So I make all other custom names "padded" with "spaces" ($20) such that all the names are 5 characters long. This way you can save lots of bytes. And if you are lucky and have shorter "longest" name then you will even save more!!

Bye the way, you are right about the Pause protocol. There is some problem with this protocol in 8910 extender. I have downloaded the procol saperately from Yahoo file section and "edited" the protocol $01F8 of the extender. Here is the protocol:

00 00 01 08 03 18 03 F6 01 0D AF

This will result in 1 second pause for every $10 e.g $20 = 2 sec, $FF = 16 sec, etc.

Hope this helps,
bargain_pro

IR v5.00