View previous topic :: View next topic |
Author |
Message |
Digital Larry
Joined: 28 Dec 2007 Posts: 56
|
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Thu Jan 24, 2008 6:49 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
Digital Larry
Joined: 28 Dec 2007 Posts: 56
|
Posted: Thu Jan 24, 2008 7:28 pm Post subject: |
|
|
You seem to imply there's a brute force workaround? |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Thu Jan 24, 2008 8:17 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
Digital Larry
Joined: 28 Dec 2007 Posts: 56
|
Posted: Fri Jan 25, 2008 1:33 am Post subject: |
|
|
Optimist that I am, I read too much into your description. Thanks for the information. |
|
Back to top |
|
|
binky123 Expert
Joined: 14 Feb 2004 Posts: 1292
|
Posted: Sat Jan 26, 2008 12:52 pm Post subject: |
|
|
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: |
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 |
|
Back to top |
|
|
Digital Larry
Joined: 28 Dec 2007 Posts: 56
|
Posted: Sat Jan 26, 2008 1:00 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
spotlas
Joined: 07 Feb 2007 Posts: 3
|
Posted: Sun Jan 25, 2009 10:47 am Post subject: update / progress? |
|
|
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 |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Mon Jul 27, 2009 5:00 pm Post subject: |
|
|
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: | 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 |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Mon Jul 27, 2009 9:37 pm Post subject: |
|
|
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? _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
Posted: Mon Jul 27, 2009 10:17 pm Post subject: |
|
|
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. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21237 Location: Chicago, IL |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Tue Jul 28, 2009 3:18 am Post subject: |
|
|
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 |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Tue Jul 28, 2009 8:49 am Post subject: |
|
|
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. |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Tue Jul 28, 2009 10:08 am Post subject: |
|
|
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. |
|
Back to top |
|
|
|