UPC HORIZON REMOTE

[Noirfire]

Hey Guys,

I Scanned in this UPC remote anf found the they all came back as;
Protocol Device SubDevice OBC Hex
"Gap-494-1491-37? 48 42 242
Gap-494-1491-20? 10 4 242
Gap-494-1491-37? 48 42 234
Gap-494-1491-20? 138 4 234
Gap-494-1491-37? 48 42 233
Gap-494-1491-20? 154 4 233
Gap-494-1491-37? 48 42 232
Gap-494-1491-20? 170 4 232"

Full files can be found here;
http://www.hifi-remote.com/forums/dload ... e_id=11273

IR's have been captured but none came back with the correct protocol or coherent data.

Any help I would be very grateful.

Thanks Phil

Name; UPC Horizon
Model; SMT-G7400
type; Cable
Manufacturer; Samsung

[vickyg2003]

I did some of the grunt work, but of course I can't see the pattern for the checksum.

The OBC appears to be LSB and starts right after the 5 in part b. The next byte must be some sort of checksum, but I can't work with binary.

Its a midframe burst protocol.

Code: Select all

{38.5k,497,msb}<1,-1|1,-3>(9,-9,A:16,1,-9,B:20,1,-52.0m)					
Power	1	{A=$0C54,B=$5024F}		{A=0b0000110001010100,B=0b01010000001001001111}	
1	2	{A=$0C54,B=$51257}		{A=0b0000110001010100,B=0b01010001001001010111}	
2	3	{A=$0C54,B=$59297}		{A=0b0000110001010100,B=0b01011001001010010111}	
3	4	{A=$0C54,B=$55217}		{A=0b0000110001010100,B=0b01010101001000010111}	
4	5	{A=$0C54,B=$5D2E7}		{A=0b0000110001010100,B=0b01011101001011100111}	
5	6	{A=$0C54,B=$53267}		{A=0b0000110001010100,B=0b01010011001001100111}	
6	7	{A=$0C54,B=$5B2A7}		{A=0b0000110001010100,B=0b01011011001010100111}	
7	8	{A=$0C54,B=$57227}		{A=0b0000110001010100,B=0b01010111001000100111}	
8	9	{A=$0C54,B=$5F2C7}		{A=0b0000110001010100,B=0b01011111001011000111}	
9	10	{A=$0C54,B=$50A47}		{A=0b0000110001010100,B=0b01010000101001000111}	
0	11	{A=$0C54,B=$58A87}		{A=0b0000110001010100,B=0b01011000101010000111}	
Rew	12	{A=$0C54,B=$58589}		{A=0b0000110001010100,B=0b01011000010110001001}	
Fwd	13	{A=$0C54,B=$50549}		{A=0b0000110001010100,B=0b01010000010101001001}	
Play	14	{A=$0C54,B=$5CAFB}		{A=0b0000110001010100,B=0b01011100101011111011}	
Stop	15	{A=$0C54,B=$52A7B}		{A=0b0000110001010100,B=0b01010010101001111011}	
Rec	16	{A=$0C54,B=$54A07}		{A=0b0000110001010100,B=0b01010100101000000111}	
Menu	17	{A=$0C54,B=$5828F}		{A=0b0000110001010100,B=0b01011000001010001111}	
Up	18	{A=$0C54,B=$5C2F7}		{A=0b0000110001010100,B=0b01011100001011110111}	
Left	19	{A=$0C54,B=$5A2B7}		{A=0b0000110001010100,B=0b01011010001010110111}	
Down	20	{A=$0C54,B=$52277}		{A=0b0000110001010100,B=0b01010010001001110111}	
Right	21	{A=$0C54,B=$56237}		{A=0b0000110001010100,B=0b01010110001000110111}	
Select	22	{A=$0C54,B=$5E2D7}		{A=0b0000110001010100,B=0b01011110001011010111}	
CH+	23	{A=$0C54,B=$5C5F1}		{A=0b0000110001010100,B=0b01011100010111110001}	
CH-	23	{A=$0C54,B=$52571}		{A=0b0000110001010100,B=0b01010010010101110001}	
Back	25	{A=$0C54,B=$5420F}		{A=0b0000110001010100,B=0b01010100001000001111}	
Text	26	{A=$0C54,B=$56A3B}		{A=0b0000110001010100,B=0b01010110101000111011}

[Noirfire]

Thanks Vicky its home time I will check it out tomorrow morning.

Cheers Phil

[vickyg2003]

Phil, we seem to be a long way from an answer. The first thing we need is a decent decode. For the life of me, I can't do it. Rob usually does this, but of course we welcome anyone else to take part of the fun. I simply can't do it. Actually, I'm not even certain how to write a protocol with an odd number of nibbles.

[Vyrolan]

