I need an IQ transplant

usblipitor · Post by **usblipitor** » Tue Jan 06, 2004 12:46 pm

I bought a remote 4in-1out audio/video selector from ebay and the remote has a protocol that DecodeIR has not seen yet. I've been looking at it for a while and have come to the conclusion that am too stupid to figure it out. Sigh. I wish I had JohnSFine's brain.

One thing about the remote and the device - you have to press and hold the buttons for about a second or so to get the device to respond. Just press-and-release does nothing. Chinese-made POS.

Here is a picture of the device. Kind of ugly, don't you think?

-Steve

jon_armstrong · Post by **jon_armstrong** » Tue Jan 06, 2004 1:48 pm

My preliminary guess is {618,32.7k}<1,-3|3,-1>((D:8,D:8,F1:8,1,-31),(D:8,D:8,F2:8,1,-31)+)

CBL2 command has a one time segment where F1=8 and a repeating sement where F2=12. There may well be a relationship betweeen F1 and F2. The other F2 values appear to be 2, 32, and 128.

In order to capture the one time signal (and it could be a fluke) learn the commands by just a hard tap on the OEM remote.

If it does have a different non-repeat and repeat segment, then it may still only require the repeat segment for recognition and that can easily be done in PB.

Post by **The Robman** » Tue Jan 06, 2004 2:03 pm

And here's what those signals look like in binary form:

01010101 01010101 01000000
01010101 01010101 00110000
01010101 01010101 00000100
01010101 01010101 00000001

usblipitor · Post by **usblipitor** » Tue Jan 06, 2004 7:24 pm

Jon and Rob,

Thank you both very much! I have been studying your posts and am starting to get it. I am just a little slow.

I know I should know this, but tell me again why we read the binary numbers backwards:

01000000 = 2
00110000 = 12
00000100 = 32
00000001 = 128

(I therefore would also read the 01010101 backwards, and get a device number of 170, right ? Would I select LSB option in PB ?)

Thank you both again,
-Steve

johnsfine · Post by **johnsfine** » Tue Jan 06, 2004 7:35 pm

Most computer equipment use LSB (least significant bit first) when transmitting data over serial (single bit wide) media. Some IR signals are LSB, some are MSB, but more are LSB, so we tend to assume LSB unless we see evidence of MSB.

The LSB option in PB only affects some advanced features (mini combiner). It has no effect on ordinary protocols. You choose the real LSB vs. MSB when you create a manual upgrade in KM, or create a protocols.ini entry for RM.

jon_armstrong · Post by **jon_armstrong** » Tue Jan 06, 2004 7:46 pm

usblipitor wrote: I know I should know this, but tell me again why we read the binary numbers backwards:

01000000 = 2
00110000 = 12
00000100 = 32
00000001 = 128

The bits are recorded in the order transmitted. Most but not all protocols transmit LSB first. we generally try to make sense out of them, like making the numerals go up in value. In this case it looks like the comands are LSB first or backwards.

I therefore would also read the 01010101 backwards, and get a device number of 170, right ?

Yes.

Would I select LSB option in PB ?)

No, and other than when the mini-combiner is selected there is no entry for that. PB and UEIC protocols don't care which order the bits are in. They do care where the byte boundries are (bits per byte settings etc.)

The protocol DEFINITIONS do care a lot about bit order and the default is LSB first unless otherwise noted. There would be an MSB in the first expression in {}.

KM Master also cares (usually) about bit order and it makes the conversion if you enter OBC values.

I'll be glad to help and normally I would have just created it and posted it for most people, but I figured you wanted to do it yourself.

Also, don't forget to learn the commands again to see if we get that one time segment with a different OBC.

usblipitor · Post by **usblipitor** » Tue Jan 06, 2004 10:35 pm

Many many thanks to Rob and Jon and John!

The new device upgrade works and I uploaded it to misc dev upgrade folder.

Upon doing so, I found that this device upgrade was already done, twice even.

