RMIR v3.0 Major new release!

[mathdon]

Personally, I believe this shouldn't be controlled by an input parameter. If the NEC sub-device is the complement of the device code, it means there isn't a sub-device, so there shouldn't be a parameter where you can request that the program mis-represent the data. I believe the program should test for this and only display a sub-device when necessary, just like how we only display OBC2 for NEC-f16 signals, if OBC2 is the complement of OBC1, we call it NEC.

Actually, I agree with you. The problem with IrpTransmogrifier in RMIR is that you have a binary choice, you either display all parameter defaults or none of them. There are many defaults that need to be displayed, as unlike this subdevice issue, they are defaults for values unrelated to the value of other parameters. I now recall that is why I set "keep" in RMIR.

I will try add code to RMIR to sort this out for NEC protocols. Is this an issue specific to NEC protocols, though, or should RMIR suppress subdevice values whenever they are the complement of the device code? I am not sufficiently knowledgeable of protocols in general to know the answer. Do you? In the absence of other guidance I will try to make it specific to NEC.

[The Robman]

Personally, I believe this shouldn't be controlled by an input parameter. If the NEC sub-device is the complement of the device code, it means there isn't a sub-device, so there shouldn't be a parameter where you can request that the program mis-represent the data. I believe the program should test for this and only display a sub-device when necessary, just like how we only display OBC2 for NEC-f16 signals, if OBC2 is the complement of OBC1, we call it NEC.

Actually, I agree with you. The problem with IrpTransmogrifier in RMIR is that you have a binary choice, you either display all parameter defaults or none of them. There are many defaults that need to be displayed, as unlike this subdevice issue, they are defaults for values unrelated to the value of other parameters. I now recall that is why I set "keep" in RMIR.

I will try add code to RMIR to sort this out for NEC protocols. Is this an issue specific to NEC protocols, though, or should RMIR suppress subdevice values whenever they are the complement of the device code? I am not sufficiently knowledgeable of protocols in general to know the answer. Do you? In the absence of other guidance I will try to make it specific to NEC.

Yes, I think you can apply this to all NEC variants, the rule should simply be, if the sub-device is the complement of the main device, don't display it.

Just for my information, what does the term "default" mean in this context? Assuming one of its meanings is, the default sub-device is the complement of the main device, what are its other meanings? The only other fields in an NEC signal are OBC1 and OBC2, where if OBC2 is the complement, you don't display it (but you also change the name of the protocol).

Or is this a global switch that applies to all protocols, not just NEC?

[The Robman]

What about if someone is setting up an NEC-f16 upgrade which is a mix of f16 signals and regular NEC signals, do they always need to specify the device and OBC complements, or will RMIR take care of those details?

Actually, I just tried it, I selected NEC-f16 and started a new function, I entered 0 as the device code (so 255 should be the default sub-device code) but when I tabbed to the next field, the sub-device defaulted to 30. Then I tried entering 0 as OBC1 and tabbed out (so again, 255 should be the default OBC2 value) but it defaulted to 0.

This is the only scenario that I can think of where a user might need to know what the complement values are, and to be honest, I'd rather have RMIR let those columns default to the complements, if possible, than depend on the user to figure them out, especially if that brings us back to needing to display the complements for all NEC signals.

[Barf]

The problem with IrpTransmogrifier in RMIR is that you have a binary choice, you either display all parameter defaults or none of them. There are many defaults that need to be displayed, as unlike this subdevice issue, they are defaults for values unrelated to the value of other parameters.

Sorry, I do not follow you here. Except for toggles, there are very few defaults in the protocols of IrpProtocols.xml. Can you give a detailed example of when the removal removes too much? I suspect there is a misunderstanding here.

Just for my information, what does the term "default" mean in this context?

In the IrpDefinition of a protocol, in IrpProtocols.xml, there may be a default in the ParameterSpec. For example, NEC1:

Code: Select all

{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)*) [D:0..255,S:0..255=255-D,F:0..255]

The ParameterSpec for S reads

Code: Select all

S:0..255=255-D

meaning that if S (subdevice) does not have a value, the value 255-D is used. Documentation.

[Barf]

What about if someone is setting up an NEC-f16 upgrade which is a mix of f16 signals and regular NEC signals, do they always need to specify the device and OBC complements, or will RMIR take care of those details?

Actually, I just tried it, I selected NEC-f16 and started a new function, I entered 0 as the device code (so 255 should be the default sub-device code) but when I tabbed to the next field, the sub-device defaulted to 30. Then I tried entering 0 as OBC1 and tabbed out (so again, 255 should be the default OBC2 value) but it defaulted to 0.

This is a completely different issue. The defaults for the values for an executor are taken from protocols.ini. For NEC1-f16 it says

Code: Select all

CmdParms=OBC1=0,OBC2=0

which, as I understand it, explains the behavior.

[The Robman]

What about if someone is setting up an NEC-f16 upgrade which is a mix of f16 signals and regular NEC signals, do they always need to specify the device and OBC complements, or will RMIR take care of those details?

Actually, I just tried it, I selected NEC-f16 and started a new function, I entered 0 as the device code (so 255 should be the default sub-device code) but when I tabbed to the next field, the sub-device defaulted to 30. Then I tried entering 0 as OBC1 and tabbed out (so again, 255 should be the default OBC2 value) but it defaulted to 0.

This is a completely different issue. The defaults for the values for an executor are taken from protocols.ini. For NEC1-f16 it says

