JP1 Remotes

While researching the Thomson protocol in this thread I discovered that there are two versions of the $004B executor out there. The original version split the 12 bits of data 6-6 between device code and OBC, whereas the more recent versions split it 5-7.

There are two versions in protocols.ini where the basic version is 6-6 and there's a "VariantName=7" version which also splits the data 6-6 but it uses the 5-7 executors. The problem with this is it doesn't let you vary the data in that cross-over bit, which was why UEI changed the split in the first place.

The device mentioned in the thread above has variable data in that bit.

I had to switch to KM and use "manual settings" to generate the upgrade for the user, but obviously it would be preferable if protocols.ini could be changed to allow for variable data in that bit, I just don't know how to do it.

Also, I believe the RDFs for the following 3 remotes should be updated to use the variant=7 version of the executor:

Dreambox V2
URC-3440
URC-7562 B01

According to my records, the following remotes use the 004B:7 variant of the Thomson executors:

I think this is the corrected protocols.ini entry for variant 7:

[Thomson]
PID=00 4B
VariantName=7
DefaultCmd=00
DevParms=Device:5=0
DeviceTranslator=Translator(lsb,comp,0,5)
FixedData=00
CmdParms=OBC:7=0
CmdTranslator=Translator(lsb,comp,0,7)
DefaultCmd=00
Code.S3C80=76 76 11 8B 0E C5 41 05 07 00 F2 03 DC 00 F2 08 \
BE 9C 40 31 02 27 07 03 31 C2 8D 01 46
Code.HCS08=20 11 3C 3C 11 C5 41 05 07 00 E5 04 01 00 E5 08 F2 9C 40 01 B3 06 B6 60 A8 08 B7 60 CC FF 5F

Can some one verify that it produces the expected results?

Greg, thanks for the fix.

Mike,
At first I thought this was a current post, but then I checked the post date. The last list that Mike gave me says that the following Remotes use variant 7

10181018 URC-39860 B00
10211021 URC-8206
10231023 URC-8204
10261026 URC-8203
10381038 Dreambox V4
10481048 URC-8210
10621062 URC-7780
10691069 Dreambox V5
10751075 URC-7555
10951095 URC-6022
11131113 URC-9040
11221122 URC-8305
11311131 URC-7781
11411141 Arcam CR100
11421142 URC-8308
11691169 URC-8350
30293029 URC-7950
30383038 Cricket
30583058 URC-7525
ECL0ECO0 URC-3440
EKA4EKA0 URC-8040
EM60EM60 URC-7562B01
ESPBESP2 Dreambox Keyboard
KAMEKAM0 URC-8060
LATLLAT0 Mundial 4
OLVAOLV0 DreamboxV2
OUKAOUK1 Dreambox V3

Slingbox PK
Slingbox RV

On my machine, which may not have the latest RDF's, 15 RDF's have the wrong variant for this protocol.

gfb107 wrote:I think this is the corrected protocols.ini entry for variant 7:

I don't have time to investigate beyond what I just read in this thread. But I'm worried that this change is moving away from the intended design of protocols.ini

A name such as "Thomson" in protocols.ini should represent as consistent as possible relationship between the Device and OBC numbers specified in RM and the signal that is sent.

That consistent relationship should be more important than getting the maximum range of possibilities out of a specific executor.

I don't see anything to tell me whether this added flexibility (7 bit OBC) serves any actual device.

If we really want a protocol.ini entry for Thompson with 7 bits variable and a different one for Thompson with six bits variable, they should have different names.

Even with different names, we should try to get the definition of the Device/OBC split consistent between those names and between protocols.ini, DecodeIR and hopefully KM.

If we define 6 OBC bits but a variant has 7 bits variable, that is a "mini-combo" variant in which you should select one base device number on the setup sheet creating a two device selection item in a column of the functions sheet.

If we define 7 OBC bits but a variant has only 6 bits variable, that should require a check box or similar choice on the setup sheet for which of two OBC ranges is supported.

I think Greg's proposed changes to protocols.ini would change the OBC values, so that's not really the best way to go. I think the mini-combo approach is the right one to follow.

OK, please explain in more detail.
Here's what I'm getting:
We're going to keep the 6-bit OBC.
The device number will be 5 bits.
There will be another command parameter (coded into the hex cmd),
allowing the user to choose between the specified device number and a second device number. The second device number is the specified device number + 64.
The protocol name should be changed to something like "Thomson Combo"

Is that right?

That sounds right, except I don't see the need for a new name. I think John just suggested using a new name if you were going to proceed with the entry that would change the OBCs.

I think we can continue to call this Thomson, but like you said, a new column will appear where the user can select either the entered device code or the +- 64 version.

Try this: Please double check the cmd hex generation to make sure it's correct.

It's close but not exact. With the device code set to 3, the fixed data should be "30". Plus, it looks like the OBC binary is off by 1 position. For example, while OBC 0 correctly translates to hex "FE", OBC 2 should translate to hex "DE" but instead OBC4 translates to "DE".

