JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

TDC TV learned but unknown protocol

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
The_Dexter



Joined: 11 Jul 2009
Posts: 3
Location: Denmark

                    
PostPosted: Tue Jul 14, 2009 5:50 pm    Post subject: TDC TV learned but unknown protocol Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Jul 14, 2009 10:28 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
The_Dexter



Joined: 11 Jul 2009
Posts: 3
Location: Denmark

                    
PostPosted: Wed Jul 15, 2009 1:25 am    Post subject: Perfect Reply with quote

U a awesome Smile thats the best support I could ever imagine Smile

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Wed Jul 15, 2009 9:00 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Jul 23, 2009 8:06 am    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Jul 23, 2009 10:30 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Jul 23, 2009 11:08 am    Post subject: Reply with quote

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? Smile 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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Jul 23, 2009 12:35 pm    Post subject: Reply with quote

mathdon wrote:
I can't win, can I? Smile 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
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Jul 24, 2009 8:46 am    Post subject: Reply with quote

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? Smile 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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Fri Jul 24, 2009 11:58 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Aug 16, 2009 11:06 am    Post subject: Reply with quote

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
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Sun Aug 16, 2009 11:12 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control