Code: Select all

CmdParms=OBC1=0,OBC2=0

which, as I understand it, explains the behavior.

It's a related issue in the sense that, if a user is trying to create an upgrade for a device that uses a mix of NEC and f16 signals, the current version of the executor in protocols.ini requires them to enter the complement values for the NEC signals. You see what I mean? Which might lead us back to wanting to display them for NEC signals, even when they're not necessary. So, to avoid that, I was suggesting that the f16 entries in protocols.ini be tweaked so that the sub-device and OBC2 default to the complement of the device and OBC1 codes.

[mathdon]

Sorry, I do not follow you here. Except for toggles, there are very few defaults in the protocols of IrpProtocols.xml. Can you give a detailed example of when the removal removes too much? I suspect there is a misunderstanding here.

Not a misunderstanding, but a problem with my memory of something I did a long time ago. I should not have said "many". I want toggling learned signals to display the toggle value even when it is the default. It is confusing to have one signal showing T=1 and the next not showing the T value when it is the default of 0.

[The Robman]

I want toggling learned signals to display the toggle value even when it is the default. It is confusing to have one signal showing T=1 and the next not showing the T value when it is the default of 0.

While I too would like to see the T=0 value displayed, if it's a binary choice, I would rather lose the T=0 and not have default NEC sub-device codes displayed, than have T=0 *and* have default NEC sub-device codes displayed.

[mathdon]

It is a binary choice in IrpTransmogrifier but I have added code in RMIR to suppress default subdevice values for NEC protocols, so you can have it both ways! I had not intended to issue RMIR v3.1.0 as a development version, but will now do so, hopefully tomorrow, so you (and others) can test if the NEC changes meet your needs.

[The Robman]

Thanks Graham.

[Barf]

Graham, I am not convinced over your handling of toggles. Due to the nature of toggles, it appears to me that almost always the correct behavior would be remove the toggle parameter, instead of ensuring that it is displayed uniformly. What if the signal collected contains the same signal, both with T=0 and T=1?

In IrScrutinizer there is a parameter "Ignore T on parametric learns"; if true, parameters named "T" are removed before entering it as parametric learns.

So, if you decide to nuke the Ts, you can enable the removal of defaulted parameters without any bad side effects.

[The Robman]

Showing the toggle value won't lead to the user programming an RC5 upgrade incorrectly, and there might be cases where knowing the value is useful, so I'm in favor of showing it.

[mathdon]

Due to the nature of toggles, it appears to me that almost always the correct behavior would be remove the toggle parameter

It depends on what use you have for the learned signals. If you are viewing learns from an executor that toggles to see that it behaves as expected, you want to see the toggle values. I can see no harm in showing them when they are not needed, but situations like this where they are needed. So RMIR will continue to display toggle values.

It's a related issue in the sense that, if a user is trying to create an upgrade for a device that uses a mix of NEC and f16 signals, the current version of the executor in protocols.ini requires them to enter the complement values for the NEC signals. You see what I mean? Which might lead us back to wanting to display them for NEC signals, even when they're not necessary. So, to avoid that, I was suggesting that the f16 entries in protocols.ini be tweaked so that the sub-device and OBC2 default to the complement of the device and OBC1 codes.

There is a problem in RMIR that has been there forever, that calculated default values such as complements of other values work OK with Device Parameters but not Command Parameters. So the only f16 case where I think it is OK to change a fixed default to a complement is the subdevice in NEC1-f16 2Fixed, which I have done for v3.1.0.

To handle the rare case where it is desired to see default subdevice values for NEC protocols, I will make it selectable. There will be a menu item "Suppress NEC default subdevices" in RMIR Options > Advanced menu and also in RMDU Options menu that is Selected by default. When it is desired to see default subdevice values, simply deselect this item.

[The Robman]

To handle the rare case where it is desired to see default subdevice values for NEC protocols, I will make it selectable. There will be a menu item "Suppress NEC default subdevices" in RMIR Options > Advanced menu and also in RMDU Options menu that is Selected by default. When it is desired to see default subdevice values, simply deselect this item.

If you haven't already done the coding for this, I would suggest to not bother. I only brought up the subject as I'd like to make things easier for the non-expert user (plus making it easier for me too), but the non-expert is never going to know to dig into a deeply buried menu item to make a change like that. I doubt I'll ever use it either as, if I know I need to enter a complement value, I'll just copy the data to Excel and have it calculate them for me and copy it back.

[mathdon]

I have now posted development build RMIR v3.1.0 in the RMIR Development folder on SourceForge. This is issued to allow testing prior to the release of RMIR 3.1, which will be this build unchanged if no issues are found with it, or build 1 if changes are needed.

The main change in RMIR v3.1 is the use of JCommander to parse command line arguments. This has required splitting GUI creation from RemoteMaster.java into a new file GuiMain.java. It has allowed scaling to be set within RMIR as a "-scaling" argument rather than the previous ugly way of using a Java property.

Following the above discussion, it adds an item "Suppress NEC default subdevices", selected by default, to RMIR menu Options > Advanced to suppress SubDevice values for NEC protocols that are the complement of the Device code. Rob, you may not find it useful to have this option selectable, but I do so I have implemented it. Switching this option acts immediately, so you can have the Learned Signals panel displayed with suppressed defaults, deselect the option to have a quick look at the default values then reselect it to hide them again.