UEI Nokia32 Protocol

dsarens · Post by **dsarens** » Thu Feb 02, 2006 6:25 am

UEI have recently updated their internet download upgrades and I've come across the Nokia32 protocol. It has an ID of 0173h and is already incorporated in some of the newer OFA remotes.

Whilst someone on this forum had developed a Nokia32 protocol, it was a bit fiddly to use because the fixed data had to be manually translated and the EFCs had to be converted to 4-byte hex format.

The UEI protocol uses a fixed data of 4 bytes. The first byte is 00, the next two are the device and sub-device, and the last is the value of X (Misc) as reported by IR using decodeIR.dll.

I have successfully made an upgrade using the Nokia32 protocol for a Digifusion FVRT90 PVR which can be found here https://www.hifi-remote.com/forums/dload ... le_id=2763. This upgrade can be modified for other devices using this protocol.

mietde · Post by **mietde** » Thu Feb 02, 2006 6:47 am

Thanks.

mvtl9902 · Post by **mvtl9902** » Mon Oct 02, 2006 7:37 am

Thanks a lot dsarens.

Thanks to your explanations and file, I built myself the upgrade code for my PVR remote which uses nokia32 protocol.

Regards

johnsfine · Post by **johnsfine** » Wed Mar 14, 2007 11:10 am

I tested that protocol with my 8910 and it does produce nokia32 signals as described in post one of this thread.

Does anyone know the relationship between this pid 0173 and the pid 0173 in RM's protocols.ini file?

I tested that pid 0173 and I can't figure out what it does.

I'd like to add nokia32 to protocols.ini so building upgrades will be easier. But I'm uncomfortable changing pid 0173 in protocols.ini until I understand which variants do what.

BTW, further investigation of the Nokia32 pid 0173 gave the meaning of the first byte of fixed data:

0 = normal
1 = use the high bit of the X value as a toggle bit
2 = use the high bit of the X value as a release bit

To find out which you need, check multiple learns including some learns done with as short a press of the original remote button as possible:

If the X value is the same in every decode, you want 0.
If each learn has a single Nokia32 decode (or muiltiple identical Nokia32 decodes) and the X value alternates between keypresses between two values that differ by 128, you want 1.
If every learn starts with a decode with an X value less than 128 and a very short press yields a learn with a second decode, same as the first but with an X value 128 higher, you want 2.

Post by **The Robman** » Wed Mar 14, 2007 12:15 pm

John, the decodes for the AT&T Homezone show multiple sub-device codes, is this usual for Nokia32 signals or do we need a "combo" version.

Post by **The Robman** » Wed Mar 14, 2007 12:31 pm

johnsfine wrote:Does anyone know the relationship between this pid 0173 and the pid 0173 in RM's protocols.ini file?

The version in protocols.ini replicates the executor that's built into a handful of JP1 remotes (such as URC-3440, URC-8040, URC-8060). I assume the version in the upgrade file posted here is a more recent version.

johnsfine · Post by **johnsfine** » Wed Mar 14, 2007 12:36 pm

The Robman wrote:John, the decodes for the AT&T Homezone show multiple sub-device codes, is this usual for Nokia32 signals or do we need a "combo" version.

I just decoded that file. What I see is Device=34, Subdevice=208 in every decoded signal (A few signals didn't decode).

The X value is semi-randomly 38 or 166. I'm fairly sure that is the toggle behavior (value of 1 in the first byte of fixed data). It definitely is not a 0 or 2 in that byte, so either 1 is correct or it isn't supported.

The Robman wrote: The version in protocols.ini replicates the executor that's built into a handful of JP1 remotes (such as URC-3440, URC-8040, URC-8060). I assume the version in the upgrade file posted here is a more recent version.

When I tested the version in protocols.ini, it didn't produce nokia32 at all. I haven't yet figured out whether I had unreasonable fixed data for that version, or whether it is some other protocol that was issued with the same pid, or whether someone made a mistake when copying it into protocols.ini.

For all but the last case, we ought to make some decision about a variant name, so RM can understand that those remotes have a pid 0173 but don't have the right pid 0173 for nokia32 fixed data generated as discussed in this thread.

Selecting a variant name probably requires editing some rdf files, not just the protocols.ini file.

Edit: I looked more closely at the pid 0173 in protocols.ini. It is just wrong. I understand the mistake that was made when it was put there, and probably could fix it. But there is no point because we have a correct newer version. I don't have an easy way to test, but I believe the older version as it exists in the remotes Rob listed is correct and has the same behavior as the new version. I think it is only wrong in protocols.ini.

Post by **The Robman** » Wed Mar 14, 2007 1:37 pm

johnsfine wrote:I just decoded that file. What I see is Device=34, Subdevice=208 in every decoded signal (A few signals didn't decode).

You're right. I was looking at it in Notepad rather than Excel, so the columns where shifted over.

Post by **The Robman** » Wed Mar 14, 2007 8:22 pm

johnsfine wrote:When I tested the version in protocols.ini, it didn't produce nokia32 at all. I haven't yet figured out whether I had unreasonable fixed data for that version, or whether it is some other protocol that was issued with the same pid, or whether someone made a mistake when copying it into protocols.ini.

Just in case the fixed data was an issue, here's the fixed data for some official UEI setup codes that use $0173

02 21 A0 26 = Cbl/1356
02 20 C0 27 = Cbl/1483
01 22 90 80 = Cbl/1561
01 20 C0 26 = Cbl/1582
00 0E 40 28 = Sat/0867
00 0D 50 08 = Sat/1111
01 20 E0 26 = Sat/1259
01 21 60 26 = Sat/1455
01 22 90 00 = Sat/1561
01 21 90 26 = Sat/1591
00 0D 50 08 = Sat/1743
01 22 D0 26 = Vid/2045
00 0E 60 28 = TV/0614
00 0E 61 28 = TV/0617

Post by **The Robman** » Wed Mar 14, 2007 8:24 pm

johnsfine wrote:0 = normal
1 = use the high bit of the X value as a toggle bit
2 = use the high bit of the X value as a release bit

Do you have any recommendations as to how we should handle these variants in RM/KM and (where possible) DecodeIR?

mr_d_p_gumby · Post by **mr_d_p_gumby** » Wed Mar 14, 2007 9:18 pm

The Robman wrote:
johnsfine wrote:0 = normal
1 = use the high bit of the X value as a toggle bit
2 = use the high bit of the X value as a release bit
Do you have any recommendations as to how we should handle these variants in RM/KM and (where possible) DecodeIR?

FYI, When I added the URC-8206 to KM v9.06, I added supoort for both versions of PID 0173. At the time I uploaded PB files for both versions: variant 1 and variant 2.