Hi all,

I want to build my own RC for the DVDplayer in subj all models listed there are inter-compatible), just to kill two birsies with one stone (get RC and learn how it works).

Does anyone here know the actual buttonpress codes transmitted on IR channel for this device (RenoteCtrl p/n is SE-R0049), or point me to a resource that would explain Toshiba remote controlling scheme/codes?

Thanks a lot,
:-DS

For every device that I've seen, Toshiba uses the NEC1 protocol, and the SD series of DVD players is no exception as these use NEC1 with a single device code of 69.

Note: "NEC1" is the term we use to denote the version of the NEC protocol where the data portion repeats once followed by a 2-pair stream that indicates that the button is being held down.

Rob
http://www.hifi-remote.com

Thanks Rob, much appreciated.

Could you please refer me to NEC1 protocol source or to at least a difference between NEC protocol and NEC1 protocol? How different would it be from what is described here:

[Link: xs4all.nl]

And then, could you tell where I can get hold of the specific button codes for SE-R0049 Toshiba milti-device remote controller?

Thanks again,
:-DS

The page you linked to describes what we call the "NEC1" protocol. The version that we call "NEC2" differs in the way it handles the situation when the button is held down.

Both variants have the same data portion of the signal which is sent once at the beginning, as shown by the first picture under the heading "Protocol":



hey differ in how they handle the repeating signal. For NEC1, the following signal is sent:



but for NEC2, the original data portion is repeated for as long as the button is held down.

Now, if you're wondering how come I have such ready access to this sort of information, I'm getting it from the JP1 group. JP1 is a process whereby you can program certain types of universal remotes to do exactly what you want them to do. You sound like you might just be nerdy enough to find what we do fun! :)

Check us out at [Link: hifi-remote.com] and
[Link: hifi-remote.com]

As for the button codes, here they are...

OBC Functions
000 pause
001 num 1
002 num 2
003 num 3
004 num 4
005 num 5
006 num 6
007 num 7
008 num 8
009 num 9
010 num 0
013 slow fwd
014 slow rev
018 power
019 fast fwd
020 stop
021 play
022 display
025 rewind
032 setup
033 select
035 chapter down
036 chapter up
037 enter
039 audio
040 subtitles
041 angle
042 memory
043 repeat
044 A-B rpt
045 last play
046 random
064 zoom
065 fl. Dimmer
067 3D
074 disc select
077 right arrow
081 left arrow
128 up arrow
129 down arrow
132 menu
222 top menu
239 clear
243 open/close 2
245 open/close 1

Rob
http://www.hifi-remote.com

Rob,

Thanks so much again. I love learning things on a very low level, one-zero-one-zero... Still plenty to learn... need another 100 lives or more... :-)

I'll definitely have a look at JP1 group, thanks.

Now, can I nag you again with couple more?

1) What's OBC ?

2) As I understand from the pictures, the message consists of address and command, one byte each (or can it be more?) Now, correct me if I am wrong: Address normally refers to the device to control (CD, DVD etc.), and command is related to the button pressed.
So, for every button press, there should be two bytes transmitted (forget inverted bytes for the time being, they are just for redundancy). How are the OBC codes from the column above related to those two bytes in case of SE-R0049?

Thanks again for your great help,
:-DS

OBC stands for "Original Button Code", it's the same as "command code".

The "device code" doesn't specifically differentiate between device types (such as CD, DVD, etc), it's designed to differentiate between actual devices.

For example, device code 1 might be used by a Toshiba TV, device code 2 might be used by an NEC TV, device code 3 could be an Apex DVD player, etc, etc.

In real life, there is sometimes an overlap between devices using device codes. For example, the Apex AD600A DVD player uses the same device codes as some Goldstar TVs (but the button codes are different).

Back to your questions about the codes. If you read the description of the NEC signal on the page you linked to, you'll see that it's what we call "LSB" (Least Significant Bit first). In layman's terms, that means the binary is backwards.

For example, the binary for decimal 1 is normally: 00000001 bot for an LSB protocol it's 10000000

As I stated in my first post, the device code for this device is 69, which in binary is 01000101. Now let's reverse the order of the bits (to make it LSB) and we get 10100010. The OBC for "POWER" is 18, which in binary is 00010010, and LSB is 01001000

As you've noticed, each byte of data is followed by it's compliment (ie, inverted).

So the binary for the POWER button for this device is:

10100010 01011101 01001000 10110111

NOTE: it's becoming less common for the 2nd byte to be the compliment of the device code byte. More and more we're seeing a second un-related device code in this byte now. The 4th byte is always the compliment of the OBC (command code) with the one exception being the signal used for Tivo, where they have replaced the first four bits (counting from the left) with a 4-bit unit code.

Rob

Rob,

Everything is nice, except for the case when button code consists of three non-zero nibbles (1.5 bytes), as for example, up and down arrow buttons from your list above (codes 128 and 129), that is the leading nibble is not 0.

From what is described above, the command cosists of 4 bytes:

(1-byte device code) followed by
(1-byte complement of DeviceCode) followed by
(1-byte OBC code) followed by
(1-byte complement of OBC code)

So, for "POWER" button (Device code = 69, OBC=018) the bitstream is as what you specified above:
10100010 01011101 01001000 10110111

Note that the leading zero from OBC=18 is omitted here, and OBC is transmitted as 18, not 018.

What would the command and bitstream look like in case of non-zero leading nibble, like say "UP ARROW" button (OBC=128)? Where does the upper nibble go?
Do we have to transmit an extra byte (nibble?) for it or what?

Could you please clarify?

Thanks in advance,
:-DS

I'm not sure where you got lost here, but you did get lost. One byte can hold values up to 255, so as long as your OBC doesn't go above 255 (and I can guarantee you it won't) you're all set.

When you refer to an OBC, it doesn't matter if you include any number of leading zeroes as it's just a number, the binary on the other hand will have leading zeroes. There will always be 8 bits to a byte, regardless of the value of the OBC.

Rob

Argh-h-h-h,

That's what it was! It just had to be that simple!
I know now where I got lost!

My problem was that I apriori treated all these code numbers of yours as HEX not DECIMAL, without actually bothering to look carefully (lazy [email protected]@rd!) at how they were converted into binaries in your text, so to me, code 128 was a Hexadecimal number 0x128, not decimal. Too much of a low-level C/ASM programming here, sorry...

Now everything comes together: device code 69 is 0x45, or 01000101 binary, exactly as you wrote above (if only I bothered to look carefully at what you wrote in a first place! :-(

And device code 128 is 0x80 or 10000000 binary
(NOT 0x128 or 000100101000 binary as I wrongly assumed!)

This also means that we can only have up to 255 (or 0xFF or 11111111B :-) buttons on the remote control unit (that should be enough, I guess :-)

It's all clear now!

Once again, many thanks to you Rob The Man for your clear and helpful explanation.

Learnt something today and become a bit happier,
:-DS

And if for some reason 255 buttons isn't enough, you can either pick a protocol with 2 variable bytes or you can adapt this one. Just like how the device code compliment has been co-opted as a second device code, you could co-opt the command code compliment and use it as a second command code, if you want.

Rob