Need help decoding Galaxis SAT
Moderator: Moderators
Need help decoding Galaxis SAT
Hi,
since January I'm trying to find a way to make a protocol for my Galaxis SAT box. After reading lots of information in both RemoteCentral and here, I have more information on what I need.
1. Device: Galaxis Easy
2. Type of device: SAT
3. Remote model: OFA 9910
4. JP1 user? yes
5. Still have original remote? yes
6. Checked Yahoo file section? yes
7. Checked Pronto file section (at R/C)? yes
The reason why I need help is because the original has 39 buttons, I learned a maximum of 20 because each signal uses 49 bytes.
The protocol it's using I think is RC-MM (or at least exist a LIRC file that said, see http://lirc.sourceforge.net/remotes/galaxis/RCMM) because uses bursts of 2 bits which lenghts are:
zero +166 -278
one +166 -444
two +166 -611
three +166 -778
I tried coding each of the values with correlative burst based on binary (suggestion based on topic 2724):
Zero= +166 -278
One= +0 -166
and then:
Zero (Base4) = 0 (+166 -278)
One (Base4) = 01 (+166 -278 +0 -166)
Two (Base4) = 011 (+166 -278 +0 -166 +0 -166)
Three (Base4) = 0111 (+166 -278 +0 -166 +0 -166 +0 -166)
But, at the end, I obtained codes of 5 bytes length that doesn't work.
On other way, I found the KM code for Motorola DCP501, it works with bursts of two bits, but this protocol isn't like the Galaxis because it's only for two bytes and includes a checksum at the end.
I left the file: http://groups.yahoo.com/group/jp1/files ... alaxis.txt on the DiagnosisArea.
Thanks in advance for any help,
Julian.
since January I'm trying to find a way to make a protocol for my Galaxis SAT box. After reading lots of information in both RemoteCentral and here, I have more information on what I need.
1. Device: Galaxis Easy
2. Type of device: SAT
3. Remote model: OFA 9910
4. JP1 user? yes
5. Still have original remote? yes
6. Checked Yahoo file section? yes
7. Checked Pronto file section (at R/C)? yes
The reason why I need help is because the original has 39 buttons, I learned a maximum of 20 because each signal uses 49 bytes.
The protocol it's using I think is RC-MM (or at least exist a LIRC file that said, see http://lirc.sourceforge.net/remotes/galaxis/RCMM) because uses bursts of 2 bits which lenghts are:
zero +166 -278
one +166 -444
two +166 -611
three +166 -778
I tried coding each of the values with correlative burst based on binary (suggestion based on topic 2724):
Zero= +166 -278
One= +0 -166
and then:
Zero (Base4) = 0 (+166 -278)
One (Base4) = 01 (+166 -278 +0 -166)
Two (Base4) = 011 (+166 -278 +0 -166 +0 -166)
Three (Base4) = 0111 (+166 -278 +0 -166 +0 -166 +0 -166)
But, at the end, I obtained codes of 5 bytes length that doesn't work.
On other way, I found the KM code for Motorola DCP501, it works with bursts of two bits, but this protocol isn't like the Galaxis because it's only for two bytes and includes a checksum at the end.
I left the file: http://groups.yahoo.com/group/jp1/files ... alaxis.txt on the DiagnosisArea.
Thanks in advance for any help,
Julian.
Trying to learn from the masters
DecodeR.dll version
John,
first of all, many thanks for your interest. But, I have a doubt, which version of DecodeIR.dll are you using? Mine is 2.14. With it:
The signals appears as:
For SAT: guide
Nokia 13/80-8
Nokia 53/64-33
Nokia 80/8-120
For SAT: power
Nokia 13/80-8
Nokia 53/64-32
Nokia 80/8-12
And, really, I don't know what to do with all of these
Regards.
first of all, many thanks for your interest. But, I have a doubt, which version of DecodeIR.dll are you using? Mine is 2.14. With it:
The signals appears as:
For SAT: guide
Nokia 13/80-8
Nokia 53/64-33
Nokia 80/8-120
For SAT: power
Nokia 13/80-8
Nokia 53/64-32
Nokia 80/8-12
And, really, I don't know what to do with all of these
Regards.
Trying to learn from the masters
Version 2.16 is here
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip
I'm not where I was when I wrote the earlier message, so I can't check which version I used for those Nokia32 decodes.
Until I added the Nokia32 decoder, various parts of a Nokia32 signal were decoded as Nokia.
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip
I'm not where I was when I wrote the earlier message, so I can't check which version I used for those Nokia32 decodes.
Until I added the Nokia32 decoder, various parts of a Nokia32 signal were decoded as Nokia.
The thread I was remembering is here
https://www.hifi-remote.com/forums/viewt ... ight=nokia
It doesn't seem to tell what to do with the information even if the Nokia32 decoder is correct now.
https://www.hifi-remote.com/forums/viewt ... ight=nokia
It doesn't seem to tell what to do with the information even if the Nokia32 decoder is correct now.
DecodeIR.dll
John,
thnks a lot for the link. At the official site, the last version is 2.12.
Now, IR it's knowing the learned bursts as Nokia32, but, as you said, what can I do now...!
Has anybody the KeyMaster upgrade code for this protocol?
thnks a lot for the link. At the official site, the last version is 2.12.
Now, IR it's knowing the learned bursts as Nokia32, but, as you said, what can I do now...!
Has anybody the KeyMaster upgrade code for this protocol?
Trying to learn from the masters
-
jon_armstrong
- Expert
- Posts: 1238
- Joined: Sun Aug 03, 2003 9:14 pm
- Location: R.I.P. 3/25/2005
- Contact:
I put together a device and protocol upgrade using Protocol Builder (PB). Since you did a lot of research here is what I did:
In this case the fixed data according to the method of converting 00,01,10,and 11 ==> 0,01,011, and 0111 is:
00011101010100000110
That is 20 bits
The maximum value for OBC (255) is
0111011101110111 (16 bits)
But we must end with a 0 to get the on pulse of the lead out and we have to do it that way since the number of bits varies. (You must then pad after the 0 with sufficient 1's to get 16 bits). Fortunately, all OBC's will begin with a zero so we can add the zero to the last bit of fixed data. That way we can still do what we need in 16 variable bits or two bytes. since all the 1's after the final on pulse are just off times, we use a feature of PB that allows us to set a constant frame length in this case 100,516 uS.
We could have three 7-bit fixed bytes (if you have >2 bytes of fixed or >2 bytes of variable data then the fixed or varaible bytes must all be the same byte width), but I originally miscounted and and decided to use 24 bits of fixed data and put in 3 leading 111 (all off time so they are ignored) and used a mid frame burst after bit three as the lead-in.
My testing shows it to be decoding correctly so I think it will work. To convert the other OBC's that you decode use Excel and convert OBC to 8-bit binary, then convert each 2 bits as mentioned above. Then drop the most significant bit add a 0 as the least significant bit and then enough ones to make 16 bits and convert to two hex bytes.
For fixed data:
00011101010100000110
111 00011101010100000110 0 add three leading 1's and one trailing 0
11100011 10101010 00001100 rearranging
0xE3 0xAA 0x0C
For variable data:
OBC=1
00000001
00 00 00 01 ==> 0 0 0 01
00001 without the spaces
x00010 Drop the first msb 0 add lsb 0
00010 11111111111 add eleven 1's
00010111 11111111
0x17 0xFF
In this case the fixed data according to the method of converting 00,01,10,and 11 ==> 0,01,011, and 0111 is:
00011101010100000110
That is 20 bits
The maximum value for OBC (255) is
0111011101110111 (16 bits)
But we must end with a 0 to get the on pulse of the lead out and we have to do it that way since the number of bits varies. (You must then pad after the 0 with sufficient 1's to get 16 bits). Fortunately, all OBC's will begin with a zero so we can add the zero to the last bit of fixed data. That way we can still do what we need in 16 variable bits or two bytes. since all the 1's after the final on pulse are just off times, we use a feature of PB that allows us to set a constant frame length in this case 100,516 uS.
We could have three 7-bit fixed bytes (if you have >2 bytes of fixed or >2 bytes of variable data then the fixed or varaible bytes must all be the same byte width), but I originally miscounted and and decided to use 24 bits of fixed data and put in 3 leading 111 (all off time so they are ignored) and used a mid frame burst after bit three as the lead-in.
My testing shows it to be decoding correctly so I think it will work. To convert the other OBC's that you decode use Excel and convert OBC to 8-bit binary, then convert each 2 bits as mentioned above. Then drop the most significant bit add a 0 as the least significant bit and then enough ones to make 16 bits and convert to two hex bytes.
For fixed data:
00011101010100000110
111 00011101010100000110 0 add three leading 1's and one trailing 0
11100011 10101010 00001100 rearranging
0xE3 0xAA 0x0C
For variable data:
OBC=1
00000001
00 00 00 01 ==> 0 0 0 01
00001 without the spaces
x00010 Drop the first msb 0 add lsb 0
00010 11111111111 add eleven 1's
00010111 11111111
0x17 0xFF
-Jon
Galaxis SAT Working
Jon,
thanks for the protocol and the explanation. Initially it's working, but I think the LeadOut is too large (it could depend on my remote) because the SAT Box doesn't recognize the second number after few seconds. I'll test different LOs tonight.
As addendum, I completed the keys that initially didn't appear on the file I left. I'm sure that tomorrow I'll publish a full Galaxis SAT KeyMaster file.
Again, thanks to you, my OFA9910 has the learning memory free and all the original keys (39) mapped on it.
Regards,
Julian.
thanks for the protocol and the explanation. Initially it's working, but I think the LeadOut is too large (it could depend on my remote) because the SAT Box doesn't recognize the second number after few seconds. I'll test different LOs tonight.
As addendum, I completed the keys that initially didn't appear on the file I left. I'm sure that tomorrow I'll publish a full Galaxis SAT KeyMaster file.
Again, thanks to you, my OFA9910 has the learning memory free and all the original keys (39) mapped on it.
Regards,
Julian.
Trying to learn from the masters
Galaxis working
Jon,
once I checked all the keys, they seem to work properly.
I left the Keymaster file for the rest that want to manage this nice sat box with a universal remote.
I changed the length of the LeadOut (hex value 0xC452 from the untested) to 0x1388. I don't know why, but -with this new value- it works fine.
Thanks for your help.
once I checked all the keys, they seem to work properly.
I left the Keymaster file for the rest that want to manage this nice sat box with a universal remote.
I changed the length of the LeadOut (hex value 0xC452 from the untested) to 0x1388. I don't know why, but -with this new value- it works fine.
Thanks for your help.
Trying to learn from the masters
-
jon_armstrong
- Expert
- Posts: 1238
- Joined: Sun Aug 03, 2003 9:14 pm
- Location: R.I.P. 3/25/2005
- Contact:
I just got a chance to get back to this. My original KM Master hex entry for the OBC=0 command (numeral 0) is wrong it should be 0F FF. That may explain part of the problem. Also on the functions page could you please label L1 through L4 and M1 throught M3 with the actual function rather than the key asigned.
I'm glad you got this working.
I'm glad you got this working.
-Jon
Galaxis with Nokia32
Hi,
thanks to new IR release that decodes WAV files, and going to http://www.ezremote.com/cgi-bin/helpBV.cgi I obtained a file that upgrades one european remote model with Galaxis SAT Nokia 32 protocol.
To obtain a workable code for URC-9910, I loaded it on IR and manually modified buttons going to the device page and editing directly the hex code.
The final code is as follows
I hope it could be useful for other people and specially for those who are trying to understand the Nokia32 protocol. From my point of view this protocol uses a fixed byte plus three bytes identifying device. In this case, device is identified with 0D 50 08.
Probably the gurus will understand the protocol and include it for future releases of KM and RM.
Regards,
Julian.
thanks to new IR release that decodes WAV files, and going to http://www.ezremote.com/cgi-bin/helpBV.cgi I obtained a file that upgrades one european remote model with Galaxis SAT Nokia 32 protocol.
To obtain a workable code for URC-9910, I loaded it on IR and manually modified buttons going to the device page and editing directly the hex code.
The final code is as follows
Code: Select all
Device:
73 00 F6 FE DA 81 00 0D 50 08 00 01 02 03 04 05
06 07 08 09 10 11 0D 20 21 0C 0F 58 59 5A 5B 5C
45 78 55 4E 6E 50 6F 6D 70
Protocol:
47 93 41 8B 15 00 00 54 00 77 00 54 00 CA 00 54
01 1D 00 54 01 71 00 D0 00 77 A6 0D 02 EB 03 E6
0D 12 76 03 01 6B 08 76 00 01 6B 03 B6 06 80 F6
FF 56 6C 09 F6 01 0A FB 0B C6 F8 13 88 F6 01 58
6A F2 8B EB 76 03 02 EB 01 AF C6 F8 13 88 F6 01
58 6A F7 46 06 80 1C 22 F6 01 4C B0 C4 87 34 04
F6 FF 6C 4E 37 44 F6 1C 12 8D 01 4C 5C 04 90 C3
90 C3 08 C3 56 C0 03 86 04 C0 06 C1 12 F6 01 4C
5A EC AF Probably the gurus will understand the protocol and include it for future releases of KM and RM.
Regards,
Julian.
Trying to learn from the masters