| View previous topic :: View next topic |
| Author |
Message |
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
 Posted: Tue Jan 06, 2004 8:52 am Post subject: |
 |
|
| 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. |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
|
| Back to top |
|
|
mwinters
Joined: 03 Jan 2004
Posts: 17
|
| Posted: Tue Jan 06, 2004 4:37 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Jan 06, 2004 5:23 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Jan 06, 2004 5:39 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
jon_armstrong
Expert
Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005
|
| Posted: Tue Jan 06, 2004 6:16 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Tue Jan 06, 2004 6:42 pm Post subject: |
|
|
| 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). |
|
| Back to top |
|
|
gjarboni
Expert
Joined: 20 Sep 2003
Posts: 294
Location: Columbia, MD
|
| Posted: Tue Jan 06, 2004 6:50 pm Post subject: |
|
|
| 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.) |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Tue Jan 06, 2004 8:42 pm Post subject: |
|
|
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/Diagnosis%20Area/Teac-checksum.xls
_________________
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 |
|
|
mwinters
Joined: 03 Jan 2004
Posts: 17
|
| Posted: Tue Jan 06, 2004 9:55 pm Post subject: |
|
|
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..
(: |
|
| Back to top |
|
|
mwinters
Joined: 03 Jan 2004
Posts: 17
|
| Posted: Tue Jan 06, 2004 10:11 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
gjarboni
Expert
Joined: 20 Sep 2003
Posts: 294
Location: Columbia, MD
|
| Posted: Tue Jan 06, 2004 10:44 pm Post subject: |
|
|
| 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, ... |
|
| Back to top |
|
|
mwinters
Joined: 03 Jan 2004
Posts: 17
|
| Posted: Wed Jan 07, 2004 3:49 am Post subject: |
|
|
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.. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Wed Jan 07, 2004 9:22 am Post subject: |
|
|
| 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
_________________
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 Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Wed Jan 07, 2004 1:17 pm Post subject: |
|
|
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.
_________________
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 |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