I took a crack at understanding the data section... It seems pretty clear that the static 16-bits before the midframe burst are the device/subdevice. The parts after though seemed all over the place. The first bits are static 0101 so I've thrown those out. I took the other 16 bits and after a lot of trial and error, I noticed a pattern in some of the bits...but I needed to read them LSB instead of MSB...

Check this out:

Code: Select all

           A        B        C      D        E
Power = 00001100 01010100 | 0101 00000010 01001111 | A=48, B=42, C=10, D= 64, E=242, D+E=306
1     = 00001100 01010100 | 0101 00010010 01010111 | A=48, B=42, C=10, D= 72, E=234, D+E=306
2     = 00001100 01010100 | 0101 10010010 10010111 | A=48, B=42, C=10, D= 73, E=233, D+E=306
3     = 00001100 01010100 | 0101 01010010 00010111 | A=48, B=42, C=10, D= 74, E=232, D+E=306
4     = 00001100 01010100 | 0101 11010010 11100111 | A=48, B=42, C=10, D= 75, E=231, D+E=306
5     = 00001100 01010100 | 0101 00110010 01100111 | A=48, B=42, C=10, D= 76, E=230, D+E=306
6     = 00001100 01010100 | 0101 10110010 10100111 | A=48, B=42, C=10, D= 77, E=229, D+E=306
7     = 00001100 01010100 | 0101 01110010 00100111 | A=48, B=42, C=10, D= 78, E=228, D+E=306
8     = 00001100 01010100 | 0101 11110010 11000111 | A=48, B=42, C=10, D= 79, E=227, D+E=306
9     = 00001100 01010100 | 0101 00001010 01000111 | A=48, B=42, C=10, D= 80, E=226, D+E=306
0     = 00001100 01010100 | 0101 10001010 10000111 | A=48, B=42, C=10, D= 81, E=225, D+E=306
Rew   = 00001100 01010100 | 0101 10000101 10001001 | A=48, B=42, C=10, D=161, E=145, D+E=306
Fwd   = 00001100 01010100 | 0101 00000101 01001001 | A=48, B=42, C=10, D=160, E=146, D+E=306
Play  = 00001100 01010100 | 0101 11001010 11111011 | A=48, B=42, C=10, D= 83, E=223, D+E=306
Stop  = 00001100 01010100 | 0101 00101010 01111011 | A=48, B=42, C=10, D= 84, E=222, D+E=306
Rec   = 00001100 01010100 | 0101 01001010 00000111 | A=48, B=42, C=10, D= 82, E=224, D+E=306
Menu  = 00001100 01010100 | 0101 10000010 10001111 | A=48, B=42, C=10, D= 65, E=241, D+E=306
Up    = 00001100 01010100 | 0101 11000010 11110111 | A=48, B=42, C=10, D= 67, E=239, D+E=306
Left  = 00001100 01010100 | 0101 10100010 10110111 | A=48, B=42, C=10, D= 69, E=237, D+E=306
Down  = 00001100 01010100 | 0101 00100010 01110111 | A=48, B=42, C=10, D= 68, E=238, D+E=306
Right = 00001100 01010100 | 0101 01100010 00110111 | A=48, B=42, C=10, D= 70, E=236, D+E=306
Sel   = 00001100 01010100 | 0101 11100010 11010111 | A=48, B=42, C=10, D= 71, E=235, D+E=306
CH+   = 00001100 01010100 | 0101 11000101 11110001 | A=48, B=42, C=10, D=163, E=143, D+E=306
CH-   = 00001100 01010100 | 0101 00100101 01110001 | A=48, B=42, C=10, D=164, E=142, D+E=306
Back  = 00001100 01010100 | 0101 01000010 00001111 | A=48, B=42, C=10, D= 66, E=240, D+E=306
Text  = 00001100 01010100 | 0101 01101010 00111011 | A=48, B=42, C=10, D= 86, E=220, D+E=306

The | represents the midframe burst...so we have A and B beforehand (interpreting them as LSB as well for A=48 and B=42)... Afterwards, we have the static C as 0101 everytime...

Then we have D and E...I noticed when I converted them to decimal (reading LSB), I got two numbers that always added up to decimal 306. That fits the pattern for all of these learns. Now, I have no freaking clue where the 306 came from (I tired to figure it out but found nothing)... However, I think a protocol could be written that would use either D or E as the OBCs and calculate the other as 306-OBC and it would work. It would probably only work for these exact signals though...I doubt you'd be able to try random other OBCs and have any luck. The 306 and the fixed 0101 (C in my text above) are probably derived some way I don't understand or are additional parameters to the protocol.

I'm not sure if we actually have the capability to write a protocol in such a fashion. I tried to figure out a relationship between them using only bitwise operations, but I found nothing.

Hope that helps...

