Page 1 of 1

PID $019B: Konka protocol

Posted: Sat Jan 28, 2006 4:47 pm
by The Robman
All of the other Akai TV remotes that I've captured use either the NEC1 protocol or the Konka protocol, but I've just captured one Akai remote that uses an as yet unidentified protocol.

I've loaded the learns to the Diagnosis Area: click here

Here's how I've decoded the signals:

Code: Select all

freq = 37.7
lead in = +3050 -3020
leadout + +500 -3970 +500 -23000
0 = +500 -1500
1 = +500 -2500
format: MSB

+3046 -3020 00000010 00001011   +500 -3946 +500 -23154 power
+3046 -3020 00000010 00010100   +500 -3976 +500 -23232 mute
+3046 -3020 00000010 00000001   +500 -3974 +500 -23234 1
+3046 -3020 00000010 00000010   +500 -3976 +500 -23210 2
+3046 -3020 00000010 00000011   +500 -3960 +500 -23156 3
+3046 -3020 00000010 00000100   +500 -3960 +500 -23090 4
+3046 -3030 00000010 00000101   +500 -3974 +500 -22948 5
+3046 -3028 00000010 00000110   +500 -3960 +500 -22972 6
+3046 -3020 00000010 00000111   +500 -3976 +500 -23240 7
+3046 -3020 00000010 00001000   +500 -3974 +500 -23184 8
+3046 -3020 00000010 00001001   +500 -3974 +500 -23156 9
+3046 -3020 00000010 00000000   +500 -3960 +500 -23092 0
+3046 -3028 00000010 00001110   +500 -3974 +500 -22998 prev ch
+3046 -3028 00000010 00001010   +500 -3946 +500 -22948 display
+3046 -3020 00000010 00010111   +500 -3974 +500 -23106 sleep
+3046 -3020 00000010 00011110   +500 -3974 +500 -23160 browse
+3046 -3028 00000010 00011111   +500 -3946 +500 -23028 pic
+3046 -3028 00000010 00001100   +500 -3974 +500 -23190 clear
+3046 -3020 00000010 00001111   +500 -3960 +500 -23146 tv/av
+3046 -3020 00000010 00010001   +500 -3946 +500 -23000 ch+
+3046 -3028 00000010 00010000   +500 -3946 +500 -22994 ch-
+3046 -3020 00000010 00010011   +500 -3946 +500 -23206 vol+
+3046 -3020 00000010 00010010   +500 -3948 +500 -23208 vol-
+3046 -3028 00000010 00010101   +500 -3974 +500 -22946 menu
+3046 -3020 00000010 00011100   +500 -3946 +500 -23112 sound
+3046 -3020 00000010 00001101   +500 -3948 +500 -23210 ccd
+3046 -3028 00000010 00011011   +500 -3974 +500 -23186 stereo
Now for my question. Is there a way to do this 2-part leadout using the IR engine or do you have to send the final pair seperately?

Re: New protocol for DecodeIR (and a question)

Posted: Sat Jan 28, 2006 9:05 pm
by johnsfine
The Robman wrote: Is there a way to do this 2-part leadout using the IR engine or do you have to send the final pair seperately?
I never had a 100% understanding of the IR engine, so maybe there is a way, but I don't think I ever knew a reasonable way to do that.

Posted: Sat Jan 28, 2006 9:12 pm
by The Robman
There is at least one feature of the IR engine that we haven't documented, and that's the one that lets you send an NEC1 style signal rather than an NEC2 style signal. You'd think that we would have documented that one by now, but we haven't.

Posted: Sat Jan 28, 2006 10:34 pm
by mr_d_p_gumby
The Robman wrote:...the one that lets you send an NEC1 style signal rather than an NEC2 style signal...
Well, it's still not documentation, but take a look at the PB file for the Apple iPod Dock that I recently posted. It uses the flags to make an NEC1-style repeat, and not just for the S3C8. I sure could have used that documentation! :lol:

Posted: Thu Feb 18, 2010 4:54 pm
by The Robman
I just stumbled across this old post about the "Konka" protocol and it appears that it never did get added to DecodeIR, so here's another one for you Graham if you're interested.

The official UEI executor for this is $019B.

I don' think it ever got added to RM either, but it is in KM.

Posted: Fri Feb 19, 2010 8:54 am
by mathdon
The Robman wrote:Is there a way to do this 2-part leadout using the IR engine or do you have to send the final pair seperately?
This appears to be a version of what you have documented with bits 5 and 6 of the R29 block both set - Lead-in burst, One-on, Lead-out. In the HCS08 engine these timings are only default ones, they have their own memory addresses and are only initialised to be a lead-in burst and One-on. A protocol can modify that data and so should be able to send the double lead-out you have described.
_____________
Graham

Posted: Fri Apr 02, 2010 7:11 am
by mathdon
The Robman wrote:I just stumbled across this old post about the "Konka" protocol and it appears that it never did get added to DecodeIR, so here's another one for you Graham if you're interested.
The Konka protocol is supposed to be supported by DecodeIR, i.e. there is code for it, so if it doesn't decode it then it sounds as if there is a bug. I will look into it. I'm looking at unusual protocols for other reasons at present, and Konka is one of those.
_________________
Graham