Linux MythTV PVR w/ Nice Tracker Wireless keyboard

[jon_armstrong]

If you liked that, go unhide all the sheets in KM Master and look around

[Ironbreeze]

KM flat out impressed me the minute I opened it up, and I haven't even un-hid anything. My ability to do anything with a spreadsheet stops right about around =SUM(A1,A2) for complexity.
You guys are doing things with Excel that I had no idea was possible, so I'll leave any spreadsheet work up to yall (yeah, I'm a southerner). Now on the other hand, if you ever come across a need for a spreadsheet to add two cells together and display the results in a third cell, I'm your man.

[The Robman]

KM flat out impressed me the minute I opened it up, and I haven't even un-hid anything.

If you do start unhiding stuff, start with the EFCw sheet!

...if you ever come across a need for a spreadsheet to add two cells together and display the results in a third cell, I'm your man.

We'll keep that in mind!

Now, if you could write a spreadsheet that would look for things like the formula you spotted for this keyboard, please step forward! I'd still love to know what to look for to spot checksums that use ADD.

[Ironbreeze]

I skipped explaining how I figured out the formula, because quite frankly I didn't think anyone would really care. But I'll run through it since it very well may help you or someone else here be able to spot another one in the future. And you may be able to incorporate some of the methodology <sp?> in a spreadsheet, or some other automated method. Of course I don't think it would be possible to automate all of it, but maybe some of it none the less.
ok here goes...
The first thing was to order and group the samples by the validation code to see if a pattern was obvious. And keep in mind this is prior to realizing this was a LSB first format, so it wasn't truly in order, but still helps.

Code: Select all

0000 0000 0000 

0001 0001 0001      *
0101 0110 0001	

0010 0010 0010      * 
0110 0100 0010
	
0000 1001 0011		
0111 0101 0011	
0011 0011 0011      *

0000 0010 0100
0110 1111 0100
0100 0100 0100      *
0010 0000 0100	
0100 1100 0101	
0101 0101 0101      *
0011 0001 0101	
0101 0101 0101      *

0100 0000 1000
0000 0100 1000
	
0001 0101 1001
0100 1000 1001	
0101 0001 1001
0011 0110 1001	

0110 0010 1010	
	
0000 1101 1011	
0111 0011 1011	

0110 0000 1100	
0010 0100 1100	
0111 1010 1100	

0000 1111 1111	

The ones I put an asterisk by stuck out because if A=B then C=A (C being the validation nibble). Which meant that an AND was probably being used. But AND alone didn't work for all of the samples, so we needed something else. XOR would be a perfect candidate because whatever we had left to do couldn't interfere with the AND of the situations where A=B. And of course when you XOR a number by itself it always comes out 0 which we could ADD, SUB, OR, or AND and it wouldn't change those results that we already have working. So to test this I grabbed some samples who's AND came out 0, and therefore probably wouldn't impact the XOR results.

Code: Select all

A    B    C        A XOR B 
0000 1001 0011     1001
0000 0010 0100     0010 
0010 0000 0100     0010
 
0100 0000 1000     0100 
0000 0100 1000     0100

0100 1000 1001     1100 

0000 1101 1011     1101

0110 0000 1100     0110
0010 0100 1100     0110

0000 1111 1111     1111

Well that was a definate pattern, and from there we can see that the XOR results just need to be ROL by 1 bit. Now we just needed to figure out how these two results (the AND and the XOR) are combined when neither are 0.
I tried the obvious of AND,XOR,OR,ADD etc but none yeilded the correct results.
So the first thing I did was take the right most bit of the AND and XOR results to see what the different combinations would yield,
if it was
0 0 = 0
0 1 = 1
1 0 = 1
1 1 = 1
then its probably an OR;
if its
0 0 = 0
0 1 = 0
1 0 = 0
1 1 = 1
then an AND;
if
0 0 = 0
0 1 = 1
1 0 = 1
1 1 = 0
then probably an ADD, etc
But this is where the confusion set in, none of the bit combinations resulted in a recognizable pattern. So that lead me to reason that there was interference from another column by (most likely) a carry bit. And since ADD causes carry bits (actually so does SUB, MUL, DIV but hopefully you wont have to deal with these very often). Now the only way a carry bit can effect the right most bit is if this is in LSB-MSB order. Which ended up being that missing link, so then when I did the ADD as a LSB-MSB the results came out right (except the one I screwed up ).
So if you want to incorporate some of this in an automated way, I'd suggest checking for a known combination on the right most bit (which shouldn't be effected by any other column in a MSB-LSB number) and if that doesn't yeild one of the known combinations try using the left most bit which won't be effected in a LSB-MSB situation.
Since there is virtually an unlimited amount of things you can do to 2 set of numbers to get a result set, testing all possibilities would be impossible. But luckily since the remote guys are limited by memory and clock cycles, they'll keep it to these simple operations.
I hope some of this helps you come up with a few ideas to implement. Even if not, I enjoyed reminiscing about the day I actually figured something out.