, by the famous hanarmco2000 and also by alehaz. The one by alehaz, that says it was tested, also works for my unit (I have not tested the untested hanarmco one yet).

My question is this: alehaz uses a different protocol upgrade than I do. Upon copying his upgrade into Protocol Builder and pressing decode, protocol builder asks me about a duplicate name called error, then I click yes or no, but either way when I click decode, nothing happens.. what am I doing wrong?

The protocol I am trying to decode from alehaz is as follows:
Upgrade Protocol 0 = 01 26 (S3C8+)
4D 9F 21 8B 14 87 51 08 08 01 2C 03 70 03 84 01
18 24 54 FF FF FF FF FF 03 8D 01 46
End

I have learned several things today. I learned that for some reason, OBCs work and EFCs did not work. I learned that I needed to put in the frequency after all. I learned that if I leave the duty cycle blank, it does not seem to work, and 33 or 50 both work, but 100 always makes the protocol builder throw up. I learned that it is always a good idea to check in the device upgrade folder first, no matter how bizarre and rare the device may seem to be. I learned that if I build a protocol and it does not work, using another remote to learn the non-working signal is the fastest way to find out whats wrong and fix it. And I have learned that even in version 3.00 of PB, I still cannot decode protocols, no matter how many times I press the decode button.

Anyway, many many thanks to John, Jon and Rob for their help!

(Also, happy birthday to me for the remaining 23 minutes of today!)

gjarboni · Post by **gjarboni** » Tue Jan 06, 2004 10:48 pm

usblipitor wrote:(Also, happy birthday to me for the remaining 23 minutes of today!)

Happy Birthday! And don't forget, it's still your birthday for a while longer in other timezones. (until you get to that date line thingy). Be sure to exact some birthday tribute from those in other parts of the world

gjarboni · Post by **gjarboni** » Tue Jan 06, 2004 10:50 pm

usblipitor wrote:And I have learned that even in version 3.00 of PB, I still cannot decode protocols, no matter how many times I press the decode button.