Also, when you're converting a KM file, would it be possible to have the new column default to the entered device code. When I imported this KM file the new column defaulted to device code 35 instead of device code 3, so I had to change every entry.

The Robman wrote:It's close but not exact. With the device code set to 3, the fixed data should be "30".

OK, I obviously don't know the correct encoding for the device number. I thought we had a 5-bit device number, encoded lsb-comp.
3 (decimal) => 00011 (binary) => 11100 (binary-comp) => 00111 (binary lsb-comp) => 0011 1000 (filled to 8 bits) => 38 (hex)

Is it really only a 4-bit device number?

Plus, it looks like the OBC binary is off by 1 position. For example, while OBC 0 correctly translates to hex "FE", OBC 2 should translate to hex "DE" but instead OBC4 translates to "DE".

I had the OBC encoded before the device select bit, but looks like it should be other way around. The fix for that is:

CmdTranslator=Translator(lsb,comp,0,6,1) Translator(comp,1,1,0)

Also, when you're converting a KM file, would it be possible to have the new column default to the entered device code. When I imported this KM file the new column defaulted to device code 35 instead of device code 3, so I had to change every entry.

The fix for that is:

gfb107 wrote:

The Robman wrote:It's close but not exact. With the device code set to 3, the fixed data should be "30".

OK, I obviously don't know the correct encoding for the device number. I thought we had a 5-bit device number, encoded lsb-comp.
3 (decimal) => 00011 (binary) => 11100 (binary-comp) => 00111 (binary lsb-comp) => 0011 1000 (filled to 8 bits) => 38 (hex)

Is it really only a 4-bit device number?

I don't know the answer to that, I'll need to research how we came up with the device codes for this protocol. All I know is that the current versions of both RM and KM produce hex code "30" when device code 3 is entered.

Here's another version to try.

It uses the device translators from the original Thomson protocols.ini entry, which doesn't really make sense to me.
The first one takes the 4 least signifcant bits ( msb bits 0-3) of the device number and uses lsb-comp encoding to store them at lsb bits 0-3 of the fixed data. So far so good, just a 4-bit device number.

The second translator takes msb bit 5 of the device number and stores it (comped) into lsb bit 5 of the fixed data. What's that for? What happened to (msb) bit 4? Looks to me like KM just uses a 4-bit device number.

Here's the complete protocols.ini entry:

The Robman wrote:

gfb107 wrote:Is it really only a 4-bit device number?

I don't know the answer to that, I'll need to research how we came up with the device codes for this protocol. All I know is that the current versions of both RM and KM produce hex code "30" when device code 3 is entered.

I just dug up an IR file with Thomson signals and compared it to John Fine's description of the Thomson protocol, so I can now see what's going on.

John has defined the signal as such:
{33k,500}<1,-4|1,-9>(D:4,T:1,D:1:5,F:6,1,^80m)+

Which means that he considers it to have a 5-bit device code where the first 4 bits (left to right) are defined in the fixed data and the 5th bit is defined in the first variable bit. The next 6 variable bits are the OBC. The last 4 fixed bits are always zero. The first bit in the last four will get re-used as the toggle bit and the remaining 3 bits are ignored. The last variable bit is also ignored.

Having said all that, I think our representation of the Thomas protocol is un-necessarily complicated, but I suppose it's too late to change it. I don't see any logical pattern in the OBCs that shows that it really matters how we interpret the OBCs. Therefore, if we were just starting this, I would have decided that it has a 4-bit device code and a 7-bit command code. However, if we were to do that now, all the OBCs in the current files would be wrong.

I suppose one option would be to consider the 1st variable bit to be the 7th OBC bit, rather than adding it to the device code, so the bits would be "6012345". That way, all the current OBCs would be correct, except for the cases where the 2nd device code is needed, in which case they would be +64.

If there is consensus to do that, Graham would need to change DecodeIR accordingly.

OK. Here it is. 4-bit base device number. 5th bit is selectable as a command parameter and encoded in the hex command.

[Thomson]
PID=00 4B
VariantName=7
DefaultCmd=00
DevParms=Device:4=0
DeviceTranslator=Translator(lsb,comp,0,4)
FixedData=00
CmdParms=OBC:6=0,Dev:0|1
CmdTranslator=Translator(lsb,comp,0,6,1) Translator(comp,1,1,0)
CmdParmInit=ParmInitializer(1,0,5,1)
DefaultCmd=80
Code.S3C80=76 76 11 8B 0E C5 41 05 07 00 F2 03 DC 00 F2 08 \
BE 9C 40 31 02 27 07 03 31 C2 8D 01 46
Code.HCS08=20 11 3C 3C 11 C5 41 05 07 00 E5 04 01 00 E5 08 F2 9C 40 01 B3 06 B6 60 A8 08 B7 60 CC FF 5F