I'm off for the day,
so have a good one.
IB

[The Robman]

I tried creating a custom protocol to generate the complicated checksum for this keyboard, but I couldn't get it to work correctly. The signal generated was all 1's. I ran out of time to dig into this any further, so I've posted my files in the Diagnosis Area in case anyone else wants to take a look: keyboard.zip

[Ironbreeze]

I haven't had time to look at it much (been very busy here today). But I gather that you're using the right bit of the command to represent the make/break bit, and dropping the left bit to make room for it. Might as well, it appears to always be 0 anyway. But the code doesn't seem to right shift the command back into it's correct place and appending the 0 to the left before doing the calculations on it.

Code: Select all

start:	LD	RC0,R04		; save command in RC0
	LD	RC1,RC0		; save command in RC1
	LD	RC6,RC0		; save command in RC6 (just need LSB)
	SWAP	RC1		; swap nibbles in RC1

should be...

Code: Select all

start:	LD	RC0,R04		; save command in RC0
	LD	RC6,RC0		; save command in RC6 (just need LSB)

                RCF                                           ;set carry to 0
                RRC	RC0                           ;shift the make bit off 

	LD	RC1,RC0		; save command in RC1

	SWAP	RC1		; swap nibbles in RC1

also since the bits haven't been reversed at the point of the rr of the xor result...

Code: Select all

	XOR	RC0,RC1		; XOR RC1 into RC0
	RR	RC0		; rotate result right 1 bit
	AND	RC2,RC3		; AND RC2 and 3 together

I think that it should be...

Code: Select all

	XOR	RC0,RC1		; XOR RC1 into RC0
	RL	RC0		; rotate result left 1 bit
	AND	RC2,RC3		; AND RC2 and 3 together

I may be completely wrong, I have no way to test these changes, not to mention my understanding of what your doing may be way off.

ps. That reverse sub is a work of a pure genius. I would never have believed that bits could be reversed with so few opcode bytes.

Anyway, hopefully this helps
IB

[The Robman]

I haven't had time to look at it much (been very busy here today). But I gather that you're using the right bit of the command to represent the make/break bit, and dropping the left bit to make room for it. Might as well, it appears to always be 0 anyway. But the code doesn't seem to right shift the command back into it's correct place and appending the 0 to the left before doing the calculations on it.

Actually, here's how I was trying to do it. Rather than define the signal as using a 5-bit device, 8-bit command and 4-bit checksum, I set it up as 5-bit device, 7-bit function and 5-bit checksum. So once control is passed to the engine, it will only take the 7 leftmost bits from the command (R04) and ignore the right bit. It will get the rightmost command bit from the first bit of the checksum, which I do make sure is the right value.

The reason I did it like this was so that I could use one XOR to set up the BREAK signal.

However, now that I'm re-thinking it, I realize that I do need to clear that bit before I load R04 into the registers that I'm using to calculate the checksum. I just updated the zip file with a new version of the code that does clear the make/break bit.

At any rate, I think there is a problem bigger than whether my code calculates the correct checksum because I'm seeing all 1's regardless of what device and command codes I use. My next move (when time permits) is to try Jon's original 2-byte upgrade to see if that works, as that's what my code is based on.

ps. That reverse sub is a work of a pure genius. I would never have believed that bits could be reversed with so few opcode bytes.

Why, thank you sir!