Unknown protocol

[Tobinh]

I have a remote manufactured that controls my PVR.
http://www.interact.tv.com

The Remote appears to be made in Tiawan.
http://www.fwd.com.tw/products/remote/IACR/cftype.htm

I tried to decode the signals using IRtool and DecodeCCF. Both programs returned back RC5 dev:31 obc:63 efc:18 for every signal I tried to decode. If I am reading the raw code correctly, this does not look like RC5 or any other Protocol I can Identify. The pulses are way too short. It was recorded on a TSU2000 and from what I gather from other pages each unit is 23us. Am I correct?

Here are the signals I am trying to decode.

RawCode("Learned","0000 006d 0000 000e 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 002b 0012 001a 0012 0019 0012 001a 0012 0011 0012 0022 0012 0022 0012 0022 0012 0bf7");

RawCode("Learned","0000 006d 0000 000e 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 0011 0012 0022 0012 0019 0012 001a 0012 002b 0012 001a 0012 0022 0012 0022 0012 0bf7");

RawCode("Learned","0000 006d 0000 000e 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 001a 0012 0022 0012 001a 0012 001a 0012 0022 0012 001a 0012 0022 0012 0022 0012 0bf7");

RawCode("Learned","0000 006d 0000 000e 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 002b 0012 0022 0012 001a 0012 001a 0012 0011 0012 001a 0012 0022 0012 0022 0012 0bf7");

RawCode("Learned","0000 006d 0000 000e 0023 0011 0012 002b 0012 0011 0012 0011 0012 0011 0012 0022 0012 001a 0012 0019 0012 001a 0012 001a 0012 0022 0012 0022 0012 0022 0012 0bf7");

Any help would be much appreciated

Tobin.

[Tobinh]

OOPS...

Interact-tv

http://interact-tv.com

[The Robman]

Just out of curiosity, what's your end goal here? Are you trying to program a One FOr All remote with this info?

[Tobinh]

yes, 8012 2k with extender.

[johnsfine]

Do you have a URL for the CCF file you decoded.

I'll try to fix my RC5 decoder so it won't think this is RC5. But it isn't an easy protocol, so I think I would need a lot more samples in order to figure out what is going on.

Why do you think the pulses are way too short? They look pretty typical. To compute a pulse width you need to multiply the unit (that .23 uS you mentioned) by the wavelength (the 0x6D) and multiply that by each of the duration values 0x23, 0x11, 0x12, etc.

[Tobinh]

Ok, that explains a bit. I was unaware of the wavelength parameter, is there any other resource to explain this format? I tried looking on the web, and didn't find much.

here's the file.
http://groups.yahoo.com/group/jp1/files ... /tobin.ccf

I'll try to learn a bit more, but it may take a while. BTW my PVR also used an IR keyboard, however I havn't tried to capture the codes from it yet. I tried the acer keyboard protocol, but it didn't work. If you will also notice, this remote has a track ball. (Just to make it interesting!)[/url]

[johnsfine]

The Documentation for that form of Pronto hex is here:
http://www.remotecentral.com/features/irdisp1.htm

Where did you get that CCF file?

I just see 6 functions in that CCF, one more than you posted above. The original remote generates more than 6 different functions doesn't it?

Are the up, down, right and left in the CCF from buttons or are they from the trackball? I'd need many more samples to be sure, but if those are from the trackball I think it may have an analog duration component in the middle of the signal. That would be totally unlike anything we've seen in other protocols.

[Tobinh]

Yes, 33 + track ball. Sorry to spoon feed you, but here's "0-9" hope that help

http://groups.yahoo.com/group/jp1/files ... in_0-9.ccf

To this point I havn't been able to capture the track ball. So to answer your question the recorded signals are for the buttons.

I'll try to record the rest of the buttons later.

[Tobinh]

In the event that there is no nice neet package that this can fit in, has anyone pondered creating a raw format protocol? (I know what you're thinking, yea that would take up alot of space)

[johnsfine]

I'll try to record the rest of the buttons later.

So you have a Pronto or some emulation of one?

I'm pretty sure the menu command int that CCF was learned wrong. Can you operate the device with your Pronto? Please verify that the learned menu command doesn't work and try relearning it.

I think I see the pattern now. It's just a double-bit encoding (two bits encoded per burst).

That's a little harder than an ordinary protocol to create an executor for. I'll probably need to review some of the other protocols that encode two-bits per burst to see how best to achieve it.

[johnsfine]

First cut at irp notation before looking for check bytes etc.:

{38K,226}<2,-2|2,-3|2,-4|2,-5>(4,-2,D:8,F:16,2,-356)+

Other experts feel free to second guess me on that because I wasn't very careful in computing the above.

[johnsfine]

Assuming I have the irp notation roughly right, one could represent this in the normal one bit per burst (that ProtocolBuilder and the remote's basic IR engine can handle) by making fake bits:
0 = 0,-226
1 = 452,-452

There are 12 bit pairs in the irp description. Each bit pair would need to be translated to fake bits and would use from 1 to 4 fake bits by the following rules.

00 -> 1
01 -> 10
10 -> 100
11 -> 1000

I think there may be a way to make the IR engine do the above translation. If not, then it would need to be done either in S3C80 assempler in the protocol, or in Java code in RemoteMaster. If the engine doesn't translate then the result is variable length from the engine's point of view, so we'd need to include the lead out as a bit rather than as lead out.

12 double bits each taking up to 4 fake bits plus a lead out would add up to 49 bits. We probably could restrict it to less than that safely. But even 49 bits is OK for PB. The engine would then get a signal fixed length at the maximum length by tacking extra 0's on the end.

[johnsfine]

I looked up some details of Nokia protocol for comparison, since I though that would be the most similar protocol. It's a LOT closer to this than I remembered before looking up those details. I forget how Nokia is supported, but however that is done ought to be real easy to tweak to become this.

[johnsfine]

You may need to change batteries in the original remote before more learning.

Now that I understand the protocol, I can decode the bad learn on "menu" and reconstruct what it would have been if it were learned correctly. Comparing that to what you actually learned for menu indicates a learning error of a very specific type that is cause by weak batteries in the original remote. I don't know why other learns weren't affected. But weak batteries can get better and worse for a while before really dieing. I wouldn't trust them after seeing the menu learn.

[johnsfine]

I decoded all 16 commands in that CCF. I see a redundancy pattern that probably will be consistent through the remaining commands, so we probably don't need 16 bits of function (two byte hex command). A one byte hex command ought to be enough. The first 16 commands effectively use only 5 function bits.

The redundancy pattern is a little strange, so I'm not 100% comfortable with it.

The first function burst is the inverse of the 5'th consistently across all 4 possible values.

The second function burst is the inverse of the 6'th consistently across all 4 possible values.

The fourth function burst is always 1 and the 8'th always 2. 1 is the inverse of 2 (in 2-bit bursts) but that doesn't prove much, especially considering the third burst.

The third burst is either 0 or 1 and the 7'th is 1 when the third is 0 and 2 when the third is 1. That is not an inverse rule. So most likely the 7'th and 8'th bursts are redundant with the third and fourth bursts by some rule other than the rule used to get the 5'th and 6'th from the first and second.