JP1 Remotes

mwinters wrote: I have uploaded the file to the diagnosis area (Universal with dvb300 - 2.txt).

I looked there and can't find that file.

gjarboni wrote:I'll leave it to John or Jon to figure out the rest. If they haven't answered by tomorrow then I'll decode the rest and help you create an upgrade for it.

I actually sleep on occasion.

gjarboni wrote:There looks like a relationship between the fifth and sixth byte, but I can't figure out what it is. It will probably be easier to code it in PB as a four fixed, two variable byte protocol.

I guess the programmers at UEI didn't figure out that relationship either, because Protocol 00BB (used by Audio/0286 in the 7560) also has four fixed and two variable.

For a few signals, use KeyMoves based on Audio/0286. For a larger number, build a new upgrade for pid 00BB.

The translation is "comp" like most UEI protocols. If I understand your description below you used LSB for the bit order, so the fifth signal byte is the first byte of hex command LSB-comp and the sixth signal byte is the second byte of hex command LSB-comp.

I've tried to figure this checksum out myself, and I can get it close but I can't get it completely right.

If anyone else wants to pick it up, here's what I've done so far...
http://groups.yahoo.com/group/jp1/files ... ecksum.xls

johnsfine wrote:

mwinters wrote: I have uploaded the file to the diagnosis area (Universal with dvb300 - 2.txt).

I looked there and can't find that file.

Aaa poop, I copied the wrong filename into the post, look for
teac-DV-D990 - 2.txt

It's interesting looking at how these are decoded.. I wouldn't bust your guts on it as if it doesn't work I will just live as I do now..

Have a good one.
Mathew.

The Robman wrote:I've tried to figure this checksum out myself, and I can get it close but I can't get it completely right.

If anyone else wants to pick it up, here's what I've done so far...
http://groups.yahoo.com/group/jp1/files ... ecksum.xls

The checksum rule was obvious as soon as I got the IR file from diagnosis. I think you misled yourself by the way you structured that binary information.

First notice that this has the basic structure of a Kaseikyo signal. So the first two bytes ($43 and $53 when viewed in the proper LSB form) are the manufacturer numbers. Thus the next nibble (1) is XOR of those four hex digits (4 ^ 3 ^ 5 ^ 3 = 1). Interestingly those five digits also add to zero modulo 16 (so I think whoever designed these may have musunderstood that aspect of Kaseikyo).

Look at the 5 "data" nibbles (0, 4, 0, 1, 7) in the signal for '1'. Now look at the last two nibbles as a byte (rather than as seperate nibbles). The value 0C of that byte is the sum of the 5 data nibbles. That same rule holds for all these learned signals.

Within the 5 data nibbles, I don't know what the first three are, since they are always 0,4,0. In other Kaseikyo forms we treat that 4,0 in LSB sequence as a subdevice. The first data nibble is treated elsewhere as a device number (though in Panasonic we multiply it by 16 to treat it as a device number). The last two data bytes (1,7) are taken in LSB sequence as the OBC byte $71 = 113.

I'll add this shortly to DecodeIR.dll (it's a very tiny change to the existing Kaseikyo code).

What should I call it?

Do we think Teac is the main or only brand associated with the $43 $53 manufacturer numbers?

I think it might be a good idea to start adding "-K" to the end of protocol names that represent unusual forms of Kaseikyo, so maybe this should be "Teac-K".

So far I've seen signals from only one manufacturer that follows the Kasiekyo checksum rules exactly as I understand them from the Kaseikyo specification (plus JVC and Panasonic follow a stricter checksum rule, which satisfies the documented rule). This one is seriously different because it uses adding rather than XORing.

I think you just defined:

{37.9k,432}<1,-1,1,-3>((8,-4,M:8,N:8,X:4,D:4,S:8,F:8,C:8,1,-100),(8,-8,1,-100)+)

where:
X=M(0..3)^M(4..7)^N(0..3)^N(4..7)
C=D+S(0..3)+S(4..7)+F(0..3)+F(4..7)


I think Teac-K and the -K suffix makes sense on the 48 bit protocols that are probably the various Asian manufacturer's interpretation of Kaseikyo.

Since as of yet we don't have any uniformity on the calculation of the second check byte, this is probably no worse than Fujitsu that has no second check byte at all.

I am sure you noticed that the main segement is sent once and it has a NEC1 like repeat frame.

jon_armstrong wrote: I am sure you noticed that the main segement is sent once and it has a NEC1 like repeat frame.

You're too polite. I totally missed that major departure from Kaseikyo. I was so impressed with the way the first 5 nibbles fit the Kaseikyo rules that I ignored all the low level details. (Either that or, go in looking for a checksum rule and I see a checksum rule and miss everything else).

johnsfine wrote:

gjarboni wrote:I'll leave it to John or Jon to figure out the rest. If they haven't answered by tomorrow then I'll decode the rest and help you create an upgrade for it.

I actually sleep on occasion.

Yeah, so do I (on occasion). I'm pretty sure you were kidding, but just in case -- I meant to say tomorrow evening (EST). I certainly wasn't trying to accuse you of slacking on your JP1 duties (you certainly do more than your share of the work here.)

In case anyone's interested in this but couldn't quite follow John's explanation, I have updated the spreadsheet to show all of the binary and the various hex codes that were mentioned, along with the calculated checksum.

http://groups.yahoo.com/group/jp1/files ... ecksum.xls

I have just downloaded the checksum spreadsheet, I will attemtp in the new few spare moments to add the other button codes from this remote..

(:

mwinters wrote:I have just downloaded the checksum spreadsheet, I will attemtp in the new few spare moments to add the other button codes from this remote..

(:

Or maybe not - how does one find the binary data as used in the spreadsheet - or should I just wait until the new decodeir.dll is out?

The simpliest way is to take the text from the learned signals tab and copy and paste it into a word processor. There do a search and replace, replacing every instance of +422 -468 (and close matches like +422 -442 or -470) with a 0 and (+392 -1198) with a 1. You should have 48 bits. The left most bit is bit 0 of the first byte, followed by bit 1 of the first byte, ...

I have just uploaded to dagnosis Teac-checksum-all-buttons.xls which has the codes for all 58 buttons. This might help in checking the decode.

Mathew..

mwinters wrote:I have just uploaded to dagnosis Teac-checksum-all-buttons.xls which has the codes for all 58 buttons. This might help in checking the decode.

Mathew..

Thanks Matt. (Note to self, we need to teach Matt how to use links)
Teac-checksum-all-buttons.xls

I have trimmed down the spreadsheet to just the info related to the hex commands for the functions. It's all generated from the OBC now.

I have also created both a regular KM upgrade for this, and a second upgrade which just contains all the "gap" OBCs. You can use this second upgrade to search for discrete codes and any other functions your device might support that are not on the remote.

Teac-mini-system-DV-D990.txt
Teac-mini-system-OBC-gaps.txt

If you find any additional functions, let me know so I can add them to the main KM file. Also, let me know how the main KM file works out.