[The Robman]

That decode works for me.

As for writing a protocol, the mid-frame burst is easy and PB supports that. We've actually got 20 bits of fixed data, so it might be easier to treat it as four 5-bit codes rather than two 8-bit and one 4-bit.

For the checksum, we can only do ADDs with MSB data, so to generate the checksum we'd need to reverse the bits, do the math, then reverse them again.

Also, there's something weird going on with the leadout time. At first glance, when I saw the different leadout times I assumed it was an "off as total" signal, but counting the number of ONEs in the signal doesn't correspond with the leadout times, so I don't know what's causing the difference from -51k for the "6" button to -57k for the "5" button.

[Vyrolan]

Also, there's something weird going on with the leadout time. At first glance, when I saw the different leadout times I assumed it was an "off as total" signal, but counting the number of ONEs in the signal doesn't correspond with the leadout times, so I don't know what's causing the difference from -51k for the "6" button to -57k for the "5" button.

I'm not seeing those values as the leadouts? Here's what I see for buttons 5 through 8:

Code: Select all

5 = LI 0000110001010100 MPB 0101 00110010 01100111 +500 -54000
6 = LI 0000110001010100 MPB 0101 10110010 10100111 +500 -53000
7 = LI 0000110001010100 MPB 0101 01110010 00100111 +500 -54000
8 = LI 0000110001010100 MPB 0101 11110010 11000111 +500 -52000

Those data sections match up with what Vicky provided...so then count the 1s in the data:

Code: Select all

5 = LI 0000110001010100 MPB 0101 00110010 01100111 +500 -54000   15 ones
6 = LI 0000110001010100 MPB 0101 10110010 10100111 +500 -53000   16 ones
7 = LI 0000110001010100 MPB 0101 01110010 00100111 +500 -54000   15 ones
8 = LI 0000110001010100 MPB 0101 11110010 11000111 +500 -52000   17 ones

So then the Lead Out off time is 69000 minus 1000 times the number of logical 1s in the data:

Code: Select all

5 = 69 - 15 ==> +500 -54000
6 = 69 - 16 ==> +500 -53000
7 = 69 - 15 ==> +500 -54000
8 = 69 - 17 ==> +500 -52000

[The Robman]

Duh, you know what it is, when I first grabbed the data I didn't save the leadouts, so I did it again and pasted them into the spreadsheet I was working with, but I forgot that I had sorted the sheet before.

[vickyg2003]

What are we controling? What is the model number, etc.

Here is a Remotemaster file
http://www.hifi-remote.com/forums/dload ... e_id=11279

I decided against computing the checksum, so made it a two byte protocol instead.


Here is the protocol file
http://www.hifi-remote.com/forums/dload ... e_id=11281


Here is a KM version,
http://www.hifi-remote.com/forums/dload ... e_id=11280

Boy it will be nice when Graham brings out the new beta RMIR that I am testing. It opened the KM file fine! No need to do two versions!

[Noirfire]

Hi Vicky,

Thanks I will test the files and get back to you. In regards to the Model number for the STB and remote. I wasn't given one and the remote doesn't have any info on it. I am still awaiting more information from the customer as soon as I get it I will let you know.

All I know at the moment it product is called Horizon and it made by UPC.

Cheers Phil

[The Robman]

Here's an un-tested custom protocol designed to replicate this protocol:
http://www.hifi-remote.com/forums/dload ... e_id=11282

[vickyg2003]

Here's an un-tested custom protocol designed to replicate this protocol:
http://www.hifi-remote.com/forums/dload ... e_id=11282

Doh! Make all the device entries nibbles! What a very clever solution!

I like it. I certainly learned a lot from this.

If I get some time, later today I'll change the upgrade to use this protocol and give it a whirl.

[The Robman]

They're a little bit more than nibbles as it's 4 bytes of 5-bits each, but I could just as easily have done 5 bytes of 4-bits each.

I took a wild guess as to what the total leadout time should be, so if the code does work, be sure to check the leadout time in the results to see if it should be increased or decreased.

[vickyg2003]

Hey Phil, I am having an issue with RM and the RDMU file I created.

Its losing the device settings, 48, 42, 10.
also check the hex on the keys. 8A 4F should be the first hex column.

So it will not work , if those fields are empty.

I'm working on an alpha RM, so it may only be an issue for me, maybe not.


Rob,
Lots of bugs. Which is good for cementing the reversing steps in my brain.

Edit.
I'm still chasing down errors. I thought I had a binary math error, but now it looks like it might be an IRScope problem with the decode.

[The Robman]

I spotted a few silly errors in there myself, like not moving the computed checksum to the output register. I have updated the PB file and created a KM file and an RMDU file.

All are here:
http://www.hifi-remote.com/forums/dload ... e_id=11282