I discovered that you can restrict the input of OBCs to e.g. <128
with the entry "CmdParms=OBC:7" in protocols.ini.
(How) can you restrict the input of EFC (Hex) values to that
corresponding OBCs < 128?
For instance:
Input of OBC=0 translates to EFC=018 (HEX=00) whether OBCs are restricted
to < 128 or not.
But in contrast to the "unrestricted case" where input of EFC=018
translates to OBC=0 (HEX=00) and EFC=010 translates to OBC=128 (HEX=01)
the "restricted case" produces OBC=0 (HEX=00) from EFC=018 and
input of EFC=010 translates to OBC=0 as well (but HEX=01).
It really can make a difference if you have Hex=00 or Hex=01
transferred to your learning RC to representing OBC=0
Therefore it is desirable to prevent the user from
entering "wrong" values (e.g. EFC=010/HEX=01) right away.
Is there a parameter in protocols.ini (or elsewhere) to accomplish
that task?
RemoteMaster - Data input problem
Moderator: Moderators
I don't know if RM includes the specific feature you request. Maybe Greg will answer.
But usually it doesn't make a difference.
If a bit within the hex command has a meaning, then we usually include its meaning in some column on the functions sheet, so that when you change the EFC or Hex command to change that bit, you'll see its effect in some other column.
Many OFA protocol executors simply ignore the least significant bit(s) of the hex command because they don't need them to construct the signal.
Sometimes the executor supports an option per command that we decide (for compatibility with KM, for compatibility with related executors in other models, or simply to reduce confusion) not to support on RM's functions sheet. In that case we may want a bit in the hex command controlled by a bit on the setup sheet rather than by a bit on the functions sheet. I think you can do that, but I forget how. If the user then sets the bit wrong in the EFC or hex column of the functions sheet, I don't know how agressively RM corrects it.
But usually it doesn't make a difference.
If a bit within the hex command has a meaning, then we usually include its meaning in some column on the functions sheet, so that when you change the EFC or Hex command to change that bit, you'll see its effect in some other column.
If you found a simple example with a 7 bit OBC, with no extra meaning for that extra bit, then it actually wouldn't matter if you have Hex=00 or Hex=01.spock wrote: It really can make a difference if you have Hex=00 or Hex=01
transferred to your learning RC to representing OBC=0
Many OFA protocol executors simply ignore the least significant bit(s) of the hex command because they don't need them to construct the signal.
Sometimes the executor supports an option per command that we decide (for compatibility with KM, for compatibility with related executors in other models, or simply to reduce confusion) not to support on RM's functions sheet. In that case we may want a bit in the hex command controlled by a bit on the setup sheet rather than by a bit on the functions sheet. I think you can do that, but I forget how. If the user then sets the bit wrong in the EFC or hex column of the functions sheet, I don't know how agressively RM corrects it.
The problem is that in that special case I wanted the 8th bit rather have
excluded from user access.
This easily can be done by restricting the OBCs.
But by entering EFC or HEX one can change the bit unintentionally.
In this special case the 8th bit of the HEX/EFC is actually interpreted as a
device bit.
If decodeIR uses exactly the same routine to calculate the Device and
EFC from the bits as RemoteMaster calculates the bits from the Device
and EFC, it will work however.
BTW, I'm working on a protocols.ini entry to that MC44107 code
and there the problem has occurred but it is present in other protocols too.
excluded from user access.
This easily can be done by restricting the OBCs.
But by entering EFC or HEX one can change the bit unintentionally.
In this special case the 8th bit of the HEX/EFC is actually interpreted as a
device bit.
If decodeIR uses exactly the same routine to calculate the Device and
EFC from the bits as RemoteMaster calculates the bits from the Device
and EFC, it will work however.
BTW, I'm working on a protocols.ini entry to that MC44107 code
and there the problem has occurred but it is present in other protocols too.
RM does not have a way to restrict the EFC value. By definition, EFCs are 8-bit values.
If there is a bit in the Hex command that comes from a Device parameter, RM can handle that using a TranslatorFromDev as one of the CmdTranslator entries.
The parameters are the same as for Translator, except that in the index applies to the device parms instead of the command parms.
If there is a bit in the Hex command that comes from a Device parameter, RM can handle that using a TranslatorFromDev as one of the CmdTranslator entries.
The parameters are the same as for Translator, except that in the index applies to the device parms instead of the command parms.
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Unfortunately it is just the other way round this time.gfb107 wrote: If there is a bit in the Hex command that comes from a Device parameter...
I need a bit from the Hex command going to the fixed data.
And since this is impossible AFAIK (at least with a built in protocol),
I wanted to make sure that the user can't change that bit at all by
mistake.