Oh and about your question -- first you might want to try the decode again with a freshly opened PB v3.00. Make sure you do "Paste Special -- Values" when you paste the protocol from KM (trying to paste the Excel cells will cause all kinds of problems.

If that doesn't work try PB 1.16 (or whatever the latest v1 version is).

usblipitor · Post by **usblipitor** » Tue Jan 06, 2004 11:00 pm

Pasted special values. Did not get the message about the error variable, but still "decode" button does nothing. Sigh.

Thanks for the suggestion though!

mr_d_p_gumby · Post by **mr_d_p_gumby** » Tue Jan 06, 2004 11:36 pm

usblipitor wrote:Pasted special values. Did not get the message about the error variable, but still "decode" button does nothing. Sigh. Thanks for the suggestion though!

Don't give up, PB v3.01 will be coming to the rescue soon, with (hopefully) a more functional Decode button. We decided the error thingy wasn't a good thing to keep after all.

usblipitor wrote:I learned that I needed to put in the frequency after all. I learned that if I leave the duty cycle blank, it does not seem to work, and 33 or 50 both work, but 100 always makes the protocol builder throw up.

PB can't calculate the frequency until you enter the duty cycle, so if the protocol requires a carrier, you have to enter both. If you don't know what duty cycle it should be, start by entering 30. You should never enter 0 or 100 (that would translate to no carrier).

In the meantime, play with this (copy & paste to a .txt file):

PB Version:,v3.01,Steve'sAVSelector,,,,,,,,
Remote:,S3C8+ (New),None,device,sub-dev,parm1,parm2,parm3,parm4,parm5,parm6
Protocol ID:,01 26,dev2,,,,,,,,
Frequency (Khz):,33.30,dev3,,,,,,,,
Duty Cycle %:,32,dev4,,,,,,,,
Signal Style:,LSB-Comp,Notes:,,,,,,,,
Signal Structure:,dev-cmd,Upgrade Protocol 0 = 01 26 (S3C8+) ,,,,,,,,
[Fixed] Device Bytes:,2,4D 9F 21 8B 14 87 51 08 08 01 2C 03 70 03 84 01 ,,,,,,,,
Bits/Dev:,8,18 24 54 FF FF FF FF FF 03 8D 01 46 ,,,,,,,,
Bits/Dev2:,0,End ,,,,,,,,
Dev Bit Doubling:,None,,,,,,,,,
[Variable] Cmd Bytes:,1,,,,,,,,,
Bits/Cmd:,8,,,,,,,,,
Bits/Cmd2:,,,,,,,,,,
Cmd Bit Doubling:,None,,,,,,,,,
Repeat Value:,3,,,,,,,,,
Repeat Type:,Minimum,,,,,,,,,
Repeat When Held:,Yes,,,,,,,,,
Check Byte:,None,,,,,,,,,
Bytes Checked:,,,,,,,,,,
['1' Burst] Time - ON:,600,,,,,,,,,
OFF:,1800,,,,,,,,,
['0' Burst] Time - ON:,1800,,,,,,,,,
OFF:,600,,,,,,,,,
Xmit '0' Reversed:,No,,,,,,,,,
[Lead-In] Style:,None,,,,,,,,,
Burst Mid-Frame:,No,,,,,,,,,
After # of bits:,,,,,,,,,,
[Lead-In] Time - ON:,,,,,,,,,,
OFF:,,,,,,,,,,
[Lead-Out] Style:,"2 = [OneOn, -LO]",,,,,,,,,
OFF Time:,18600,,,,,,,,,
OFF as Total:,No
Alt [Lead-Out] Time:,
Use Alt [Lead-Out]:,No
Alt Freq (Khz):,
Alt Duty %:,
Toggle Bit:,

jon_armstrong · Post by **jon_armstrong** » Tue Jan 06, 2004 11:41 pm

Steve,

A belated happy birthday! And yes this protocol did look familiar when I decoded it. The protocol that you are trying to decode is in the JP1|Files|protocol builder under AVS-14 protocol or something like that. One thing I noticed is that I had to reverse the One Zero definitions to get the lead out on time to work. That will mean that you have to use the complement of your OBC's.

Anyway, a few quick replies. When we decode stuff from scratch always think OBC's. In addition to having to look them up somehow, EFC's are always 8-bits and OBC's aren't. In this case that is not the issue but many times it is.

On duty cycle, use 30 to 30 % if you value your battery life. 50% is really the Max and we should fix that since anything beyond that makes no sense. Above 33% is for higher frequency protocols > 100KHz to increase range and you would definitely want 50% at 455 KHz.

jon_armstrong · Post by **jon_armstrong** » Wed Jan 07, 2004 12:04 am

usblipitor wrote:...I have learned several things today... I learned that it is always a good idea to check in the device upgrade folder first, no matter how bizarre and rare the device may seem to be.

I think we should call this Steve's First Law

mr_d_p_gumby · Post by **mr_d_p_gumby** » Wed Jan 07, 2004 12:26 am

usblipitor (sort of) wrote:I have learned several things today. I learned that for some reason, Steve always makes the protocol builder throw up.

Well, happy birthday Steve, anyway!

usblipitor · Post by **usblipitor** » Wed Jan 07, 2004 7:46 am

Jon and Mike: Thank you very much for your help, patience, and observations! I looked at the protocols you pointed me to, and can report that all the protocols including the one I set up are pretty much all the same, which means the system is working.

jon_armstrong wrote:I think we should call this Steve's First Law!

I like that very much. Thank you! Now I am working on a second law. I'm leaning towards: "Keymoves usually fail when invoking special protocols that one has forgotten to install."

mr_d_p_gumby wrote:Well, happy birthday Steve, anyway!

Thank you! Have some imaginary cake and imaginary Tosti Asti Spumanti!

And thanks again for the help!
-Steve