JP1 Remotes

How diverse are the formats for keymoves, macros and upgrades? Are they different for different MCUs and/or models? Does any of the extenders change them?

For the most part the keymove format is pretty much the same (except for the URC-6131 and Atlas remotes).

Upgrades have the buttons arranged in different orders depending on the remote and the device type.

Protocols are unique to an MCU type (ie, S3C8, S3C8+, 740, 6805, etc)

Thanks, Rob.
What about macro? I don't think extenders have to change the format in order to provide nesting but would ask just in case. On the other hand some of them provide Fav/Scan in entirely different way than original soft. For this I believe they need different format, or at least they can use keymove/macro formats in a new role.

wwwoholic wrote:Thanks, Rob.
What about macro? I don't think extenders have to change the format in order to provide nesting but would ask just in case. On the other hand some of them provide Fav/Scan in entirely different way than original soft. For this I believe they need different format, or at least they can use keymove/macro formats in a new role.

As far as I recall, the only significant KeyMove or Macro format change is the 6131 extender changing the KeyMove format from the strange format native to the 6131 to the normal format used by other models.

Nested macros use exactly the same format as ordinay macros. The extender changes the way it behaves, not the way it is stored.

Similarly the major change in Fav behavior works without any change in the way the Fav list is stored.

I forget the exact details of the extender support for very long KeyMoves. I think that the extender does increase the maximum possible KeyMove size slightly, which could be considered a format change. But the way KeyMove size is encoded doesn't change. It just allows all lengths that can be encoded that way rather than having a slightly lower limit.

The extender DSM's and ToadTogs are stored as KeyMoves. You could call that a format change in that it stores a different kind of information within the KeyMove format than non extender KeyMoves can hold.

johnsfine wrote:The extender DSM's and ToadTogs are stored as KeyMoves. You could call that a format change in that it stores a different kind of information within the KeyMove format than non extender KeyMoves can hold.

I would rather say these do not qualify, as it seems the main executing code does not know about toads or dsms and treats them as regular keymoves. Only when it comes to the protocol they will be processed differently. Doesn't this work in non-extended remotes as well?

Anyway, my questions were parts of general "how to interpret eeprom dump from different remotes?" question. I believe I got the picture, thanks. Pls, let me know if anything else comes to mind.

johnsfine wrote:I forget the exact details of the extender support for very long KeyMoves. I think that the extender does increase the maximum possible KeyMove size slightly,

I this related to the size of the macro buffer? When testing a DSM for 1994 ext 5, I found that although the extender allows 15 byte macros, IR wouldn't allow the DSM keymove to be more than 13 bytes. Or is this just just the way it is in IR, vs some keymove limitation?

ot04298 wrote: I this related to the size of the macro buffer? When testing a DSM for 1994 ext 5, I found that although the extender allows 15 byte macros, IR wouldn't allow the DSM keymove to be more than 13 bytes. Or is this just just the way it is in IR, vs some keymove limitation?

The maximum size hex command in a KeyMove AFTER that has been increased by the extender is still smaller than the maximum length macro. 13 sounds right.

I believe that without the extender the limit is a little less than that, but IR.EXE knows the encoding method (which works up to length 13) and doesn't know the size limit, so it would be perfectly happy to create a 13 byte hex command in a remote where that wouldn't work. (In the older S3C80 remotes the limit is MUCH lower, and IR still doesn't know).