JP1 Remotes

Greg, I made a mistake by calling them device specific macros. I think what wnewell is seeing are multimacros. Multiple macros(up to 5) on a single key. Press key and a macro fires(usually a favorite channel # and the return key). A counter is saved and the next press of this key fires the next macro.

The RDFs do have support for multimacros already. I don't know if RMIR supports it. Multimacro is type $90, $A0, $B0, $C0, $D0(up to 5). The multimacro RDF entry specifies where the byte is that stores the counter of which macro to fire next. The low nibble is the device mode($F means global or all device modes).

I think unclemiltie has to update the RDF to handle multimacros for this remote.

gfb107 wrote:Hmm. The hex for those macros don't make sense to me.

Specifically, the second byte values.
I know that the $80 bit means macro, and the $10 bit means key move.
I don't know what $A0, $90, and $B1 mean.

OK, I did some more testing. I reset my RS 15-135 remote to factory defaults ('981' [manufacturer's] reset) and manually (i.e. via the remote's keypad) loaded a simple (non-"Multi") macro. The 2nd byte in the macro is 0x81. I then manually loaded a single macro on the "HD[Fav]" key, which on the RS 15-135 is the only "MultiMacro" key, per the RDF. This macro shows up with a 0x91 (not 0x81) for the 2nd byte in the macro definition. I proceeded to manually add 4 more macros to that 'HD[Fav]' key and for the 2nd byte of their macros they have 0xA1, 0xB1, 0xC1, and 0xD1. If you try to add a 6th macro, it overwrites the 1st macro's slot (not the flash memory spot, just the virtual "slot"), leaving you with just the last 5 that you defined.

So, it seems to me as if the test for a macro is '(byte#2 & 0x80 == 0x80)'.

I don't know what the significance of the '(byte#2 & 0x01)' bit is. I've seen macros where it is set and macros where it is not. Anybody know what that bit means? EDIT: Later testing reveals that that least significant nybble (not bit) is actually the device code that was active when the macro was manually programmed. It's silly because this is a Device-Independent Macro (995) not a Device-Specific macro (978), so there's no reason for the lower nybble to be anything other than 0xF! But that's the way the RS 15-135 works. In fact, the URC-8820/URC-10820 remotes always encode 0x80 (better, but not perfect) and the new RCA RCRP05B, which supports extender-free Device-Specific (978) macros, encodes 0x8F (which is what the other remotes should really be doing).

I need to experiment some more, but I think that RMIR is at some (as yet undefined) point corrupting some of the 2nd bytes in macros, erroneously making them 0x80.

I'll report more when I've learned more, but hopefully that will help some.

Aside: I found out something else that surprised the heck out of me. I was running 'IR.exe' to download from the remote and save the memory to a '.ir' file. I was assuming that it would essentially be a copy of what's in the remote's flash memory but found out that that is not the case! 'IR.exe' was actually re-writing the 2nd byte of every one of the multi-macro definitions so that they were ordered sequentially. In other words, the bytes in flash memory were actually 0xA1, 0xB1, 0xC1, 0xD1, and 0x91 (because I'd tried to add a 6th macro and it replaced the 1st one, which was also 0x91). But when I look at the '.ir' file, it has the same data for the macros, but the 2nd bytes are now 0x91, 0xA1, 0xB1, 0xC1, and 0xD1! I don't know if that's intentional or not, but it sure surprised me. I tested with RMIR and it does not do this -- i.e. it preserves the flash memory as-is.

Note: I hadn't read Binky's reply when I composed my post above, but I agree with almost everything he says with 1 clarification. The RDF v4 spec says that this byte referred to in the "[MultiMacros]" section reports the number of macros assigned (0-5) in the high nybble and the number of the "next macro to fire" in the low nybble. I need to test more, but in my limited testing, I can confirm the high nybble's function, but the low nybble seemed to always be "1" for me, even after using the "HD[Fav]" key different numbers of times (i.e. so that the "next macro to fire" value should have been different).

Bill

WagonMaster wrote:I can confirm the high nybble's function, but the low nybble seemed to always be "1" for me, even after using the "HD[Fav]" key different numbers of times (i.e. so that the "next macro to fire" value should have been different).

Some of the older remotes that used MultiMacros did not always update the byte to the EEPROM when the low nybble changed, but still used it internally in RAM that way. It was a long time ago, but IIRC, I think IR was designed to always set the low nybble to 1 to keep things simple.

WagonMaster wrote:I found out something else that surprised the heck out of me. I was running 'IR.exe' to download from the remote and save the memory to a '.ir' file. I was assuming that it would essentially be a copy of what's in the remote's flash memory but found out that that is not the case! 'IR.exe' was actually re-writing the 2nd byte of every one of the multi-macro definitions so that they were ordered sequentially.

Yes, it surprised me when I first discovered how IR.exe works. It reads the flash ROM, parses it for the various tables it displays, and then re-encodes the data in those tables. So if you download the flash ROM and then upload the result without changing anything, the upload may not be identical to the original contents. This is nothing to do with me - this is deeply ingrained in the underlying design of IR.exe.
_____________
Graham

RMIR doesn't yet have support for MultiMacros. Guess it's time to add support.

Let's see if I understand it.
There is space (outside of the advanced code area, defined in the MultiMacro section of the RDF) for each key that supports multimacros to store

1. The number of macros defined for that key
2. The sequence number of the next macro to execute for that key (IR forces this to 1)

The multimacros themselves are stored within the advanced code area.
Multimacros have the macro bit (0x80) set in the type byte, but must also have a sequence number between 1 and 5 encoded in the high nibble (producing type values $9? - $D?). A sequence number of 0 is used for normal macros.

For remotes that use AdvCodeBindFormat=LONG, macros (even multimacros?) can be device mode specific, in which case the low nibble contains the device mode index, where F means a global macro).
Have we defined an RDF entry to indicate whether these types of macros are supported, or is AdvCodeBinFormat=LONG enough?

mathdon wrote:It reads the flash ROM, parses it for the various tables it displays, and then re-encodes the data in those tables. So if you download the flash ROM and then upload the result without changing anything, the upload may not be identical to the original contents.

Thanks for the clarification, Graham.

mathdon wrote:This is nothing to do with me - this is deeply ingrained in the underlying design of IR.exe.

I hope I didn't imply it was anything bad you'd done. I was just so surprised by the effect because I'd been (erroneously) treating the download/save step as "dump flash memory", but I'll be more careful to not make that assumption in the future now that I know how 'IR.exe' really works.

Regards,
Bill

gfb107 wrote:There is space (outside of the advanced code area, defined in the MultiMacro section of the RDF) for each key that supports multimacros to store

1. The number of macros defined for that key
2. The sequence number of the next macro to execute for that key (IR forces this to 1)

The multimacros themselves are stored within the advanced code area.
Multimacros have the macro bit (0x80) set in the type byte, but must also have a sequence number between 1 and 5 encoded in the high nibble (producing type values $9? - $D?). A sequence number of 0 is used for normal macros.

This part matches my understanding. If my testing indicates otherwise, I'll certainly speak up. EDIT: As of 14 Oct 2009, this explanation still matches everything I've seen and tested, and that now includes the new RCA RCRP05B remote.

I'd still like to know the meaning of the bit at 0x01 of the 2nd macro byte. I suppose if nobody knows, I'll eventually figure it out through testing. EDIT: I figured this out. See my edit in my earlier post on this page for details.

I'm also wondering (rhetorically) why a multi-macro cannot support 7 macros instead of just 5. Or maybe it can, on other remotes. I mean, there are 3 bits in that upper nybble to use where a value of zero means "non-multi-macro" and 1-7 (not just 1-5) could be used for 7 macros. It seems like an artificial limitation (by the remote control manufacturer) to me.

gfb107 wrote:For remotes that use AdvCodeBindFormat=LONG, macros (even multimacros?) can be device mode specific, in which case the low nibble contains the device mode index, where F means a global macro).

This part I don't know about, but plan to do some more testing to help my understanding of all this. I hope some of the experts will jump in here with some information. EDIT: As of 14 Oct 2009, more testing I've done confirms this to be the case. But I have not yet seen any remote that can handle DSMMs (Device-Specific Multi-Macros), and that now includes the RCA RCRP05B.

I'm a bit surprised that all of this isn't documented somewhere. I've used Don Grovestine's useful 'The WHAT and WHY of JP1' document, but it's dated March 2004 and shows its age for some things, like macro format. I've also used the excellent RDF spec document to advantage. But there are still missing pieces in my understanding that I'd like to fill in. Does anybody know of a source of documentation of these details?

Bill

I'm getting puzzled/worried by some of this discussion.

WagonMaster wrote:So, it seems to me as if the test for a macro is '(byte#2 & 0x80 == 0x80)'.

Certain remotes, the URC-7780/81 being examples, use a Type 2 macro coding in which the high nibble is 3, not 8. As far as I know, no remote that uses Type 2 coding yet has multimacros, but values 4-7 would be available for them. In Type 2 coding, high nibble values $8-$F signify timed macros, which no longer need a separate section in the flash as they do with Type 1 (the normal) coding.

WagonMaster wrote:I don't know what the significance of the '(byte#2 & 0x01)' bit is. I've seen macros where it is set and macros where it is not. Anybody know what that bit means?

I need to experiment some more, but I think that RMIR is at some (as yet undefined) point corrupting some of the 2nd bytes in macros, erroneously making them 0x80.

Bill, how were you looking at the value of the low nibble of that 2nd byte? For remotes with AdvCodeBindFormat=LONG, such as the RS15-135, IR.exe sets it always to $F. According to notes in the IR.exe source code, this nibble is not used internally in remotes, except for one remote which requires it to be $F. (This pre-dates my involvement.) Because of the way IR.exe operates (as in previous posting), when you load a flash ROM you should see $8F there, even if it was, say, $81 in the flash. RDF Spec 4 has a concept of internal special protocols (which is due to me), which use values $0-$E for this low nibble as the device code. Likewise for multimacros, $AF say is the 2nd macro of a multimacro but $AC is internal special protocol 2 for device with code $C. I hope RMIR is not going to do anything that is incompatible with this.

Note that it doesn't matter if the remote natively uses a value other than $F for the low nibble, provided that it doesn't actually test it, as by the time a special protocol is put in, it will have been through IR.exe and will have been set to $F. Again, I hope RMIR follows suit.

Edit: Oops, that sounds self-contradictory. The low nibble will be set to $F if IR.exe has parsed it as a macro, which it will do if there are no internal special protocols defined in the RDF. If there are such SPs then it will parse the flash as an internal SP and so write it accordingly, preserving the low nibble.
____________
Graham

I believe the internal IR.exe limit for multimacros is 3(based on the older remotes). The newer remotes seem to use 5.

Other uses for the type nibble are $C0 for device specific macro on the Vizio 1033 remote. $30 for FAVkey on URC-10820. $20 for Learn.

For remotes that do support Device Specific Macros, it will use the low nibble as the mode selector. Remotes that don't support DSM, will ignore the low nibble value. IR used to use 0 as the low nibble value but when the remotes with DSM appeared, IR switched over to using $F. I don't recall if we have an RDF entry for DSM support.

RMIR doesn't yet have support for MacroCodingType 2. So all discussion here is about AdvCodeBindFormat=LONG and MacroCodingType=1, even though not always explicitly stated.

However, please don't be worried that RMIR would do something incompatible with what IR does, because both MUST be compatible with how actual remotes work.

binky123 wrote:I believe the internal IR.exe limit for multimacros is 3(based on the older remotes). The newer remotes seem to use 5.

Sounds like we need an RDF entry for that, unless we want to base it on AdvCodeBindFormat as well.

Other uses for the type nibble are $C0 for device specific macro on the Vizio 1033 remote.

$C0 for DSM on the Vizio 1033 would conflict with multimacros if it supported multimacros, but according to the RDF it doesn't.

$30 for FAVkey on URC-10820.

RMIR doesn't fully support FAVkey, but is coded to recognize $30 as FAVKey.

$20 for Learn.

Unless I'm missing something, $20 for Learn doesn't really apply here as Learned Signals have their own section and there's no need to distinguish them by type from KeyMoves, Macros, MultiMacros, or DSMs. RMIR certainly isn't coded to recognize OR store $20 for LearnedSignals. But that could just be because of my ignorance.

For remotes that do support Device Specific Macros, it will use the low nibble as the mode selector. Remotes that don't support DSM, will ignore the low nibble value. IR used to use 0 as the low nibble value but when the remotes with DSM appeared, IR switched over to using $F. I don't recall if we have an RDF entry for DSM support.

If IR is always using $F, I would guess there isn't an entry for it. Guess it's time to add one.

mathdon wrote:Certain remotes, the URC-7780/81 being examples, use a Type 2 macro coding in which the high nibble is 3, not 8.

I (unintentionally) ignored the 'Type 2' macros in that comment. I actually knew about them from inspection of the 'IR.exe' source code, but have been focusing on 'Type 1' macros, which is what all of my remotes seem to use, I believe. Sorry for introducing the inaccuracy/confusion.

mathdon wrote:Bill, how were you looking at the value of the low nibble of that 2nd byte?

Well, initially, I was mostly using RMIR with occasional checks with 'IR.exe'. When I started seeing problems with unexpected data alterations in RMIR, I started using 'IR.exe' more often as sort of a "sanity check". But in my most recent testing, I'm now relying on a utility of my own that I know is not "fooling" me in any way -- it just dumps the raw flash memory, using the library code to read a flash page. In fact, use of my own utility is how I discovered that 'IR.exe' was re-ordering the macro 'type' bytes (byte #2) without actually re-ordering the other macro data, as described earlier in the thread. It's with that utility (confirmed with both 'IR.exe' and RMIR) that I've been seeing these low nybble values with the LSB set (e.g. 0x81, 0xA1, etc). FWIW, I've seen such values for a while now, even before I started digging into how macro data is actually formatted in flash memory.

mathdon wrote:For remotes with AdvCodeBindFormat=LONG, such as the RS15-135, IR.exe sets it always to $F.

At first I thought that something funny was going on, because I'm not seeing that here. But then I read your edit and things are clearer.

mathdon wrote:$AF say is the 2nd macro of a multimacro but $AC is internal special protocol 2 for device with code $C

OK, but how can the flash memory be unambiguously interpreted then, if the high nybble of the 2nd byte of a sequence in the 'advanced codes' section can be the same value and mean 2 different things entirely. I'm clearly missing something. It may have to do with my absolute ignorance of special protocols. What does byte #1 (the 'bound key' specification in a macro) mean to a special protocol sequence? Wait, I think I answered my own question below....

mathdon wrote:Edit: Oops, that sounds self-contradictory. The low nibble will be set to $F if IR.exe has parsed it as a macro, which it will do if there are no internal special protocols defined in the RDF. If there are such SPs then it will parse the flash as an internal SP and so write it accordingly, preserving the low nibble.

OK, that makes what you wrote pre-edit make a lot more sense in my case, because I'm definitely not seeing 0x8F (or any byte with the low nybble set to 0xF) in that 2nd byte of any macros. EDIT: Recent testing with my RCA RCRP05B remote shows that this is the only one of 3 remote types that I own which actually sets the low nybble (the device code of the device associated with the macro) to 0xF. My RS 15-135 inexplicably sets it to the device code, even though the macro is Device-Independent, and the URC-10820/URC-8820 set it to 0x0 (i.e. the byte is 0x80) always.

But I'm confused. If I believe the Grovestine document mentioned earlier, then Special Protocols are implemented as keymoves. Doesn't that take them completely out of the discussion about macros? That is, (I think) I can already detect a (Type 1) macro unambiguously from a keymove (by masking byte #2 with 0x80 and expecting the bit to be set for a macro), so if I'm dealing with macros, how can a Special Protocol enter into the picture? Sorry if I'm being obtuse, here -- I just don't understand.

gfb107 wrote:RMIR doesn't fully support FAVkey, but is coded to recognize $30 as FAVKey.

This could be my ignorance rearing its ugly head again, but I thought the "Fav" key was the same as a multi-macro. I really need to read and test all of this some more to be sure, I guess. I really wish all this stuff was better documented (i.e. not just in various snippets from the forum). The Grovestine document seems like a great start, if only it were updated for modern times.

Bill

WagonMaster wrote:I really wish all this stuff was better documented (i.e. not just in various snippets from the forum). The Grovestine document seems like a great start, if only it were updated for modern times.
Bill

I think you just volunteered to bring it up to date!

gfb107 wrote:

WagonMaster wrote:I really wish all this stuff was better documented (i.e. not just in various snippets from the forum). The Grovestine document seems like a great start, if only it were updated for modern times.
Bill

I think you just volunteered to bring it up to date!

I'd gladly bring it up to date if I had the requisite knowledge. But, as you can see from this thread alone, I don't.

I've tried to understand things by reading what's out there, but what's "out there" is often either incomplete, out-of-date, or just doesn't attempt to cover these topics at all. It often seems that too much of the "how it works" is buried in the bowels of the various forum threads and in the 'IR.exe' and RMIR code itself. I've certainly looked at both of those applications' source code, but there are so few actual comments in either of them, that understanding these somewhat complex issues, many of which have a long and changing history, is incredibly difficult for a newcomer like myself.

That's not to say that I won't update some of the documentation eventually, but I have so much more to understand, and it's coming in teeny-tiny bits, it seems.

Bill

As you can tell from my questions in this thread, I don't have a grasp of all this either. And I've been around JP1 since 2002, working on RM & RMIR since 2003!