Page 1 of 3
Canal+ CANALSAT remote decodes as Phase Encoded (RC-type)
Posted: Thu Jan 24, 2008 4:44 pm
by Digital Larry
See IR file at:
http://www.hifi-remote.com/forums/dload ... le_id=5330
I'm using RemoteMaster 1.82 and target is UEI PL/PK chip.
Thanks,
DL
Posted: Thu Jan 24, 2008 5:49 pm
by johnsfine
Those decodes indicate there is not yet support for your protocol in DecodeIR.dll, so it can't decode those signals. But it recognizes a characteristic of the signal that lets it partially decode them as an aid to whatever expert tries to figure out the rest of the details.
I'm rather busy, so I can't promise to find time to add support even to DecodeIR.dll (which only I can do and which would make the next step easier but isn't required for the next step).
I assume your VOL+ and VOL- signals are not for the same device as the other signals. I assume the original remote has some form of volume punch through enabled, as is common for CBL and SAT remotes. It's strange that mute wasn't covered by that volume punch through. If I'm misunderstanding some aspect of that, please explain. Anyway, you're not likely to get the VOL signals into the same Slingbox upgrade with the rest (but you probably have no need to).
Posted: Thu Jan 24, 2008 6:28 pm
by Digital Larry
You seem to imply there's a brute force workaround?
Posted: Thu Jan 24, 2008 7:17 pm
by johnsfine
Digital Larry wrote:You seem to imply there's a brute force workaround?
How did I imply that?
A JP1 expert (such as myself if I had time) can figure out the protocol details from those signals and create a executor, which would allow him or you to create an upgrade, which could be used to create the desired Slingbox file(s).
If I first figure out the protocol details while adding support to DecodeIR.dll, the above process would be partially done and the remainder made easier (DecodeIR.dll support makes testing the executor and building the upgrade easier).
Posted: Fri Jan 25, 2008 12:33 am
by Digital Larry
Optimist that I am, I read too much into your description. Thanks for the information.
Posted: Sat Jan 26, 2008 11:52 am
by binky123
I decoded your signals as 23 bits long. Some are listed as 24 bits wth the 24th bit the LeadOut signal. Frequency 55.555KHz. The fixed data is 8B 00. bit1 of the second fixed byte is set to 1 when the signal is repeated. The last 7 bits are the OBC number. Digits are 0-9. The last signal SAT:Menu was only 12 bits long.
Mute: 16
CH+: 20
CH-: 19
Up: 34
Select: 42
Down: 46
Right: 32
Left: 36
Here are Protocol Upgrades for HCS08 and S3C8 remotes
Code: Select all
Upgrade protocol 0 = 01 A1 (HCS08) Custom Protocol for Canal+
20 17 17 31 21 86 80 10 08 07 00 7D 00 7D 00 7D
00 7D AD D4 FF FF FF FF 08 38 62 CD FF 5F 12 61
CD FF 92 25 F6 81
End
Upgrade Protocol 0 = 01 A1 (S3C8+) Custom Protocol for Canal+
2C 60 21 8B 14 86 80 10 08 07 00 7D 00 69 00 7D
00 69 AD D4 FF FF FF FF 08 90 05 F6 01 46 46 04
02 F6 01 0A 7B F5 AF
End
I used this device upgrade to test and the signals seemed to match yours.
Upgrade Code 0 = 0C 2C (CBL/1068) Canal+
A1 00 61 8B 00 01 02 03 04 05
End
Posted: Sat Jan 26, 2008 12:00 pm
by Digital Larry
Thanks a lot. I will try this on Monday when I'm back in the office. I hope it's OK if I send you the rest of the keys for review, I just sent as many as I could learn at one time in the URC 8910.
update / progress?
Posted: Sun Jan 25, 2009 9:47 am
by spotlas
Hi there,
Have you been able to get this to work? I'm trying to find the SBAV or create one for a Canalsat box (want to watch it with my slingbox)
Thank!
Spot
Posted: Mon Jul 27, 2009 4:00 pm
by mathdon
I have now added this protocol into DecodeIR, with IRP
CanalSat {55.5k,250,msb}<-1,1|1,-1>(1:1,D:7,S:6,P:1,F:8,^89m)+
where P is a position code:
0 for first frame of repeat sequence
1 for all repeats
The output is:
Code: Select all
LEARNED SIGNALS:
LEARNED CODE DATA
# Btn Key Protocol Dev Sub OBC Hex EFC
1 SAT 1 CanalSat 11 0 1 01 010
2 SAT 2 CanalSat 11 0 2 02 034
3 SAT 3 CanalSat 11 0 3 03 026
4 SAT 4 CanalSat 11 0 4 04 242
5 SAT 5 CanalSat 11 0 5 05 234
6 SAT 6 CanalSat 11 0 6 06 002
7 SAT 7 CanalSat 11 0 7 07 250
8 SAT 8 CanalSat 11 0 8 08 082
9 SAT 9 CanalSat 11 0 9 09 074
10 SAT 0 CanalSat 11 0 0 00 018
11 SAT Mute CanalSat 11 0 16 10 146
12 SAT CH+ CanalSat 11 0 20 14 114
13 SAT CH- CanalSat 11 0 19 13 154
16 SAT Up CanalSat 11 0 34 22 035
17 SAT Select CanalSat 11 0 42 2A 099
18 SAT Down CanalSat 11 0 38 26 003
19 SAT Right CanalSat 11 0 32 20 019
20 SAT Left CanalSat 11 0 36 24 243
21 SAT Menu Phase Encoded (RC-Type) 12 bits, MSB value = 100010110000
I assume that the 12-bit signal for Menu is a learning error. The missing entries nos 14 and 15 were for Vol+/- with an entirely different protocol. As with the OrtekMCE protocol, this has a position bit that varies between the first and subsequent transmissions of the signal (OrtekMCE had a two-bit position code). My understanding is that this is different from a Toggle Bit. Again as with the Ortek protocol, I check for such repeat transmissions and return just one entry for the whole signal.
Have I got this one OK?
___________________
Graham
Posted: Mon Jul 27, 2009 8:37 pm
by The Robman
I haven't looked at the original learns yet, so I can't check your handy work, but do you think you're ready to try the next step and create an upgrade based on that info?
Posted: Mon Jul 27, 2009 9:17 pm
by The Robman
The learn was incomplete for the MENU button, so DL would need to re-learn that one. You should take a look at the data for the SELECT button as it's the only button which is 100% complete.
You should notice that there are "sent once", "repeat" and "extra" portions for this learn and they show that the "position" bit reverts back to zero when the button is released, so while it's not a traditional toggle bit, it's not exactly a "position" bit either.
Posted: Mon Jul 27, 2009 9:36 pm
by The Robman
Posted: Tue Jul 28, 2009 2:18 am
by mathdon
The Robman wrote:The learn was incomplete for the MENU button, so DL would need to re-learn that one. You should take a look at the data for the SELECT button as it's the only button which is 100% complete.
You should notice that there are "sent once", "repeat" and "extra" portions for this learn and they show that the "position" bit reverts back to zero when the button is released, so while it's not a traditional toggle bit, it's not exactly a "position" bit either.
I hadn't looked at the Extra part and thought that might be an erroneous half-frame. DecodeIR doesn't process Extra parts at all. Although it is present in the argument passed by IR.exe, it isn't copied into the burst list that DecodeIR builds and so there is no way for me to test it. (John, please please tell me if I'm wrong about that.) So I'm just looking at the 23-bit frames to check that they are the same apart from the "position" bit, which I test to be 1 in the repeat. But if the Extra part is real then it must be put into the IRP.
I haven't dared venture into PB yet
but suppose it is about time I did so! So thanks for the PB file on this one. It will encourage me (in both senses!) to do so!
Rob, are there any protocols missing from DecodeIR that you know of and would like me to look at to see if I can deal with them?
_________________
Graham
Posted: Tue Jul 28, 2009 7:49 am
by johnsfine
mathdon wrote: DecodeIR doesn't process Extra parts at all. Although it is present in the argument passed by IR.exe, it isn't copied into the burst list that DecodeIR builds and so there is no way for me to test it. (John, please please tell me if I'm wrong about that.)
The input parameters to DecodeIr allow no way to present the structure of initial, repeat and final. I think UEI learned format can represent than and a moderate number of protocols have that, but UEI learning usually fails to capture that. So even if the signal has the structure the learned signal usually doesn't.
Maybe DecodeIr should be enhanced to allow that.
The UEI learned signal structure also supports a three part form where the three parts are just used together to represent a long one time signal in which either there was no repeat or the learning logic failed to understand the repeat. I think IR correctly passes that form to DecodeIr.
Posted: Tue Jul 28, 2009 9:08 am
by vickyg2003
Hey Rob, student #2 checking in.
We're nowhere near close on this one. I am assuming this protocol is supposed to send three different frames. Well, all we are getting is ones. I tried just changing the xmit 0 reversed to YES and that didn't improve things. I turned on the Repeat flag and I got some data comming through but it was the same on every frame.
I'm going to hack away on this in MY language, but I don't have time to get to this until tomorrow.