Canal+ CANALSAT remote decodes as Phase Encoded (RC-type)

[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

[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).

[Digital Larry]

You seem to imply there's a brute force workaround?

[johnsfine]

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).

[Digital Larry]

Optimist that I am, I read too much into your description. Thanks for the information.

[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

[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.

[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

[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

[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?

[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.

[The Robman]

Here's my (untested) attempt at an upgrade...
http://www.hifi-remote.com/forums/dload ... le_id=6980

And here's the commented PB source...
http://www.hifi-remote.com/forums/dload ... le_id=6981

[mathdon]

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

[johnsfine]

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.

[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.