|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The_Dexter
Joined: 11 Jul 2009 Posts: 3 Location: Denmark |
Posted: Tue Jul 14, 2009 5:50 pm Post subject: TDC TV learned but unknown protocol |
|
|
I now theres a lot of Danes out there with the new TDC TV IPTV and who is the happy owner of a slingbox but cant shift channels, because the STB/remote is not recognized by the Slingbox nor ir.exe
The remote is to a Danish IPTV STB ftom the Danish Telephone/ISP provider TDC.
The product is called "TDC TV"
And there STB is only branded with TDC.
There's a few gusses of the original brand of the STB, wich are:
Scientific atlanta KMM-3000
Scientific atlanta KMM-3010
Kiss KMM-3010
Kreatel KMM-3010
TDC KMM-3010
Here is the learned files:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6935 |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21254 Location: Chicago, IL |
Posted: Tue Jul 14, 2009 10:28 pm Post subject: |
|
|
Try this...
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6936
Just for the record, this is an 18 bit msb bi-phase signal, with 10 bits of fixed data, an 8 bit OBC and a 1-bit checksum, where the checksum is just the complement of the last bit.
The freq is 38kHz, the pairs are +315 -315 for 1 and -315 +315 for 0, and the leadout time is 38k. _________________ 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_Dexter
Joined: 11 Jul 2009 Posts: 3 Location: Denmark |
Posted: Wed Jul 15, 2009 1:25 am Post subject: Perfect |
|
|
U a awesome thats the best support I could ever imagine
It works perfectly well.
Is it possible to change the Slingbox remote layout so you can use the picture and layout of the original remote?
Like if you choose a Samsung STB in slingbox it would be the Samsung remote wich are pictured as the remote, if you catch my sense??? |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21254 Location: Chicago, IL |
Posted: Wed Jul 15, 2009 9:00 am Post subject: |
|
|
Not with upgrades, you're pretty much stuck with the generic remote. _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Thu Jul 23, 2009 8:06 am Post subject: |
|
|
I've added this one also to my private version of DecodeIR, but this time I've gazed into my shiny new crystal ball and predicted that we may find a variant of this protocol in which the check bit and the last data bit are equal rather than being complements. So in IRP notation I have
TDCn {38k,315,msb}<-1,1|1,-1>(1:1,D:8,S:2,F:6,C:1,^89m)+
where n is 0 or 1 and is XOR of C with right-most bit of F. The version in the provided data is TDC1.
Including the initial 1 bit, required as the signal must start with an ON pulse, there are 11 fixed bits. For no particular reason I've split the 10 potentially changeable fixed bits as 8-bit device code and 2-bit subdevice code. That leaves a 6-bit command code and the final check bit. After juggling the layout to give decent alignment, the DecodeIR output for The Dexter's learned signals is
Code: | LEARNED SIGNALS:
LEARNED CODE DATA
# Btn Key P'col Dev Sub OBC Hex EFC Misc Note
1 AUX RIGHT TDC1 86 2 36 24 243 track fwd
2 AUX LEFT TDC1 86 2 33 21 011 track rew
3 AUX RED TDC1 86 2 37 25 235 red
4 AUX GREEN TDC1 86 2 38 26 003 green
5 AUX YELLOW TDC1 86 2 39 27 251 yellow
6 AUX BLUE TDC1 86 2 40 28 083 blue
7 AUX REC TDC1 86 2 28 1C 178 record
8 AUX Shift-GREEN (Play) TDC1 86 2 27 1B 218 play
9 AUX Shift-YELLOW (Pause) TDC1 86 2 27 1B 218 pause
10 AUX Shift-RED (Rewind) TDC1 86 2 34 22 035 rewind
11 AUX Shift-BLUE (Fast Fwd) TDC1 86 2 35 23 027 fast fwd
|
Is this OK?
_____________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21254 Location: Chicago, IL |
Posted: Thu Jul 23, 2009 10:30 am Post subject: |
|
|
Personally, I would not expect to see a variant where the checksum bit is not the complement of the preceding bit.
Also, I don't see any reason why the signal has to start with a 1 bit. If the signal were to start with a 0 it would start with a double ON time. _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Thu Jul 23, 2009 11:08 am Post subject: |
|
|
The Robman wrote: | Personally, I would not expect to see a variant where the checksum bit is not the complement of the preceding bit. |
I can't win, can I? This attempt of mine is TOO general! Is there any harm in leaving it, or do I reject the case where the last 2 bits are equal?
The Robman wrote: | Also, I don't see any reason why the signal has to start with a 1 bit. If the signal were to start with a 0 it would start with a double ON time. |
I'm still on a steep learning curve with all this, but I was assuming that the ON pulse after the long OFF leadout was the first half of a biphase "burst", so it had to be an ON/OFF burst, i.e. a 1. If it could be the second half, that would make it be a 0 with the first OFF half being concatenated with the preceding leadout. But if it were allowed to be either the first or second half, how would we ever know which it was? An initial long ON could only be the second half of a 0 concatenated with the first half of the following 1, but an initial short ON could be EITHER first half of a 1 OR second half of a 0 without any way to distinguish between them.
If I'm wrong, could you please explain how it does work?
_______________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21254 Location: Chicago, IL |
Posted: Thu Jul 23, 2009 12:35 pm Post subject: |
|
|
mathdon wrote: | I can't win, can I? This attempt of mine is TOO general! Is there any harm in leaving it, or do I reject the case where the last 2 bits are equal? |
It's all a question of instinct. I'm not saying that it will never happen, I'm just saying that I don't expect it to ever happen. I've been decoding these protocols for years, whereas you've just started, so it will take a while for you to develop an instinct for what's likely to occur and what isn't.
mathdon wrote: | I'm still on a steep learning curve with all this, but I was assuming that the ON pulse after the long OFF leadout was the first half of a biphase "burst", so it had to be an ON/OFF burst, i.e. a 1. If it could be the second half, that would make it be a 0 with the first OFF half being concatenated with the preceding leadout. But if it were allowed to be either the first or second half, how would we ever know which it was? An initial long ON could only be the second half of a 0 concatenated with the first half of the following 1, but an initial short ON could be EITHER first half of a 1 OR second half of a 0 without any way to distinguish between them. |
Here's a look at the data for the 1 and 2 buttons:
1:
(raw times)
+315 -630 +630 -630 +630 -630 +630 -315 +315 -630 +630 -630 +315 -315 +315 -315 +315 -315 +315 -315 +315 -315 +630 -630 +315 -89145
(split into EVEN bi-phase pairs)
+315 -315; -315 +315; +315 -315; -315 +315; +315 -315; -315 +315; +315 -315; +315 -315; -315 +315; +315 -315; -315 +315; -315 +315; -315 +315; -315 +315; -315 +315; -315 +315; +315 -315; -315 +315; -89145
(binary)
101010110100000010 -89145
2:
(raw times)
+315 -630 +630 -630 +630 -630 +630 -315 +315 -630 +630 -630 +315 -315 +315 -315 +315 -315 +315 -315 +630 -630 +630 -89460
(split into EVEN bi-phase pairs)
+315 -315; -315 +315; +315 -315; -315 +315; +315 -315; -315 +315; +315 -315; +315 -315; -315 +315; +315 -315; -315 +315; -315 +315; -315 +315; -315 +315; -315 +315; +315 -315; -315 +315; +315 -89460;
(binary)
101010110100000101 -89145
(Note: you'll notice that the 2 string ends with +315 -89460, which is really +315 -315; -89145 but the last OFF time gets merged with the leadout time).
Now, let's create a fictional signal that starts with a zero. (This is really the 2 string with the first binary digit changed).
(binary)
001010110100000101 -89145
(split into ODD bi-phase pairs)
+315; -315 +315; +315 -315; -315 +315; +315 -315; -315 +315; +315 -315; +315 -315; -315 +315; +315 -315; -315 +315; -315 +315; -315 +315; -315 +315; -315 +315; +315 -315; -315 +315; +315 -89460;
(raw times)
+315 -315 +630 -630 +630 -630 +630 -315 +315 -630 +630 -630 +315 -315 +315 -315 +315 -315 +315 -315 +630 -630 +630 -89775
(note, I added the leading -315 to the leadout to come up with -89775)
The reason why there's an ODD selection in IR.exe for bi-phase is exactly for situations like this. When I'm decoding a new signal, I select EVEN first and then look at the data. If I see pairs like "+315 +315" or "-315 -315", I change the selection to ODD to see if that fixes it. Of course, as with every rule, there will always be exceptions, and one such exception is the ReplayTV signal, where there are a couple of "double wide" pairs in the beginning of the string. To see an example of this, look at the FromRob.ir file that's in the IR zip and select the P&P:REW button. Select Bi-Phase: ODD and enter 440 as the rounding, which gives:
+2640; -440 -440; +440 -440; +440 -440; +440 -440; -440 +440; -440 -440; +440 +440; -440 +440; -440 +440; -440 +440; -440 +440; -440 +440; -440 +440; -440 +440; +440 -440; -440 +440; -440 +440; -440 +440; -440 +440; -440 +440; -440 +440; -440 +440; +440 -440; -440 +440; -440 +440; -440 +440; -440 +440; +440 -440; +440 -440; -440 +440; +440 -109120;
In binary that's:
+2640 -440; -440 1110 -880 +880; 00000001 00000001 00001101 -108680; _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Fri Jul 24, 2009 8:46 am Post subject: |
|
|
Thanks a lot, Rob, for your detailed and very helpful explanation. I'm learning in leaps and bounds!
The Robman wrote: | mathdon wrote: | I can't win, can I? This attempt of mine is TOO general! Is there any harm in leaving it, or do I reject the case where the last 2 bits are equal? |
It's all a question of instinct. I'm not saying that it will never happen, I'm just saying that I don't expect it to ever happen. I've been decoding these protocols for years, whereas you've just started, so it will take a while for you to develop an instinct for what's likely to occur and what isn't. |
Is there any reason behind this curious checkbit? A parity bit would make far more sense in data terms than merely checking the last data bit. Is is perhaps to do with it being a Biphase protocol, so that with a complement it creates a double-length ON or OFF? If it genuinely is only there as a check on the last bit, a repeat seems just as sensible as a complement.
The protocol in this thread seems to be yet a third variant and that seems to have two frames that do have the final two bits equal, but maybe in that case it isn't a check bit but just another data bit. I've a number of questions about that protocol and will post another message shortly in that thread about them.
The Robman wrote: | mathdon wrote: | I'm still on a steep learning curve with all this, but I was assuming that the ON pulse after the long OFF leadout was the first half of a biphase "burst", so it had to be an ON/OFF burst, i.e. a 1. |
let's create a fictional signal that starts with a zero. (This is really the 2 string with the first binary digit changed).
(binary)
001010110100000101 -89145
(split into ODD bi-phase pairs)
+315; -315 +315; +315 -315; -315 +315; +315 -315; -315 +315; +315 -315; +315 -315; -315 +315; +315 -315; -315 +315; -315 +315; -315 +315; -315 +315; -315 +315; +315 -315; -315 +315; +315 -89460;
(raw times)
+315 -315 +630 -630 +630 -630 +630 -315 +315 -630 +630 -630 +315 -315 +315 -315 +315 -315 +315 -315 +630 -630 +630 -89775
(note, I added the leading -315 to the leadout to come up with -89775)
The reason why there's an ODD selection in IR.exe for bi-phase is exactly for situations like this. When I'm decoding a new signal, I select EVEN first and then look at the data. If I see pairs like "+315 +315" or "-315 -315", I change the selection to ODD to see if that fixes it. |
Wow, have I been an idiot! I thought that box marked Biphase was an information box, like Frequency, though I wondered why it always seemed to say NO, even with Biphase signals. Now I see what's in it, and what it does, it makes looking at biphase timings a h*** of a lot easier!
It still seems to me, however, that whether a biphase signal with no leadin is even or odd must be a property of the protocol as a whole, rather than of an individual signal, as there are clearly signals that have valid but different translations into data bits if taken either as even or as odd. As far as I can tell, all the biphase protocols decoded by DecodeIR either have a leadin or have a fixed 1 as initial bit, ie are even. So I still think I am right to put a constant 1 bit at the start of the TDC protocol. An 18-bit biphase odd signal with the same frequency and base timing would, to me, be from a different protocol. So please put me right if you disagree!
____________________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21254 Location: Chicago, IL |
Posted: Fri Jul 24, 2009 11:58 am Post subject: |
|
|
mathdon wrote: | Is there any reason behind this curious checkbit? A parity bit would make far more sense in data terms than merely checking the last data bit. Is is perhaps to do with it being a Biphase protocol, so that with a complement it creates a double-length ON or OFF? If it genuinely is only there as a check on the last bit, a repeat seems just as sensible as a complement. |
I can't really comment on the thought process that goes into why people include checksums in their protocols, nor why they selected the checksum that they did, as I have not had any contact with anyone that's ever invented a protocol. If I had the opportunity, I'd love to ask the folks behind the Lutron protocol why they felt the need to encrypt the data the way they did. I'd like to ask UEI why they felt the need to invent a protocol as cumbersome of the XMP protocol. I'd like to ask Pioneer why they do all the messing around that they do with their signals.
But to your question, I stand by my position that I think it's unlikely that we'll ever see an exact copy of the IODATA protocol where the only difference is the checksum bit is a copy rather than a complement. Having said that, I would not be surprised to see some completely different protocol where they do indeed repeat the last bit.
mathdon wrote: | The protocol in this thread seems to be yet a third variant and that seems to have two frames that do have the final two bits equal, but maybe in that case it isn't a check bit but just another data bit. I've a number of questions about that protocol and will post another message shortly in that thread about them. |
I've just revisited that protocol and re-analised the signal and posted my results in that thread.
mathdon wrote: | Wow, have I been an idiot! I thought that box marked Biphase was an information box, like Frequency, though I wondered why it always seemed to say NO, even with Biphase signals. Now I see what's in it, and what it does, it makes looking at biphase timings a heck of a lot easier! |
Yup, that's why I asked Binky to add it for me. I used to hate decoding bi-phase signals but with that one little drop-down menu, it makes it a 100 times easier.
mathdon wrote: | It still seems to me, however, that whether a biphase signal with no leadin is even or odd must be a property of the protocol as a whole, rather than of an individual signal, as there are clearly signals that have valid but different translations into data bits if taken either as even or as odd. As far as I can tell, all the biphase protocols decoded by DecodeIR either have a leadin or have a fixed 1 as initial bit, ie are even. So I still think I am right to put a constant 1 bit at the start of the TDC protocol. An 18-bit biphase odd signal with the same frequency and base timing would, to me, be from a different protocol. So please put me right if you disagree! |
Obviously, having only seen one example of the IODATA protocol I can't say that you're wrong, and it would certainly be nice of the IODATA folks if they did indeed hard code a 1 at the beginning, but I still don't see any reason why you need to hard code it that way. I certainly didn't hard code it that way in my executor, so if someone were to enter a device code that starts with a zero, my executor would generate a signal like the fictitious sample that I posted earlier. So, if my executor is flexible enough to generate the signal, why can't your decode routine be equally as flexible?
Like I said, I'm not saying that you're wrong to say that the first bit needs to be 1, but as we don't know for sure, why hard code that assumption when there's no need to do so? _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sun Aug 16, 2009 11:06 am Post subject: |
|
|
The Robman wrote: | So, if my executor is flexible enough to generate the signal, why can't your decode routine be equally as flexible? |
Sorry for the delay in responding, Rob, but I'm revisiting this protocol now I'm looking at executors and noticed I hadn't replied to this question. The answer is: because a biphase signal can be ambiguous if you don't know whether it starts with a 1 or a 0. Look at
+315 -315 +315 -315 +315 -9000.
Is that biphase even:
+315 -315; +315 -315; +315 -315; -8685 = 111
or biphase odd:
+315; -315 +315; -315 +315; -9000 = 000 ?
I am looking at executors as I would like protocols.ini to include all the protocols that I am adding to DecodeIR. If it doesn't do so then this forum will continue to get posts about them from users who don't find the RM, KM or PB files that have already been constructed.
If anyone wants me to STOP posting potential additions to protocols.ini, please say so.
_______________
Graham |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Sun Aug 16, 2009 11:12 am Post subject: |
|
|
I find the posts intereresting Graham. _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|