TDC TV learned but unknown protocol

[The_Dexter]

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 ... le_id=6935

[The Robman]

Try this...
http://www.hifi-remote.com/forums/dload ... le_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.

[The_Dexter]

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

[The Robman]

Not with upgrades, you're pretty much stuck with the generic remote.

[mathdon]

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: Select all

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

[The Robman]

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.

[mathdon]

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?

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

[The Robman]

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.

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;

[mathdon]

Thanks a lot, Rob, for your detailed and very helpful explanation. I'm learning in leaps and bounds!

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.

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

[The Robman]

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.

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.

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.

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?

[mathdon]

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

[vickyg2003]

I find the posts intereresting Graham.